Пълно ръководство за това как да разчупите монолита на данните.

Как да се справим с новата голяма цел в софтуерния свят.

Разчупете монолита на данните!

мотивиране

Монолит на данни

Човекът е единственото животно, което пътува два пъти по една и съща скала. След години говори за нарушаване на монолита в услугите, ние отново направихме същото: данни монолити (известни още като езера на данни и хранилища на данни).

Работя по много проекти (в различни компании) през последните години и видях, че проблемите, които причинява монолитът на данни са подобни:

  • Грешки в данните поради промени не се координират между кодове и тръбопроводи за данни.
  • Обикновено монолитът създава информационни силози, тъй като се нуждаем от специалисти по кодове и специализирани екипи за обучение и данни.
  • Тъй като компаниите растат, ние имаме повече източници на данни и това е нещо, което само се разраства, което прави наличието на данните на едно място тежко предизвикателство.
  • Обикновено е трудно хората, работещи в тръбопроводи за данни, да разберат значението на данните правилно (поне не по-добре от хората, които ги произвеждат), защото имат по-малък контекст.
  • Понякога е необходимо да се правят групови актуализации в складовете с данни, за да се отстранят недоразуменията и несъответстващите данни в ETL процесите.
  • Трудно е да се намали разликата между нова идея и кога тази идея е в производство. Така че не можем да иноваваме. Ако сте бавни, не можете да имате бърз тест и цикъл на обучение и без това не можете да иновавате.

Освен това, монолитът на данни всъщност е монолит, и ние разбираме много лоши неща (и някои добри), които включват това; така че не е необходимо да обясняваме как тези неща (свързани услуги, проблеми с пускането на нови функции, затрудняващи непрекъснатото внедряване, разхвърляна стратегия за тестване и т.н. ...) могат да бъдат проблем.

Обичайният начин да го направите

Действителният начин е да поставим фокуса в нашите услуги и след това чрез ETL да вземем данните, които услугите / източниците произвеждат и след някои преобразувания поставят данните подредени на място, където по-късно ще бъдат използвани / обслужвани (marts data, API, BigQuery, тръбопроводи за модели и т.н.). Тези процеси се извършват вътре в тръбопроводи за данни и както казахме преди да можем да различим три ясни части (ETL):

  • Първо, процес, който поглъща данните от различни източници.
  • Част за обработка, при която почистваме данните и правим някои трансформации по тръбопроводите за данни.
  • Стъпка на обслужване на данните, объркана. В нашия случай BigQuery прави тази услуга на данните.
Монолитен модел на данни

Как да разчупим монолита

Идеята на това отделяне е да се прекъсне този тръбопровод в някои тръбопроводи, по домейни или добре, от услуги по същия начин, както ние с кодовите услуги.

И така, какво, ако вместо да има само един тръбопровод, всяка услуга имаше свой собствен (или повече), който да обработва собствените си данни? Така че всяка услуга трябва да бъде отговорна за чистата, преобразуваща се и споделяща собствените си данни в неизменни набори от данни като продукти.

Какво можем да спечелим с тази промяна? На първо място, не трябва да забравяме, че има много промени в различните услуги. Ето кога започват проблемите, защото или забравяме да се координираме с хората с данни за промените или тази координация не е възможна в този момент. Наистина изглежда, че отговорността да не се нарушава аналитиката или другите услуги в данните са на екипа да променя услугите, нали? Освен това, кой знае по-добре от този екип за това как са данните и какъв формат има?

Така че, обобщено, всеки домейн подготвя своите данни, поставя ги като продукт в брокер за съобщения, откъдето други услуги, поточни инструменти, управление, анализи, инструменти на учените за данни (като бележник на юпитер), тръбопроводи за машинно обучение, глобално съхранение и много повече, може да ги постигне.

Стратегия за разпространение на данни

Отвъд това съм сигурен, че ако сега не правите нищо с машинно обучение, ще се справите. Така че, помислете за това, възможно ли е да направите добър модел, без да имате добри данни? Ако искате да свършите добра работа в ML, вероятно се нуждаете от модел тръбопровод, също по домейн, и той ще се нуждае от този тръбопровод за данни. Ако искате повече информация по тази тема, можете да прочетете тази друга публикация, която написах: непрекъснато внедряване в системите за машинно обучение.

Инфраструктура за данни като платформа

Така че, ние ще разрушим монолита на данните и ще го имаме по домейн, но всъщност екипите нямат време да създават всяка своя собствена инфраструктура за данни. За да разрешат този проблем, компаниите трябва да поставят фокуса върху създаването на обща инфраструктура за данни.

В статията за мрежата от данни от блога на Мартин Фоулър (написана от бившия ми колега в Thoughtworks Zhamak Dehghani) те пишат някои възможности, които тази инфраструктура трябва да има, някои от тях: мащабируемо съхранение на данни на полиглот, версия на данни, схема на данни, линия на данни, мониторинг на данните / алармиране / дневник, показатели за качеството на продуктите с данни, управление на данните, сигурност и изчисление и локация на данните.

