Una guia completa sobre com es trenca el monòlit de dades.

Com afrontar el nou gran objectiu del món del programari.

Trenqueu el monòlit de dades!

Motivació

Monòlit de dades

L’humà és l’únic animal que viatja dues vegades a la mateixa roca. Després d’anys parlant de trencar el monòlit en serveis, hem tornat a fer el mateix: monòlits de dades (alias data lages i data data stores).

He estat treballant en molts projectes (en diferents empreses) durant els darrers anys i he vist que els problemes que provoca el monòlit de dades són similars:

  • Els errors de dades a causa dels canvis no es coordinen entre el codi de dades i les canonades de dades.
  • Normalment, el monòlit crea sitges d’informació perquè necessitem especialistes en codis i equips especialitzats en dades i aprenentatge automàtic.
  • A mesura que les empreses creixen, tenim més fonts de dades, i això només creix, cosa que fa que les dades en un sol lloc siguin un repte dur.
  • Normalment és difícil que les persones que treballen en canonades de dades entenguin correctament el significat de les dades (almenys no millor que les persones que les produeixen) perquè tenen menys context.
  • De vegades és necessari fer actualitzacions massives als magatzems de dades per solucionar malentesos i dades incoherents en els processos ETL.
  • És difícil reduir la bretxa entre una idea nova i quan aquesta idea es troba en producció. Per tant, no podem innovar. Si sou lent, no podeu tenir un cicle de proves ràpides i aprendre i sense això no podreu innovar.

A més d’això, el monòlit de dades és, de fet, un monòlit i entenem moltes coses dolentes (i algunes bones) que això comporta; de manera que no cal que expliqui com aquestes coses (serveis acoblats, problemes de publicació de noves funcions que dificulten el desplegament continuat, estratègia de proves desordenades, etc.) poden ser un problema.

La manera habitual de fer-ho

La manera real és posar els focus en els nostres serveis i, després, mitjançant un ETL obtenir les dades que produeixen els serveis / fonts i després d’algunes transformacions posar les dades embolicades en un lloc on després s’utilitzaran / serviran (marts de dades, API, BigQuery, models de canonades, etc). Aquests processos es realitzen dins de canonades de dades i, com hem dit abans, podem diferenciar tres parts clares (ETL):

  • Primer, un procés que ingereix les dades de diferents fonts.
  • Una part de processament on netejem les dades i fem algunes transformacions al llarg de canonades de dades.
  • Pas de publicació de les dades agrupades. En el nostre cas, BigQuery fa aquest servei de les dades.
Patró de monòlits de dades

Com trencar el monòlit

La idea d’aquest desacoblament és trencar aquest pipeline en alguns pipelines, per dominis o bé, per serveis de la mateixa manera que ho fem amb els serveis de codi.

Què passa si, en lloc de tenir només un gasoducte, cada servei tingués el seu propi (o més) processador de les seves pròpies dades? Per tant, cada servei hauria de ser responsable de netejar, transformar i compartir les seves pròpies dades en conjunts de dades immutables com a productes.

Què podem guanyar amb aquest canvi? En primer lloc, no hem d’oblidar que hi ha molts canvis en els diferents serveis. Aquí és quan comencen els problemes perquè, o oblidem coordinar-nos amb les dades de la gent sobre els canvis o aquesta coordinació no és possible en aquest moment. Realment, sembla que la responsabilitat de no trencar les analítiques o els altres serveis en dades és que l’equip estigui canviant els serveis, oi? A més, qui sap millor que aquest equip sobre com són les dades i quin format té?

De manera que, en resum, cada domini prepara les seves dades, posa-les com a producte en un agent de missatgeria des d’on surten altres serveis, eines de streaming, governança, analítica, eines de científics de dades (com a quadern de jupyter), pipelines d’aprenentatge automàtic, un emmagatzematge global i molt. més, pot aconseguir-los.

Estratègia distribuïda de dades

Més enllà d’això, estic segur que si ara no feu res amb l’aprenentatge automàtic, ho fareu. Penseu-hi, és possible fer un bon model sense tenir bones dades? Si voleu fer un bon treball a ML, probablement necessiteu un model de canalització, també per domini, i necessitareu aquest pipeline de dades. Si voleu més informació sobre aquest tema podeu llegir aquest altre missatge que vaig escriure: desplegament continuat en sistemes d'aprenentatge automàtic.

