Поўнае кіраўніцтва пра тое, як разбіць маналіт дадзеных.

Як змагацца з новай вялікай мэтай у свеце праграмнага забеспячэння.

Разбівайце маналіт дадзеных!

Матывацыя

Маналіт дадзеных

Чалавек - адзінае жывёла, якое двойчы ездзіць па адной скале. Пасля многіх гадоў размоваў пра парушэнне маналіту ў сферы паслуг мы зноў зрабілі тое ж самае: маналіты дадзеных (ён жа азёры дадзеных і сховішчы дадзеных).

Я працую над многімі праектамі (у розных кампаніях) на працягу апошніх гадоў, і я бачыў, што праблемы маналіту дадзеных падобныя:

  • Памылкі ў дадзеных з-за змяненняў не каардынуюцца паміж кодам і трубаправодамі дадзеных.
  • Звычайна маналіт стварае інфармацыйныя бункеры, таму што нам патрэбны спецыялісты па пытаннях кода і спецыялізаваныя каманды па дадзеных і машынным навучанні.
  • Па меры таго, як кампаніі растуць, у нас усё больш крыніц дадзеных, і гэта тое, што толькі расце, што робіць наяўнасць дадзеных у адным месцы цяжкай задачай.
  • Людзям, якія працуюць у трубаправодах, звычайна цяжка зразумець сэнс дадзеных правільна (прынамсі, не лепш, чым людзі, якія іх ствараюць), паколькі ў іх менш кантэксту.
  • Часам неабходна зрабіць масавыя абнаўлення ў сховішчах дадзеных, каб выправіць непаразуменні і супярэчлівыя дадзеныя ў працэсах ETL.
  • Цяжка скараціць разрыў паміж новай ідэяй і калі гэтая ідэя знаходзіцца ў вытворчасці. Таму мы не можам інававаць. Калі вы павольныя, вы не можаце прайсці хуткі цыкл праверкі і навучання, і без гэтага вы не зможаце ўносіць інавацыі.

Акрамя таго, маналіт дадзеных - гэта на самай справе маналіт, і мы разумеем шмат дрэнных рэчаў (прычым добрых). таму нам не трэба тлумачыць, як гэта можа быць праблемай (звязаныя службы, праблемы з выпускам новых функцый, якія перашкаджаюць пастаянным разгортванню, брудная тэставая стратэгія і г.д. ...).

Звычайны спосаб зрабіць гэта

Фактычны спосаб - зрабіць акцэнт у нашых службах, а потым, атрымаўшы ETL, атрымаць дадзеныя, якія службы / крыніцы вырабляюць, і пасля некаторых пераўтварэнняў змясціць дадзеныя ў выглядзе месца, дзе пасля яны будуць выкарыстоўвацца / абслугоўвацца (маніторы дадзеных, API, BigQuery, мадэль трубаправодаў і г.д.). Гэтыя працэсы вырабляюцца ўнутры трубаправодаў перадачы дадзеных, і, як мы ўжо казалі, перш чым мы можам адрозніць тры зразумелыя часткі (ETL):

  • Па-першае, працэс, які прымае дадзеныя з розных крыніц.
  • Частка апрацоўкі, дзе мы ачышчаем дадзеныя і робім некаторыя пераўтварэнні ўздоўж трубаправодаў перадачы дадзеных.
  • Крок абслугоўвання дадзеных няспраўны. У нашым выпадку BigQuery робіць гэтую паслугу дадзеных.
Маналіт дадзеных дадзеных

Як разбіць маналіт

Ідэя гэтага развязкі складаецца ў тым, каб разбіць гэты канвеер у некаторых трубаправодах, па даменах альбо добра, па службах такім жа чынам, як і мы з службамі кода.

Такім чынам, што рабіць, калі б не адзін трубаправод, кожная служба мела ўласную (або больш), якая б апрацавала ўласныя дадзеныя? Такім чынам, кожная служба павінна адказваць за чыстую, пераўтварэнне і абмен уласнымі дадзенымі ў нязменных наборах дадзеных як прадуктаў.

Што мы можам перамагчы з гэтай зменай? Перш за ўсё, не трэба забываць, што ў розных службах адбылося шмат зменаў. Вось калі пачынаюцца праблемы, таму што альбо мы забываем узгадняць з дадзенымі людзей пра змены, альбо гэтая каардынацыя ў гэты момант немагчымая. Сапраўды, здаецца, што адказнасць не парушаць аналітыку ці іншыя паслугі ў дадзеных, што каманда мяняе паслугі, так? Акрамя таго, хто ведае лепш, чым гэтая каманда пра тое, як працуюць дадзеныя і які фармат?

