Python ökoszisztéma felépítése a hatékony és megbízható fejlesztés érdekében

Tl;dr: Ez a blogbejegyzés leírja, hogyan fejlesztettünk ki egy hatékony, megbízható Python-ökoszisztémát a Pants, egy nyílt forráskódú buildrendszer segítségével, és hogyan oldottuk meg a Python-alkalmazások nagy léptékű kezelésének kihívását a Coinbase-en.

A Coinbase Compute Platform Team által

A Python az egyik leggyakrabban használt programozási nyelv adattudósok, gépi tanulással foglalkozó szakemberek és a Coinbase blokklánc-kutatói számára. Az elmúlt néhány évben a Python-alkalmazások növekedésének lehettünk tanúi, amelyek célja a kriptovaluta világában számos kihívást jelentő probléma megoldása, mint például az Airflow adatfolyamok, blokklánc-elemző eszközök, gépi tanulási alkalmazások és sok más. Belső adataink alapján 3 harmadik negyedéve óta csaknem megduplázódott a Python alkalmazások száma. Belső adataink szerint ma hozzávetőleg 2022 Pythonnal fejlesztett adatfeldolgozási folyamat és szolgáltatás létezik. Az építések teljes száma heti 1,500 körül van a cikk írásakor. Még szélesebb körű alkalmazást tervezünk, mivel több Python-központú keretrendszer (például Ray, Modin, DASK stb.) kerül be az adatökoszisztémába.

A mérnöki siker nagyrészt a megfelelő szerszámok kiválasztásából fakad. Egy nagyszabású Python ökoszisztéma felépítése a növekvő mérnöki követelményeink támogatására bizonyos kihívásokat vethet fel, beleértve a megbízható összeállítási rendszer használatát, a rugalmas függőségkezelést, a gyors szoftverkiadást és a következetes kódminőség-ellenőrzést. Ezek a kihívások azonban integrálással leküzdhetők Nadrág, a Toolchain labs által kifejlesztett összeállítási rendszer a Coinbase build infrastruktúrájába. Ezt választottuk Python build rendszernek a következő okok miatt:

1. A nadrág ergonomikus és felhasználóbarát,
2. A Pants számos összeállítással kapcsolatos parancsot megért, mint például a „test”, „lint”, „fmt”, „typecheck” és „package”
3. A Pants a valós Python használatára készült, mint első osztályú használati eset, beleértve a harmadik féltől származó függőségek kezelését is. Valójában a Pants egyes részei Python nyelven íródnak (a többi Rust nyelven).
4. A Pantsnak kevesebb metaadatra és BUILD-fájlra van szüksége, mint más eszközöknek, köszönhetően a függőségi következtetés, ésszerű alapértelmezések és a BUILD fájlok automatikus generálása. A Bazelnek hatalmas mennyiségű, kézzel írott BUILD kazánra van szüksége.
5. A Pants könnyen bővíthető egy erőteljes beépülő API-val, amely idiomatikus Python 3 aszinkronkódot használ, így a felhasználók természetes vezérlési folyamatot kaphatnak a bővítményeikben.
6. A Pants valódi OSS-irányítással rendelkezik, ahol bármely szervezet azonos szerepet játszhat.
7. A nadrág gyengéd tanulási görbével rendelkezik. Sokkal kisebb a súrlódása, mint más eszközöknek. A karbantartási költségek mérsékeltek az eszköz egy kattintással történő telepítésének és az egyszerű konfigurációs fájloknak köszönhetően.

A Python az egyik legtöbb népszerű programozási nyelvek gépi tanuláshoz és adattudományi alkalmazásokhoz. Azonban a Python-first build rendszer, a Pants elfogadása előtt a Python ökoszisztémába való belső befektetésünk alacsony volt, mint a Golang és a Ruby – a Coinbase szolgáltatások és webalkalmazások írásának elsődleges választása – befektetései.

A Coinbase monorepo használati statisztikái szerint a Python ma már csak a használat 4%-át teszi ki, mert hiányzik a rendszerépítési támogatás. 2021 előtt a Python-projektek többsége több tárolóban volt egységes felépítési infrastruktúra nélkül – ami a következő problémákhoz vezetett:

1. A kódmegosztással kapcsolatos kihívások: A megosztott könyvtár frissítésének folyamata összetett volt. A kódon végrehajtott módosításokat közzétették egy belső PyPI-kiszolgálón, mielőtt bebizonyosodott, hogy stabilabbak. Egy új verzióra frissített, de nem kellően tesztelt könyvtár potenciálisan megszakíthatja azt a függőt, amely rögzített verzió nélkül fogyasztotta a könyvtárat.
2. Az egyszerűsített kiadási folyamat hiánya: A kódváltoztatás gyakran bonyolult, több tárhelyre kiterjedő frissítéseket és kiadásokat igényelt. Nem volt automatikus munkafolyamat a vonatkozó változtatások integrációs és szakaszolási tesztjeinek elvégzésére. A koherens megfigyelhetőség és megbízhatóság hiánya óriási mérnöki ráfordítást rótt fel.
3. Ellentmondásos fejlesztési tapasztalatok: A fejlesztési tapasztalatok nagyon változatosak voltak, mivel minden adattárnak megvolt a maga módja a virtuális környezet beállításának, a kódminőség ellenőrzésének, a felépítésnek és a telepítésnek stb.

Úgy döntöttünk, hogy megépítjük a PyNestet – egy új Python „monorepót” a Coinbase adatszervezete számára. Nem az a szándékunk, hogy a PyNest monorepoként használja az egész vállalatot, hanem az, hogy az adattárat az adatszervezeten belüli projektekhez használják.

1. Az egész vállalatra kiterjedő monorepo felépítéséhez elit csapatra van szükség. Nincs elég csapatunk ahhoz, hogy reprodukáljuk a monorepos sikertörténeteket a Facebookon, a Twitteren és a Google-on.
2. A Python-t elsősorban a vállalat adatszervezetén belül használják. Fontos a megfelelő hatókör beállítása, hogy az adatok prioritásaira összpontosíthassunk anélkül, hogy az ad hoc követelmények elvonnák a figyelmünket. A PyNest build infrastruktúráját más csapatok is felhasználhatják Python-tárolóik felgyorsításához.
3. Kívánatos, hogy a kölcsönösen függő projekteket (lásd az ML platform projektek függőségi grafikonját) egyetlen tárolóba konszolidálja a véletlen ciklikus függőségek elkerülése érdekében.

1. ábra: Gépi tanulási platform (MLP) projektek függőségi grafikonja.

1. Bár a monorepo a termelékenység új világát ígérte, bebizonyosodott, hogy nem hosszú távú megoldás a Coinbase számára. A Golang monorepo egy lecke, ahol egy év használat után olyan problémák merültek fel, mint a szétterülő kódbázis, a sikertelen IDE-integrációk, a lassú CI/CD, az elavult függőségek stb.
2. A nyílt forráskódú projekteket külön tárolókban kell tartani.

Az alábbi grafikon a Coinbase tároló architektúráját mutatja, ahol a zöld blokkok jelzik az általunk felépített új Python ökoszisztémát. A lerakatközi működést olyan rétegek kiszolgálásával érik el, beleértve a kódtermékeket és a séma-nyilvántartást.

2. ábra. A Coinbase adattár architektúrája

# harmadik féltől származó függőség

# harmadik féltől származó függőség├── 3. fél│ ├── függőség1│ │ ├── ÉPÍTÉS│ │ ├── követelmények.txt│ │ └── solve1.lock # lockfile│ ││ └── függőség2│ │ ├── ÉPÍTÉS│ │ ├── követelmények.txt│ │ └── solve2.lock...│# megosztott könyvtár├── lib│# legfelső szintű projektmappa├── projekt1 # projekt neve│ ├── src│ │ └── python│ │ ├── adattégla│ │ │ ├── ÉPÍTÉS│ │ │ ├── TULAJDONOSOK│ │ │ ├── gateway.py│ │ │ ...│ │ └── notebook│ │ ├── ÉPÍTÉS│ │ ├── TULAJDONOSOK│ │ ├── etl_job.py│ │ ...│ └── teszt│ └── python│ ├── adattégla│ │ ├── ÉPÍTÉS│ │ ├── gateway_test.py│ │ ...│ └── jegyzetfüzet│ ├── ÉPÍTÉS│ ├── etl_job_test.py│ ...├── projekt2...│# Docker fájlok├── docker-fájlok│# eszközök szöszöléshez, formázáshoz stb.├── eszközök│# Buildkite CI munkafolyamat├── .buildkite│ ├── pipeline.yml│ └── horgok│# Nadrágkönyvtár├── nadrág├── nadrág.toml└── pants.ci.toml

