În procesarea datelor, există diferite tipuri de formate de fișiere pentru a vă stoca seturile de date. Fiecare format are propriile sale avantaje și dezavantaje, în funcție de cazurile de utilizare și există pentru a servi unuia sau mai multor scopuri. Este important să cunoașteți și să le folosiți specificul atunci când alegeți un anumit tip de format.

Unele formate sunt mai relevante pentru anumite utilizări sau tratamente, cum ar fi Business Intelligence, comunicare în rețea, aplicație web, procesare în loturi sau fluxuri. De exemplu, formatul CSV este foarte ușor de înțeles și, în timp ce toată lumea îi critică lipsa de formalism, este încă utilizat pe scară largă. În cazul comunicării web, JSON este privilegiat și acoperă cea mai mare parte a comunicării mondiale, chiar dacă, în unele cazuri, XML ar putea face aceeași activitate. Cel mai recent format beneficiază de un ecosistem mare de instrumente și este utilizat pe scară largă în lumea întreprinderilor. În ceea ce privește procesarea în flux, AVRO și Protocol Buffers sunt formate privilegiate. În plus, tampoanele de protocol reprezintă baza „gRPC” (RPC înseamnă Remote Procedure Call) pe care se bazează ecosistemul „Kubernetes”. În cele din urmă, stocarea pe coloană oferită de ORC și Parquet oferă o creștere semnificativă a performanței în analiza datelor.

Considerent de luat în considerare pentru alegerea unui format de fișier

Cele mai populare și reprezentative formate de fișiere sunt descrise cu diferitele considerații de care trebuie să țineți cont atunci când alegeți un format în detrimentul altuia. Dar mai întâi, să trecem în revistă principalele lor caracteristici în ceea ce privește stocarea, tipurile de interogări, utilizări în lot versus streaming, ...

Text versus binar

Formatele de fișiere bazate pe text sunt mai ușor de utilizat. Acestea pot fi citite de utilizatorul final care poate modifica și conținutul fișierului cu un editor de text. Aceste formate sunt de obicei comprimate pentru a reduce amprenta lor de stocare. Formatele de fișiere binare necesită crearea și consumarea unui instrument sau a unei biblioteci, dar oferă performanțe mai bune prin optimizarea serializării datelor.

Tip de date

Unele formate nu permit declararea mai multor tipuri de date. Tipurile sunt clasificate în 2 categorii. Tipurile scalare dețin o valoare „unică” (de exemplu, întreg, boolean, șir, nul, …). Tipurile complexe sunt un compus de tipuri scalare (de exemplu, matrice, obiecte, …). Declararea tipului unei valori oferă câteva avantaje. Consumatorul poate distinge, de exemplu, un număr dintr-un șir sau o valoare nulă de șirul „null”. Odată codificat în formă binară, câștigul de stocare este semnificativ. De exemplu, șirul "1234" utilizează 4 octeți de stocare, în timp ce booleanul 1234 necesită doar 2 octeți.

Aplicarea schemei

Schema poate fi asociată cu datele sau lăsată consumatorului despre care se presupune că știe și înțelege cum să interpreteze datele. Poate fi furnizat împreună cu datele sau separat. Utilizarea unei scheme garantează că setul de date este valid și oferă informații suplimentare, cum ar fi tipul și formatul unei valori. Schemele sunt, de asemenea, utilizate în formate de fișiere binare pentru a cripta și decripta conținutul.

Sprijină evoluția schemei

Schema stochează definiția fiecărui atribut și tipurile acestuia. Cu excepția cazului în care se garantează că datele dvs. nu se vor schimba niciodată (de exemplu, arhivele) sau sunt prin natura lor imuabile (de exemplu, jurnalele), va trebui să vă gândiți la evoluția schemei pentru a vă da seama dacă schema dvs. de date se schimbă în timp. Cu alte cuvinte, evoluția schemei permite actualizarea schemei utilizate pentru a scrie date noi, menținând în același timp compatibilitatea cu schema vechilor tale date.

Stocare în rânduri și coloane, OLTP versus OLAP

