🥇Ужыванне low-code у аналітычных платформах

Паважаныя чытачы, добрага дня!

Задача пабудовы ІТ-платформаў для назапашвання і аналізу дадзеных рана ці позна ўзнікае ў любой кампаніі, у аснове бізнэсу якой ляжаць інтэлектуальна нагружаная мадэль аказання паслуг або стварэнне тэхнічна складаных прадуктаў. Пабудова аналітычных платформаў - складаная і працаёмкая задача. Аднак любую задачу можна спрасціць. У гэтым артыкуле я хачу падзяліцца досведам ужывання low-code-інструментаў, якія дапамагаюць у стварэнні аналітычных рашэнняў. Дадзены вопыт быў набыты пры рэалізацыі шэрагу праектаў напрамкі Big Data Solutions кампаніі "Неафлекс". Кірунак Big Data Solutions кампаніі "Неафлекс" з 2005 года займаецца пытаннямі пабудовы сховішчаў і азёр дадзеных, вырашае задачы аптымізацыі хуткасці апрацоўкі інфармацыі і працуе над метадалогіяй кіравання якасцю дадзеных.

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

Аднак у якім выпадку задачы аналітыкі дадзеных могуць перарасці ў задачы класа "Rocket Science"? Мабыць, у той момант, калі гаворка ідзе пра сапраўды вялікія дадзеныя.
Каб спрасціць задачу "Rocket Science", можна ёсць слана па частках.

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

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

Але нават пры "паасобнай, слановай" дыеце мы маем нядрэнныя шанцы на "перанасычэнне" IT-ландшафту. У гэты момант варта спыніцца, выдыхнуць і паглядзець у бок low-code engineering platform.

Многіх распрацоўшчыкаў палохае перспектыва з'яўлення тупіку ў кар'еры пры сыходзе ад непасрэднага напісання кода ў бок "перацягвання" стрэлачак у UI-інтэрфейсах low-code сістэм. Але з'яўленне станкоў не прывяло да знікнення інжынераў, а вывела іх працу на новы ўзровень!

Давайце разбірацца чаму.

Аналіз дадзеных у сферы лагістыкі, тэлекам-індустрыі, у галіне медыядаследаванняў, фінансавым сектары, заўсёды спалучаны з наступнымі пытаннямі:

Хуткасць правядзення аўтаматызаванага аналізу;
Магчымасць правядзення эксперыментаў без уздзеяння на асноўны паток вытворчасці даных;
Дакладнасць падрыхтаваных дадзеных;
Адсочванне змен і версіяванне;
Data proveance, Data lineage, CDC;
Шпаркасць дастаўкі новых фіч на прадукцыйнае асяроддзе;
І праславутае: кошт распрацоўкі і падтрымкі.

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

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

Давайце правядзём аналогію з нізкаўзроўневымі і высокаўзроўневымі мовамі праграмавання. Пераход ад нізкаўзроўневых моў у бок высокаўзроўневых - гэта пераход ад напісання "прамых дырэктыў на мове жалеза" ў бок "дырэктыў на мове людзей". Гэта значыць даданне некаторага пласта абстракцыі. У такім выпадку пераход на low-code-платформы з высокаўзроўневых моў праграмавання - гэта пераход ад "дырэктыў на мове людзей" у бок "дырэктыў на мове бізнесу". Калі знойдуцца распрацоўшчыкі, якіх гэты факт засмуціць, тады засмучаныя яны, магчыма, яшчэ з таго моманту, як на святло з'явіўся Java Script, у якім выкарыстоўваюцца функцыі сартавання масіва. І гэтыя функцыі, зразумела, маюць пад капотам праграмную імплементацыю іншымі сродкамі таго ж самага высокаўзроўневага праграмавання.

Такім чынам, low-code - гэта ўсяго толькі з'яўленне яшчэ аднаго ўзроўню абстракцыі.

Прыкладны досвед выкарыстання low-code

