Най-общо казано, един Data Engineer има за цел да създава процеси, които предоставят разнородни видове информация по начин, достъпен за анализатори, Data Scientists, Machine Learning модели, Business Intelligence софтуери и т.н.

От няколко години насам ролята на Data Engineer специалиста еволюира непрекъснато. Преди 10 години, очакваното от един такъв инженер е било да знае как да използва различни ETL софтуери (Extract-Transform-Load), с които да създава споменатите процеси. Най-често използвани софтуери са били Informatica, SSIS, Mulesoft и други. Много от тях все още съществуват и се използват в по-големите компании, макар и да е общоприето да се считат за старомодни системи поради причини, които ще изброим по-долу. Традиционните ETL софтуери ни помагат да посочим даден източник на информация – например база данни, FTP, API, откъдето тя да бъде извлечена, трансформирана по определен начин и като нейна крайна цел да бъде съхранена, най-често в база данни, оптимизирана за анализи.
Трансформациите предимно включват елементарни операции (преобразуване от един тип данни в друг – например от string в date); както и по-сложни операции, например разбиване на масив от структури в отделни таблици, създаване на алтернативни ключове, както и разнообразни имплементации на dimensional model (star-schema, snowflake-schema и др.).
Целта на всичката тази работа е да направим информацията достъпна за анализ или за опресняване на виртуално табло с данни (дашборд). Тези табла показват информация от сорта на това колко продажби са направени на предишния ден, разделени по категория на продукт/страна/марка; дали има недостиг на определени продукти в склада; продукти, чиито срок изтича много скоро; проблеми с производителността или проблеми отчетени на предишния ден с различни машини, както и много, много други видове информация. На практика, всички видове дашборди са продукт на Business Intelligence екипа, който от своя страна разчита на Data Engineering екипа да им предостави навременна коректна информация.

Проблемът с този метод на работа е, че много често не гарантира, че информацията е коректна, нито че ще пристигне навреме. Много дебели книги могат да бъдат изписани с обосновка защо (а и вече са написани много такива, препоръчвам Designing Data-Intensive Applications от Martin Kleppmann, както и книгите на Ralph Kimball). Тук желая да спомена, че когато извличаме информация от други системи, върху които нямаме никакъв контрол, се случва много често структурата на тази информация да се променя, което в свой ред прави нашите процеси неправилни. Също така, когато информацията нараства като размер, много от тези системи, както и нашите ETL процеси, започват да се затрудняват да я пренесат навреме. Случвало ни се е да виждаме важни ETL процеси да отнемат над 25 часа, предоставяйки информацията от предишния ден. Както разбирате, това е индикация за проблемна архитектура. Това е подчертано и от факта, че когато процесът даде грешка на последната стъпка, много често няма как да се процедира освен да се рестартира целият процес отначало. Резултатът е часове изгубено време, както и оперативни пропуски и разходи поради недостъпността на информация.

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

За всеобща радост, през последните 5 години дистрибутираните системи започнаха да стават много по-популярни. Тенденцията за тяхното ползване в света на Data Engineering навлезе бързо, като например появата на Hadoop, а след това Spark, промениха изцяло как мислим за начина на работа с информацията. Това ни позволи да намерим решение за набъбналия размер на информация, която ни се наложи да обработваме все по-бързо. Породи се и концепцията за Data Lake – запазваме цялата информация в най-суровият ѝ вид, дори и в момента да ни трябват само 5% от нея. Използвайки технологии като Spark, успяхме лесно да се върнем към този Data Lake, да обработим петабайти информация и да извлечем само нужната информация и то във формат, в който ни трябва.

По същото време и базите данни за анализи започнаха да стават все по-добри. Преди говорихме за OLTP и кубове, сега говорим за масивно паралелни, дистрибутирани Columnar Data Stores. Дистрибутирани означава, че имаме начини да подкараме огромна база данни на много компютри, имайки спокойствието, че няма да имаме сривове в системата, както и загуби на информация. Също така по това време имахме повече „еластичност“, което означава, че все повече процеси можеха да текат по едно и също време. Фокусът върху разпределението на информацията по колони (а не по редове, както преди) ни позволи да правим много по-оптимизирани заявки към нашите таблици, дори когато говорим за милиарди редове.

Изброените стъпки до момента ни помогна да минимизираме случаите, в които опресняването на информацията за нашите информационни табла отнема 25 часа. Позитивен ефект от оптимизацията е факта, че анализатори, както и хора с по-модерни титли като Data Scientists и Machine Learning Engineers започнаха да боравят с тези големи количества информацията в същото време, в което течеше и ETL процесът (вместо да чакат да спре, защото системата няма достатъчно ресурси за ETL, и за други видове заявки).