În stocarea pe rând, datele sunt stocate rând cu rând, astfel încât prima coloană a rândului va fi lângă ultima coloană a rândului precedent. Această arhitectură este adecvată pentru a adăuga date ușor și rapid. Este, de asemenea, potrivit în cazul în care întregul rând de date trebuie accesat sau procesat simultan. Acesta este utilizat în mod obișnuit pentru procesarea tranzacțiilor online (OLTP). Sistemele OLTP procesează de obicei interogări CRUD (Citire, Inserare, Actualizare și Ștergere) la nivel de înregistrare. Tranzacțiile OLTP sunt de obicei foarte specifice în sarcina pe care o îndeplinesc și implică de obicei o singură înregistrare sau o mică selecție de înregistrări. Accentul principal pentru sistemele OLTP este concentrarea pe menținerea integrității datelor în medii cu acces multiplu și a eficacității măsurate prin numărul de tranzacții pe secundă.

În mod invers, în stocarea pe coloană, datele sunt stocate astfel încât fiecare rând al unei coloane va fi lângă alte rânduri din aceeași coloană. Acest lucru este cel mai util atunci când se efectuează interogări de analiză care necesită doar un subset de coloane examinate pe seturi de date foarte mari. Acest mod de procesare a datelor este de obicei numit interogare „OLAP (OnLine Analytical Processing)”. OLAP este o abordare concepută pentru a răspunde rapid la întrebările de analiză care implică mai multe dimensiuni. Această abordare a jucat un rol critic în analiza business intelligence, în special în ceea ce privește Big Data. Stocarea datelor în coloană evită timpii excesivi de procesare de citire a informațiilor irelevante dintr-un set de date, ignorând toate datele care nu se aplică unei anumite interogări. De asemenea, oferă un raport de compresie mai mare prin alinierea datelor de același tip și prin optimizarea valorilor null ale coloanelor rare.

Voici un exemple pour connaître la densité de population moyenne dans les villes de plus d’un million d’habitants. Avec un stockage orienté lignes, your requête traverse chaque enregistrement de la table (c’est-à-dire tous ses champs) pour obtenir les informations nécessaires des trois colonnes pertinentes that are city name, density et population. Cela impliquerait beaucoup de recherches et de lectures de disque inutiles, ce care a un impact sur les performances. Les bases de données en colonnes optimisent le processus en réduisant la quantité de données à lire on the disk.

Splittable

Într-un sistem de fișiere distribuit precum Hadoop HDFS, este important să aveți un fișier care poate fi împărțit în mai multe bucăți. În Hadoop, sistemul de fișiere HDFS stochează datele în bucăți, iar procesarea datelor este inițial distribuită în funcție de acele bucăți. Este util să puteți începe citirea datelor în orice punct dintr-un fișier pentru a profita de toate avantajele procesării distribuite Hadoop. Când formatul de fișier nu poate fi divizat, este responsabilitatea utilizatorului să-și parționeze datele în mai multe fișiere pentru a permite paralelismul.

Compresie (Bzip2, LZO, Sappy,...)

Un sistem este lent ca componentele sale cele mai lente și, de cele mai multe ori, cele mai lente componente sunt discurile. Utilizarea compresiei reduce dimensiunea setului de date care este stocat și, prin urmare, reduce cantitatea de I/-uri citite de efectuat. De asemenea, accelerează transferurile de fișiere prin rețea. Stocarea pe coloană aduce un raport de compresie mai mare și o performanță mai bună în comparație cu stocarea pe rând, deoarece bucăți similare de date sunt stocate împreună. După cum am menționat mai devreme, este deosebit de eficient pe coloanele rare care conține mai multe valori null.

În plus, compresia se aplică în mare parte formatelor de fișiere text, cu excepția cazului în care formatul de fișier binar include compresia în definiția sa. Încercarea de a comprima un fișier binar duce adesea la un fișier generat mai greu în comparație cu originalul său. De asemenea, atunci când comparăm raportul de compresie, trebuie să punem în perspectivă și dimensiunea fișierului original. Nu ar fi un preț să comparăm raportul de compresie al JSON față de XML dacă nu luăm în considerare faptul că XML este inițial mai mare decât omologul său JSON.

Există multe tipuri de algoritmi de compresie care diferă în funcție de raportul de compresie, viteză, performanță, splittable, ...

Loturi și Streaming

Procesarea loturilor citește, analizează și transformă mai multe înregistrări simultan. În opoziție, procesarea fluxului funcționează în timp real și procesează înregistrările pe măsură ce ajung. Uneori, același set de date poate fi procesat atât în ​​flux, cât și în lot. Să luăm în considerare tranzacțiile financiare primite în interiorul unui sistem. Datele ajung în Streaming și ar putea fi procesate instantaneu pentru a detecta detectarea fraudei. În plus, odată ce datele sunt stocate, un job ar putea rula periodic în lot pentru a pregăti unele rapoarte. În acest caz, ne putem baza pe unul sau două formate de fișiere între formatul datelor care sosesc prin cablu și formatul datelor stocate în depozitul nostru de date sau Data Lake.