Тэма low-code дастаткова шырокая, але цяпер я хацеў бы расказаць аб прыкладным прымяненні «малакодавых канцэпцый» на прыкладзе аднаго з нашых праектаў.

Падраздзяленне Big Data Solutions кампаніі "Неафлекс" у большай ступені спецыялізуецца на фінансавым сектары бізнесу, ладу сховішча і азёры дадзеных і аўтаматызуючы розную справаздачнасць. У дадзенай нішы ўжыванне low-code даўно стала стандартам. Сярод іншых low-code-інструментаў можна згадаць сродкі для арганізацыі ETL-працэсаў: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Ці ж Oracle Apex, які выступае асяроддзем хуткай распрацоўкі інтэрфейсаў доступу і рэдагаванні дадзеных. Аднак ужыванне малокодовых сродкаў распрацоўкі не заўсёды спалучана з пабудовай вузканакіраваных прыкладанняў на камерцыйным стэку тэхналогій з відавочна выяўленай залежнасцю ад вендара.

З дапамогай low-code-платформаў можна таксама арганізоўваць аркестрацыю патокаў дадзеных, стварыць data-science-пляцоўкі ці, напрыклад, модулі праверкі якасці дадзеных.

Адным з прыкладных прыкладаў вопыту выкарыстання малокодовых сродкаў распрацоўкі – з'яўляецца калабарацыя "Неафлекс" c кампаніяй Mediascope, адным з лідэраў расійскага рынку даследаванняў медыя. Адна з задач бізнэсу дадзенай кампаніі - вытворчасць дадзеных, на аснове якіх рэкламадаўцы, інтэрнэт-пляцоўкі, тэлеканалы, радыёстанцыі, рэкламныя агенцтвы і брэнды прымаюць рашэнне аб куплі рэкламы і плануюць свае маркетынгавыя камунікацыі.

Медыядаследаванні - тэхналагічна нагружаная сфера бізнесу. Распазнанне відэашэрагу, збор дадзеных з прылад, якія аналізуюць прагляд, вымярэнне актыўнасці на вэб-рэсурсах - усё гэта мае на ўвазе наяўнасць у кампаніі вялікага IT-штата і каласальнага вопыту ў пабудове аналітычных рашэнняў. Але экспанентны рост колькасці інфармацыі, колькасці і разнастайнасці яе крыніц прымушае ўвесь час прагрэсаваць IT-індустрыю дадзеных. Самым простым рашэннем маштабавання ўжо якая функцыянуе аналітычнай платформы Mediascope магло стаць павелічэнне штата IT. Але значна больш эфектыўнае рашэнне - гэта паскарэнне працэсу распрацоўкі. Адным з крокаў, кіроўных у гэты бок, можа з'яўляцца ўжыванне low-code-платформаў.

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

Стаялая перад намі задача была сапраўды амбіцыйнай – "Неафлекс" і Mediascope трэба было стварыць прамысловае рашэнне менш чым за год, пры ўмове выхаду MVP ужо на працягу першага квартала ад даты пачатку работ.

У якасці падмурка для пабудовы новай платформы дадзеных, заснаванай на low-code-вылічэннях, быў абраны стэк тэхналогій Hadoop. Стандартам захоўвання дадзеных стаў HDFS з выкарыстаннем файлаў фармату parquet. Для доступу да дадзеных, змешчаных у платформе, скарыстаны Hive, у якім усе даступныя вітрыны прадстаўлены ў выглядзе вонкавых табліц. Загрузка дадзеных у сховішча рэалізоўвалася з дапамогай Kafka і Apache NiFi.

Lowe-code-інструмент у дадзенай канцэпцыі быў ужыты для аптымізацыі самай працаёмкай задачы ў пабудове аналітычнай платформы – задачы разліку дадзеных.