Infraestructura de dades com a plataforma

Així, anem a trencar el monòlit de dades i ho tindrem per domini, però en realitat, els equips no tenen temps per crear cadascuna la seva pròpia infraestructura de dades. Per resoldre aquest problema, les empreses han de posar el focus en la creació d’una infraestructura de dades comuna.

A l’article de malla de dades del bloc de Martin Fowler (escrit pel meu ex company de Thoughtworks Zhamak Dehghani) s’escriuen algunes capacitats que hauria de tenir aquesta infraestructura, algunes d’elles: emmagatzematge de dades de políglot escalable, versionat de dades, esquema de dades, llinatge de dades, supervisió de dades / alerta / registre, mètriques de qualitat del producte de dades, govern de dades, seguretat i càlcul de dades i localitat de dades.

Amb aquesta plataforma de dades, els equips (desenvolupadors i científics de dades) només han de tenir cura de què volen fer amb les dades que produeixen i com serviran aquestes dades a altres equips, com ara ho fem amb CircleCi o Jenkins (els equips només han de pensar en com volen fer el seu CI, no en la infraestructura). Per exemple, en aquesta imatge, Metaflow explica la infraestructura des del punt de vista dels científics de dades:

Imatge de Metaflow

I la següent imatge (del post de malla de dades del bloc de Martin Fowler) podria ser un possible estat final. En aquest esquema, podeu veure els diferents dominis amb pipelines propis i la plataforma de dades transversals.

Esquema de malla de dades del bloc de Martin Fowler

D'acord, d'acord D'acord ... Entenc el concepte i tota la resta, però ... Què passa amb l'estratègia per aconseguir-ho?

Bé, primer de tot ens encanta el codi, i des de fa anys hem millorat les millors pràctiques en codi i les millors metodologies i totes les tècniques que conté XP. Per tant, fem servir el codi també en les dades i totes les bones pràctiques que coneixem.

Podríem utilitzar moltes eines i marcs per fer les pipelines de dades amb codi. A l’equip d’Enginyeria de Packlink, ens encanta GCP, així que en aquesta publicació explicaré aquestes coses amb Airflow, ja que la plataforma Google té una orquestració de flux de treball i clic completament gestionada integrada a Airflow: Cloud Composer.

Recordeu que els punts importants (el mateix que en els serveis és el mateix si feu servir CircleCI, Jenkins, etc.) són les idees, l'eina només és una manera d'aconseguir els nostres objectius. Altres bones eines / marcs són Metaflow, Luigi, Prefect, Pinball. En aquest moment cada empresa està construint el seu propi marc i totes elles diferents, però, insistint, la idea és que cada un d'ells és codi. En les següents seccions passo:

  • Patró de desconcert: com a estratègia per aconseguir-ho.
  • Pacte de dades: com ha de ser aquest pipeline?
  • Codi: el codi provat per escriure el pipeline.

Patró de desconcert

Suposo que ara teniu un monòlit de dades. Si no, si teniu un camp verd potser aquest capítol no us interessa, però ho sentim, estem parlant de trencar el monòlit.

Tenim el monòlit de dades, quina és la millor estratègia? No sembla que fer una cascada i posar tota la infraestructura alhora és una bona idea, així que per assolir el nostre objectiu anem a utilitzar el patró Strangler. Aquesta és una manera típica de trencar el monòlit en els sistemes heretats i, com he dit abans, hem après moltes coses i volem reutilitzar aquest coneixement.

Aquest patró és bo per utilitzar; tenim moltes coses funcionant i volem fer aquest treball amb una mentalitat útil i àgil en aquests tres passos:

  • Elimineu un domini del monòlit construint-lo en una nova canalització.
  • Posar en producció i comprovar que tot funciona bé mentre que les dues maneres de conviure són.
  • Elimina aquesta part simplement heretada del monòlit.
Patró de contraprestació en acció

De manera que, per començar, podem triar el domini més senzill i crear un pipeline de dades nou, després fer una migració tranquil·la convivint ambdós sistemes i quan tinguem seguretat que tot funciona correctament, suprimim la part heretada.

Oleoducte de dades