Такім чынам, кожны дамен рыхтуе свае дадзеныя, змяшчае іх у якасці прадукту ў брокера для абмену паведамленнямі, адкуль іншыя сэрвісы, струменевыя інструменты, кіраванне, аналітыка, інструменты навукоўцаў дадзеных (як нататнік юпітэра), машыннае навучанне, канвеер, глабальнае сховішча і шмат іншага больш, можна іх дасягнуць.

Стратэгія размеркавання дадзеных

Акрамя гэтага, я ўпэўнены, што калі вы зараз нічога не зробіце з машынным навучаннем, вы будзеце рабіць. Такім чынам, падумайце, ці можна зрабіць добрую мадэль, не маючы добрых дадзеных? Калі вы хочаце зрабіць добрую працу ў ML, вам, верагодна, патрэбен мадэльны трубаправод, таксама па дамене, і ён будзе мець патрэбу ў гэтым трубаправодзе дадзеных. Калі вы хочаце атрымаць дадатковую інфармацыю па гэтай тэме, вы можаце прачытаць гэты іншы пост, які я напісаў: пастаяннае разгортванне ў сістэмах машыннага навучання.

Інфраструктура дадзеных як платформа

Такім чынам, мы збіраем маналіт дадзеных, і мы будзем мець гэта па дамене, але на самой справе каманды не паспяваюць ствараць у кожнай уласную інфраструктуру дадзеных. Каб вырашыць гэтую праблему, кампаніі павінны засяроджвацца на стварэнні агульнай інфраструктуры дадзеных.

У артыкуле з сеткі дадзеных з блога Марціна Фаўлера (напісанага маім былым калегам па Thoughtworks Zhamak Dehghani) яны пішуць некаторыя магчымасці, якія гэтая інфраструктура павінна мець, некаторыя з іх: маштабуецца захоўванне дадзеных на паліглоце, пашырэнне дадзеных, схема дадзеных, радок дадзеных, маніторынг дадзеных / сігналізацыя / часопіс, паказчыкі якасці прадукцыі дадзеных, кіраванне дадзенымі, бяспека і вылічэнні і месцазнаходжанне дадзеных.

З дапамогай гэтай платформы дадзеных каманды (распрацоўшчыкі і навукоўцы дадзеных) павінны клапаціцца толькі пра тое, што яны хочуць рабіць з дадзенымі, якія яны вырабляюць, і як яны будуць перадаваць гэтыя дадзеныя іншым камандам, як зараз мы робім з CircleCi або Джэнкінс (камандам трэба толькі падумаць пра тое, як яны хочуць зрабіць свой ІП, а не інфраструктуру). Напрыклад, у гэтым малюнку Metaflow тлумачыць інфраструктуру з пункту гледжання навукоўцаў:

Выява з Metaflow

І наступны вобраз (з паведамлення сеткі блога Марціна Фаўлера) можа стаць магчымым канчатковым статусам. У гэтай схеме вы можаце ўбачыць розныя дамены з уласнымі трубаправодамі і папярочнай платформай дадзеных.

Схема дадзеных Mesh з блога Марціна Фаўлера

Добра, нармальна ... Я разумею канцэпцыю і ўсё астатняе, але ... А як наконт стратэгіі яе дасягнення?

Ну, па-першае, мы любім код, і на працягу многіх гадоў мы ўдасканальваем лепшыя практыкі ў кодзе і лепшыя метадалогіі і ўсе метады, якія змяшчае XP. Такім чынам, давайце выкарыстоўваць код таксама ў дадзеных і ўсіх лепшых практыках, якія мы ведаем.

Мы маглі б выкарыстоўваць шмат інструментаў і рамак, каб зрабіць нашы трубаправоды дадзеных з кодам. У інжынернай камандзе Packlink мы любім GCP, таму ў гэтым пасце я збіраюся растлумачыць гэты артыкул Airflow, таму што платформа Google мае клік і прайграванне і цалкам кіруецца аркестрацыяй працоўнага працэсу, пабудаванай у Airflow: Cloud Composer.