Асноўным механізмам для мапіравання дадзеных быў абраны low-code-інструмент Datagram. Neoflex Datagram - Гэта сродак для распрацоўкі трансфармацый і патокаў дадзеных.
Ужываючы дадзеную прыладу, можна абыйсціся без напісання кода на Scala «уручную». Scala-код генеруецца аўтаматычна з выкарыстаннем падыходу Model Driven Architecture.

Відавочны плюс такога падыходу - паскарэнне працэсу распрацоўкі. Аднак апроч хуткасці ёсць яшчэ і наступныя добрыя якасці:

Прагляд змесціва і структуры крыніц/прымачоў;
Адсочванне паходжання аб'ектаў патоку дадзеных да асобных палёў (lineage);
частковае выкананне пераўтварэнняў з праглядам прамежкавых вынікаў;
Прагляд зыходнага кода і яго карэкціроўка перад выкананнем;
Аўтаматычная валідацыя трансфармацый;
Аўтаматычная загрузка дадзеных 1 у 1.

Парог уваходжання ў low-code-рашэнні для генерацыі трансфармацый досыць невысокі: распрацоўніку неабходна ведаць SQL і мець досвед працы з ETL-інструментамі. Пры гэтым варта абмовіцца, што code-driven-генератары трансфармацый - гэта не ETL-інструменты ў шырокім разуменні гэтага слова. Low-code-прылады могуць не мець уласнага асяроддзя для выканання кода. Гэта значыць згенераваны код будзе выконвацца на тым асяроддзі, якое мелася на кластары яшчэ да ўсталёўкі low-code-рашэнні. І гэта, мабыць, яшчэ адзін плюс у карму low-code. Бо ў раўналежнік з low-code-камандай можа працаваць класічная каманда, якая рэалізуе функцыянал, напрыклад, на чыстым Scala-кодзе. Уцягванне дапрацовак абедзвюх каманд у прадуктыў будзе простым і "бясшвовым".

Мабыць, варта яшчэ адзначыць, што апроч low-code ёсць яшчэ і no-code рашэнні. І па сваёй сутнасці гэта розныя рэчы. Low-code у большай ступені дазваляе распрацоўніку ўмешвацца ў генераваны код. У выпадку з Datagram магчымы прагляд і рэдагаванне генераванага кода Scala, no-code такой магчымасці можа не падаваць. Гэтая розніца вельмі істотная не толькі ў плане гнуткасці рашэння, але і ў плане камфорту і матывацыі ў працы дата-інжынераў.

Архітэктура рашэння

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

Крыніцы дадзеных у нашым выпадку вельмі разнастайныя і разнастайныя:

Піплметры (ТБ-метры) - праграмна-апаратныя прылады, якія счытваюць карыстацкія паводзіны ў рэспандэнтаў тэлевізійнай панэлі - хто, калі і які тэлеканал глядзеў у дворагаспадарцы, якое ўдзельнічае ў даследаванні. Пастаўляемая інфармацыя - гэта паток інтэрвалаў назірання эфіру з прывязкай да медыяпакета і медыяпрадукту. Дадзеныя на этапе загрузкі ў Data Lake могуць быць узбагачаныя дэмаграфічнымі атрыбутамі, прывязкай да геастраты, таймзоны і іншымі звесткамі, неабходнымі для правядзення аналізу тэлепрагляду таго ці іншага медыя прадукта. Вырабленыя вымярэнні могуць быць выкарыстаны для аналізу або планавання рэкламных кампаній, ацэнкі актыўнасці і пераваг аўдыторыі, складання эфірнай сеткі;
Дадзеныя могуць паступаць з сістэм маніторынгу струменевага тэлевяшчання і замеру прагляду кантэнту відэарэсурсаў у інтэрнэце;
Вымяральныя прылады ў web-асяроддзі, сярод якіх як site-centric, так і user-centric лічыльнікі. Пастаўшчыком дадзеных для Data Lake можа служыць надбудова браўзэра research bar і мабільнае прыкладанне з убудаваным VPN.
Дадзеныя таксама могуць паступаць з пляцовак, якія кансалідуюць вынікі запаўнення анлайн-анкет і вынікі правядзення тэлефонных інтэрв'ю ў апытальных даследаваннях кампаніі;
Дадатковае ўзбагачэнне возера даных можа адбывацца за кошт загрузкі звестак з логаў кампаній-партнёраў.