Els punts principals que ha de tenir aquest conducte són:

  • Ordenació de dades. No totes les dades produïdes pels serveis són compartides i no totes les dades que es produeixen es realitzen de forma bruta. De vegades, hem de fer algunes transformacions. Ho farem amb el codi i, com dic sempre, el codi és el codi, de manera que cal aplicar les bones pràctiques de sempre.
  • Comprovar esquemes. Si volem assegurar la qualitat de les nostres dades, hem de fer servir un esquema quan les compartim amb altres parts de l’empresa (serveis, analítiques, etc.). Per exemple, tenim l’edat de les persones que volem assegurar que aquest valor sigui un nombre enter i que el valor màxim sigui de… 150? Podeu utilitzar diferents sistemes de serialització de dades per aconseguir-ho, us recomano Protocol Buffers o Avro. Amb això, tant el productor com el consumidor saben què significa cada punt de dades.
  • Una exportació de conjunts de dades immutables com a productes. Cada servei és responsable de compartir la informació amb l’organització. L’òptim és compartir conjunts de dades immutables versionats a través d’un agent de missatgeria com Kafka o pub / sub. Es pot llegir aquí un bon post parlant de les dades de compartició dels sistemes distribuïts. Tingueu en compte això: les dades, tal com hem après també en la programació funcional, han de ser immutables i, a més, ens permet tenir un historial complet i fer les agregacions necessàries després sense desar-les.
  • Versió de dades / dades com a codi. Com hem creat en codi, necessitem versionar els nostres conjunts de dades, encara més, volem que les dades siguin codi. Té alguns avantatges: podem reproduir fàcilment errors, utilitzar els conjunts de dades de les nostres proves i els nostres pipelines, molts avantatges en l'aprenentatge de màquines (més informació aquí) i definitivament totes les coses bones que té el codi. DVC, un sistema de control de versions de dades i models basat en git, és la meva solució, per a mi, una de les millors eines del món de les dades.
Diagrames DVC sobre Dades i models com a codi i compartició de dades
  • Governança i llinatge de dades. Aquest és un dels punts més importants per al pipeline de dades si volem trencar el monòlit de dades. En primer lloc, necessitem a la plataforma de dades una eina per guardar-la. Hi ha algunes bones alternatives, però només en recomanaré dues: Lyft Ammundsen i si feu servir GCP, Catàleg de dades. Tots dos tenen descobriment automàtic de les dades. L’important aquí no és l’eina, sinó que també és el concepte. Hem de guardar en els nostres pipelines la descripció de les dades que estem compartint i els metadades mitjançant API a la nostra eina, com fa aquesta biblioteca al catàleg de dades i posar el necessari per tenir un llinatge correcte de les dades. Gràcies a això, tothom sabrà on són les dades, qui és el propietari, com és i què significa cada valor.
Governança de dades amb Lyft Ammundsen
  • Observabilitat. Hem d’entendre com funciona el nostre sistema i ho farem treballant per sobre de tres tipus de nivells: nivell d’infraestructura, esdeveniments de nivell de feina i nivell de dades. Creeu un quadre de comandament amb informació clara i útil. Aquest és el punt principal. Estem fent sistemes complexos per la qual cosa hem de tenir un quadre de comandament només amb la informació més important per entendre fàcilment si els nostres sistemes funcionen correctament. Amb això, quan el vaixell passi i serà així, seràs el primer a descobrir-lo. Un error típic de les dades és oblidar els errors silenciosos. Si una font deixa de produir dades noves, hem de ser conscients d’això perquè abans els nostres models, altres serveis o negocis, depenen d’aquestes dades en un percentatge elevat. A més, gràcies a un bon pipeline de dades podem aconseguir una anomalia automàtica de detecció de fallades, per exemple, quan hi ha menys esdeveniments en un període de temps.
  • Qualitat de les dades. Proves, proves i més proves. fem proves. I a més de les proves en codi, necessitem algunes proves amb dades. Per exemple, què en penseu de fer una prova d’aquest pipeline que us aconsella si fem més comandes que productes? Sembla lògic i útil, no?
  • Obteniu formació sobre dades. Si també es treballa amb l'aprenentatge automàtic i perquè volem fer la vida dels nostres científics de dades, necessiteu obtenir les dades de formació. Aquí hi ha molts punts crítics: mostreig pel pes en importància, tallar les dades en llesques més petites, anonimitzar totes les dades sensibles ... més informació aquí.
  • Tenim cura dels nostres clients, per la qual cosa hem de tenir cura de les seves dades, per la qual cosa necessitem molta seguretat en aquesta part de dades. És important anonimitzar totes les dades sensibles si volem treballar amb elles.

