Jorg Schneider

5 decembrie 2019

·

15

min citit

De Jorg Schneider si Niels Degrande de la BCG GAMMA Engineering

Airflow este campionul incontestabil al programarii bazate pe Python si, incepand din 2019, un proiect de nivel superior Apache. Impreuna cu marea sa flexibilitate vine si provocarea utilizarii Airflow pentru a crea structuri de baza de coduri cu modele durabile. In acest articol, va prezentam Airflow si Airtunnel , un set de principii si o biblioteca open source care va imblanzeste fluxul de aer!

Ca parte a muncii noastre la o consultanta in domeniul stiintei datelor, construim si operam sisteme pentru a ajuta in diferite proiecte de analiza. Acestea sunt adesea proiecte la scara larga care implica mii de locuri de munca pe zi, procesand sute de active de date, impreuna cu echipe de dezvoltatori considerabile care colaboreaza la fluxurile de lucru. In urmatoarea discutie surprindem cateva dintre invataturile despre orchestrarea fluxului de lucru pentru prelucrarea datelor (mari) .

Pentru orice flux de lucru¹ care ar putea fi repetat de mai multe ori, ar trebui sa luati in considerare automatizarea procesului. In acest articol vom argumenta ca, din motive de productivitate, repetabilitate si documentare, aveti nevoie de un anumit grad de automatizare prin orchestrarea fluxului de lucru. A fi clar:

Productivitatea in acest context se refera la capacitatea de a efectua cu usurinta si eficient o serie de pasi de cate ori este necesar. Zicala IT de „automatizare si modularizare timpurie” este valabila mai ales pentru fluxurile de lucru.

Repetabilitatea se refera la executarea sarcinilor in exact aceeasi ordine si intr-un mod consecvent. Aplicatiile de prelucrare a datelor, de exemplu, necesita repetabilitate pentru a va asigura ca rezultatele pot fi reproduse.

Documentatia pentru un flux de lucru, in acest context reprezentat ca codul sau configuratia care il orchestreaza, este la fel de determinista pe cat se poate obtine si, prin urmare, un instrument puternic pentru schimbul si transferul de cunostinte. Aceasta forma de „documentare” nu exclude – si nu ar trebui – sa excluda documentatia care poate fi citita de om, care imbunatateste intelegerea fluxului de lucru.

Un bun exemplu al necesitatii orchestrarii fluxului de lucru este un proces ETL . Adesea un proces ETL va fi repetat zilnic si, ca atare, necesita coerenta. Nerespectarea coerentei poate corupe procesul decizional, procesele de afaceri si alte sarcini de afaceri.

Array

(Nota: Cu exceptia cazului in care exista certitudine, cel de mai sus este un eveniment unic, orchestrarea ar trebui luata in considerare de la inceput.)

Un flux de lucru al procesului ETL include adesea urmatorii pasi:

1. Conectarea la sursa de date.

2. Preluarea si stocarea temporara a datelor brute.

3. Efectuarea unei liste predefinite de transformari, cum ar fi deduplicarea si corectarea problemelor de date cunoscute.

4. Incarcarea datelor finale in sistemul tinta.

Un alt exemplu de flux de lucru (care nu implica date), se refera la construirea, testarea si implementarea software-ului (cfr. CI / CD). Acesta este un alt proces repetat, in mai multi pasi, care necesita o examinare constanta a modului in care sunt efectuati diferitii pasi. Acest proces implica de obicei verificarea codului din controlul versiunilor, efectuarea controlului calitatii, compilarea artefactelor, efectuarea testelor, inspectarea rezultatelor si implementarea in medii multiple. Avand in vedere aceasta complexitate, o abordare manuala ar fi foarte plictisitoare si predispusa la erori. Mai mult, lipsa unei orchestrari clare a fluxului de lucru poate impiedica in mod semnificativ capacitatea mai multor dezvoltatori de a lucra impreuna pe o singura aplicatie.

Array

