Data Mesh: как да работим с данни без монолит.

Здравей, Хабър! В Dodo Pizza Engineering много обичаме данните (а кой не ги обича сега?). Сега ще разкажем история как да съберем всички данни на Dodo Pizza и да осигурим удобен достъп до този масив данни за всеки служител на компанията. Задача с ⭐️: да запазим нервите на екипа по данни.

Като истински Плюшкини, ние събираме всякаква информация за работата на нашите пицарии:

• знаем всички поръчки на потребителите;
• знаем колко време е отнело приготвянето на първата пица в Сыктывкар;
• виждаме колко време отнема на пицата да се охлади на топъл рафт в Воронеж в момента;
• съхраняваме данни за отписването на продукти;
• и много-много друго.

За работата с данни в Dodo Pizza в момента отговарят няколко екипа, единият от които е екипът по данни. В момента пред нас (т.е. пред нас) стои задачата: да осигурим удобен достъп до този масив данни за всеки служител в компанията.

Когато започнахме да мислим как да го направим и започнахме да обсъждаме задачата, намерихме много интересен подход за управление на данните - Data Mesh (на линка ще намерите огромна страхотна статия). Идеите в нея отлично се вписват в нашето разбиране за това как искаме да изградим нашата система. По-нататък в статията ще видите нашето преосмисляне на подхода и как виждаме внедряването му в Dodo Pizza Engineering.

Какво имаме предвид под "данни"

Първо, нека определим какво разбираме под данни в Dodo Pizza Engineering:

• Събития, които изпращат услугите (имаме обща шина, изградена с RabbitMQ);
• Записи вътре в базата данни (за нас това са MySQL и CosmosDB);
• Clickstream от мобилното приложение и сайта.

За да може бизнесът на Dodo Pizza да използва тези данни и да разчита на тях, е важно да се изпълняват следните условия:

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

Като вземем под внимание всички тези изисквания, стигнахме до извода, че данните в Dodo – това е продукт. Такъв, какъвто е публичното API на услугата. Следователно, данните трябва да бъдат собственост на същия екип, който притежава услугата. Освен това, промените в схемата на данните винаги трябва да бъдат обратно съвместими.

Традиционният подход – Data Lake

За решаване на задачите за надеждно съхранение и обработка на големи данни съществува традиционен подход, приет в много компании, които работят с такъв обем информация – Data Lake. В рамките на този подход, инженерите по данни събират информация от всички компоненти на системата и я съхраняват в едно голямо хранилище (пример за това могат да бъдат Hadoop, Azure Kusto, Apache Cassandra или дори MySQL реплика, ако данните влязат в нея).

След това същите тези инженери пишат заявки към такова хранилище. Реализацията на този подход в Dodo Pizza Engineering означава, че екипът по Data Engineering ще управлява схемата на данните в аналитичното хранилище.

В този сценарий, екипът става много тъжен и ето защо:

• Той трябва да следи за промените в ВСИЧКИ услуги в компанията. А те са много и промените са многобройни (в средно ние проверяваме ~100 pull requests за седмица, при това много услуги изобщо не правят pull requests).
• При промяна на схемата на данните, продуктът собственик и екипът, който променя схемата на данните, трябва да чакат, докато Data Engineering допише кода, необходим, за да се поддържат промените. В същото време, отдавна имаме функционалности и ситуация, в която един екип чака друг – много рядка. И ние не искаме това да стане "нормална" част от процеса на разработка.
• Той трябва да бъде потопен в ЦЯЛО бизнес на компания. Мрежата от пицарии изглежда като прост бизнес, но това е само на пръв поглед. Много трудно е да се съберат достатъчно компетенции в един екип, за да се изградят адекватни модели на данни за цялата компания.
• Тя е единствената точка на отказ. Всеки път, когато трябва да се променят данните, които връща услугата или да се напише запитване, всички тези задачи падат на екипа по данни. В резултат на това, екипът е натоварен с огромен беклог.

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

Преминавайки от Data Lake към Data Mesh

За щастие, този въпрос не е задаван само от нас. Всъщност, подобен проблем вече е решен в индустрията (аллилуйа!). Само в друга област: разгръщане на приложения. Да, говоря за подхода DevOps, при който екипът определя как да се разгръща продукта, който създават.