Sí Juan molt bonic, però ...

Programació extrema per al rescat

Primer de tot, continuarem tendint tot com a codi, de manera que el pipeline de dades també.

Amb l’enfocament desconegut, i en la primera iteració, el lògic és reutilitzar part de la lògica que hem fet abans i ho farem amb TDD, com diuen XP i el nostre sentit comú.

Si estàs pensant en com explico un mètode senzill per aconseguir-ho de manera ràpida. A més d'això, haureu de decidir la vostra estratègia a llarg termini.

Si coneixeu Airflow, sabeu que hi ha diversos operadors (python_operator, http_operator, bash_operator, mysql_operator i un llarg etcètera), segons el tipus de codi que vulgueu introduir a cada DAG. Aquests operadors tenen alguns problemes. El pitjor per a mi és la manera complexa i lletja de provar-les, a més, si feu servir Python hauràs escoltat alguna cosa sobre l’embolic de dependència. Amb aquests operadors, necessiteu instal·lar totes les dependències en tot el projecte, no necessiteu una versió diferent i utilitzeu la mateixa versió de Python. A més, som una empresa moderna i volem tenir un sistema de políglot i provar nous idiomes!

La meva solució és utilitzar, mentre estem fent el patró de desconegut, l'operador docker, kubernetes_pod_operator. Si utilitzeu Google Composer, haureu d’utilitzar el Kubernetes i mai el GKEContainerOperator, ja que pot provocar una competència de recursos. Amb aquests operadors, el codi que s'executarà a cada DAG serà dins d'un contenidor (hi pot haver codi python, scala, java, processos Beam, processos Spark, fluxos de Kafka, resumint tot el que pugueu imaginar ...), de manera que podeu utilitzeu el vostre TDD en l’idioma que vulgueu i podríeu reutilitzar part del vostre codi heretat. Les proves d’unitat i les proves d’integració es fan… gairebé!

Encara hem d’escriure el codi del propi flux de l’aire, de manera que també farem TDD per fer-ho. Serà la part de proves de definició inclosa a la prova d’unitat de la part Airflow. Abans de mostrar el codi, vull donar les gràcies a Chandu Kavar i Sarang Shinde per la publicació sobre les estratègies de prova en fluxos d'aire.

Així, com fem el TDD, primer testem la unitat:

Aquest és el codi de producció del pipeline que hem generat amb TDD:

Però les proves d'unitats no són suficients, ja que Packlink Engineering sap que les proves són la part més important del codi. Per tant, anem amb més proves.

Ara és hora de realitzar proves d’integració a la part del flux d’aire (els contenidors tenen la seva pròpia unitat i proves d’integració). Amb aquest enfocament, les proves d’integració aquí es relacionen amb la configuració Airflow i els XComs, que en resum són la forma en el flux d’aire que hem de compartir informació entre les tasques d’un DAG. En el nostre exemple, hem de provar que la informació que es desa a packlink_hello_task és la presa per stream_data_task:

L’última part de les proves de piràmide són les proves e2e. A la piràmide, les proves e2e sempre són per la part més petita, perquè són molt cares. A Airflow potser encara més. Podeu veure un bon exemple aquí: https://github.com/chandulal/airflow-testing. No ho hauria pogut fer millor.

Conclusions

Això em porta al final de la publicació. Només volia posar algunes conclusions per resumir la publicació:

  • El codi és el codi. Feu servir pràctiques XP.
  • Els monòlits de dades com a monòlits de codi tenen problemes similars.
  • Comparteix conjunts de dades immutables com a productes.
  • Conegueu la vostra data, poseu l’amor en el govern de les dades. Tothom de l'empresa ha de ser capaç de comprendre les dades.
  • La merda passa. Posar atenció en l’observabilitat.
  • Ningú sap millor que els dominis sobre les seves dades. Aplicar una visió DDD a les dades.
  • Regles de Packlink !.

Recursos i enllaços