Ecosistem

Este adesea considerată o bună practică respectarea modului de utilizare și a culturii unui ecosistem atunci când vine vorba de alegerea între alternative multiple. De exemplu, atunci când alegeți între Parchet sau ORC cu Hive, este recomandat să folosiți primul pe platformele Cloudera și al doilea pe platformele Hortonworks. Sunt șanse ca integrarea să fie mai ușoară, iar documentația și sprijinul din partea comunității să fie de mare ajutor.

Formate de fișiere populare

CSV

CSV este un format de text care utilizează o linie nouă ca delimitator de înregistrare cu un antet opțional. Este ușor de editat manual și foarte ușor de înțeles din perspectiva umană. CSV nu acceptă evoluția schemei, chiar dacă uneori antetul este considerat opțional ca schema datelor. În forma sa complexă, nu poate fi împărțit, deoarece nu conține un caracter specific pe care să vă bazați pentru a împărți textul, rămânând în același timp relevant.

În general, în Big Data, CSV pare să fie folosit pentru procesare, dar, strict vorbind, este mai aproape de formatul TSV. „Diferentele” dintre cele două formate sunt subtile.

Formatul CSV nu este un format complet standardizat. Delimitatorii săi de câmp ar putea fi, de exemplu, două puncte sau punct și virgulă. Devine dificil de analizat atunci când câmpul în sine poate conține și acest tip de ghilimele sau chiar întreruperi de linie încorporate. În plus, datele de câmp ar putea fi cuprinse între ghilimele. Aceste citate ridică uneori structură irelevantă a datelor despre identificarea începutului sau sfârșitului de propoziții sau chiar a unor valori nule. Spre deosebire de TSV, CSV încorporează un caracter de escape (\) în datele sale. Astfel, toate aceste considerații variate îl fac complex pentru analiza. În timp ce, TSV fiind în general delimitat fie prin tabulare, fie prin virgulă, nu acceptă un caracter de escape. Acest lucru permite distingerea cu ușurință a fiecărui câmp și, în cele din urmă, ajută la analizarea cu ușurință decât CSV. Acesta este motivul pentru care este utilizat în principal în cazul datelor mari.

  • Avantaj
  • Raport de compresie excelent
  • Lectură ușoară
  • Acceptă procesarea lot și streaming
  • Dezavantaj
  • Nu suportă valori nule, identice cu valorile goale
  • Fără garanție de a fi divizabil și nici suport pentru evoluția schemei
  • Format non-standard, fiecare cu propriile interpretări
  • Ecosisteme
  • Sprijinit de o gamă largă de aplicații (Hadoop, Spark, kafka,…) și limbi (de exemplu, CSV pentru Node.js)
  • Unul dintre cele mai populare formate folosite datorită simplității sale, dar de obicei nu este recomandat
Player Name;Position;Nicknames;Years Active
Skippy Peterson;First Base;"""Blue Dog"", ""The Magician""";1908-1913
Bud Grimsby;Center Field;"""The Reaper"", ""Longneck""";1910-1917
Vic Crumb;Shortstop;"""Fat Vic"", ""Icy Hot""";1911-1912

JSON (notație obiect JavaScript)

JSON este un format text care conține o înregistrare care poate avea mai multe forme (șir, întreg, boolean, matrice, obiect, cheie-valoare, date imbricate...). Fiind citit de om și de mașină, JSON este un format relativ ușor și privilegiat în aplicația web. Este susținut pe scară largă de multe software și relativ simplu de implementat în mai multe limbi. JSON acceptă în mod nativ procesul de serializare și deserializare.