С тази платформа за данни екипите (разработчици и учен за данни) трябва само да се грижат за това какво искат да правят с данните, които произвеждат и как ще служат на тези данни на други екипи, както сега правим с CircleCi или Дженкинс (екипите трябва само да помислят как искат да направят своя CI, а не инфраструктурата). Например, в това изображение Metaflow обяснява инфраструктурата от гледна точка на учените за данни:

Изображение от Metaflow

И следващото изображение (от публикацията на мрежата от данни на блога на Мартин Фаулър) може да бъде възможно окончателно състояние. В тази схема можете да видите различните домейни със собствени тръбопроводи и платформата за напречни данни.

Data Mesh схема от блога на Мартин Фаулър

Добре, добре ОК ... разбирам концепцията и всичко останало, но ... Какво ще кажете за стратегията за нейното постигане?

Е, на първо място, ние обичаме кода и от години подобряваме най-добрите практики в кода и най-добрите методологии и всички техники, които XP съдържа. Така че, нека използваме код и в данните и всички най-добри практики, които познаваме.

Бихме могли да използваме много инструменти и рамки, за да направим нашите тръбопроводи за данни с код. В инженерния екип на Packlink, ние обичаме GCP, така че в тази публикация ще обясня тези неща с Airflow, защото платформата на Google има кликване и игра и напълно управлявана оркестрация на работния процес, изградена в Airflow: Cloud Composer.

Не забравяйте, че важните точки (същите като в услугите са същите, ако използвате CircleCI, Jenkins и т.н.) са идеите, инструментът е само начин за постигане на нашите цели. Други добри инструменти / рамки са Metaflow, Luigi, Prefect, Pinball. Към настоящия момент всяка компания изгражда своя собствена рамка и всички те са различни, но, настоявайки, смисълът е идеята и всяка от тях е код. В следващите раздели преминавам през:

  • Удушващ модел: като стратегия за постигането му.
  • Тръбопровод за данни: как трябва да бъде този тръбопровод?
  • Код: тестваният код за писане на тръбопровода.

Удушващ модел

Предполагам, че в момента имате монолит на данни. Ако не, ако имате зелено поле, може би тази глава не ви е интересна, но съжаляваме, говорим за разбиване на монолита.

Имаме монолит на данните, Коя е най-добрата стратегия? Не изглежда, че да направим водопад и да поставим цялата инфраструктура наведнъж е добра идея, така че за да постигнем целта си, ще използваме модела на Strangler. Това е типичен начин за разбиване на монолита в наследените системи и както вече казах, научихме много и искаме да използваме отново тези знания.

Този модел е добре да се използва, защото; имаме много неща, които вървят добре и искаме да извършим тази работа в полезен и пъргав начин на мислене в тези три стъпки:

  • Премахнете домейн от монолита, изграждайки го в нов тръбопровод.
  • Пуснете в производство и проверете дали всичко работи добре, докато двата начина съвместно живеят.
  • Премахнете тази просто наследена част към монолита.
Удушващ модел в действие

Така че, за начало, можем да изберем най-простия домейн и да изградим нов тръбопровод за данни, след което да направим мързелива миграция, съжителстваща и двете системи и когато сме сигурни, че всичко работи добре, изтриваме наследената част.

Тръбопровод за данни

Основните точки, които трябва да има този тръбопровод, са:

  • Разправии с данни. Не всички данни, произведени от услугите, се споделят и не всички данни, които се получават, се правят сурови. Понякога трябва да направим някои трансформации. Ще правим с код и както винаги казвам, кодът е код, така че винаги трябва да прилагаме най-добрите практики.
  • Проверка на схемата. Ако искаме да гарантираме качеството на нашите данни, трябва да използваме схема, когато я споделяме с други части на компанията (услуги, анализи и т.н.). Например, имаме възрастта на хората, които искаме да гарантираме, че тази стойност е цяло число и че максималната стойност е ... 150? Можете да използвате различни системи за сериализиране на данни, за да я постигнете, препоръчвам буфери на протоколи или Avro. С това и производителят, и потребителят знаят какво означава всяка точка от данни.
  • Експорт на неизменни набори от данни като продукти. Всяка услуга отговаря за споделянето на информацията с организацията. Оптималният е да споделяте неизменни набори от данни, преобразувани чрез посредник за съобщения като Kafka или pub / sub. Един добър пост, който говори за споделяне на данни в разпределените системи, може да прочетете тук. Моля, обърнете внимание на това: данните, както научихме и във функционалното програмиране, трябва да бъдат неизменни и също така ни позволяват да имаме цялата история и да правим необходимите агрегации по-късно, без да ги запазваме.
  • Версия на данните / данни като код. Както направихме в кода, имаме нужда от версия на нашите набори от данни, още повече, ние искаме данните като код. Има някои предимства: можем да възпроизвеждаме лесно грешки, да използваме наборите от данни в нашите тестове и нашите тръбопроводи, много предимства в машинното обучение (повече информация тук) и определено всички добри неща, които кодът има. 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 процеси, Spark процеси, 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 !.

Ресурси и връзки