Памятаеце, што важныя моманты (тое ж, што і ў службах тое ж самае, калі вы карыстаецеся CircleCI, Джэнкінс і г.д.) - гэта ідэі, інструмент - гэта толькі спосаб дасягнуць нашых мэтаў. Іншыя добрыя інструменты / рамкі - Metaflow, Luigi, Prefect, Pinball. У гэты момант кожная кампанія будуе свае рамкі, і ўсе яны розныя, але, настойваючы, справа ў тым, каб кожная з іх была кодам. У наступных раздзелах я пераглядаю:

  • Задушаная карціна: як стратэгія яе дасягнення.
  • Трубаправод дадзеных: якім павінен быць гэты трубаправод?
  • Код: тэставаны код для напісання канвеера.

Удушны ўзор

Я збіраюся выказаць здагадку, што ў вас зараз маналіт дадзеных. Калі не, калі ў вас ёсць "зялёнае поле", магчыма, гэты раздзел вам не цікавы, але прабачце, мы гаворым пра разрыў маналіту.

У нас ёсць маналіт дадзеных, якая найлепшая стратэгія? Здаецца, каб зрабіць вадаспад і паставіць усю інфраструктуру адразу, гэта добрая ідэя, таму для дасягнення пастаўленай мэты мы збіраемся выкарыстаць задуму Штундгера. Гэта тыповы спосаб разбурыць маналіт у спадчынных сістэмах, і, як я ўжо казаў, мы шмат чаму навучыліся і хочам паўторна выкарыстоўваць гэтыя веды.

Гэты ўзор добра выкарыстоўваць, таму што; У нас шмат рэчаў, якія працуюць добра, і мы хочам зрабіць гэтую працу ў карысным і спрытным мысленні ў гэтыя тры крокі:

  • Выдаліце ​​дамен з маналітнага будаўніцтва яго ў новым трубаправодзе.
  • Увядзіце ў вытворчасць і праверце, ці ўсё ў парадку, пакуль два спосабы сужыцця.
  • Выключыце гэтую проста састарэлую частку маналіту.
Удушэнне ў дзеянні

Такім чынам, для пачатку мы можам выбраць самы просты дамен і пабудаваць новы канвеер дадзеных, потым зрабіць лянівую міграцыю сумесна жывой абедзвюх сістэм і, калі мы ўпэўненыя, што ўсё працуе добра, выдаліць састарэлую частку.

Трубаправод дадзеных

Асноўныя моманты, якія павінен мець гэты трубаправод:

  • Перабор дадзеных. Не ўсе звесткі, атрыманыя паслугамі, падзяляюцца, і не ўсе дадзеныя, якія выдаюцца, робяцца неапрацаванымі. Часам нам трэба зрабіць некаторыя пераўтварэнні. Мы будзем рабіць з кодам, і, як я заўсёды кажу, код - гэта код, таму нам трэба заўсёды прымяняць лепшыя практыкі.
  • Праверка схемы. Калі мы хочам забяспечыць якасць нашых дадзеных, нам трэба выкарыстоўваць схему, калі мы абменьваемся імі з іншымі часткамі кампаніі (службамі, аналітыкай і г.д.). Напрыклад, у нас ёсць узрост людзей, якіх мы хочам дамагчыся таго, каб гэта значэнне было цэлым і максімальнае значэнне - 150? Для яго дасягнення можна выкарыстоўваць розныя сістэмы серыялізацыі дадзеных, я рэкамендую буферы пратаколаў альбо Avro. Пры гэтым і вытворца, і спажывец ведаюць, што азначае кожная кропка дадзеных.
  • Экспарт нязменных набораў дадзеных у якасці прадукцыі. Кожная служба нясе адказнасць за абмен інфармацыяй з арганізацыяй. Аптымальным варыянтам з'яўляецца сумеснае выкарыстанне нязменных набораў дадзеных у выглядзе брокера па абмену паведамленнямі, як Kafka або паб / пад. Добры пост, які распавядае пра дадзеныя аб абмену ў размеркаваных сістэмах, можна прачытаць тут. Звярніце ўвагу на гэта: дадзеныя, як мы даведаліся і ў функцыянальным праграмаванні, павінны быць нязменнымі, а таксама дазваляюць нам мець усю гісторыю і рабіць агрэгацыі, неабходныя пазней, не захоўваючы іх.
  • Версія дадзеных / дадзеныя ў выглядзе кода. Як мы зрабілі ў кодзе, нам патрэбны версіі нашых набораў дадзеных, нават больш, мы хочам дадзеныя ў выглядзе кода. У гэтым ёсць некаторыя перавагі: мы можам лёгка прайграваць памылкі, выкарыстоўваць наборы дадзеных у нашых тэстах і трубаправодах, шмат пераваг у машынным навучанні (больш інфармацыі тут) і, безумоўна, усе добрыя рэчы ў кода. DVC, сістэма кіравання версіямі дадзеных і мадэляў, заснаваная на git, з'яўляецца для мяне рашэннем адным з лепшых інструментаў у свеце дадзеных.