Inconvenientul său major este legat de faptul că nu poate fi împărțit. Formatul alternativ utilizat în acest caz este, în general, „linii JSON”. Acesta conține mai multe linii în care fiecare linie individuală este un obiect JSON valid, separate prin caracterul de nouă linie \n. Deoarece JSON garantează absența caracterelor newline în datele serializate, putem folosi prezența acelor caractere pentru a împărți seturile de date în mai multe bucăți.

  • Avantaj
  • JSON este o sintaxă simplă. Poate fi deschis de orice editor de text
  • Există multe instrumente disponibile pentru a valida schema
  • JSON este compresibil și utilizat ca format de schimb de date
  • Acceptă procesarea în lot și în flux
  • Stochează metadate cu date și acceptă evoluția schemei
  • JSON este format ușor bazat pe text în comparație cu XML
  • Dezavantaj
  • JSON nu este divizabil și nu are indexarea la fel de multe formate de text
  • Ecosisteme
  • Este formatul privilegiat pentru aplicații web
  • JSON este un format de fișier utilizat pe scară largă pentru bazele de date NoSQL, cum ar fi MongoDB, Couchbase și Azure Cosmos DB. sau de exemplu, în MongoDB, BSON este folosit în schimb formatul standard. Această arhitectură a MongoDB este mai ușor de modificat decât baza de date structurată ca „Postgres”, unde ar trebui să extrageți întregul document pentru modificare. într-adevăr, BSON este codificarea binară a documentelor asemănătoare JSON. Este indexat și permite să fie analizat mai mult minereu mai rapid decât JSON standard. Cu toate acestea, acest lucru nu înseamnă că nu vă puteți gândi la MongoDB ca la o bază JSON.
  • JSON este, de asemenea, un limbaj folosit în GraphQL pe care se bazează date complet tastate. GraphQL este un limbaj de interogare pentru un API. În loc să lucrați cu puncte finale rigide definite de server, puteți trimite interogări pentru a obține exact datele pe care le căutați într-o singură solicitare.
{
  "fruits": [{
    "kiwis": 3,
    "mangues": 4,
    "pommes": null
  },
  {
    "panier": true
  }],
  "legumes": {
    "patates": "amandine",
    "poireaux": false
  },
  "viandes": [
    "poisson","poulet","boeuf"
  ]
}
{"id":1,"father":"Mark","mother":"Charlotte","children":["Tom"]}
{"id":2,"father":"John","mother":"Ann","children":["Jessika","Antony","Jack"]}
{"id":3,"father":"Bob","mother":"Monika","children":["Jerry","Karol"]}

XML

XML este un limbaj de marcare creat de W3C pentru a defini o sintaxă pentru codificarea documentelor care pot fi citite atât de oameni, cât și de mașini. XML permite definirea limbajelor mai mult și mai puțin complexe. De asemenea, permite stabilirea unui format de fișier standard pentru schimbul între aplicații.

La fel ca JSON, XML este folosit și pentru a serializa și a încapsula date. Sintaxa sa este verbosă, în special pentru cititorii umani, în comparație cu alte formate alternative „bazate pe text”.

  • Avantaj
  • Suporta procesarea lot/streaming.
  • Stochează metadatele de-a lungul datelor și sprijină evoluția schemei.
  • Fiind un format pronunțat, oferă un raport bun de compresie în comparație cu fișierul JSON sau alt format de fișier text.
  • Dezavantaj
  • Nu poate fi împărțit, deoarece XML are o etichetă de deschidere la început și o etichetă de închidere la sfârșit. Nu puteți începe procesarea în niciun moment în mijlocul acelor etichete.
  • Natura redundantă a sintaxei determină costuri mai mari de stocare și transport atunci când volumul de date este mare.
  • Spațiile de nume XML sunt problematice de utilizat. Suportul spațiului de nume poate fi dificil de implementat corect într-un parser XML.
  • Dificultăți de analizare care necesită selectarea și utilizarea unui parser DOM sau SAX adecvat.
  • Ecosisteme
  • Prezență istorică mare în companii care tinde să scadă în timp.
<?xml version="1.0" encoding="UTF-8"?>
<scientists>
  <!-- Some important physicists -->
  <scientist id="phys0">
    <name firtname="Galileo" lastname="Galilei" />
    <dates birth="1564-02-15" death="1642-01-08" />
    <contributions>Relativity of movement &amp; heliocentric system</contributions>
  </scientist>
</scientists>

AVRO