Імплементацыя as is загрузкі з сістэм-крыніц у першасны staging волкіх дадзеных можа быць арганізавана рознымі спосабамі. У выпадку выкарыстання для гэтых мэт low-code магчыма аўтаматычная генерацыя сцэнараў загрузкі на аснове метададзеных. Пры гэтым няма неабходнасці спускацца на ўзровень распрацоўкі source to target мэпінгаў. Для рэалізацыі аўтаматычнай загрузкі нам неабходна ўсталяваць злучэнне з крыніцай, пасля чаго вызначыць у інтэрфейсе загрузкі пералік сутнасцяў, якія падлягаюць загрузцы. Стварэнне структуры каталогаў у HDFS адбудзецца аўтаматычна і будзе адпавядаць структуры захоўвання дадзеных у сістэме-крыніцы.

Аднак у кантэксце дадзенага праекту гэтую магчымасць low-code-платформы мы вырашылі не выкарыстоўваць у сілу таго, што кампанія Mediascope ужо самастойна пачала працу па вырабе аналагічнага сэрвісу на звязку Nifi + Kafka.

Варта адразу пазначыць, што дадзеныя прылады з'яўляюцца не ўзаемазаменнымі, а хутчэй дапаўняльнымі адзін аднаго. Nifi і Kafka здольныя працаваць як у прамой (Nifi -> Kafka), так і ў зваротнай (Kafka -> Nifi) звязку. Для платформы медыядаследаванняў выкарыстоўваўся першы варыянт звязкі.

У нашым выпадку найфаю патрабавалася апрацоўваць розныя тыпы дадзеных з сістэм-крыніц і перасылаць іх брокеру Kafka. Пры гэтым кірунак паведамленняў у вызначаны топік Kafka выраблялася пасродкам ужывання Nifi-працэсараў PublishKafka. Аркестрацыя і абслугоўванне гэтых pipeline`аў вырабляецца ў візуальным інтэрфейсе. Інструмент Nifi і выкарыстанне звязкі Nifi + Kafka таксама можна назваць low-code-падыходам да распрацоўкі, які валодае нізкім парогам уваходжання ў тэхналогіі Big Data і паскарае працэс распрацоўкі прыкладанняў.

Наступным этапам у рэалізацыі праекта з'яўлялася прывядзенне да фармату адзінага семантычнага пласта дэталёвых дадзеных. У выпадку наяўнасці ў сутнасці гістарычных атрыбутаў разлік робіцца ў кантэксце разгляданай партыцыі. Калі ж сутнасць не з'яўляецца гістарычнай, то апцыянальна магчымы альбо пералік усяго змесціва аб'екта, альбо зусім адмова ад пераліку гэтага аб'екта (з прычыны адсутнасці змен). На дадзеным этапе адбываецца генерацыя ключоў для ўсіх сутнасцяў. Ключы захоўваюцца ў адпаведныя майстар-аб'ектам даведнікі Hbase, якія змяшчаюць адпаведнасць паміж ключамі ў аналітычнай платформе і ключамі з сістэм-крыніц. Кансалідацыя атамарных сутнасцяў суправаджаецца ўзбагачэннем вынікамі папярэдняга разліку аналітычных дадзеных. Framework`ам для разліку дадзеных з'яўляўся Spark. Апісаны функцыянал прывядзення дадзеных да адзінай семантыкі быў рэалізаваны таксама на аснове мапінгаў low-code-інструмента Datagram.