Exista astazi o gama larga de instrumente pentru orchestrarea fluxului de lucru, inclusiv instrumente open-source, instrumente proprietare bazate pe cloud pentru orchestrarea procesarii datelor si planificatoare usoare si extensibile. Mai jos, prezentam abordarea fiecarui instrument cu privire la subiectul abordat. Aceste instrumente se concentreaza in mare masura pe procesarea datelor in serie si sunt mai putin aplicabile aplicatiilor in flux aproape de timp in timp real sau alte tipuri de aplicatii.

Instrumente de orchestrare a fluxului de lucru open-source

Multe dintre aceste instrumente open source isi au radacinile in utilitati construite ca parte a unor proiecte mai mari, cum ar fi Hadoop, si de atunci au evoluat pentru a deveni manageri de fluxuri de lucru cu drepturi depline. Mai jos sunt cele mai mature instrumente, care ofera experiente extraordinare. Aceste cadre sunt cele mai apreciate in ceea ce priveste construirea fluxurilor de lucru.

Cele mai comune instrumente de orchestrare open source.

Unelte proprietare bazate pe cloud pentru orchestrarea prelucrarii datelor

Urmatoarele instrumente sunt fie personalizate de furnizori mari de servicii cloud, fie versiuni gestionate ale orchestratorilor de flux de lucru mentionati mai sus.

Orchestratori proprietari pe baza de cloud.

Planificatoare usoare, extensibile

Urmatorul set de instrumente sunt planificatori simpli care, in combinatie cu scripturi shell sau o baza de cod mai mare, pot reproduce o parte din functionalitatea oferita de instrumentele mentionate mai sus. Acestea sunt utile pentru proiecte la scara mica, care nu necesita un cadru, dar nu ofera caracteristici mai avansate, cum ar fi o interfata de utilizare pentru gestionarea si monitorizarea fluxurilor de lucru, pluginuri pentru functionalitate generica sau capacitatea de a gestiona cu usurinta dependentele de sarcini.

Planificatoare usoare, extensibile.

Nota: datele pentru tabelele de mai sus au fost colectate in august 2019. Popularitatea se refera la numarul de stele GitHub.

Motivele pentru a lua in considerare fluxul de aer pentru gestionarea fluxurilor de lucru includ:

1. Flexibilitate si scalabilitate: cu Airflow puteti incepe rapid si continua sa il utilizati atunci cand fluxurile de lucru devin mai numeroase si mai complexe.

Array

2. Rezilienta: fluxul de aer va ajuta sa gestionati sarcinile sau fluxurile de lucru intarziate sau esuate, oferind caracteristici avansate de planificare (de exemplu, depinde de trecut), un cadru de reincercare si un mecanism de alerta incorporat.

3. Scrieti fluxuri de lucru programatic : fluxul de aer este util mai ales atunci cand utilizati deja Python pentru aplicatia sau algoritmul dvs.

4. Interfata web usor de utilizat: fluxul de aer face mai usor sa monitorizeze si sa controleze executiile fluxului de lucru, cum ar fi declansarile si sa obtineti informatii despre rularile (istorice) si esecurile.

5. Dovada viitoare : fluxul de aer are un cadru de maturizare rapida, cu o baza de utilizatori mare si in crestere rapida , ambele conducand la un program de lansare rapida.

In plus, Airflow vine cu o serie de caracteristici avansate : declansarea unui flux de lucru de la altul, ramificarea in cai din aval la momentul executiei, asistenta pentru umplere si gestionarea resurselor cu suport pentru SLA-uri.

Cand fluxul de aer s-ar putea sa nu se potriveasca perfect:

1. Atunci cand nu este necesara programarea , caz in care pot fi utilizate alternative usoare.

2. Daca dezvoltatorii dvs. nu sunt familiarizati cu Python , utilizarea lor a fluxului de aer poate anula partial avantajele fluxurilor de lucru ca cod.

3.

Atunci cand aveti de-a face cu job-uri critice pentru misiune care necesita disponibilitate si asistenta ridicate , caz in care solutiile de nivel intreprindere precum Control-M pot fi mai potrivite.

