{"id":84416,"date":"2020-06-07T13:42:50","date_gmt":"2020-06-07T11:42:50","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez"},"modified":"2020-06-07T13:42:50","modified_gmt":"2020-06-07T11:42:50","slug":"formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","title":{"rendered":"Formati di file nei Big Data: una breve introduzione","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Formati
\nDeit\u00e0 del Tempo di Remarin<\/i><\/a><\/noindex> <\/p>\n

Team Mail.ru Cloud Solutions<\/a><\/noindex> offre la traduzione di un articolo<\/a><\/noindex> ingegnere Rahul Bhatia di Clairvoyant sui diversi formati di file nei big data, le funzioni pi\u00f9 comuni dei formati Hadoop e quale formato sia meglio utilizzare.
\n<\/a><\/noindex><\/p>\n

Perch\u00e9 sono necessari diversi formati di file<\/h2>\n

\nUn serio collo di bottiglia nelle prestazioni delle applicazioni che supportano HDFS, come MapReduce e Spark, \u00e8 il tempo di ricerca, lettura e scrittura dei dati. Questi problemi si complicano ulteriormente dalla gestione di grandi set di dati, specialmente se abbiamo uno schema evolutivo piuttosto che fisso, o se ci sono limitazioni nella memorizzazione.<\/p>\n

L'elaborazione dei big data aumenta il carico sul sottosistema di memorizzazione: Hadoop memorizza i dati in modo ridondante per garantire la resilienza. Oltre ai dischi, sono sotto pressione anche il processore, la rete, il sistema di input\/output e cos\u00ec via. Con l'aumento del volume dei dati, aumentano anche i costi di elaborazione e memorizzazione.<\/p>\n

Diverse formati di file in Hadoop<\/a><\/noindex> sono stati ideati per affrontare proprio questi problemi. Scegliere il formato di file giusto pu\u00f2 portare a vantaggi sostanziali:<\/p>\n

    \n
  1. Tempi di lettura pi\u00f9 rapidi.<\/li>\n
  2. Tempi di scrittura pi\u00f9 rapidi.<\/li>\n
  3. File condivisibili.<\/li>\n
  4. Supporto per l'evoluzione degli schemi.<\/li>\n
  5. Supporto esteso per la compressione.<\/li>\n<\/ol>\n

    \nAlcuni formati di file sono destinati a usi generali, altri a opzioni pi\u00f9 specifiche, e alcuni sono progettati per caratteristiche di dati specifiche. Quindi, la scelta \u00e8 davvero piuttosto ampia.<\/p>\n

    Formato file Avro<\/h2>\n

    \nPer serializzazione dei dati <\/i>Avro \u00e8 ampiamente utilizzato \u2014 \u00e8 un formato di archiviazione dei dati basato su righe<\/i>, ovvero basato su stringhe, in Hadoop. Memorizza lo schema in formato JSON, facilitando la lettura e l'interpretazione da parte di qualsiasi programma. I dati stessi sono memorizzati in formato binario, in modo compatto ed efficiente.<\/p>\n

    Il sistema di serializzazione Avro \u00e8 neutro rispetto al linguaggio. I file possono essere elaborati in diversi linguaggi, attualmente C, C++, C#, Java, Python e Ruby.<\/p>\n

    Una caratteristica chiave di Avro \u00e8 il supporto robusto per gli schemi di dati che cambiano nel tempo, ovvero evolvono. Avro comprende le modifiche dello schema \u2014 eliminazione, aggiunta o modifica dei campi.<\/p>\n

    Avro supporta una variet\u00e0 di strutture dati. Ad esempio, \u00e8 possibile creare un record che contiene un array, un tipo enumerativo e un sotto-record.<\/p>\n

    \"Formati
    \nQuesto formato \u00e8 ideale per la registrazione nella zona di ingresso del lago dati (    lago dati<\/a><\/noindex>, o data lake \u2014 una collezione di istanze per la memorizzazione di vari tipi di dati in aggiunta alle fonti di dati). <\/p>\n

    Quindi, per la registrazione nella zona di ingresso del lago dati, questo formato \u00e8 il pi\u00f9 adatto per i seguenti motivi:<\/p>\n

      \n
    1. I dati in questa zona vengono generalmente letti per intero per ulteriore elaborazione da parte dei sistemi sottostanti \u2014 e un formato basato su righe in questo caso \u00e8 pi\u00f9 efficiente.<\/li>\n
    2. I sistemi sottostanti possono facilmente estrarre le tabelle di schema dai file \u2014 non \u00e8 necessario conservare gli schemi separatamente in un meta-storage esterno.<\/li>\n
    3. Qualsiasi cambiamento nello schema originale viene elaborato facilmente (evoluzione dello schema).<\/li>\n<\/ol>\n

      <\/p>\n

      Il formato file Parquet<\/h2>\n

      \nParquet \u00e8 un formato file open source per Hadoop che memorizza strutture dati annidate in formato flat columnar<\/i>.<\/p>\n

      Rispetto all'approccio tradizionale basato su righe, Parquet \u00e8 pi\u00f9 efficiente in termini di spazio e prestazioni.<\/p>\n

      Questo \u00e8 particolarmente utile per le query che leggono determinate colonne da una tabella ampia (con molte colonne). Grazie a questo formato, vengono letti solo i colonne necessari, riducendo al minimo l'input e l'output.<\/p>\n

      Una piccola digressione esplicativa<\/strong>: per capire meglio il formato del file Parquet in Hadoop, vediamo cos'\u00e8 un formato basato su colonne, ovvero un formato colonne. In questo tipo di formato, i valori simili di ogni colonna vengono memorizzati insieme. <\/p>\n

      Ad esempio<\/a><\/noindex>, la registrazione comprende i campi ID, Name e Department. In questo caso, tutti i valori della colonna ID saranno memorizzati insieme, cos\u00ec come i valori della colonna Name e cos\u00ec via. La tabella avr\u00e0 all'incirca questo aspetto:<\/p>\n

      ID<\/strong>
      \nName<\/strong>
      \nDepartment<\/strong><\/p>\n

      1
      \nemp1
      \nd1<\/p>\n

      2
      \nemp2
      \nd2<\/p>\n

      3
      \nemp3
      \nd3<\/p>\n

      \nNel formato a righe, i dati saranno memorizzati nel seguente modo:<\/p>\n

      1
      \nemp1
      \nd1
      \n2
      \nemp2
      \nd2
      \n3
      \nemp3
      \nd3<\/p>\n

      \nNel formato a colonne, gli stessi dati saranno memorizzati in questo modo:<\/p>\n

      1
      \n2
      \n3
      \nemp1
      \nemp2
      \nemp3
      \nd1
      \nd2
      \nd3<\/p>\n

      \nIl formato colonne \u00e8 pi\u00f9 efficiente quando \u00e8 necessario interrogare pi\u00f9 colonne da una tabella. Legger\u00e0 solo le colonne necessarie, poich\u00e9 sono vicine. In questo modo, le operazioni di input e output sono ridotte al minimo.<\/p>\n

      Ad esempio, hai bisogno solo della colonna NAME. In formato a righe<\/a><\/noindex> \u00e8 necessario caricare ogni record nel set di dati, analizzarlo nei campi e poi estrarre i dati NAME. Il formato colonnare consente di accedere direttamente alla colonna Name, poich\u00e9 tutti i valori per questa colonna sono memorizzati insieme. Non \u00e8 necessario scandagliare l'intero record.<\/p>\n

      In questo modo, il formato colonnare migliora le prestazioni delle query, poich\u00e9 \u00e8 richiesto meno tempo di ricerca per accedere alle colonne richieste e si riducono le operazioni di input\/output, poich\u00e9 si leggono solo le colonne necessarie.<\/p>\n

      Una delle caratteristiche uniche Parquet<\/a><\/noindex> \u00e8 che in questo formato pu\u00f2 memorizzare dati con strutture annidate<\/i>. Ci\u00f2 significa che nel file Parquet \u00e8 possibile leggere anche i campi annidati singolarmente senza dover leggere tutti i campi nella struttura annidate. Per memorizzare strutture annidate, Parquet utilizza l'algoritmo di frantumazione e assemblaggio.<\/p>\n

      \"Formati
      \nPer comprendere il formato del file Parquet in Hadoop, \u00e8 necessario conoscere i seguenti termini:<\/p>\n

        \n
      1. Gruppo di righe<\/strong> (row group): partizione logica orizzontale dei dati in righe. Un gruppo di righe \u00e8 composto da un frammento di ogni colonna nel set di dati.<\/li>\n
      2. Frammento di colonna<\/strong> (column chunk): frammento di una specifica colonna. Questi frammenti di colonna vivono in un certo gruppo di righe e saranno sicuramente contigui nel file.<\/li>\n
      3. Pagina<\/strong> (page): i frammenti di colonna sono suddivisi in pagine, registrate una dopo l'altra. Le pagine condividono un'intestazione comune, quindi durante la lettura \u00e8 possibile saltare parti non necessarie.<\/li>\n<\/ol>\n

        \n\"Formati
        \nQui l'intestazione contiene semplicemente un numero magico PAR1<\/i> (4 byte), che identifica il file come un file del formato Parquet.<\/p>\n

        Nel footer \u00e8 scritto quanto segue:<\/p>\n

          \n
        1. Metadati del file, che contengono le coordinate di partenza dei metadati di ciascuna colonna. Durante la lettura, \u00e8 necessario prima leggere i metadati del file per trovare tutti i frammenti di colonna di interesse. Successivamente, i frammenti di colonna devono essere letti in sequenza. Inoltre, i metadati includono la versione del formato, lo schema e eventuali coppie chiave-valore aggiuntive.<\/li>\n
        2. Lunghezza dei metadati (4 byte).<\/li>\n
        3. Numero magico PAR1<\/i> (4 byte).<\/li>\n<\/ol>\n

          <\/p>\n

          Formato file ORC<\/h2>\n

          \nFormato file a colonne ottimizzato<\/i> (Optimized Row Columnar, ORC<\/a><\/noindex>) offre un modo molto efficiente di archiviazione dei dati ed \u00e8 stato progettato per superare le limitazioni di altri formati. Memorizza i dati in una forma perfettamente compatta, consentendo di omettere dettagli non necessari, senza richiedere la costruzione di indici complessi o di difficile manutenzione. <\/p>\n

          Vantaggi del formato ORC:<\/p>\n

            \n
          1. Un file in uscita per ogni attivit\u00e0, il che riduce il carico sul NameNode (nodo dei nomi).<\/li>\n
          2. Supporto per i tipi di dati Hive, inclusi DateTime, numeri decimali e tipi di dati complessi (struct, list, map e union).<\/li>\n
          3. Lettura simultanea dello stesso file da parte di diversi processi RecordReader.<\/li>\n
          4. Possibilit\u00e0 di dividere i file senza scansionare alla ricerca di marcatori.<\/li>\n
          5. Valutazione della massima allocazione di memoria heap per i processi di lettura\/scrittura basata sulle informazioni nel footer del file.<\/li>\n
          6. I metadati sono memorizzati in formato binario di serializzazione Protocol Buffers, che consente di aggiungere e rimuovere campi.<\/li>\n<\/ol>\n

            \n\"Formati
            \nORC memorizza collezioni di righe in un unico file, e all'interno della collezione i dati di riga sono archiviati in formato colonnare.<\/p>\n

            Il file ORC contiene gruppi di righe chiamate stripe e informazioni ausiliarie nel footer del file. Il postscript alla fine del file include parametri di compressione e la dimensione del footer compresso.<\/p>\n

            Per impostazione predefinita, la dimensione delle stripe \u00e8 di 250 MB. Grazie a stripe di tali grandi dimensioni, la lettura da HDFS avviene in modo molto pi\u00f9 efficiente: in blocchi continui di grande dimensione.<\/p>\n

            Nel footer del file \u00e8 registrata una lista delle stripe nel file, il numero di righe per stripe e il tipo di dati di ciascuna colonna. Sono riportati anche i valori risultanti di count, min, max e sum per ciascuna colonna.<\/p>\n

            Il footer della stripe contiene un catalogo delle posizioni delle righe.<\/p>\n

            I dati riga vengono utilizzati durante la scansione delle tabelle.<\/p>\n

            I dati di indice includono i valori minimi e massimi per ogni colonna e le posizioni delle righe in ciascuna colonna. Gli indici ORC vengono utilizzati solo per selezionare le stripe e i gruppi di righe, non per rispondere a query.<\/p>\n

            Confronto tra diversi formati di file<\/h2>\n

            <\/p>\n

            Avro rispetto a Parquet<\/h3>\n

            <\/p>\n

              \n
            1. Avro \u00e8 un formato di memorizzazione a righe, mentre Parquet memorizza i dati a colonne.<\/li>\n
            2. Parquet \u00e8 pi\u00f9 adatto per le query analitiche, cio\u00e8 le operazioni di lettura e richiesta di dati sono molto pi\u00f9 efficienti rispetto alla scrittura.<\/li>\n
            3. Le operazioni di scrittura in Avro sono pi\u00f9 efficienti rispetto a quelle in Parquet.<\/li>\n
            4. Avro gestisce in modo pi\u00f9 maturo l'evoluzione degli schemi. Parquet supporta solo l'aggiunta di schemi, mentre Avro implementa un'evoluzione multifunzionale, che consente l'aggiunta o la modifica delle colonne.<\/li>\n
            5. Parquet \u00e8 ideale per interrogare sottoinsiemi di colonne in una tabella a pi\u00f9 colonne. Avro \u00e8 adatto per operazioni ETL, dove richiediamo tutte le colonne.<\/li>\n<\/ol>\n

              <\/p>\n

              ORC rispetto a Parquet<\/h3>\n

              <\/p>\n

                \n
              1. Parquet gestisce meglio i dati nidificati.<\/li>\n
              2. ORC \u00e8 meglio adattato per il pushdown dei predicati.<\/li>\n
              3. ORC supporta le propriet\u00e0 ACID.<\/li>\n
              4. ORC comprime meglio i dati.<\/li>\n<\/ol>\n

                \nUlteriori letture sull'argomento<\/strong>:<\/p>\n

                  \n
                1. Analisi dei big data nel cloud: come le aziende possono diventare data-driven<\/a><\/noindex>.<\/li>\n
                2. Guida pratica agli schemi dei database<\/a><\/noindex>.<\/li>\n
                3. Il nostro canale Telegram sulla trasformazione digitale<\/a><\/noindex>. \n<\/li>\n<\/ol>\n

                  Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

                  Weather Deity by Remarin \u041a\u043e\u043c\u0430\u043d\u0434\u0430 Mail.ru Cloud Solutions \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u0442 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430 \u0420\u0430\u0445\u0443\u043b\u0430 \u0411\u0445\u0430\u0442\u0438\u0438 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Clairvoyant \u043e \u0442\u043e\u043c, \u043a\u0430\u043a\u0438\u0435 \u0435\u0441\u0442\u044c \u0444\u043e\u0440\u043c\u0430\u0442\u044b \u0444\u0430\u0439\u043b\u043e\u0432 \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u0434\u0430\u043d\u043d\u044b\u0445, \u043a\u0430\u043a\u0438\u0435 \u0441\u0430\u043c\u044b\u0435 \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u043d\u044b\u0435 \u0444\u0443\u043d\u043a\u0446\u0438\u0438 \u0444\u043e\u0440\u043c\u0430\u0442\u043e\u0432 Hadoop \u0438 \u043a\u0430\u043a\u043e\u0439 \u0444\u043e\u0440\u043c\u0430\u0442 \u043b\u0443\u0447\u0448\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c. \u0417\u0430\u0447\u0435\u043c \u043d\u0443\u0436\u043d\u044b \u0440\u0430\u0437\u043d\u044b\u0435 \u0444\u043e\u0440\u043c\u0430\u0442\u044b \u0444\u0430\u0439\u043b\u043e\u0432 \u0421\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435 \u0443\u0437\u043a\u043e\u0435 \u043c\u0435\u0441\u0442\u043e \u0432 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 HDFS, \u0442\u0430\u043a\u0438\u0445 \u043a\u0430\u043a MapReduce \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84417,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84416","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Formati dei file nei big data: breve guida | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0424\u043e\u0440\u043c\u0430\u0442\u044b \u0444\u0430\u0439\u043b\u043e\u0432 \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u0434\u0430\u043d\u043d\u044b\u0445: \u043a\u0440\u0430\u0442\u043a\u0438\u0439 \u043b\u0438\u043a\u0431\u0435\u0437 | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-07T11:42:50+00:00","article:modified_time":"2020-06-07T11:42:50+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84416","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:58:40","updated":"2022-09-28 08:24:46","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84416","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=84416"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84416\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/84417"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=84416"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=84416"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=84416"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}