Подобен подход за решение на проблемите с Data Lake предложи Zhamak Dehghani, консултант в ThoughtWorks. Наблюдавайки как подобни задачи решават Netflix и Spotify, тя написа страхотна статия Как да преминем отвъд монолитния Data Lake към разпределен Data Mesh(линкът до нея беше в началото на статията). Основните идеи, които извлякохме от нея:

• Да разделим голямата Data Lake на домейни на данни, които наподобяват домейните от domain-driven design. Всеки домейн е малък bounded context.
• Teams Features, които отговарят за DDD домейните, отговарят също и за съответните домейни на данни. Те съхраняват схемата, правят промени в нея, зареждат в нея данни. В същото време те знаят всичко: как да променят зареждането на данни и как да не счупят нещо, когато приложението се променя. Знанията не изчезват. За да отворят данните, не трябва да ходят никъде. Самият екип управлява целия цикъл на разработка от промяната на оперативните данни до предоставянето на аналитични данни на трети страни. Един екип притежава всичко свързано с домейна (както бизнес домейн, така и домейн на данни).
• Data Engineer – роля в рамките на екипа Features. Това не е задължително да е отделен човек, но е наложително екипът да притежава тази компетенция.

А в това време екипът по данни...

Ако представим си, че всичко това се реализира с едно щракване на пръсти, остава само да отговорим на два въпроса:

С какво сега ще се занимава екипът по обработка на данни? В Dodo Pizza Engineering вече има екип за платформи/SRE. Неговата задача е да предоставя на разработчиците инструменти за лесно разгръщане на услуги. Екипът по обработка на данни ще изпълнява същата роля, но за данни.

Превръщането на оперативните данни в аналитични е сложен процес. Да направите аналитичните данни достъпни за цялата компания е дори по-сложно. Именно решаването на тези проблеми ще бъде задачата на екипа по обработка на данни.

Ние планираме да предоставим на Feature Team удобен набор от инструменти и практики, с които те да могат да публикуват данни от своята услуга за останалата част от компанията. Освен това, ние ще поемем отговорността за общите инфраструктурни части на data pipeline (опашки, надеждно хранилище, клъстери за извършване на трансформации на данни).

Как ще се появят уменията на Data Engineer в Feature Team? С Feature Team работите са по-сложни. Разбира се, можем да опитаме да наемем по един Data Engineer в всеки от нашите екипи. Но това е доста трудно. Да намерите човек с добър опит в обработката на данни и да го убедите да работи в продуктови екипи е предизвикателство.

Голямо предимство за Dodo е, че обичаме вътрешното обучение. Така че в момента нашият план е такъв: екипът по обработка на данни започва да публикува данни от някои услуги, плаче, боде се, но продължава да яде кактус. Веднага щом разберем, че имаме готов процес за публикуване, започваме да го представяме на Feature Team.

Имаме няколко начина да го направим:

1. DevForum, на който ще разкажем как изглежда процесът, който сме създали, какви инструменти има и как да ги използваме по най-ефективния начин.
2. Изпълнението на DevForum ще ни помогне да съберем обратна връзка от продуктовите разработчици. След това ще можем да се присъединим към продуктови екипи и да им помогнем да решат задачи с публикуването на данни, организирайки обучения за екипите.

Консумация на данни

Сега много говорих за публикуването на данни. Но има и консумация. Как стои въпросът с нея?

Имаме страхотен екип за BI, който съставя много сложни отчети за управленската компания. Вътре в Dodo IS имаме много отчети за нашите партньори, които им помагат да управляват пицарии. В нашия нов модел ги разглеждаме като потребители на данни, които имат свои домейни на данни. И именно потребителите ще отговарят за собствените си домейни. Понякога домейнът на потребителя може да бъде описан с едно запитване в аналитичното хранилище – и това е добре. Но разбираме, че това не винаги ще работи. Именно затова искаме платформата, която ще създадем за продуктови екипи, да може да бъде използвана и от потребителите на данни (в крайна сметка, що се отнася до отчетите в Dodo IS – те ще бъдат едни и същи екипи).

Така виждаме работата с данни в Dodo Pizza Engineering. С удоволствие ще прочетем вашите мисли по този въпрос в коментарите.

Източник: habr.com