У мэтавай архітэктуры патрабавалася забяспечыць наяўнасць SQL-доступу да дадзеных для бізнэс-карыстальнікаў. Для дадзенай опцыі быў скарыстаны Hive. Рэгістрацыя аб'ектаў у Hive вырабляецца аўтаматычна пры ўключэнні опцыі "Registr Hive Table" у low-code-інструменте.

Кіраванне патокам разліку

Datagram мае інтэрфейс для пабудовы дызайну патокаў workflow. Запуск мапінгаў можа ажыццяўляцца з выкарыстаннем планавальніка Oozie. У інтэрфейсе распрацоўніка струменяў магчыма стварэнне схем раўналежнага, паслядоўнага або які залежыць ад зададзеных умоў выканання пераўтварэнняў дадзеных. Маецца падтрымка shell scripts і java-праграм. Таксама магчымае выкарыстанне сервера Apache Livy. Apache Livy выкарыстоўваецца для запуску прыкладанняў непасрэдна з асяроддзя распрацоўкі.

У выпадку, калі ў кампаніі ўжо ёсць уласны аркестратар працэсаў, магчыма выкарыстанне REST API для ўбудавання мапінгаў ва ўжо наяўны струмень. Напрыклад, у нас меўся досыць паспяховы досвед убудавання мапінгаў на Scala у аркестратары, напісаныя на PLSQL і Kotlin. REST API малокодовой прылады мае на ўвазе наяўнасць такіх аперацый, як генерацыя выкананага года на аснове дызайну мапінга, выклік мапінга, выклік паслядоўнасці мапінгаў і, зразумела, перадача ў URL параметраў для запуску мапінгаў.

Нароўні з Oozie можна арганізаваць паток разліку сродкамі Airflow. Мабыць, не буду доўга спыняцца на параўнанні Oozie і Airflow, а проста скажу, што ў кантэксце прац па праекце медыядаследаванняў выбар упаў у бок Airflow. Галоўнымі аргументамі на гэты раз аказаліся больш актыўнае супольнасць, якое развівае прадукт, і больш развіты інтэрфейс + API.

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

Фарматам канфігурацыйнага файла для запуску мапінгаў low-code-рашэнні стаў spark-submit. Адбылося гэта з двух прычынаў. Па-першае, spark-submit дазваляе наўпрост запусціць jar-файл з кансолі. Па-другое, ён можа змяшчаць усю неабходную інфармацыю для канфігуравання працоўнага струменя (што палягчае напісанне скрыптоў, якія фармуюць Dag).
Найболей часта сустракаемым элементам працоўнага струменя Airflow у нашым выпадку стаў SparkSubmitOperator.

