Reakció erre: https://medium.com/better-programming/data-engineering-is-not-software-engineering-af81eb8d3949
Csak épp nem vallja be magának, hogy az.
Előrebocsátom: szeretem, amikor valaki megpróbál rendet vágni a szakmában, de a "data engineering nem software engineering" kijelentés annyira önellentmondásos, hogy az ember nem tudja, nevetni vagy jegyzetelni kezdjen. A data engineer kódot ír, tesztel, debugol, verziókezel, CI/CD-zik, logol, dokumentál és deployol - de nem szoftvermérnök? Persze. Mint amikor a pék azt mondja, ő nem süt kenyeret, csak lisztet formáz melegebb környezetben.
A szerző szerint a data pipeline nem alkalmazás, mert "nincs felhasználó". Ez már az első csúsztatás: minden pipeline-nak van felhasználója, csak épp nem ember, hanem egy másik rendszer. Egy API sem lesz kevésbé szoftver attól, hogy nem közvetlenül kattintgatják.
A data pipeline is egy alkalmazás, csak nem egy weboldalt renderel, hanem adatot alakít át. Input, logika, output. Ez pont az a három dolog, amiből a szoftver áll.
Ha a különbség az, hogy az egyikben print("Hello World"), a másikban meg df.to_parquet(), akkor ez nem filozófiai határ, hanem fájlrendszer-szintű különbség.
Ez a rész kifejezetten fájdalmas volt. Az agilitás nem azt jelenti, hogy kéthetente kész terméket kell szállítani, hanem hogy rendszeresen validálod az irányt, és képes vagy reagálni a változásra. Ha a data csapat hónapokig épít valamit, amit a végén senki sem használ, az nem a "data sajátossága", hanem rossz menedzsment.
A pipeline fejlesztése is felbontható iterációkra: adatforrás validálása, modellváz, első mintarun, minőségmérés, optimalizálás. Ezek mind review-zható, bemutatható lépések. A "data nem iterálható" inkább azt jelenti, hogy a szerző még soha nem vezetett iteratív fejlesztést.
Ez a fajta bináris gondolkodás minden mérnöki területen katasztrófa. A "vagy működik, vagy nem" szemlélet a tesztelés előtti korszakból származik. Egy pipeline lehet használható, részlegesen hasznos, javításra szoruló, vagy újratervezendő. A modellek, feature store-ok, és data martok mind fokozatosan fejlődnek. Aki szerint egy dataset vagy száz százalékos, vagy kukázandó, az valószínűleg még nem próbált production-ban adatot szolgáltatni napi szinten.
A valóság az, hogy minden adat pipeline MVP. Minden nap jön új adat, új hiba, új edge case, amitől jobb lesz. Ez pont az agilitás definíciója.
Ezzel a mondattal egy egész szakmát dobunk ki az ablakon. Természetesen lehet tesztelni adatfolyamokat, csak nem úgy, ahogy egy gombnyomást. Schema validation, sampling, referenciateszt, data contract - mind létező, bevett módszerek. Ha valaki azt mondja, hogy "a data pipeline-t csak production-ben lehet kipróbálni", az vagy nem ismeri az eszközeit, vagy nincs kedve megtanulni őket.
A jó data engineer pontosan tudja, hol húzódik a határ az automatizáció és az üzleti validáció között. Ez nem a szakma korlátja - ez a szakma.
Ez a kedvencem. Igen, egy pipeline fejlesztésének van előkészítési fázisa, mert az adatot meg kell ismerni - de ettől még nem lesz waterfall. A waterfall azért bukott meg, mert az életben semmi sem stabil. A forrásrendszer változik, a séma változik, a customer igény változik. Ha valaki vízesésszerűen akar fejleszteni adatot, az első production release után meg is fullad benne.
A sikeres data csapatok - Netflix, Airbnb, Uber - mind agilisek. Nem azért, mert divat, hanem mert csak így lehet életben maradni. Aki "lite waterfall"-ban gondolkodik, az épp azt a rugalmasságot adja fel, ami a data engineering legnagyobb túlélési stratégiája.
Dehogynem. Ha kódot írsz, verziót kezelsz, tesztelsz, deployolsz, rollbackelsz és monitorozol - akkor szoftvert fejlesztesz. Az, hogy a kimenet adat, nem mentesít a mérnöki elvek alól.
A data engineer attól különbözik a szoftverestől, hogy szintén ugyanazt a mérnöki gondolkodást kell alkalmaznia, de másik domainen. De ettől még nem lesz "másik szakma". Ez ugyanaz a hegy, csak másik oldalon mászunk.
A data engineering nem varázslat. Nem kell hozzá külön vallás, más módszertan, vagy új kifejezések. Csak jó szoftvermérnökök kellenek, akik értik az adatot.
Az adat nem törékenyebb, mint a kód - csak az, aki írja, gyakran kevésbé fegyelmezett.
Nem a data engineering más. Csak az lett a divat, hogy mentegetjük a saját technikai adósságainkat vele.