Olet varmaan jossain välissä uraasi törmännyt data -ympäristöön, jossa Windows Task Scheduler, crontab, ETL -työkalu tai pilvipalvelu käynnistävät datan siirto tai muokkaus -skriptejä itsenäisesti, toisista työkaluista riippumatta ja ennalta määritetyn kellotaulun mukaisesti. Ajot toimivat todennäköisesti suurimman osan ajasta täydellisesti, mutta uusien ajojen lisääminen tai kokonaisuuden hahmottaminen on välillä vaikeaa. Ajojen riippuvuuksien ymmärtäminen ja hallinta on todella haastavaa. Voit vain haaveilla Data Lineagesta, kun kunnollista historiatietoa ajojen kestosta tai onnistumisprosentista ei edes kerätä (ellei sähköpostiin tulevia ilmoituksia lasketa sellaisiksi). Jos tämä kuulostaa tutulta, niin Apache Airflow voi todennäköisesti ratkaista ongelmasi yhtä tehokkaasti kuin Patrik Laine ylivoimalla vasemman B-pisteen alapuolelta.
Yllä esitetty haaste ei ole mitenkään uusi ja markkinoilla on ollut jo pitkään useita tuotteita, jotka on suunniteltu tämän ongelman ratkaisuun. Rajaamalla Enterprise -tason ratkaisut ulos, löytyy tällä hetkellä open source -maailmasta esimerkiksi Apachen Oozie Hadoop -jobien kontrollointiin, LinkedInin kehittämä Azkaban ja Luigi Spotifyn tiimiltä. Muita kuin pelkästään Hadoop -ympäristön tuotteiden hallintaan tarkoitettuja varteenotettavia tuotteita ei ole vielä ilmestynyt, vaikka Apache Airflow yrittääkin olla sellainen.
Ymmärtääkseen mistä on kysymys, on ensin ymmärretävä, mikä on DAG?
Ennen kuin voi ymmärtää mikä on Airflow ja mistä se on kotoisin, on ensin ymmärretävä mikä on DAG. DAG on lyhenne sanoista ”Directed acyclic graph”. Suomenkielisen Wikipedian mukaan se on suunnattu syklitön verkko, joka ”..koostuu solmuista ja solmujen välisistä suunnatuista kaarista siten, että kaaria pitkin ei ole mahdollista kulkea suunnattua polkua, joka päätyisi lähtöpisteeseensä.” Täyttä hepreaa ensilukemalta siis. Tässä tapauksessa kuva vastaa kuitenkin tuhatta sanaa.
Esimerkki 1. Yksinkertainen DAG. Jokainen laatikoista esittää DAGin taskia, mikä vuorostaan voi olla mitä tahansa yksinkertaisesta bash-komennosta SQL tai Hive -kyselyyn.
Käytännössä DAG on puumainen rakenne, jossa eri tehtävien välille voidaan tehdä riippuvuuksia. Tehtävät voivat haarautua siten, että ne suoritetaan riippumatta siitä vaikka toisen haaran tehtävät epäonnistuisivat. Kärjistäen voidaan sanoa, että esimerkiksi useiden cron -tehtävien välille voitaisiin rakentaa riippuvuuksia siten, että ne käynnistyvät tai ovat käynnistymättä riippuen toistensa onnistumisesta.
Maxime Beauchemin neronleimaus
Googlettamalla ”airbnb airflow” löytää useita blogi -julkaisuja jo parin vuoden ajalta, jossa ihmiset kehuvat Maxime Beauchemin Airbnb:ssa kehittämää Airflow -tuotetta. Suosittelen tutustumaan Maximen kirjoittamiin ”The Rise of Data Engineer” ja sen jatko-osan ”The Downfall of Data Engineer” -blogikirjoitukset, jotka kuvaavat hyvin mitä datan kanssa työskentely nykypäivänä tarkoittaa. Myös kirjamerkitsemään miehen GitHub-profiilin alta löytyvän Data Engineerin työkalupakkilistan.
Kuten arvata saattaa, Airflow kehitettiin Airbnb:ssä sisäisesti ratkaisemaan kirjoituksen alussa esitettyä ongelma. Markkinoilta ei löytynyt Airbnb:lle sopivaa ohjelmistoa hallitsemaan alati kasvavien ajojen hallintaa, joten ongelma ratkaistiin rakentamalla sovellus itse. 2017 syyskuussa Airflow liittyi virallisesti Apachen sateenvarjon alle, Maximimen jatkaessa edelleen pääkehittäjänä.
Mikä siis on Apache Airflow?
Airflow yrittää ratkaista dataputkien hallinta, ylläpito- ja käsittelyongelmaa muodostamalla putkista DAGeja, joita Airflow hallitsee ja käynnistää. DAGit kirjoitetaan python-koodilla, joten halutut ominaisuudet muodostetaan tuomalla koodiin vain tarvittavat kirjastot ja lisäämällä halutut taskit DAGin sisään. Taskeja voi olla DAGin sisällä rajattomasti ja näiden väliset riippuvuudet kuvataan koodissa hyvin yksinkertaisella tavalla.
Tämä on esimerkiksi hyvin yksinkertainen DAG, jossa Airflow -palvelimelle asennetun sqlcmd -komentotyökalun avulla kopioin tuotannon kannan testiin hyväksi käyttäen aiemmin luomiani backup ja restore -proseduureja. DAGin lopussa näkee hyvin miten riippuvuudet kuvataan muutamilla linnunnokilla.
Tämä voi näyttää haastavalta aluksi, mutta rajallisellakin osaamisella pääsee hyvin alkuun kuvaavien esimerkkien ansiosta.
Mitä pellin alta löytyy?
Airflow koostuu yksinkertaisesta gunicorn -webserveristä, kaiken sydämenä toimivasta skaalautuvasta schedulerista, taskien suorittajista (worker) ja ajojen suoritushistorian sekä DAGin statuksen ylläpitävästä metadata-kannasta. Web -käyttöliittymästä pystyy käynnistämään ja hallitsemaan ajoja sekä myös näkemään tilannekuvan eri ajojen senhetkisestä statuksesta.
Esimerkki 2. Meidän oman ’Agile Data Engine demo’ -ympäristön esimerkki ’stage-lataukset’ ’Landing Tree’ -näkymän piirtämänä.
Web-käyttöliittymään on myös sisäänrakennettu useita erilaisia näkymiä, joista yksinkertaisin lienee etusivun liikennevalonäkymä, joka näyttää tutut värikoodaukset kaikista suoritetuista ja ajossa olevista ajoista. Tähän päälle UI tarjoaa lisäksi myös valmiiksi piirretyn Gantt-, riippuvuus- ja kestonäkymät, joihon piirretään jatkuvaa graafia ajojen suoritusajan mukaan.
Kuulostaako liian hyvältä ollakseen open -source tuote? Asian laita on yhtä tosi kuin se, että Lauri Markkanen on tällä hetkellä tulokkaista keskiarvoltaan paras kolmosten heittäjä. Ja siis tulokkaista paras kautta aikojen, ei vain tämän kauden.
Ei viivojen vetämistä vaan generoitua python-koodia
DAGien perustuminen python-koodiin on yksi Airflown parhaista puolista. Koodin generoinnin voi automatisoida, sen voi tallentaa versionhallintaan, suoritettavat taskit ovat selkeästi nähtävissä ja kaiken logiikan ollessa koodissa metadatakannasta ei tule pullonkaula. Koodi myös mahdollistaa laajennettavuuden. Jos jokin ominaisuus uupuu, voit lisätä sen itse kirjoittamalla tarvittavan operaattorin sen sijaan, että odottaisit valmistajan seuraavaa versiota.
DAGit myös ratkaisevat itsessään monia haasteita, mitkä ovat nykyisellään ratkaistu erillisillä tarkistusajoilla tai rakentamalla useita ajoketjuja. Esimerkkinä tämän voisi kuvata siten, että lähdejärjestelmän staging-lataus laukaisee neljä erillistä ajoa, jotka taas laukaisevat lisää ajoja. Airflowssa DAGit voidaan rakentaa siten että yhden erillisen ajon epäonnistuminen ei invalidoi koko ajoketjua, vaan ainoastaan kyseisen puun alla olevat ajot. Cronissa tällaisen rakentaminen on se kuuluisa virveli mihin kukaan ei halua koskea jälkikäteen.
Onko se tuotantovalmista kamaa?
Lyhyesti: on, jos olet valmis myös itse laittamaan työhanskat käteen.
Olen käyttänyt Airflowta kollegojeni kanssa kohta vuoden päivät ja olemme siirtyneet tuotantokäyttöön, koska uskomme todella tuotteeseen. Alun tuskailujen jälkeen olemme saaneet ympäristön vakaaksi kuin kivi ja Airflowsta löytyy jo nyt tarvittavat ominaisuudet ottaa yhteys eri järjestelmiin. Lisäksi tuki tuntuu lisääntyvän joka kuukausi.
Voimme tällä hetkellä generoida suuren osan ETL-ajoistamme koodina ja komentaa eri lähde -ja kohdejärjestelmiä yhden näkymän alta. Windows-tuki on vielä vaiheessa, mutta koodipohjaisuuden ansiosta olemme saaneet itse rakennettua Kerberos -tuen mahdollistaen Windows-koneiden käskyttämisen AD-tunnuksia hyväksikäyttäen.
Toki tuotteesta näkee vielä, että kyseessä on kehityksessä oleva open source -tuote, mutta sen nykyiset ominaisuudet korvaavat jo nyt isoimmat puutteet. Puutteet näkyvät tällä hetkellä Airflown omalla roadmapilla hyvin. Tuote ei tue hyvin multitenantti-arkkitehtuuria, DAGien näkyvyyttä ei voida rajoittaa roolipohjaisesti ja korkean käytettävyyden ratkaisu pitää rakentaa itse. Schedulerin selkeyttämisessä on myös parantamisen varaa.
Suosittelenkin kokeilemaan Airflowta omassa VirtualBoxissa tai EC2-instanssissa. Asentaminen on hyvin yksinkertaista ja alkuun pääsee nopeasti. Tämän jälkeen jos jää aikaa, niin kannattaa tutustua Maximen toiseen projektiin; Apache Supersetiin. Apache Superset on open -source visualisointituote, jonka ideana tuoda samat ominaisuudet open source -maailmaan, mistä tällä saa nauttia vain maksullisissa tuotteissa. Itse olen ainakin hyvin kiinnostunut Supersetistä ja ajoin seurata tarkasti sitä, miten tuote kehittyy.