SparkSubmitOperator дазваляе запускаць jar`нікі - спакаваныя мапінгі Datagram з папярэдне сфармаванымі для іх уваходнымі параметрамі.

Варта згадаць, што кожная задача Airflow выконваецца ў асобнай плыні і нічога не ведае пра іншыя задачы. У сувязі з чым узаемадзеянне паміж задачамі ажыццяўляецца з дапамогай кіравальных аператараў, такіх як DummyOperator або BranchPythonOperator.

У сукупнасці выкарыстання low-code-рашэнні Datagram у звязку з універсалізацыяй канфігурацыйных файлаў (якія фармуюць Dag) прывяло да істотнага паскарэння і спрашчэнню працэсу распрацоўкі струменяў загрузкі дадзеных.

Разлік вітрын

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

Асобным крокам падрыхтоўкі вітрын з'яўляецца валідацыя звестак. Алгарытм валідацыі спалучаны з ужываннем шэрагу матэматычных science-мадэляў. Аднак выкарыстанне low-code-платформы дазваляе разбіць складаны алгарытм на шэраг асобных візуальна счытваных мапінгаў. Кожны з мапінгаў выконвае вузкую задачу. З прычыны чаго магчымы прамежкавы дэбаг, лагіраванне і візуалізацыя этапаў падрыхтоўкі даных.

Алгарытм валідацыі было вырашана дыскрэтызаваць на наступныя падэтапы:

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

Прыведзены вышэй прыклад з'яўляецца пацвярджэннем гіпотэзы аб тым, што ў дата-інжынера і так занадта шмат чаго павінна быць у галаве… І, калі гэта сапраўды "інжынер", а не "кодэр", то страх прафесійнай дэградацыі пры выкарыстанні low-code-інструментаў у яго павінен канчаткова адступіць.

Што яшчэ можа low-code?

Вобласць ужывання low-code прылады для пакетнай і струменевай апрацоўкі дадзеных без неабходнасці напісання кода на Scala уручную не сканчаецца.

Ужыванне low-code у распрацоўцы datalake`ов для нас стала ўжо некаторым стандартам. Мусіць, можна сказаць, што рашэнні на стэку Hadoop паўтараюць шлях развіцця класічных DWH, заснаваных на РСУБД. Малакодавыя прылады на стэку Hadoop могуць вырашаць, як задачы апрацоўкі дадзеных, так і задачы пабудовы канчатковых BI-інтэрфейсаў. Прычым трэба заўважыць, што пад BI можа разумець не толькі рэпрэзентацыя дадзеных, але і іх рэдагаванне сіламі бізнес-карыстальнікаў. Дадзены функцыянал намі часта прымяняецца пры пабудове аналітычных платформаў для фінансавага сектара.

Сярод іншага, з дапамогай low-code і, у прыватнасці, Datagram магчыма вырашыць задачу адсочвання паходжання аб'ектаў патоку дадзеных з атамарнасцю да асобных палёў (lineage). Для гэтага ў low-code-інструменте імплементавана спалучэнне з Apache Atlas і Cloudera Navigator. У сутнасці, распрацоўніку неабходна зарэгістраваць набор аб'ектаў у слоўніках Atlas і спасылацца на зарэгістраваныя аб'екты пры пабудове мапінгаў. Механізм адсочвання паходжання дадзеных або аналіз залежнасцяў аб'ектаў эканоміць вялікую колькасць часу пры неабходнасці ўнясення дапрацовак у алгарытмы разліку. Напрыклад, пры пабудове фінансавай справаздачнасці гэтая фішка дазваляе больш камфортна перажыць перыяд змяненняў заканадаўства. Бо, чым якасней мы ўсведамляем межформенную залежнасць у разрэзе аб'ектаў дэталёвага пласта, тым менш мы сутыкнемся з "раптоўнымі" дэфектамі і скароцім колькасць рэворкаў.

Data Quality & Low-code

Яшчэ адной задачай, рэалізаванай low-code-інструментам на праекце кампаніі Mediascope, стала задача класа Data Quality. Асаблівасцю рэалізацыі канвеера праверкі дадзеных для праекту даследчай кампаніі была адсутнасць уплыву на працаздольнасць і хуткасць працы асноўнага струменя разліку дадзеных. Для магчымасці аркестравання незалежнымі патокамі праверкі даных прымяняўся ўжо знаёмы Apache Airflow. Па меры гатоўнасці кожнага кроку вытворчасці дадзеных раўналежна адбываўся запуск адасобленай часткі DQ-канвеера.

Добрай практыкай лічыцца назіранне за якасцю даных з моманту іх зараджэння ў аналітычнай платформе. Маючы інфармацыю аб метададзеных, мы можам ужо з моманту траплення інфармацыі ў першасны пласт правяраць выкананне базавых умоў - not null, constraints, foreign keys. Гэты функцыянал рэалізаваны на аснове аўтаматычна генераваных мэпінг сямейства data quality ў Datagram. Кодагенерацыя ў дадзеным выпадку таксама грунтуецца на метададзеных мадэлі. На праекце кампаніі Mediascope спалучэнне адбывалася з метададзенымі прадукта Enterprise Architect.