DVC-дыяграмы пра дадзеныя і мадэлі як код і абмен дадзенымі
  • Кіраванне дадзенымі і радавод. Гэта адзін з найбольш важных момантаў у канвееры дадзеных, калі мы хочам парушыць маналіт дадзеных. Перш за ўсё, нам патрэбны на платформе дадзеных інструмент для яго захавання. Ёсць некалькі добрых варыянтаў, але я рэкамендую толькі дзве: Lyft Ammundsen і калі вы карыстаецеся GCP, Каталог дадзеных. Абодва яны аўтаматычна адкрываюць дадзеныя. Важным тут не інструмент, гэта таксама канцэпцыя. Мы павінны захаваць у нашых трубаправодах апісанне дадзеных, якімі мы абменьваемся, і метададзеных з дапамогай API да нашага інструмента, як гэта робіць у каталогу дадзеных і паставіць неабходныя для правільнай радка дадзеных. Дзякуючы гэтаму ўсе будуць ведаць, дзе знаходзяцца дадзеныя, хто ўладальнік, як гэта і што азначае кожнае значэнне.
Кіраванне дадзенымі з Lyft Ammundsen
  • Назіральнасць. Мы павінны зразумець, як працуе наша сістэма, і мы будзем рабіць гэта, працуючы вышэй трох узроўняў: узровень інфраструктуры, мерапрыемствы і ўзровень дадзеных. Стварыце прыборную панэль з дакладнай і карыснай інфармацыяй. Гэта галоўны момант. Мы працуем з складанымі сістэмамі, таму нам трэба мець прыборную панэль толькі з самай важнай інфармацыяй, каб лёгка зразумець, калі нашы сістэмы працуюць належным чынам. З гэтым, калі карабель здарыцца, і ён будзе, вы будзеце першым, хто яго адкрые. Тыповая памылка дадзеных - забыцца на маўклівыя збоі. Калі крыніца спыняе выдаваць новыя дадзеныя, мы павінны ведаць пра гэта рана, таму што, магчыма, нашы мадэлі, іншыя паслугі ці бізнес залежаць ад гэтых дадзеных у вялікім працэнце. Акрамя таго, дзякуючы добраму канвеера дадзеных мы можам дасягнуць аўтаматызаванага выяўлення няспраўнасцяў анамаліі, напрыклад, калі ў перыяд часу адбываецца менш падзей.
  • Якасць дадзеных. Тэсты, тэсты і шмат іншага. Мы тэсты. А акрамя тэстаў у кодзе, нам патрэбныя некаторыя тэсты з дадзенымі. Напрыклад, што вы думаеце пра тэст у гэтым трубаправодзе, які нам параіў, калі мы адпраўляем больш заказаў, чым прадуктаў? Гэта здаецца лагічным і карысным, так?
  • Прайсці навучанне па дадзеных. Калі вы таксама працуеце з машынным навучаннем і таму, што мы хочам зрабіць жыццё вучоных нашых дадзеных, вам трэба атрымаць дадзеныя аб навучанні. Тут ёсць мноства крытычных момантаў: адбіраецца важнасць вагі, рэжам дадзеныя на невялікія кавалачкі, ананімізуем усе адчувальныя дадзеныя ... больш інфармацыі тут.
  • Мы клапоцімся пра сваіх кліентаў, таму мы павінны клапаціцца пра іх дадзеныя, таму нам трэба шмат бяспекі ў гэтай частцы дадзеных. Важна ананімізаваць усе сакрэтныя дадзеныя, калі мы хочам працаваць з імі.

Так, Хуан вельмі прыгожы, але ...

Экстрэмальнае праграмаванне на дапамогу

Перш за ўсё, мы будзем працягваць трэндаваць усё як код, таму і трубаправод дадзеных таксама.

З прыдушэннем падыходу і ў першай ітэрацыі, лагічна - гэта паўторнае выкарыстанне часткі логікі, якую мы рабілі раней, і мы збіраемся зрабіць гэта з TDD, як сцвярджае XP і наш здаровы сэнс.

