Приложение на low-code в аналитични платформи

Уважаеми читатели, добър ден!

Задачата за изграждане на ИТ платформи за събиране и анализ на данни рано или късно възниква пред всяка компания, чийто бизнес се основава на интелектуално зареден модел за предоставяне на услуги или създаване на технически сложни продукти. Изграждането на аналитични платформи е сложна и отнемаща време задача. Всяка задача обаче може да бъде опростена. В тази статия искам да споделя моя опит в използването на инструменти с нисък код, за да помогна за създаването на аналитични решения. Този опит е придобит при изпълнението на редица проекти в посока Big Data Solutions на компанията Neoflex. От 2005 г. направление Big Data Solutions на Neoflex се занимава с проблемите на изграждането на хранилища и езера за данни, решава проблемите на оптимизирането на скоростта на обработка на информацията и работи върху методология за управление на качеството на данните.

Никой няма да може да избегне съзнателното натрупване на слабо и/или силно структурирани данни. Може би дори ако говорим за малък бизнес. В края на краищата, когато мащабира бизнес, обещаващ предприемач ще се сблъска с проблемите на разработването на програма за лоялност, ще иска да анализира ефективността на точките за продажба, ще мисли за целева реклама и ще бъде озадачен от търсенето на съпътстващи продукти . В първо приближение проблемът може да се реши "на коляно". Но тъй като бизнесът се разраства, достигането до аналитична платформа все още е неизбежно.

В какъв случай обаче задачите за анализ на данни могат да се превърнат в проблеми от класа „Ракетна наука“? Може би в момента, когато говорим за наистина големи данни.
За да улесните Rocket Science, можете да ядете слона парче по парче.

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

Почти всички наши клиенти стигнаха до този постулат, след като възстановиха пейзажа въз основа на инженерните практики на екипите на DevOps.

Но дори и с „разделна, слонска“ диета, имаме добри шансове за „пренасищане“ на ИТ пейзажа. В този момент си струва да спрете, да издишате и да погледнете отстрани инженерна платформа с нисък код.

Много разработчици се плашат от перспективата за задънена улица в кариерата си, когато се отдалечават от директно писане на код към „влачене“ на стрелки в UI интерфейсите на системи с нисък код. Но появата на машинните инструменти не доведе до изчезването на инженерите, а изведе работата им на ново ниво!

Нека да разберем защо.

Анализът на данни в областта на логистиката, телеком индустрията, медийните изследвания, финансовия сектор винаги е свързан със следните въпроси:

• Скорост на автоматизиран анализ;
• Възможност за провеждане на експерименти, без да се засяга основният производствен поток на данни;
• Надеждност на изготвените данни;
• Проследяване на промени и версии;
• Произход на данни, произход на данни, CDC;
• Бързо доставяне на нови функции в производствената среда;
• И прословутото: разходите за разработка и поддръжка.

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

Предпоставките разработчиците да преминат на ново ниво бяха еволюцията и дигитализацията на бизнеса. Стойността на разработчика също се променя: има значителен недостиг на разработчици, които могат да се потопят в концепциите на автоматизирания бизнес.

Нека направим аналогия с езиците за програмиране от ниско и високо ниво. Преходът от езици на ниско ниво към езици на високо ниво е преход от писане на „директни директиви на езика на хардуера“ към „директиви на езика на хората“. Тоест добавяне на някакъв слой абстракция. В този случай преходът към платформи с нисък код от езици за програмиране на високо ниво е преход от „директиви на езика на хората“ към „директиви на езика на бизнеса“. Ако има разработчици, които са натъжени от този факт, те са натъжени може би от момента, в който се роди Java Script, който използва функции за сортиране на масиви. И тези функции, разбира се, имат софтуерна реализация под капака чрез други средства на същото програмиране на високо ниво.

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

Приложен опит с използване на нисък код

Темата за ниския код е доста широка, но сега бих искал да говоря за практическото приложение на „концепции с нисък код“, използвайки примера на един от нашите проекти.

Подразделението за решения за големи данни на Neoflex е специализирано повече във финансовия сектор на бизнеса, изграждане на складове за данни и езера и автоматизиране на различни отчети. В тази ниша използването на нисък код отдавна се е превърнало в стандарт. Сред другите инструменти с нисък код можем да споменем инструменти за организиране на ETL процеси: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Или Oracle Apex, който действа като среда за бързо развитие на интерфейси за достъп и редактиране на данни. Въпреки това, използването на инструменти за разработка с нисък код не винаги включва изграждане на силно насочени приложения върху комерсиален технологичен стек с ясна зависимост от доставчика.

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