Дзякуючы спалучэнню low-code-інструмента і Enterprise Architect аўтаматычна былі згенераваны наступныя праверкі:

Праверка прысутнасці значэнняў "null" у палях з мадыфікатарам "not null";
Праверка прысутнасці дубляў першаснага ключа;
Праверка знешняга ключа сутнасці;
Праверка ўнікальнасці радка па наборы палёў.

Для больш складаных праверак даступнасці і дакладнасці дадзеных быў створаны мэпінг з Scala Expression, які прымае на ўваход вонкавы Spark SQL-код праверкі, падрыхтаванай сіламі аналітыкаў у Zeppelin.

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

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

Мабыць, асноўнай перавагай стварэння сэрвісу параметрызаваных праверак з'яўляецца скарачэнне часу дастаўкі функцыяналу на прадукцыйнае асяроддзе. Новыя праверкі якасці могуць абмінуць класічны патэрн дастаўкі кода апасродкавана праз асяроддзі распрацоўкі і тэставанні:

Усе праверкі метададзеных генеруюцца аўтаматычна пры змене мадэлі ў EA;
Праверкі даступнасці дадзеных (вызначэнне наяўнасці якіх-небудзь дадзеных на момант часу) могуць быць згенераваны на аснове даведніка, які захоўвае чаканы таймінг з'яўлення чарговай порцыі дадзеных у разрэзе аб'ектаў;
Бізнес-праверкі дакладнасці дадзеных ствараюцца сіламі аналітыкаў у notebook`ах Zeppelin. Адкуль накіроўваюцца наўпрост у наладкавыя табліцы модуля DQ на прадукцыйным асяроддзі.

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

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

замест заключэння

Перавага прымянення low-code відавочная. Распрацоўнікам не трэба распрацоўваць дадатак "з нуля". А вызвалены ад дадатковых задач праграміст дае вынік хутчэй. Хуткасць, у сваю чаргу, вызваляе дадатковы рэсурс часу на вырашэнне пытанняў аптымізацыі. Такім чынам, у дадзеным выпадку можна разлічваць на наяўнасць больш якаснага і хуткага рашэння.

Зразумела, low-code - не панацэя, і чараўніцтва само па сабе не здарыцца:

Малакодавая індустрыя праходзіць стадыю "крепчания", і пакуль у ёй няма аднастайных індустрыяльных стандартаў;
Многія low-code-рашэнні не бясплатныя, і іх набыццё павінна быць усвядомленым крокам, зрабіць які варта пры поўнай упэўненасці фінансавай выгады ад іх выкарыстання;
Многія малакодавыя рашэнні не заўсёды добра сябруюць з GIT / SVN. Або няёмкія ў выкарыстанні ў выпадку ўтойвання генераванага кода;
Пры пашырэнні архітэктуры можа запатрабавацца дапрацоўка малокодового рашэнні што, у сваю чаргу, правакуе эфект прыхільнасці і залежнасці ад пастаўшчыка low-code-рашэнні.
Належны ўзровень забеспячэння бяспекі магчымы, але вельмі працаёмкі і складзены ў рэалізацыі рухавікоў low-code-сістэм. Малакодавыя платформы павінны выбірацца не толькі па прынцыпе пошуку выгады ад іх выкарыстання. Пры выбары варта задацца пытаннямі наяўнасці функцыяналу кіраваннем доступу і дэлегаваннем/эскалацыяй ідэнтыфікацыйных дадзеных на ўзровень усяго IT-ландшафту арганізацыі.

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

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

Калі ў вас сціснутыя тэрміны, нагружаная бізнес-логіка, дэфіцыт тэхналагічнай экспертызы, і вам патрабуецца паскорыць time to market, то low-code - гэта адзін са спосабаў задавальнення вашых патрэбаў.

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

Крыніца: habr.com

Ужыванне low-code у аналітычных платформах