Калі вы думаеце пра тое, як я збіраюся растлумачыць просты метад, каб дасягнуць гэтага хутка. Акрамя гэтага, вы павінны вызначыць сваю стратэгію ў доўгатэрміновай перспектыве.

Калі вы ведаеце Airflow, вы ведаеце, што існуе некалькі аператараў (python_operator, http_operator, bash_operator, mysql_operator і доўгі і г.д.) у залежнасці ад выгляду кода, які вы хочаце ўвесці ў кожную DAG. У гэтых аператараў ёсць некаторыя праблемы. Горш мне складаны і непрыгожы спосаб выпрабавання іх, акрамя таго, калі вы карыстаецеся Python, вы будзеце слухаць нешта пра беспарадак залежнасці. З гэтымі аператарамі трэба ўсталяваць усе залежнасці ва ўсім праекце, не трэба іх іншая версія і выкарыстоўваць тую ж версію Python. Больш за тое, мы - сучасная кампанія, і хочам мець паліглот і паспрабаваць новыя мовы!

Маё рашэнне заключаецца ў выкарыстанні, пакуль мы робім удушальнік, аператар докера, kubernetes_pod_operator. Калі вы выкарыстоўваеце Google Composer, вы павінны выкарыстоўваць Kubernetes адзін, а ніколі GKEContainerOperator, бо гэта можа прывесці да канкурэнцыі за рэсурсы. З гэтымі аператарамі код, які будзе выконвацца ў кожнай DAG, будзе знаходзіцца ў кантэйнеры (там можа быць код python, scala, java, працэсы Beam, працэсы іскры, патокі Kafka, абагульняючы, што вы можаце сабе ўявіць ...), так што вы можаце выкарыстоўвайце TDD на патрэбнай вам мове і вы зможаце паўторна выкарыстоўваць некаторыя са свайго састарэлага кода. Тэставанне блока і тэставанне інтэграцыі зроблена ... практычна!

Нам яшчэ трэба напісаць уласны код Airflow, каб мы таксама зрабілі TDD. Гэта будзе частка тэставання вызначэння, якая ўваходзіць у блок тэставання часткі паветранага патоку. Перш чым паказаць код, я хачу падзякаваць Чанду Кавару і Сарангу Шындзе за паведамленні аб інструкцыях, якія тычацца стратэгій тэставання паветранага патоку.

Такім чынам, як мы робім TDD, спачатку тэсты модуля:

Гэта вытворчы код канвеера, які мы стварылі з дапамогай TDD:

Але адзінкавага тэсціравання недастаткова, у Packlink Engineering ведаюць, што тэсты з'яўляюцца найбольш важнай часткай кода. Такім чынам, пойдзем з дадатковым тэсціраваннем.

Цяпер час для інтэграцыйных тэстаў у частцы паветранага патоку (кантэйнеры маюць уласную прыладу і тэсты інтэграцыі). Пры такім падыходзе сюды інтэграцыйныя тэсты звязаны з канфігурацыяй Airflow і XComs, якія, у рэзюмэ, з'яўляюцца спосабам паветранага патоку, і мы павінны дзяліцца інфармацыяй паміж задачамі ў DAG. У нашым прыкладзе нам трэба праверыць, што інфармацыя, захаваная ў packlink_hello_task, з'яўляецца інфармацыяй, узятай stream_data_task:

Апошняя частка тэставання пірамід - гэта тэсты e2e. У пірамідзе тэсты e2e заўсёды з меншага боку, таму што яны вельмі дарагія. У паветраным патоку можа быць нават больш. Вы можаце ўбачыць добры прыклад тут: https://github.com/chandulal/airflow-testing. Я не мог бы зрабіць гэта лепш.

Высновы

Гэта прыводзіць мяне да канца паста. Я проста хацеў зрабіць тут некалькі высноў для абагульнення паста:

  • Код - гэта код. Выкарыстоўвайце практыку XP.
  • Маналіты дадзеных як кодавыя маналіты маюць падобныя праблемы.
  • Падзяліцеся нязменнымі наборамі дадзеных як прадукты.
  • Ведайце сваю дату, укладзіце любоў у кіраванне дадзенымі. Усе ў кампаніі павінны мець магчымасць разумець дадзеныя.
  • Лайно бывае. Звярніце ўвагу на назіранне.
  • Ніхто не ведае лепш, чым дамены аб сваіх дадзеных. Прымяніць зрок DDD да дадзеных.
  • Правілы Packlink !.

Рэсурсы і спасылкі