4. Cand aveti nevoie de control de acces si autentificare cu granulatie fina . Aceasta capacitate se adauga incet la Airflow, asa cum se intampla adesea cu software-ul open-source.

5. Cand trebuie sa orchestrati conducte sau procese in timp real. (Fluxul de aer este mai orientat spre lot.)

Airflow este un orchestrator de flux de lucru bazat pe Python, cunoscut si sub numele de sistem de gestionare a fluxului de lucru (WMS). Provenit de la AirBnB, este un proiect de nivel superior Apache, cu aproape 900 de colaboratori² pana in prezent. Misiunea sa este:

Crearea si intretinerea de software legate de automatizarea si planificarea fluxului de lucru pentru crearea si gestionarea conductelor de date

(In sectiunea urmatoare introducem pe scurt Airflow pentru a asigura o linie de baza comuna. Cititorul experimentat poate sari peste aceasta sectiune.)

Elementele de baza ale fluxului Airflow includ DAG, Operator, Task si Task Instance.

Grafic aciclic directionat (DAG)

Un flux de lucru in fluxul de aer este reprezentat de un grafic acilic directionat (DAG). Acest grafic contine sarcini si dependentele (directionate) dintre ele. Pentru a crea un DAG, adaugati un obiect DAG (un script Python) in folderul dag_, din care asa-numitul dag_bag va colecta cele mai recente definitii. Definitia , ca obiect DAG, serveste doar ca o descriere a structurii graficului, completata de un set de proprietati pentru planificare si executie. Periodic, planificatorul de flux de aer va evalua definitiile partii dagbagului, o actiune care apoi conduce la rularea DAG, asigurand executarea in timp util a fluxului de lucru.

Un exemplu de definitie Airflow DAG.

Operatori si sarcini

Luand in considerare toate dependentele de grafic, planificatorul creeaza instante de activitate din obiecte de activitate care sunt instantieri ale operatorilor. Exista diferiti operatori, fiecare efectuand un anumit tip de munca. Senzorii sunt de un anumit tip, asteapta pana la indeplinirea unei conditii – si astfel blocheaza graficul de executie din aval. Este posibil sa extindeti functionalitatea Airflow scriind operatorii personalizati. Instantele de activitate sunt izolate de contextul DAG si pot fi alocate diferitilor lucratori. Datorita acestei caracteristici, nu ar trebui sa utilizati constructii Python standard pentru comunicare. In schimb, utilizati XComs pentru a partaja informatii intre instantele de activitate.

Un exemplu de implementare a operatorului Airflow.

Arhitectura

Exista trei componente principale ale arhitecturii fluxului de aer:

1. Planificatorul / executorul , asa cum s-a explicat mai sus, colecteaza obiecte DAG, porneste rulari DAG si atribuie executia sarcinilor proceselor de lucru. In plus, gestioneaza esecurile DAG si ale sarcinilor, asa cum este configurat in definitia DAG.

2. Serverul web ruleaza interfata de utilizator Airflow, permitand utilizatorului final sa interactioneze cu planificarea si executarea sarcinilor si sa monitorizeze rularile.

3. Baza de date capteaza metadatele pe DAG si ruleaza sarcini si, prin urmare, este esentiala pentru planificator. Printre alte operatiuni, baza de date va pastra starea DAG si executarea sarcinii (in coada, succes, esuat sau reincercat) pana la data executarii.

Este extrem de usor sa incepeti cu Airflow. Puteti sa-l instalati ca pachet din PyPi sau sa descarcati codul sursa din GitHub. Alternativ, puteti extrage o imagine Docker existenta sau puteti instala una dintre diagramele Helm disponibile. Fara configurare suplimentara, instanta dvs. Airflow va rula probabil in modul independent , cu Airflow SequentialExecutor configurat ca executant bazandu-se pe o baza de date SQLite. Datorita limitarii SQLite, nu va exista nicio paralelizare a sarcinilor. In majoritatea scopurilor, acest mod nu trebuie utilizat in productie, desi este excelent pentru invatare si experimentare.

