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 решават подобни задачи, тя написа впечатляваща статия How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh(линкът към нея беше в началото на статията). Основните идеи, които извлякохме от нея, са:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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