{"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: breve corso introduttivo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Formati
\nDivinit\u00e0 del Meteo 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 della compagnia Clairvoyant su quali formati di file esistano nei big data, quali siano le funzioni pi\u00f9 comuni dei formati Hadoop e quale formato sia migliore da utilizzare.
\n<\/a><\/noindex><\/p>\n

Perch\u00e9 servono 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 sono aggravati dalle difficolt\u00e0 nella gestione di grandi set di dati, se abbiamo uno schema che non \u00e8 fisso, ma evolutivo, o ci sono alcune limitazioni nello stoccaggio.<\/p>\n

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

Diversi formati di file in Hadoop<\/a><\/noindex> sono stati pensati per affrontare proprio questi problemi. La scelta del formato di file appropriato pu\u00f2 portare a vantaggi significativi:<\/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 avanzato per la compressione.<\/li>\n<\/ol>\n

    \nAlcuni formati di file sono progettati per un uso generale, altri per varianti pi\u00f9 specifiche e alcuni sono stati sviluppati tenendo conto delle caratteristiche specifiche dei dati. Quindi, la scelta \u00e8 davvero ampia.<\/p>\n

    Formato file Avro<\/h2>\n

    \nPer serializzazione dei dati <\/i>\u00e8 ampiamente utilizzato da Avro: questo \u00e8 un formato di archiviazione dei dati basato su righe<\/i>, cio\u00e8 a righe, nel Hadoop. Memorizza lo schema in formato JSON, facilitandone 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 neutrale rispetto al linguaggio. I file possono essere elaborati in vari linguaggi, attualmente sono C, C++, C#, Java, Python e Ruby.<\/p>\n

    Una caratteristica chiave di Avro \u00e8 il supporto affidabile per gli schemi di dati che cambiano nel tempo, cio\u00e8 evolvono. Avro comprende le modifiche allo schema: rimozione, aggiunta o modifica dei campi.<\/p>\n

    Avro supporta diverse strutture di dati. Ad esempio, \u00e8 possibile creare un record che contiene un array, un tipo enumerabile e un sottoregistro.<\/p>\n

    \"Formati
    \nQuesto formato \u00e8 perfetto per la scrittura nella zona di atterraggio (transitoria) di un lago dati (    lago di dati<\/a><\/noindex>, o data lake\u2014una collezione di istanze per la memorizzazione di vari tipi di dati in aggiunta alle fonti di dati dirette). <\/p>\n

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

      \n
    1. I dati di questa zona vengono generalmente letti per intero per ulteriori elaborazioni da parte dei sistemi sottostanti, e il formato basato su righe \u00e8 pi\u00f9 efficiente in questo caso.<\/li>\n
    2. I sistemi sottostanti possono facilmente estrarre le tabelle degli schemi dai file\u2014non \u00e8 necessario memorizzare gli schemi separatamente in un meta-magazzino esterno.<\/li>\n
    3. Qualsiasi modifica allo schema di origine viene elaborata facilmente (evoluzione dello schema).<\/li>\n<\/ol>\n

      <\/p>\n

      Formato file Parquet<\/h2>\n

      \nParquet \u00e8 un formato di file open-source per Hadoop che memorizza strutture di dati nidificate in un formato colonnare piatto<\/i>.<\/p>\n

      Rispetto all'approccio tradizionale basato su righe, Parquet \u00e8 pi\u00f9 efficiente dal punto di vista della memorizzazione e delle prestazioni.<\/p>\n

      Questo \u00e8 particolarmente utile per le query che leggono colonne specifiche da una tabella ampia (con molte colonne). Grazie al formato dei file, vengono letti solo le colonne necessarie, riducendo al minimo le operazioni di input\/output.<\/p>\n

      Una piccola digressione-spiegazione<\/strong>: per comprendere meglio il formato dei file Parquet in Hadoop, diamo un'occhiata a cosa significa un formato basato su colonne\u2014cio\u00e8 colonnare. In questo formato, vengono memorizzati insieme valori dello stesso tipo per ogni colonna. <\/p>\n

      Ad esempio<\/a><\/noindex>, la registrazione include i campi ID, Nome e Dipartimento. In questo caso, tutti i valori della colonna ID saranno memorizzati insieme, cos\u00ec come i valori della colonna Nome e cos\u00ec via. La tabella avr\u00e0 un aspetto simile a questo:<\/p>\n

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

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

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

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

      \nIn formato righe, i dati verranno memorizzati nel seguente modo:<\/p>\n

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

      \nIn formato colonnare, gli stessi dati verranno memorizzati in questo modo:<\/p>\n

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

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

      Ad esempio, ti serve solo la colonna NOME. In formato righe<\/a><\/noindex> ogni registrazione nel set di dati deve essere caricata, analizzata in campi e poi estratti i dati NOME. Il formato colonnare consente di accedere direttamente alla colonna Nome, poich\u00e9 tutti i valori per quella colonna sono memorizzati insieme. Non sar\u00e0 necessario scansionare l'intera registrazione.<\/p>\n

      In questo modo, il formato colonnare migliora l'efficienza delle query, poich\u00e9 ci vuole meno tempo per cercare le colonne richieste e si riduce il numero di operazioni di input\/output, poich\u00e9 vengono letti solo i 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 anche i campi annidati possono essere letti separatamente senza dover leggere tutti i campi nella struttura annidata. Per memorizzare strutture annidate, Parquet utilizza un 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 gruppo di righe specifico e saranno necessariamente adiacenti nel file.<\/li>\n
      3. Pagina<\/strong> (page): i frammenti di colonna sono suddivisi in pagine, scritte una dopo l'altra. Le pagine hanno un'intestazione comune, quindi alla lettura \u00e8 possibile saltare quelle 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 file del formato Parquet.<\/p>\n

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

          \n
        1. Metadati del file, che contengono le coordinate iniziali dei metadati di ogni colonna. Durante la lettura, \u00e8 necessario prima leggere i metadati del file per individuare tutti i frammenti di colonna di interesse. I frammenti di colonna devono quindi essere letti in sequenza. I metadati includono anche 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

          Il formato file ORC<\/h2>\n

          \nFormato file colonnare ottimizzato<\/i> (Optimized Row Columnar, ORC<\/a><\/noindex>) offre un modo molto efficace per memorizzare i dati ed \u00e8 stato sviluppato per superare le limitazioni di altri formati. Memorizza i dati in una forma idealmente compatta, consentendo di saltare dettagli non necessari \u2014 senza richiedere la costruzione di indici grandi, complessi o gestiti manualmente. <\/p>\n

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

            \n
          1. Un file all'uscita di ogni task, il che riduce il carico sul NameNode.<\/li>\n
          2. Supporto ai tipi di dati Hive, compresi DateTime, tipi decimali e tipi complessi (struct, list, map e union).<\/li>\n
          3. Lettura simultanea dello stesso file da diversi processi RecordReader.<\/li>\n
          4. Possibilit\u00e0 di dividere i file senza scansionare per la presenza di marcatori.<\/li>\n
          5. Valutazione della massima allocazione possibile della memoria heap per i processi di lettura\/scrittura in base alle informazioni nel footer del file.<\/li>\n
          6. I metadati vengono salvati in un 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, mentre all'interno della collezione i dati delle righe sono memorizzati in formato colonnare.<\/p>\n

            Il file ORC memorizza gruppi di righe, chiamati strisce (stripes), e informazioni accessorie nel footer del file. Il postscript alla fine del file contiene parametri di compressione e dimensione del footer compresso.<\/p>\n

            Per impostazione predefinita, la dimensione della striscia \u00e8 di 250 MB. Grazie a strisce di tale grandezza, la lettura da HDFS \u00e8 pi\u00f9 efficiente: in blocchi grandi e continui.<\/p>\n

            Nel footer del file \u00e8 registrata una lista delle strisce nel file, il numero di righe per striscia e il tipo di dati di ogni colonna. \u00c8 anche registrato il valore risultante di count, min, max e sum per ogni colonna.<\/p>\n

            Il footer della striscia contiene un catalogo delle posizioni dello stream.<\/p>\n

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

            I dati degli indici includono i valori minimi e massimi per ogni colonna e le posizioni delle righe in ogni colonna. Gli indici ORC vengono utilizzati solo per selezionare le strisce e i gruppi di righe, non per rispondere alle 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 archiviazione a righe, mentre Parquet memorizza i dati a colonne.<\/li>\n
            2. Parquet \u00e8 pi\u00f9 adatto per le query analitiche, ovvero 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 meglio l'evoluzione degli schemi. Parquet supporta solo l'aggiunta di schemi, mentre Avro implementa un'evoluzione multifunzionale, cio\u00e8 l'aggiunta o la modifica di colonne.<\/li>\n
            5. Parquet \u00e8 ideale per la richiesta di sottoinsiemi di colonne in una tabella multicolonna. 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

                \nCosa leggere ancora 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 basilare ai modelli di 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 di file nei big data: breve introduzione | 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}]}}