Avro este un cadru dezvoltat în cadrul „proiectului Apache’s Hadoop”. Este un format de stocare pe rând, care este utilizat pe scară largă ca proces de serializare. AVRO își stochează schema în format JSON, făcându-l ușor de citit și interpretat de către orice program. Datele în sine sunt stocate în format binar făcându-le compacte și eficiente. O caracteristică cheie a AVRO este legată de faptul că gestionează cu ușurință evoluția schemei. Atașează metadate în datele lor din fiecare înregistrare.

  • Avantaj
  • Avro este un sistem de serializare a datelor.
  • Este divizabil (AVRO are un marker de sincronizare pentru a separa blocul) și compresibil.
  • Avro este un format de fișier bun pentru schimbul de date. Are o stocare de date foarte compactă, rapidă și eficientă pentru analiză.
  • Susține foarte mult evoluția schemei (la momente diferite și independent).
  • Acceptă lot și este foarte relevant pentru streaming.
  • Scheme Avro definite în JSON, ușor de citit și analizat.
  • Datele sunt întotdeauna însoțite de schemă, care permit prelucrarea completă a datelor.
  • Dezavantaj
  • Datele sale nu pot fi citite de om.
  • Nu este integrat în toate limbile.
  • Ecosisteme
  • Folosit pe scară largă în multe aplicații (Kafka, Spark, …).
  • Avro este un apel de procedură de la distanță (RPC).

Protocol tampon

Tamponele de protocol au fost dezvoltate de Google și au fost deschise în 2008. Este neutră din punct de vedere al limbii, o modalitate extensibilă de a serializa datele structurate. Este folosit în protocoalele de comunicații, stocarea datelor și multe altele. Este ușor de citit și de înțeles de către om. Spre deosebire de Avro, schema este necesară pentru a interpreta datele

  • Avantaj
  • Datele sunt complet tastate.
  • Protobuf acceptă evoluția schemei și procesarea lot/streaming.
  • Folosit în principal pentru serializarea datelor, cum ar fi AVRO.
  • Având un set predefinit și mai mare de tipuri de date, mesajele serializate pe Protobuf pot fi validate automat de codul care este responsabil să le schimbe.
  • Dezavantaj
  • Nu este divizabil și nu este compresibil.
  • Fără suport pentru reducerea hărții.
  • Solicitați un fișier de referință cu schema.
  • Nu este conceput pentru a gestiona mesaje mari. Deoarece nu acceptă acces aleatoriu, va trebui să citiți întregul fișier, chiar dacă doriți să accesați doar un anumit articol.
  • Ecosisteme
  • Instrumentele sunt disponibile pe majoritatea limbajelor de programare din jur, cum ar fi JavaScript, Java, PHP, C#, Ruby, Objective C, Python, C++ și Go.
  • Fundația gRPC utilizată pe scară largă în ecosistemul „kubernetes”.
  • ProfaneDB este o bază de date pentru obiecte Protocol Buffers.
syntax = "proto3";

message dog {
  required string name = 1;
  int32 weight = 2;
  repeated string toys = 4;
}

Parchet

Parquet este un format de fișier open source pentru ecosistemul Hadoop. Designul său este un efort combinat între Twitter și Cloudera pentru o stocare eficientă a datelor analitice. Parquet stochează datele în funcție de coloane, cum ar fi formatul ORC. Oferă scheme eficiente de comprimare și codificare a datelor cu performanțe îmbunătățite pentru a gestiona date complexe în vrac. Parquet este un fișier binar care conține metadate despre conținutul lor. Metadatele coloanei sunt stocate la sfârșitul fișierului, ceea ce permite o scriere rapidă, cu o singură trecere. Parchetul este optimizat pentru paradigma scrierii odată citite multe (WORM).

  • Avantaj
  • Fișiere divizate.
  • Organizare pe coloane, permițând o compresie mai bună, deoarece datele sunt mai omogene.
  • Eficiență ridicată pentru volumul de lucru OLAP.
  • Sprijină evoluția schemei.
  • Limitat la procesarea în lot.
  • Dezavantaj
  • Nu poate fi citit de om.
  • Dificultăți de a aplica actualizări, dacă nu le ștergeți și le recreați din nou.
  • Ecosisteme
  • Analiză eficientă pentru BI (Business Intelligence).
  • Foarte rapid de citit pentru motoarele de procesare precum Spark.
  • Folosit în mod obișnuit împreună cu Spark, Impala, Arrow și Drill.

ORC (Colonare de rând optimizată)