Разбира се, всичко това помогна много да се разрасне спектърът от умения, които един Data Engineer трябва да притежава. До тук споменахме: ETL софтуери, дистрибутирани системи, езици като Scala/Python за боравене със Spark, DBA (Data Base Administration) умения, с които да оптимизираме базите с данни. Разбира се, съществува очакването за разбиране на основни понятия за модерна разработка на софтуер, като test-driven development, CI/CD, многобройни DevOps и CloudOps процеси, които да бъдат следвани по време на работата в екип и подкарване на процеси в облака, и т.н.

Обработка на данни в реално време
Споменах, че традиционните ETL софтуери вече не са толкова популярни. Ето основните причини:
–       Не са много гъвкави и еластични. Гъвкави – имат лимитиран брой източници на информация, с които могат да се свържат, както и трансформации, които могат да бъдат направени. Еластични – предимно ETL софтуерите работят на централизиран сървър, което означава, че не могат да се възползват от ползите на дистрибутираните системи, които позволяват по-голяма мощ, когато е необходима. Затова тези софтуери са и склонни да отнемат прекалено дълго време.
NB! Има, разбира се, модерни Data Engineering софтуери, които работят в облака и се справят отлично (например Matillion). Помага и това, че те са по-скоро ELT – Extract, Load и тогава Transform (използвайки силата на модерната база данни, в които са заредили информацията).
–       Не работят много добре с неструктурирана информация. Например логове, свободен текст, картини, музика и т.н.
–       Изискват специализирани умения, което прави трансформациите трудни за разбиране от хора, които не разбират как работи ETL софтуера. Най-често тези хора са бизнес анализатори, Business Intelligence експерти, и други консуматори на информацията.
–       Не работят с информация в реално време.

Оказва се, че последното е много важно. Много модерни бизнеси не желаят да видят информация за това, което се е случило на предния ден. Те искат да видят нещата, които се случват в момента. Или още по-скоро, искат разнообразни алгоритми и системи да имат достъп до информация за неща, които се случват в текущият момент и да взимат решения на базата на тази информация автоматично. Примери: електронния магазин на компанията засича, че ще си оставите електронната кошница, с вече избрани артикули, и ви предлага ваучер за продукт, който е изчислен, че е най-вероятно да си закупите; температурата и вибрациите на машина минават определен праг, и машината трябва автоматично да бъде изключена, а елементите които минават през нея да бъдат пренасочени към друга машина; засичане на измамно поведение на потребители на дигитална банка, които например използват дебитната си карта на терминал, който се намира много далеч от локацията на IP адреса, от който току-що са влезли в апликацията и т.н.
Също така има полза да се събира информация в реално време дори да не я използваме веднага. Например, когато желаем да създадем модели на поведение на потребителите на един дигитален продукт, може да се наложи да обогатим информацията, за факта, че току-що са натиснали на бутона „добави в кошницата“ под артикула чадър, с информацията, че прогнозата за времето за утре сочи, че ще вали.

Тези и много още примери ни казват, че нашия Data Engineer трябва да е много наясно как да борави с информацията в реално време. Оказва се, че това не е лесна задача особено боравенето с технологии като Kafka, Redis и SQS, както и други прийоми на обработка на информация от сорта на Event Sourcing.

Трудно е да очакваме от който и да е програмист да разбира от всичките технологии, но истината е, че един модерен екип от Data Engineers трябва да покрие всички тези изисквания, за да помогне на компанията си да бъде конкурентноспособна, що се отнася до оптимизирано използване на информация като двигател на бизнеса. Някои инженери предпочитат да се фокусират върху обработването на големи количества информация чрез Spark; други моделират една база данни оптимално и разбират от неща като data skew, distribution keys, facts & dimensions; трети ще знаят как да боравят с Kafka. Вероятно всички ще трябва да знаят поне основите на Docker, различни облачни среди като AWS, GCP, Azure. И не на последно място, независимо от предпочитанията им към технологии, всеки добър дата инженер ще може да работи адекватно с техните колеги, така наречените консуматори на информация, които ще я анализират, използват в алгоритми, предоставят в информационни табла и други, с цел всичката обработена информация да има положителна полза и да движи бизнеса напред.

Атанас е CEO на Инфинит Ламбда. Завършва компютърни науки в Манчестър и прекарва първите 5 години от кариерата си работейки по Data Engineering проекти за AstraZeneca. След пауза за 1-годишна магистратура в Imperial College London, продължава като индивидуален консултант по Data Science & Engineering, като след няколко години това прераства в малък екип, а в последствие – в Infinite Lambda.
Атанас е част от борда на директорите на VR компанията OneShot, финтек компанията Dozens и е организатор на групата DataTech в Лондон.

 

 

 

Share This