Puteti intensifica functionalitatea utilizand Airflow LocalExecutor cu o baza de date mai robusta precum MySQL sau PostgreSQL. In acest scenariu, instanta Airflow va paralela instantele de sarcina la nivel local, rotind mai multe procese de lucru. Desi aceasta abordare este mai scalabila, toata gestionarea sarcinilor se intampla pe masina care ruleaza procesul de planificare / executare. Luati in considerare aceasta configurare atunci cand executia sarcinii nu este prea grea din punct de vedere al calculului sau cand prelucrarea datelor poate fi impinsa catre un cluster Spark sau similar.

Cand scalarea nu acopera nevoia dvs., Airflow ofera o varietate de optiuni pentru redimensionare, ruland in modul distribuit. Folosind Airflow CeleryExecutor, sarcinile sunt adaugate la o coada cu o prioritate stabilita. Muncitorii distribuiti vor aparea si vor executa sarcinile, izolati de planificator. Adaugarea lucratorilor la grupul de resurse va permite sa paralelati in continuare executia sarcinilor. Airflow KubernetesExecutor va crea un pod pentru fiecare instanta de activitate, izoland in continuare executia. Airflow DaskExecutor va permite sa rulati sarcini pe un cluster Dask; MesosExecutor va folosi sclavii Mesos.

In plus, Airflow are integrari cu principalii furnizori de cloud (in principal AWS), oferind o gama larga de operatori, senzori, carlige si optiuni de stocare in ceea ce priveste serviciile lor. Deoarece executarea unei instante de flux aerian la scara larga ar putea necesita o configuratie foarte mare, va recomandam sa automatizati implementarea timpurie, cum ar fi folosind Ansible sau Helm.

In timp ce proiectul Airflow ofera utilizatorului sau un set divers de instrumente si optiuni pentru a le utiliza, aceste instrumente sunt livrate fara indrumari cu privire la modul de asamblare si structurare structurala a unei baze de cod mai mari bazate pe fluxul de aer.

Este util pentru Airflow sa ofere atat de multe scenarii in care ar putea functiona o implementare a acestuia. Chiar si asa, exista riscul de a nu ajunge deloc la o structura generala sau consistenta, atata timp cat totul functioneaza . Ganditi-va la o mica baza de cod care incepe sa fie structurata in mod curat doar pentru a deveni inconsistenta si fragmentata in timp, pe masura ce diferiti dezvoltatori contribuie la aceasta fara conventii puternic afirmate si aplicate.

Aceasta sectiune este un plan pentru fluxul de aer care va poate ajuta sa il evitati. Este adaptat, fara indoiala, pentru unul dintre cele mai frecvente cazuri de utilizare ale instrumentului, care este canalizarea de date in serie in analiza.

Suntem constienti de faptul ca exista multe astfel de abordari disponibile, fiecare nascand din situatii particulare si avand locul lor specific. De asemenea, intelegem ca unele cazuri nu se incadreaza in structura noastra propusa. De fapt, le-am intalnit noi insine. In opinia noastra, acest lucru este total bine – atata timp cat exceptia nu devine regula.

Fluxurile de lucru pentru canalizarea datelor in analiza tind sa se rezolve in jurul activului de date – acesta fiind principalul subiect de interes pentru care se desfasoara lucrari. In cele din urma, fluxurile de lucru servesc scopului automatizarii conditiilor si transformarilor care se aplica activelor de date de-a lungul ciclului lor de viata, primind in primul rand actualizari de date externe si aplicandu-le in aval tuturor activelor de date dependente. Datorita acestui fapt, activul de date este cel mai important concept din planul nostru si se afla in centrul tuturor elementelor de baza. Urmatoarele trei sectiuni vor introduce principii de proiectare care va pot indruma in utilizarea blocurilor de constructie pentru a asambla o stiva holistica de conducte de date.

Coerenta fara compromisuri