Formatul ORC a fost creat și deschis de Hortonworks în colaborare cu Facebook. Este un format de stocare a datelor orientat pe coloane similar cu Parquet. Fișierele ORC conțin grupuri de date de rând numite dungi, împreună cu informații auxiliare într-un subsol de fișier. La sfârșitul fișierului, un postscript conține parametrii de compresie și dimensiunea subsolului comprimat. Dimensiunea implicită a benzii este de 250 MB. Dimensiunile mari ale benzilor permit citiri mari eficiente din HDFS.

  • Avantaj
  • Foarte compresibil, reducând dimensiunea datelor originale cu până la 75%.
  • Mai eficient pentru OLAP decât interogările OLTP.
  • Limitat la procesarea în lot.
  • Dezavantaj
  • Nu se pot adăuga date fără a fi nevoie să recreați fișierul.
  • Nu acceptă evoluția schemei.
  • În prezent, „Impala” nu acceptă formatul ORC.
  • Ecosisteme
  • Analiză eficientă pentru volumul de lucru Business Intelligence.
  • ORC îmbunătățește performanța citirii, scrierii și procesării în Hive.

Concluzie

Selectarea unui format de fișier adecvat este legată de tipul de interogare (cazuri de utilizare) legată de proprietățile fiecărui format de fișier. De obicei, bazele de date orientate pe rânduri sunt potrivite pentru sarcini de lucru asemănătoare OLTP, în timp ce sistemele orientate pe coloane sunt potrivite pentru interogări OLAP. Deoarece tipul său de stocare pe coloană conține un tip uniform în fiecare coloană, formatul de coloană va fi mai bun la compresie în comparație cu o stocare bazată pe rând.

În termeni de comparație, dacă doriți să lucrați cu un format de text, linia JSON și eventual CSV atunci când controlați tipurile de date (fără text cu caractere speciale) sunt alegeri bune. Dacă nu o impune sursa de date, evitați selectarea XML. Practic, nu este utilizat în procesarea datelor din cauza complexității sale mari, care necesită adesea un parser personalizat. În procesarea fluxului și schimbul de date, dacă doriți un format flexibil și puternic, selectați Avro. De asemenea, oferă un suport excelent pentru evoluția schemei. În timp ce Protocol Buffers este eficient în volumul de lucru în flux, nu este divizabil și nu este compresibil, ceea ce îl face mai puțin atractiv pentru stocarea datelor în repaus. În cele din urmă, formatele ORC și parchet sunt optimizate pentru analiza Business Intelligence.

Pe scurt, principala considerație de reținut este că selectarea unui format de fișier depinde de cazurile de utilizare.

Prezentare generală

| Types                                                    | CSV                                   | JSON                    | XML                     | AVRO                             | Protocol Buffers   | Parquet         | ORC             |
| -------------------------------------------------------- | ------------------------------------- | ----------------------- | ----------------------- | -------------------------------- | ------------------ | --------------- | --------------- |
| [text versus binary](#text-versus-binary)                | text                                  | text                    | text                    | metadata in JSON, data in binary | text               | binary          | binary          |
| [Data type](#data-type)                                  | no                                    | yes                     | no                      | yes                              | yes                | yes             | yes             |
| [Schema enforcement](#déclaration-dun-schéma)            | no (minimal with header)              | external for validation | external for validation | yes                              | yes                | yes             | yes             |
| [Schema evolution](#support-schema-evolution)            | non                                   | yes                     | yes                     | yes                              | non                | yes             | non             |
| [Storage type](#row-and-column-storage-oltp-versus-olap) | row                                   | row                     | row                     | row                              | row                | column          | column          |
| [OLAP/OLTP](#row-and-column-storage-oltp-versus-olap)    | OLTP                                  | OLTP                    | OLTP                    | OLTP                             | OLTP               | OLAP            | OLAP            |
| [Splittable](#splittable)                                | yes in its simpliest form             | yes with JSON lines     | non                     | yes                              | non                | yes             | yes             |
| [Compression](#compression-bzip2-lzo-sappy)              | yes                                   | yes                     | yes                     | yes                              | yes                | yes             | yes             |
| [Batch](#batch-and-streaming)                            | yes                                   | yes                     | yes                     | yes                              | yes                | yes             | yes             |
| [Stream](#batch-and-streaming)                           | yes                                   | yes                     | non                     | yes                              | yes                | non             | non             |
| Typed data                                               | non                                   | non                     | non                     | non                              | yes                | non             | non             |
| [Ecosystems](#ecosystem)                                 | popular everywhere for its simplicity | API and web             | enterprise              | Big Data and Streaming           | RPC and Kubernetes | Big Data and BI | Big Data and BI |

Acest articol a fost publicat inițial de Adaltas și a fost scris de Aida Ngom.