Един от приложените примери за опит в използването на инструменти за разработка с нисък код е сътрудничеството между Neoflex и Mediascope, един от лидерите на руския пазар за медийни изследвания. Една от бизнес целите на тази компания е производството на данни, въз основа на които рекламодатели, интернет платформи, телевизионни канали, радиостанции, рекламни агенции и марки вземат решения за закупуване на реклама и планират своите маркетингови комуникации.

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

Към момента на стартиране на проекта компанията вече разполагаше с работещо продуктово решение. Въпреки това, внедряването на решението в MSSQL не можа напълно да отговори на очакванията за функционалност за мащабиране, като същевременно поддържа приемлива цена за разработка.

Задачата пред нас беше наистина амбициозна - Neoflex и Mediascope трябваше да създадат индустриално решение за по-малко от година, при условие че MVP бъде пуснат в рамките на първото тримесечие от началната дата.

Технологичният стек Hadoop беше избран като основа за изграждане на нова платформа за данни, базирана на изчисления с нисък код. HDFS се превърна в стандарт за съхранение на данни с помощта на паркетни файлове. За достъп до данните, намиращи се в платформата, е използван Hive, в който всички налични витрини са представени под формата на външни таблици. Зареждането на данни в хранилището беше реализирано с помощта на Kafka и Apache NiFi.

Инструментът Lowe-code в тази концепция беше използван за оптимизиране на най-трудоемката задача при изграждането на аналитична платформа - задачата за изчисляване на данни.

Инструментът Datagram с нисък код беше избран като основен механизъм за картографиране на данни. Дейтаграма Neoflex е инструмент за разработване на трансформации и потоци от данни.
Използвайки този инструмент, можете да правите без да пишете Scala код ръчно. Кодът на Scala се генерира автоматично с помощта на подхода на управлявана от модел архитектура.

Очевидно предимство на този подход е ускоряването на процеса на разработка. Въпреки това, в допълнение към скоростта, има и следните предимства:

• Преглед на съдържанието и структурата на източници/приемници;
• Проследяване на произхода на обектите на потока от данни до отделни полета (потекло);
• Частично изпълнение на трансформации с преглед на междинни резултати;
• Преглед на изходния код и коригирането му преди изпълнение;
• Автоматично валидиране на трансформациите;
• Автоматично изтегляне на данни 1 в 1.

Бариерата за навлизане в решения с нисък код за генериране на трансформации е доста ниска: разработчикът трябва да знае SQL и да има опит в работата с ETL инструменти. Струва си да се спомене, че управляваните от код генератори на трансформации не са ETL инструменти в широкия смисъл на думата. Инструментите с нисък код може да нямат собствена среда за изпълнение на код. Тоест, генерираният код ще бъде изпълнен в средата, която е съществувала в клъстера дори преди инсталирането на решението с нисък код. И това може би е още един плюс за кармата с нисък код. Тъй като, успоредно с екип с нисък код, може да работи „класически“ екип, който изпълнява функционалност, например, в чист Scala код. Внасянето на подобрения от двата екипа в производството ще бъде лесно и безпроблемно.

Може би си струва да се отбележи, че в допълнение към нисък код, има и решения без код. И в основата си това са различни неща. Ниският код позволява на разработчика да се намесва повече в генерирания код. В случая на Datagram е възможно да видите и редактирате генерирания Scala код; без код може да не предостави такава възможност. Тази разлика е много съществена не само по отношение на гъвкавостта на решението, но и по отношение на комфорта и мотивацията в работата на инженерите по данни.

Архитектура на решението

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

Източниците на данни в нашия случай са много разнородни и разнообразни:

• Пийпъл метри (ТВ метри) са софтуерни и хардуерни устройства, които отчитат потребителското поведение от респондентите на телевизионния панел – кой, кога и какъв телевизионен канал е гледал в домакинството, което участва в изследването. Предоставената информация е поток от интервали за гледане на излъчване, свързани с медийния пакет и медийния продукт. Данните на етапа на зареждане в Data Lake могат да бъдат обогатени с демографски атрибути, геостратификация, часова зона и друга информация, необходима за анализиране на телевизионното гледане на конкретен медиен продукт. Направените измервания могат да се използват за анализ или планиране на рекламни кампании, оценка на активността и предпочитанията на аудиторията и съставяне на мрежата за излъчване;
• Данните могат да идват от системи за мониторинг за стрийминг на телевизионни предавания и измерване на гледането на съдържание на видео ресурси в Интернет;
• Инструменти за измерване в уеб средата, включително измервателни уреди, ориентирани както към сайта, така и към потребителя. Доставчикът на данни за Data Lake може да бъде добавка за браузър за изследователска лента и мобилно приложение с вградена VPN.
• Данните могат да идват и от сайтове, които консолидират резултатите от попълване на онлайн въпросници и резултатите от телефонни интервюта в проучвания на компании;
• Допълнително обогатяване на езерото от данни може да стане чрез изтегляне на информация от регистрационни файлове на партньорски компании.

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