Coerenta este in centrul oricarui proiect software de succes. In procesarea datelor, coerenta se obtine in primul rand prin conventii stricte de denumire si o structura clara a bazei de cod. O astfel de consistenta permite noilor membri ai echipei sa urce rapid la bord si are avantajul suplimentar de a evidentia inconsecventele. Testele unitare sunt o modalitate buna de a asigura efectiv coerenta.

Avand in vedere ca activul de date se afla in centrul proiectului, coerenta ar trebui sa cuprinda:

  • denumirea (si plasarea) activelor de date
  • denumirea fisierelor (script-urilor) de script pentru procesarea activului de date mentionat
  • denumirea fluxurilor de lucru; ca in Airflow DAG si ID-uri de operator
  • o relatie stricta 1: 1 intre scripturile / sarcinile de date si activele de date. Cu alte cuvinte, nu incarcati trei tabele folosind un singur script, ci folositi mai degraba trei scripturi (consultati mai jos „Declaratie si stocare de scripturi de date” de mai jos pentru a vedea cum imbunatateste aceasta consistenta)

Coerenta ii va ajuta pe membrii echipei sa-si formeze o imagine mentala completa a modului in care sunt conectate aspecte ale proiectului. In mod ideal, produce si o structura, astfel incat nimeni sa nu faca cautari de scripturi care sa consume mult timp sau sa efectueze actiuni similare. In schimb, dezvoltatorii au capacitatea de a deduce rapid nume si locatii doar dintr-un nume de material de date la indemana.

Redundanta declarativa primara si redusa

Am introdus Airflow ca cadru de tip „fluxuri de lucru ca cod”. Desi ne place absolut aceasta flexibilitate, aceasta poate determina dezvoltatorii sa scrie cod redundant si / sau sa ingropa proprietati de configurare in ea. Nu este nevoie sa scrieti DAG-uri si sa prelucrati scripturile complet de la zero. De fapt, acest lucru poate provoca probleme – mai ales daca aveti sute de astfel de DAG-uri si scripturi.

Asa cum este natura canalizarii datelor, tipurile de sarcini orientate spre proces, cum ar fi ingerarea, incarcarea si mutarea datelor, se repeta in mod constant de-a lungul ciclului de viata al activelor de date. Singura diferenta pe instanta este ceea ce necesita un anumit material de date: Ingerati de unde si folosind ce mecanism? Incarcati delta sau in lot? Etc.

Acesta este motivul pentru care postulam sa avem un fisier de declaratie centrala (ca in YAML sau JSON) per activ de date, capturand toate aceste proprietati necesare pentru a rula o sarcina generalizata (efectuata de un operator personalizat). Cu alte cuvinte, operatorii sunt proiectati intr-un mod generic si primesc numele unui activ de date, de unde pot prelua fisierul de declaratie si pot invata cum sa parametrizeze si sa indeplineasca sarcina specifica.

Beneficiile cheie ale acestei abordari sunt ca:

  • Permite standardizarea sarcinilor de baza de canalizare a datelor, ceea ce face posibila chiar si dezvoltatorilor incepatori sa construiasca fluxuri de lucru prin simpla furnizare a declaratiei corecte.
  • Conduce la crearea unei „surse unice de adevar” prin extragerea proprietatilor activelor de date in declaratie.
  • Permite testarea facila a declaratiilor pentru consistenta si validitate utilizand teste unitare.
  • Permite utilizarea limbajului de programare incrucisata a fisierelor de declaratie.

Metadate conduse

Metadatele sunt cunoastere, iar cunoasterea este putere. In acest caz, „putere” se refera la cum sa executati cel mai bine un flux de lucru, sa-l analizati mai tarziu si chiar sa-l optimizati. Va propunem o interfata cu metadate reduse, care ar trebui sa se extinda pe modelul intern de date Airflow.