3. ábra Pynest adattár szerkezete

Az alábbiakban felsoroljuk a tár főbb elemeit és azok magyarázatát.

1. 3. fél

A harmadik féltől származó függőségek ebbe a mappába kerülnek. A Pants elemzi a követelmények.txt fájlokat, és automatikusan létrehozza a „python_requirement” célt minden egyes függőséghez. Ugyanazon függőség több verzióját is támogatja a Pants több zárfájl funkciója. Ez a funkció lehetővé teszi, hogy a projektek ütközésbe kerüljenek akár közvetlen, akár tranzitív függőségekben. A Pants zárfájlokat generál, hogy rögzítse az összes függőséget, és biztosítsa a reprodukálható összeállítást. További magyarázatok a nadrág többszörös zárról a függőség kezelése szakasz.

2. Lib

Az összes projekt számára elérhető megosztott könyvtárak. A PyNest projektjei közvetlenül importálhatják a forráskódot. A PyNest-en kívüli projektek esetében a könyvtárak a kerékfájlok belső PyPI-kiszolgálóról történő pip-telepítésével érhetők el.

3. Projekt mappák

Az egyes projektek ebben a mappában találhatók. A mappa elérési útja a következő formátumban van: „{projekt_neve}/{src vagy teszt}/python/{névtér}”. A forrásgyökér „src/python” vagy „test/python”-ként van konfigurálva, és az alatta lévő névtér a modulok elkülönítésére szolgál.

4. Kódtulajdonos fájlok

A kódtulajdonos fájlok (OWNERS) hozzáadódnak a mappákhoz, hogy meghatározzák a mappafában található kódért felelős személyeket vagy csoportokat. A CI-munkafolyamat parancsfájlt hív meg, amely az összes OWNERS-fájlt egy CODEOWNERS-fájlba fordítja a „.github/” alatt. A kódtulajdonos-jóváhagyási szabály előírja, hogy az összes lekérési kérelemnek legalább egy jóváhagyással kell rendelkeznie a kódtulajdonosok csoportjától, mielőtt összevonhatók.

5. Eszközök

Az Eszközök mappa tartalmazza a kódminőségi eszközök konfigurációs fájljait, pl. flake8, black, isort, mypy stb. Ezekre a fájlokra hivatkozik a Pants a linterek konfigurálásához.

6. Buildkite munkafolyamat

A Coinbase a Buildkite-t használja CI platformként. A Buildkite munkafolyamat és a hook definíciói ebben a mappában vannak meghatározva. A CI munkafolyamat meghatározza a lépéseket, mint pl

• Ellenőrizze, hogy szükség van-e a függőségi zárolási fájlok frissítésére.
• Hajtsa végre a szöszöket és a kódminőségi eszközöket.
• Forráskód és dokkolóképek készítése.
• Egység- és integrációs teszteket futtat.
• Jelentéseket készít a kód lefedettségeiről.

7. Docker-fájlok

A docker-fájlok ebben a mappában vannak meghatározva. A docker lemezképeket a CI-munkafolyamat készíti, és a Codeflow – a Coinbase belső telepítési platformja – telepíti.

8. Nadrágkönyvtárak

Ez a mappa tartalmazza a Pants parancsfájlt és a konfigurációs fájlokat (pants.toml, pants.ci.toml).

Ez a cikk leírja, hogyan építjük fel a PyNestet a Pants build rendszer segítségével. Következő blogbejegyzésünkben a függőségkezelésről és a CI/CD-ről fogunk beszélni.