Въпреки това, в контекста на този проект, решихме да не използваме тази функция на платформата с нисък код поради факта, че компанията Mediascope вече е започнала самостоятелно работа по създаването на подобна услуга, използвайки комбинацията Nifi + Kafka.

Струва си веднага да се посочи, че тези инструменти не са взаимозаменяеми, а по-скоро допълващи се. Nifi и Kafka могат да работят както в пряка (Nifi -> Kafka), така и в обратна (Kafka -> Nifi) връзка. За платформата за медийни изследвания беше използвана първата версия на пакета.

В нашия случай NayFi трябваше да обработи различни видове данни от изходните системи и да ги изпрати на брокера Kafka. В този случай съобщенията са изпратени до конкретна тема на Kafka с помощта на процесори PublishKafka Nifi. Оркестрацията и поддръжката на тези тръбопроводи се извършват във визуален интерфейс. Инструментът Nifi и използването на комбинацията Nifi + Kafka също може да се нарече подход с нисък код за разработка, който има ниска бариера за навлизане в технологиите за големи данни и ускорява процеса на разработка на приложения.

Следващият етап от изпълнението на проекта беше да се приведат подробни данни в един формат на семантичен слой. Ако даден обект има исторически атрибути, изчислението се извършва в контекста на въпросния дял. Ако обектът не е исторически, тогава по избор е възможно или да преизчислите цялото съдържание на обекта, или напълно да откажете преизчисляването на този обект (поради липсата на промени). На този етап се генерират ключове за всички обекти. Ключовете се съхраняват в директориите Hbase, съответстващи на главните обекти, които съдържат съответствие между ключовете в аналитичната платформа и ключовете от изходните системи. Консолидацията на атомарните единици е придружена от обогатяване с резултатите от предварителното изчисление на аналитични данни. Рамката за изчисляване на данни беше Spark. Описаната функционалност за привеждане на данни в единна семантика също беше реализирана въз основа на картографиране от инструмента за дейтаграма с нисък код.

Целевата архитектура изисква SQL достъп до данни за бизнес потребители. За тази опция е използван Hive. Обектите се регистрират в Hive автоматично, когато активирате опцията „Registr Hive Table“ в инструмента с нисък код.

Контрол на изчислителния поток

Datagram има интерфейс за създаване на дизайни на потока от работни процеси. Картографирането може да се стартира с помощта на планировчика на Oozie. В интерфейса за разработчици на потоци е възможно да се създават схеми за паралелни, последователни или зависими от изпълнението трансформации на данни. Има поддръжка за shell скриптове и java програми. Възможно е също да използвате сървъра Apache Livy. Apache Livy се използва за стартиране на приложения директно от средата за разработка.

Ако компанията вече има свой собствен оркестратор на процеси, е възможно да използвате REST API за вграждане на съпоставяния в съществуващ поток. Например, имахме доста успешен опит с вграждане на съпоставки в Scala в оркестратори, написани на PLSQL и Kotlin. REST API на инструмента с нисък код включва операции като генериране на изпълнима година въз основа на дизайна на картографиране, извикване на картографиране, извикване на последователност от картографиране и, разбира се, предаване на параметри към URL адреса за изпълнение на картографиране.

Заедно с Oozie е възможно да се организира изчислителен поток с помощта на Airflow. Може би няма да се спирам дълго на сравнението между Oozie и Airflow, а просто ще кажа, че в контекста на работата по медиен изследователски проект изборът падна в полза на Airflow. Основните аргументи този път бяха по-активна общност, разработваща продукта и по-развит интерфейс + API.

Airflow също е добър, защото използва любимия Python, за да опише изчислителните процеси. И като цяло няма толкова много платформи за управление на работния процес с отворен код. Стартирането и наблюдението на изпълнението на процеси (включително диаграма на Гант) само добавя точки към кармата на Airflow.

Форматът на конфигурационния файл за стартиране на съпоставяния на решения с нисък код стана spark-submit. Това се случи по две причини. Първо, spark-submit ви позволява директно да стартирате jar файл от конзолата. Второ, може да съдържа цялата необходима информация за конфигуриране на работния процес (което улеснява писането на скриптове, които генерират Dag).
Най-често срещаният елемент от работния поток на Airflow в нашия случай беше SparkSubmitOperator.

SparkSubmitOperator ви позволява да стартирате буркани - пакетирани преобразувания на дейтаграми с предварително генерирани входни параметри за тях.

Струва си да се спомене, че всяка задача на Airflow се изпълнява в отделна нишка и не знае нищо за други задачи. Следователно взаимодействието между задачите се осъществява с помощта на контролни оператори, като DummyOperator или BranchPythonOperator.

Взети заедно, използването на решението с нисък код на Datagram във връзка с универсализирането на конфигурационните файлове (формиране на Dag) доведе до значително ускоряване и опростяване на процеса на разработване на потоци за зареждане на данни.

Калкулация на витрина

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

Отделна стъпка при подготовката на витрини е валидирането на данните. Алгоритъмът за валидиране включва използването на редица математически научни модели. Въпреки това, използването на платформа с нисък код ви позволява да разбиете сложен алгоритъм на няколко отделни визуално четими съпоставяния. Всяко от преобразуванията изпълнява тясна задача. В резултат на това е възможно междинно отстраняване на грешки, регистриране и визуализация на етапите на подготовка на данните.

Беше решено да се дискретизира алгоритъмът за валидиране на следните подетапи:

• Изграждане на регресии на зависимостите от гледане на телевизионни мрежи в даден регион с гледане на всички мрежи в региона за 60 дни.
• Изчисляване на студентизирани остатъци (отклонения на действителните стойности от предвидените от регресионния модел) за всички точки на регресия и за изчисления ден.
• Селекция от аномални двойки регион-мрежа, където студентизираният баланс на деня на сетълмент надвишава нормата (посочена от настройките на операцията).
• Преизчисляване на коригирания студентизиран остатък за аномални двойки регион-телевизионна мрежа за всеки респондент, който е гледал мрежата в региона, определяне на приноса на този респондент (размерът на промяната в студентизирания остатък), когато се изключи гледането на този респондент от извадката .
• Търсене на кандидати, чието изключване връща студентския баланс на деня на заплатата обратно към нормалното.

Горният пример потвърждава хипотезата, че инженерът на данни вече има твърде много наум... И ако това наистина е „инженер“, а не „кодер“, тогава страхът от професионална деградация при използване на инструменти с нисък код той трябва най-накрая да се оттегли.

Какво друго може да направи ниският код?

Обхватът на приложение на инструмент с нисък код за пакетна и поточна обработка на данни без необходимост от ръчно писане на код в Scala не свършва дотук.

Използването на нисък код при разработката на datalake вече се превърна в стандарт за нас. Вероятно можем да кажем, че решенията, базирани на стека Hadoop, следват пътя на развитие на класическите DWH, базирани на RDBMS. Инструментите с нисък код в стека на Hadoop могат да решат както задачи за обработка на данни, така и задачата за изграждане на крайни BI интерфейси. Освен това трябва да се отбележи, че BI може да означава не само представяне на данни, но и тяхното редактиране от бизнес потребители. Често използваме тази функционалност, когато изграждаме аналитични платформи за финансовия сектор.

Наред с други неща, като се използва нисък код и по-специално Datagram, е възможно да се реши проблемът с проследяването на произхода на обектите на потока от данни с атомарност до отделни полета (линия). За да направите това, инструментът с нисък код внедрява интерфейс с Apache Atlas и Cloudera Navigator. По същество разработчикът трябва да регистрира набор от обекти в речниците на Atlas и да препраща към регистрираните обекти, когато създава картографиране. Механизмът за проследяване на произхода на данните или анализиране на зависимостите на обектите спестява много време, когато е необходимо да се направят подобрения в алгоритмите за изчисление. Например, когато изготвяте финансови отчети, тази функция ви позволява по-удобно да оцелеете в периода на законодателни промени. В края на краищата, колкото по-добре разбираме зависимостта между формите в контекста на обекти от детайлен слой, толкова по-малко ще срещнем „внезапни“ дефекти и ще намалим броя на преработките.

Качество на данните и нисък код

Друга задача, реализирана от инструмента с нисък код на проекта Mediascope, беше задачата за клас Data Quality. Специална характеристика на внедряването на тръбопровода за проверка на данни за проекта на изследователската компания беше липсата на въздействие върху производителността и скоростта на основния поток от изчисления на данни. За да можете да организирате независими потоци за проверка на данни, беше използван вече познатият Apache Airflow. Тъй като всяка стъпка от производството на данни беше готова, паралелно беше пусната отделна част от DQ тръбопровода.

Счита се за добра практика качеството на данните да се следи от момента на въвеждането им в аналитичната платформа. Разполагайки с информация за метаданните, можем да проверим спазването на основните условия от момента, в който информацията влезе в първичния слой - не null, ограничения, външни ключове. Тази функционалност се изпълнява въз основа на автоматично генерирани съпоставяния на фамилията качество на данните в Datagram. Генерирането на код в този случай също се основава на метаданни на модела. В проекта Mediascope интерфейсът беше извършен с метаданните на продукта Enterprise Architect.

Чрез сдвояване на инструмента с нисък код с Enterprise Architect автоматично бяха генерирани следните проверки:

• Проверка за наличие на „нулеви“ стойности в полета с модификатора „не нулев“;
• Проверка за наличие на дубликати на първичния ключ;
• Проверка на външния ключ на обект;
• Проверка на уникалността на низ въз основа на набор от полета.

За по-сложни проверки на наличността и надеждността на данните беше създадено картографиране със Scala Expression, което приема като вход външен код за проверка на Spark SQL, изготвен от анализатори в Zeppelin.

Разбира се, автоматичното генериране на чекове трябва да се постигне постепенно. В рамките на описания проект това беше предшествано от следните стъпки:

• DQ имплементиран в преносими компютри Zeppelin;
• DQ вграден в картографиране;
• DQ под формата на отделни масивни съпоставяния, съдържащи цял набор от проверки за отделен обект;
• Универсални параметризирани DQ съпоставяния, които приемат информация за метаданни и бизнес проверки като вход.

Може би основното предимство на създаването на услуга за параметризирана проверка е намаляването на времето, необходимо за доставяне на функционалност в производствената среда. Новите проверки на качеството могат да заобиколят класическия модел на доставяне на код индиректно чрез среди за разработка и тестване:

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

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

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

Вместо заключение

Предимството от използването на нисък код е очевидно. Разработчиците не трябва да разработват приложението от нулата. А програмист, освободен от допълнителни задачи, дава резултати по-бързо. Скоростта от своя страна освобождава допълнително време за разрешаване на проблеми с оптимизацията. Следователно в този случай можете да разчитате на по-добро и бързо решение.

Разбира се, ниският код не е панацея и магията няма да се случи сама:

• Индустрията с нисък код преминава през етап на „укрепване“ и все още няма единни индустриални стандарти;
• Много решения с нисък код не са безплатни и закупуването им трябва да бъде съзнателна стъпка, която трябва да бъде направена с пълна увереност във финансовите ползи от използването им;
• Много решения с нисък код не винаги работят добре с GIT/SVN. Или са неудобни за използване, ако генерираният код е скрит;
• При разширяване на архитектурата може да се наложи прецизиране на решението с нисък код - което от своя страна провокира ефекта на „привързаност и зависимост“ към доставчика на решението с нисък код.
• Възможно е адекватно ниво на сигурност, но е много трудоемко и трудно за прилагане в системни двигатели с нисък код. Платформите с нисък код трябва да се избират не само на принципа на търсене на ползи от използването им. Когато избирате, си струва да зададете въпроси относно наличието на функционалност за контрол на достъпа и делегиране/ескалация на идентификационни данни до нивото на целия ИТ пейзаж на организацията.

Въпреки това, ако всички недостатъци на избраната система са ви известни и ползите от нейното използване все пак са в преобладаващото мнозинство, тогава преминете към малък код без страх. Още повече, че преходът към нея е неизбежен – както е неизбежна всяка еволюция.

Ако един разработчик на платформа с нисък код върши работата си по-бързо от двама разработчици без нисък код, тогава това дава на компанията преднина във всички отношения. Прагът за навлизане в решения с нисък код е по-нисък, отколкото в „традиционните“ технологии и това има положителен ефект върху проблема с недостига на персонал. Когато се използват инструменти с нисък код, е възможно да се ускори взаимодействието между функционалните екипи и да се вземат по-бързи решения относно правилността на избрания път на изследване на науката за данни. Платформите от ниско ниво могат да стимулират дигиталната трансформация на една организация, тъй като произведените решения могат да бъдат разбрани от нетехнически специалисти (особено бизнес потребители).

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

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

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