In special, trebuie sa adaugam dimensiunea activului de date, deoarece modelul de date al Airflow se bazeaza numai pe propriile obiecte precum DAG-uri, Sarcini si altele. Aici, trebuie stabilita o legatura intre activele de date si operatorii sau DAG-urile, deoarece probabil ca un parti interesate nu va va intreba niciodata: „ <Numele tau>, cand a terminat DAG load_all_the_data astazi?” In schimb, au in vedere un anumit material de date.

Pentru a fi cu adevarat bazat pe metadate, ar trebui sa colectam si informatii despre fisierele de intrare (cum ar fi dimensiunile si timpii de modificare), precum si despre activele de date construite intern (cum ar fi ce partitii au fost actualizate si la ce ora). Joburile din aval pot folosi cu usurinta aceste informatii pentru a construi mecanisme delta eficiente, cum ar fi recalcularea si inlocuirea unei partitii ale carei date de intrare s-au modificat sau efectuarea unor verificari eficiente ale calitatii datelor pe baza datelor actualizate.

Merita sa ne gandim la cat timp trebuie dezvoltat un dezvoltator intr-un cadru ca acesta. Daca, de exemplu, toate lucrarile imaginabile intr-o anumita zi pot functiona ca o incarcare completa, deoarece volumele de date sunt reduse, nu este necesar sa optimizati actualizarile delta pe baza metadatelor.

Acum completam cele trei principii de proiectare enumerate mai sus cu trei blocuri de constructie care alcatuiesc sistemul nostru de conducte de date bazat pe fluxul de aer Airtunnel .

Magazin de date fizice

Fiecare strat de date trebuie sa stocheze datele in mod constant si eficient. Acesta este motivul pentru care depozitul de date fizice – fie ca este un sistem SQL, o bucket S3 sau un serviciu de stocare a datelor in cloud – este un element cheie, demn de o structura riguroasa.

Intr-un mediu de stocare scalabil, de tip sistem de fisiere, de exemplu, o abordare comuna a structurii include:

ingestie : fisiere brute primite din surse

  • aterizare : Fisierele de date primite vor fi incarcate aici 1: 1 si vor fi completate cu un marcaj de timp de sosire
  • arhiva : Fisierele de la aterizare care au fost consumate de o conducta vor fi mutate aici

gata : active de date procesate care sunt gata sa fie citite, fiecare aflandu-se in propriul folder. Activele gata pot fi partitionate suplimentar folosind o conventie de folder stil Hive / Spark, conform careia fiecare subfolder este denumit folosind predicatul partitiei (util pentru a citi fara probleme activele de date folosind Hive, Spark sau PyArrow).

etapizare : fisierele din etapa nu sunt destinate consumului general, deoarece sunt incomplete sau se lucreaza in prezent. Stadializarea este impartita in continuare in preluare (date care au fost mutate acolo de la ingestie / aterizare), intermediare (orice fel de date temporare pentru etapele intermediare de procesare) si gata (unde se produce urmatoarea versiune pentru stratul gata). Utilizati o operatiune de mutare atomica (sau tranzactie SQL) pentru a impinge datele finalizate de la stadiul / gata la gata, astfel incat consumatorii sa nu intampine niciodata probleme de acces sau sa acceseze fisierele pe jumatate finalizate.

arhiva : ori de cate ori a fost calculata o noua versiune a unui material gata si este valoros sa pastrati o copie a rularii anterioare, mutati-o aici sub [nume-activ] / [timp de incarcare] /.

export : Aceasta este pentru ca fisierele sa fie exportate catre alti consumatori si care nu vor fi niciodata reintroduse in activele de date continute in folderele de mai sus. Exemplele includ exporturi CSV finale, date si rapoarte specifice front-end.

Magazin de scripturi de declaratii si date

O parte din baza de cod controlata de versiune ar trebui sa fie un depozit de declaratii asa cum s-a mentionat mai sus. Scopul aici este de a avea un fisier de declaratie pentru fiecare material de date, numit exact ca materialul de date:

/declarations/daily_sales_header.yaml

/declarations/daily_sales_line_item.yaml

/declarations/product_master.yaml

Daca depozitul de date fizice este un RDBMS care foloseste intens schemele, va recomandam sa cuibrati numele fisierelor in consecinta, astfel incat sa aveti /declarations/fact/daily_sales_line_item.yaml pentru activul de date fact.daily_sales_line_item

In mod similar, ar trebui sa structurati scripturile de date ca parte a bazei de cod si in functie de limba, utilizand in primul rand numele activului de date care este produs sau actualizat ca nume de fisier:

/scripts/py/daily_sales_header__ingest.py

/scripts/sql/ddl/daily_sales.sql

/scripts/sql/dml/daily_sales_header__postprocessing.sql /

scripts/

sql/ ddl/ daily_sales_ag

Un sufix de nume de script care urmeaza numele activului de date, cum ar fi „__estest” de mai sus, poate indica ce se intampla. Procedand astfel, putem intelege cu usurinta (fara a citi nici macar un cod!) Ca ingestia de date se face folosind Python, urmata de post-procesare folosind un script SQL si o agregare care va produce noul activ de date daily_sales_aggregated. De asemenea, retineti ca scripturile SQL sunt clasificate in scripturi dml si ddl.

O abordare chiar mai curata este structurarea scripturilor imperative Python in jurul unui strat de abstractizare a activelor de date, furnizat de o clasa Python. Consultati mai jos „Asamblarea tuturor” de mai jos pentru a vedea acest lucru in actiune!

Operatori personalizati

Out of the box, Airflow comes with an impressive set of operators and hooks. While we advocate making as much use of them as possible, you will have to create custom operators to facilitate the framework we have introduced up to this point.

Ideea principala este ca majoritatea operatorilor personalizati cu logica distincta (sa numim unul PySparkIngest) ar primi in primul rand numele activului de date afectat de operatiune. Folosind numele unic al activului de date, operatorul poate incarca fisierul declaratiei din depozitul de declaratii. Pentru a-si indeplini sarcina, operatorul ar depinde de proprietatile (cum ar fi sistemul sursa, numele de fisier regex si randul de antet) provenite din fisierul de declaratie, in timp ce codul sau ramane generic. Daca este necesar, operatorul poate fi completat sau partial suprascris de actiuni imperative specifice activelor de date. De exemplu, acestea ar putea fi definite in /scripts/py/daily_sales_header__ingest.py. Alti operatori, cum ar fi SQLOperator, vor primi pur si simplu calea unui script capabil de sablon sub / scripturi de-a lungul parametrilor.

Ati ajuns la sfarsitul acestei postari, asa ca felicitarile sunt in ordine! Rabdarea dvs. va rasplati in curand, deoarece tot ceea ce este descris mai sus este pregatit pentru a fi folosit la urmatorul dvs. proiect. Verificati tunelul aerian pentru:

  • Baza de cod a planului Airflow utilizand abstractizari ale activelor de date
  • Magazin declaratie , impreuna cu o interfata Python pentru bootstrap captarilor de active date din fisiere cu declaratii, de incarcare si le prelucreaza, si multe altele.
  • Structura fizica de stocare a datelor exemplificata pe disc local si usor de extins la orice stocare printr-o interfata.
  • Mai multi operatori personalizati care prezinta punctele forte ale planului nostru de tunel aerian.
  • Extensii de metadate la modelul de date Airflow, inclusiv colectarea de linii de materiale de date fara durere

Arhitectura tunelului aerian

Suntem increzatori ca, atunci cand aplicati ceea ce am descris mai sus la urmatorul dvs. proiect de canalizare a datelor, veti avea succes. Va rugam sa ne trimiteti gandurile si contributiile dvs., astfel incat sa putem continua sa imbunatatim aceasta solutie open-source pentru binele tuturor. Multumesc, si fericit pipelining!

[1] Un flux de lucru este o secventa de sarcini sau pasi care trebuie efectuate in ordine, similar unui proces. In scopul acestui articol, fluxurile de lucru vor consuma si transforma resurse IT, cum ar fi sisteme si date.

[2] Dupa cum a fost publicat pe GitHub in august 2019.

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR