🥇Zastosowanie low-code w platformach analitycznych

Szanowni Czytelnicy, życzę miłego dnia!

Zadanie budowy platform IT do gromadzenia i analizy danych prędzej czy później pojawia się w każdej firmie, której podstawą są usługi oparte na złożonych modelach biznesowych lub tworzenie technicznie skomplikowanych produktów. Budowa platform analitycznych to skomplikowane i czasochłonne zadanie. Jednak każdą sprawę można uprościć. W tym artykule chciałbym podzielić się doświadczeniem w zakresie narzędzi low-code, które pomagają w tworzeniu rozwiązań analitycznych. Doświadczenie to zostało zdobyte w trakcie realizacji szeregu projektów w obszarze Big Data Solutions firmy „Neofleks”. Obszar Big Data Solutions firmy „Neofleks” zajmuje się od 2005 roku budową hurtowni oraz jezior danych, optymalizacją prędkości przetwarzania informacji oraz opracowaniem metodologii zarządzania jakością danych.

Nikt nie uniknie świadomego gromadzenia słabo i/lub mocno ustrukturyzowanych danych. Z pewnością nawet małe firmy będą musiały się z tym zmierzyć. W miarę rozwoju biznesu ambitny przedsiębiorca napotka wyzwania związane z opracowaniem programu lojalnościowego, będzie chciał przeanalizować efektywność punktów sprzedaży, pomyśli o reklamie ukierunkowanej oraz zainteresuje się popytem na produkty towarzyszące. Na początku problem można spróbować rozwiązać w sposób „improwizowany”. Jednak w miarę wzrostu firmy przejście do platformy analitycznej staje się nieuniknione.

Kiedy mogą pojawić się zadania związane z analizą danych, które przeistoczą się w wyzwania klasy „Rocket Science”? Z pewnością w momencie, gdy mówimy o naprawdę dużych danych.
Aby uprościć zadanie „Rocket Science”, można je zrealizować, „jedząc słonia” kawałek po kawałku.

Im większa dyskretność i autonomiczność będą miał Twoje aplikacje/usługi/mikroserwisy, tym łatwiej będzie Tobie, Twoim kolegom oraz całemu biznesowi „przetrawić słonia”.

Do tego postulatu doszło praktycznie wszystkich naszych klientów, przekształcając krajobraz oparty na praktykach inżynierii zespołów DevOps.

Jednak nawet przy „oddzielnej, słoniowej” diecie mamy całkiem niezłe szanse na „przejedzenie” krajobrazu IT. W tym momencie warto się zatrzymać, odetchnąć i spojrzeć w stronę platformy inżynierii low-code.

Wielu programistów obawia się perspektywy stagnacji kariery, gdy porzucają bezpośrednie pisanie kodu na rzecz "przeciągania" elementów w interfejsach użytkownika systemów low-code. Jednak wprowadzenie maszyn nie spowodowało zniknięcia inżynierów, a jedynie wyniosło ich pracę na nowy poziom!

Zbadajmy dlaczego.

Analiza danych w obszarze logistyki, telekomunikacji, badań mediów oraz sektora finansowego zawsze związana jest z następującymi pytaniami:

Szybkość przeprowadzenia zautomatyzowanej analizy;
Możliwość przeprowadzania eksperymentów bez wpływu na główny przepływ danych;
Wiarygodność przygotowanych danych;
Śledzenie zmian i wersjonowanie;
Data provenance, Data lineage, CDC;
Szybkość dostarczania nowych funkcji na środowisko produkcyjne;
I wspomniana kwestia: koszt rozwoju i wsparcia.

Oznacza to, że inżynierowie mają ogromną ilość zadań na wysokim poziomie, które mogą być efektywnie realizowane tylko wtedy, gdy uwolnią swoje myśli od zadań niskopoziomowego programowania.

Przesłankami przejścia programistów na nowy poziom stały się ewolucja i cyfryzacja biznesu. Wartość programisty również się zmienia: istnieje znaczny niedobór programistów zdolnych zgłębić istotę konceptów automatyzowanego biznesu.

Przeanalizujmy analogię pomiędzy językami programowania niskiego a wysokiego poziomu. Przejście od języków niskiego poziomu do wysokiego poziomu to przejście od pisania "bezpośrednich dyrektyw w języku sprzętowym" do "dyrektyw w języku ludzi". Oznacza to dodanie pewnej warstwy abstrakcji. W tym kontekście przejście na platformy low-code z wysokopoziomowych języków programowania to przejście od "dyrektyw w języku ludzi" do "dyrektyw w języku biznesu". Jeśli znajdą się programiści, których ten fakt zasmuci, to być może czuli się smutni już od chwili, gdy pojawił się Java Script, w którym wykorzystuje się funkcje sortowania tablicy. A te funkcje, rzecz jasna, mają pod maską programową implementację innymi środkami tego samego wysokiego poziomu programowania.

W związku z tym low-code to jedynie nowy poziom abstrakcji.

Praktyczne doświadczenie w zakresie użycia low-code

Tematyka low-code jest dość szeroka, jednak teraz chciałbym opowiedzieć o praktycznym zastosowaniu 'konceptów low-code' na przykładzie jednego z naszych projektów.

Dział Big Data Solutions firmy «Neoflex» w dużej mierze specjalizuje się w sektorze finansowym, budując hurtownie i jeziora danych oraz automatyzując różne raporty. W tej niszy zastosowanie low-code stało się standardem. Wśród innych narzędzi low-code można wymienić środki do organizacji procesów ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Można też wspomnieć o Oracle Apex, który jest środowiskiem do szybkiego tworzenia interfejsów dostępu do danych oraz ich edytowania. Jednak zastosowanie narzędzi low-code nie zawsze wiąże się z budowaniem aplikacji o wąsko zdefiniowanej specyfice opartej na komercyjnych technologiach z wyraźną zależnością od dostawcy.

Z pomocą platform low-code można również organizować orkiestrację strumieni danych, tworzyć platformy data science lub, na przykład, moduły do weryfikacji jakości danych.

Jednym z praktycznych przykładów zastosowania narzędzi low-code jest współpraca «Neoflex» z firmą Mediascope, jednym z liderów rynku badań mediów w Rosji. Jednym z celów tej firmy jest produkcja danych, na podstawie których reklamodawcy, platformy internetowe, stacje telewizyjne, radia, agencje reklamowe i marki podejmują decyzje o zakupie reklamy i planują swoje komunikacje marketingowe.

Badania mediów to sfera biznesu o dużym obciążeniu technologicznym. Rozpoznawanie materiałów wideo, zbieranie danych z urządzeń analizujących oglądanie, pomiar aktywności na stronach internetowych – to wszystko wymaga posiadania dużego zespołu IT oraz kolosalnego doświadczenia w budowaniu rozwiązań analitycznych. Jednak wykładniczy wzrost ilości informacji, liczby i różnorodności jej źródeł zmusza przemysł IT do ciągłego postępu. Najprostszym rozwiązaniem skalowania już działającej platformy analitycznej Mediascope mogłoby być zwiększenie zespołu IT. Jednak znacznie bardziej efektywnym rozwiązaniem jest przyspieszenie procesu rozwoju. Jednym z kroków prowadzących w tym kierunku może być zastosowanie platform low-code.

Na początku projektu firma już dysponowała działającym rozwiązaniem produktowym. Jednak realizacja rozwiązania na MSSQL nie mogła w pełni zaspokoić oczekiwań dotyczących skalowalności funkcjonalności przy zachowaniu akceptowalnych kosztów zmian.

Postawione przed nami zadanie było naprawdę ambitne – "Neoflex" i Mediascope miały stworzyć przemysłowe rozwiązanie w mniej niż rok, przy założeniu, że MVP zostanie wydane w ciągu pierwszego kwartału od daty rozpoczęcia prac.

Jako fundament do budowy nowej platformy danych, opartej na obliczeniach low-code, wybrano stos technologii Hadoop. Standardem przechowywania danych stał się HDFS z użyciem plików w formacie parquet. Do uzyskania dostępu do danych znajdujących się w platformie użyto Hive, w którym wszystkie dostępne witryny są przedstawione w formie zewnętrznych tabel. Ładowanie danych do magazynu realizowano dzięki Kafka i Apache NiFi.

Narzędzie low-code w tej koncepcji zastosowano do optymalizacji najbardziej pracochłonnej zadania w budowie platformy analitycznej – zadania obliczania danych.

Głównym mechanizmem do mapowania danych wybrane zostało narzędzie low-code Datagram. Neoflex Datagram to narzędzie do rozwijania transformacji i strumieni danych.
Zastosowując to narzędzie, można obejść się bez ręcznego pisania kodu w Scala. Kod Scala generowany jest automatycznie z użyciem podejścia Model Driven Architecture.

Oczywistą zaletą tego podejścia jest przyspieszenie procesu rozwoju. Jednak, oprócz szybkości, istnieją również inne zalety:

Przeglądanie zawartości i struktury źródeł/odbiorników;
Śledzenie pochodzenia obiektów strumienia danych aż do poszczególnych pól (lineage);
Częściowe wykonywanie transformacji z podglądem wyników pośrednich;
Podgląd kodu źródłowego i jego korekta przed wykonaniem;
Automatyczna walidacja transformacji;
Automatyczne ładowanie danych 1 do 1.

Próg wejścia w rozwiązania low-code do generacji transformacji jest stosunkowo niski: programista musi znać SQL i mieć doświadczenie w pracy z narzędziami ETL. Warto jednak zaznaczyć, że generatory transformacji oparte na kodzie nie są narzędziami ETL w szerokim sensie tego słowa. Narzędzia low-code mogą nie mieć własnego środowiska do wykonania kodu. Oznacza to, że wygenerowany kod będzie działał w tym środowisku, które istniało w klastrze przed zainstalowaniem rozwiązania low-code. I to, być może, kolejny plus w karierze low-code. Ponieważ równolegle z zespołem low-code może pracować „klasyczny” zespół, wdrażający funkcjonalność np. w czystym kodzie Scala. Wprowadzenie poprawek obu zespołów do produkcji będzie proste i „bezszwowe”.

Warto również zauważyć, że oprócz low-code istnieją też rozwiązania no-code. Zasadniczo to różne rzeczy. Low-code w większym stopniu pozwala programiście ingerować w generowany kod. W przypadku Datagram możliwe jest przeglądanie i edytowanie generowanego kodu Scala, rozwiązanie no-code może nie oferować tej możliwości. Ta różnica jest istotna nie tylko pod względem elastyczności rozwiązania, ale także komfortu i motywacji w pracy inżynierów danych.

Architektura rozwiązania

Spróbujmy zrozumieć, jak dokładnie narzędzie low-code pomaga w optymalizacji szybkości rozwoju funkcjonalności obliczeń danych. Na początek zbadajmy funkcjonalną architekturę systemu. W tym przypadku przykładem jest model produkcji danych do badań medialnych.

Źródła danych w naszym przypadku są bardzo zróżnicowane i różnorodne:

Piprometry (TV meters) to programowo-sprzętowe urządzenia, które odczytują zachowanie użytkowników wśród respondentów panelu telewizyjnego – kto, kiedy i jaki kanał telewizyjny oglądał w gospodarstwie domowym biorącym udział w badaniu. Dostarczane informacje to strumień interwałów oglądania emisji powiązanych z pakietem medialnym i produktem medialnym. Dane na etapie ładowania do Data Lake mogą być wzbogacone o atrybuty demograficzne, powiązania geostrategiczne, strefy czasowe i inne informacje potrzebne do analizy oglądalności danego produktu medialnego. Zrealizowane pomiary mogą być wykorzystane do analizy lub planowania kampanii reklamowych, oceny aktywności i preferencji odbiorców, tworzenia ramówki emisji;
Dane mogą pochodzić z systemów monitorowania strumieniowych nadawców telewizyjnych i pomiaru oglądalności treści zasobów wideo w Internecie;
Narzędzia pomiarowe w środowisku sieciowym, w tym zarówno liczniki centrystyczne, jak i użytkownikocentryczne. Dostawcą danych dla Data Lake może być rozszerzenie przeglądarki research bar oraz mobilna aplikacja z wbudowanym; VPN.
Dane mogą również pochodzić z platform, które konsolidują wyniki wypełnienia ankiet online oraz wyniki przeprowadzonych rozmów telefonicznych w badaniach sondażowych firmy;
Dodatkowe wzbogacenie zbioru danych może odbywać się poprzez ładowanie informacji z logów firm-partnerów.

Implementacja as is ładowania z systemów źródłowych do początkowego stagingu surowych danych może być zorganizowana na różne sposoby. W przypadku wykorzystywania do tych celów low-code możliwa jest automatyczna generacja scenariuszy ładowania na podstawie metadanych. W tym przypadku nie ma potrzeby schodzić na poziom rozwoju mapowań source to target. Do realizacji automatycznego ładowania musimy nawiązać połączenie z źródłem, a następnie zdefiniować w interfejsie ładowania listę encji, które mają być ładowane. Tworzenie struktury katalogów w HDFS odbędzie się automatycznie i będzie zgodne ze strukturą przechowywania danych w systemie źródłowym.

Jednak w kontekście tego projektu postanowiliśmy nie korzystać z tej funkcji platformy low-code, ponieważ firma Mediascope już samodzielnie rozpoczęła pracę nad stworzeniem podobnej usługi na bazie Nifi + Kafka.

Należy od razu zaznaczyć, że te narzędzia nie są wymienne, a raczej uzupełniają się nawzajem. Nifi i Kafka mogą działać zarówno w bezpośrednim połączeniu (Nifi -> Kafka), jak i odwrotnym (Kafka -> Nifi). W platformie badań medialnych wykorzystano pierwszą wersję połączenia.

W naszym przypadku Nifi musiał przetwarzać różne typy danych z systemów źródłowych i przesyłać je do brokera Kafka. Kierunek wiadomości do określonego tematu Kafka realizowany był za pomocą procesorów Nifi PublishKafka. Orkiestracja i obsługa tych pipeline'ów odbywa się w wizualnym interfejsie. Narzędzie Nifi i użycie połączenia Nifi + Kafka można również określić jako podejście low-code do rozwoju, które ma niski próg wejścia w technologie Big Data i przyspiesza proces tworzenia aplikacji.

Kolejnym etapem realizacji projektu było doprowadzenie do formatu jednolitej warstwy semantycznej szczegółowych danych. W przypadku, gdy encja ma historyczne atrybuty, obliczenia są prowadzone w kontekście rozważanej partycji. Jeśli jednak encja nie jest historyczna, opcjonalnie możliwy jest albo przeliczanie całej zawartości obiektu, albo całkowity brak przeliczenia tego obiektu (w wyniku braku zmian). Na tym etapie generowane są klucze dla wszystkich encji. Klucze są zapisywane w odpowiednich podręcznikach master-objects Hbase, które zawierają zgodność pomiędzy kluczami w platformie analitycznej a kluczami z systemów źródłowych. Konsolidacji atomowych encji towarzyszy wzbogacanie wynikami wstępnych obliczeń danych analitycznych. Frameworkiem do obliczeń danych był Spark. Opisany funkcjonalność przekształcania danych do jednolitej semantyki został również zaimplementowany na podstawie mapowań narzędzia low-code Datagram.

W docelowej architekturze konieczne było zapewnienie dostępu SQL do danych dla użytkowników biznesowych. Do tej opcji wykorzystano Hive. Rejestracja obiektów w Hive odbywa się automatycznie po włączeniu opcji „Zarejestruj tabelę Hive” w narzędziu low-code.

Zarządzanie przepływem obliczeń

Datagram ma interfejs do tworzenia projektów przepływu pracy. Uruchomienie mapowania można przeprowadzić za pomocą harmonogramu Oozie. W interfejsie programisty przepływów można tworzyć schematy równoległych, sekwencyjnych lub zależnych operacji przetwarzania danych. Obsługiwane są skrypty powłoki i programy Java. Możliwe jest także użycie serwera Apache Livy. Apache Livy jest używany do uruchamiania aplikacji bezpośrednio z środowiska deweloperskiego.

Jeśli firma ma już własny orkiestrator procesów, możliwe jest użycie REST API do integrowania mapowań w już istniejący przepływ. Na przykład mieliśmy dość udane doświadczenie z integrowaniem mapowań w Scali w orkiestratorach napisanych w PLSQL i Kotlinie. REST API narzędzia low-code obejmuje takie operacje jak generowanie wykonalnego roku na podstawie projektu mapowania, wywoływanie mapowania, wywoływanie sekwencji mapowań i oczywiście przesyłanie parametrów w URL do uruchomienia mapowań.

Obok Oozie można zorganizować przepływ obliczeń za pomocą Airflow. Nie będę się zbyt długo zatrzymywał na porównaniu Oozie i Airflow, po prostu powiem, że w kontekście prac nad projektem badań medialnych wybór padł na Airflow. Głównymi argumentami były bardziej aktywna społeczność rozwijająca produkt oraz bardziej rozwinięty interfejs + API.

Airflow jest również dobry, ponieważ do opisu procesów obliczeniowych używa języka Python, który wielu lubi. W ogóle platform do zarządzania przepływami pracy z otwartym źródłem jest niewiele. Uruchamianie i monitorowanie wykonania procesów (w tym z wykresem Gantta) dodaje punkty do karmy Airflow.

Format pliku konfiguracyjnego do uruchamiania mapowań rozwiązania low-code stał się spark-submit. Stało się to z dwóch powodów. Po pierwsze, spark-submit pozwala bezpośrednio uruchomić plik jar z konsoli. Po drugie, może zawierać wszystkie niezbędne informacje do skonfigurowania przepływu pracy (co ułatwia pisanie skryptów tworzących Dag).
Najczęściej spotykanym elementem przepływu pracy Airflow w naszym przypadku stał się SparkSubmitOperator.

SparkSubmitOperator pozwala uruchamiać jar’y — spakowane mapowania Datagram z wcześniej przygotowanymi parametrami wejściowymi.

Warto wspomnieć, że każde zadanie Airflow wykonuje się w osobnym wątku i nie ma wiedzy o innych zadaniach. W związku z tym interakcja między zadaniami odbywa się za pomocą operatorów sterujących, takich jak DummyOperator czy BranchPythonOperator.

Zastosowanie rozwiązania low-code Datagram w połączeniu z uniwersalizacją plików konfiguracyjnych (tworzących Dag) przyczyniło się do znacznego przyspieszenia i uproszczenia procesu tworzenia strumieni ładowania danych.

Obliczanie witryn

Z pewnością najbardziej intelektualnie wymagający etap w produkcji danych analitycznych to krok budowy witryn. W kontekście jednego z procesów obliczeniowych firmy badawczej na tym etapie odbywa się dopasowanie do wzorcowej transmisji uwzględniającej korektę stref czasowych, związaną z siecią emisji. Możliwa jest również korekta lokalnej sieci emitującej (lokalne wiadomości i reklama). Wśród innych zadań na tym etapie wykonywane jest dzielenie interwałów ciągłego oglądania produktów medialnych na podstawie analizy interwałów oglądania. Jednocześnie następuje "ważenie" wartości oglądania na podstawie informacji o ich znaczeniu (obliczanie współczynnika korekcyjnego).

Oddzielnym krokiem przygotowania witryn jest walidacja danych. Algorytm walidacji wiąże się z zastosowaniem szeregu modeli matematycznych. Jednak użycie platformy low-code pozwala na rozbicie skomplikowanego algorytmu na szereg oddzielnych, wizualnie czytelnych mapowań. Każde z mapowań wykonuje wąskie zadanie. W rezultacie możliwe jest przeprowadzenie pośredniego debugowania, logowania i wizualizacji etapów przygotowania danych.

Postanowiono dyskretyzować algorytm walidacji na następujące podetapy:

Budowa regresji zależności oglądania telewizji w regionie w porównaniu do oglądania wszystkich sieci w regionie przez ostatnie 60 dni.
Obliczanie znormalizowanych reszt (odchylenia wartości rzeczywistych od przewidywanych przez model regresyjny) dla wszystkich punktów regresji i dla dnia obliczeniowego.
Wyodrębnienie anormalnych par region-sieć telewizyjna, gdzie znormalizowana reszta dnia obliczeniowego przekracza normę (określoną ustawieniem operacji).
Przeliczenie skorygowanego stanu studentów dla anormalnych par region-sieć telewizyjna dla każdego respondenta, który oglądał sieć w regionie z określeniem wkładu danego respondenta (zmiana skorygowanego stanu) przy wyłączeniu oglądania tego respondenta z próby.
Poszukiwanie kandydatów, których wykluczenie przywraca skorygowany stan obliczeniowego dnia do normy.

Podany powyżej przykład potwierdza hipotezę, że inżynier danych ma na głowie zbyt wiele rzeczy… I jeśli to naprawdę "inżynier", a nie "programista", to lęk przed degradacją zawodową przy użyciu narzędzi low-code powinien ostatecznie ustąpić.

Co jeszcze potrafi low-code?

Zakres zastosowania narzędzia low-code do przetwarzania danych wsadowych i strumieniowych bez konieczności ręcznego pisania kodu w Scala nie kończy się.

Zastosowanie low-code w tworzeniu data lake'ów stało się dla nas pewnym standardem. Można chyba powiedzieć, że rozwiązania oparte na stosie Hadoop powielają ścieżkę rozwoju klasycznych hurtowni danych opartych na RDBMS. Narzędzia low-code na stosie Hadoop mogą rozwiązywać zarówno zadania przetwarzania danych, jak i zadania tworzenia końcowych interfejsów BI. Należy jednak zauważyć, że pod pojęciem BI można rozumieć nie tylko reprezentację danych, ale także ich edycję przez użytkowników biznesowych. Ta funkcjonalność jest często przez nas stosowana przy budowie platform analitycznych dla sektora finansowego.

Między innymi, za pomocą low-code i, w szczególności, Datagram, można rozwiązać problem śledzenia pochodzenia obiektów przepływu danych z atomowością do pojedynczych pól (lineage). W tym celu w narzędziu low-code zaimplementowano połączenie z Apache Atlas i Cloudera Navigator. W zasadzie, deweloper musi zarejestrować zbiór obiektów w słownikach Atlas i odwołać się do zarejestrowanych obiektów przy tworzeniu mapowań. Mechanizm śledzenia pochodzenia danych lub analiza zależności obiektów oszczędza dużą ilość czasu w przypadku konieczności wprowadzania poprawek w algorytmach obliczeniowych. Na przykład, podczas sporządzania raportów finansowych ta funkcjonalność pozwala na łatwiejsze przetrwanie okresu zmian w legislacji. Im lepiej rozumiemy zależności między formami w kontekście obiektów szczegółowej warstwy, tym mniejsze ryzyko „niespodziewanych” defektów i mniejsza liczba poprawek.

Jakość Danych & Low-code

Kolejnym zadaniem, które zostało zrealizowane za pomocą narzędzia low-code w projekcie firmy Mediascope, było zadanie klasy Jakość Danych. Cechą realizacji potoku weryfikacji danych dla projektu firmy badawczej było brak wpływu na funkcjonalność i szybkość działania głównego strumienia obliczeń danych. W celu orkiestracji niezależnymi strumieniami weryfikacji danych wykorzystano już znany Apache Airflow. W miarę gotowości każdego kroku produkcji danych równolegle uruchamiano odrębną część potoku DQ.

Dobrą praktyką jest monitorowanie jakości danych od momentu ich powstania na platformie analitycznej. Mając informacje o metadanych, możemy już od momentu wprowadzenia informacji do warstwy pierwotnej weryfikować spełnianie podstawowych warunków — not null, constraints, foreign keys. Ta funkcjonalność została zrealizowana na podstawie automatycznie generowanych mapowań rodziny data quality w Datagram. Generacja kodu w tym przypadku również opiera się na metadanych modelu. W projekcie firmy Mediascope połączenie odbywało się z metadanymi produktu Enterprise Architect.

Dzięki połączeniu narzędzia low-code i Enterprise Architect automatycznie zostały wygenerowane następujące kontrole:

Kontrola obecności wartości „null” w polach z modyfikatorem „not null”;
Kontrola obecności duplikatów klucza głównego;
Sprawdzanie klucza obcego encji;
Sprawdzanie unikalności wiersza według zestawu pól.

Dla bardziej złożonych kontroli dostępności i wiarygodności danych stworzono mapowanie z wykorzystaniem Scala Expression, które przyjmuje jako wejście zewnętrzny kod Spark SQL stworzony przez analityków w Zeppelin.

Oczywiście, do autogeneracji kontroli należy podchodzić stopniowo. W ramach opisywanego projektu temu towarzyszyły następujące kroki:

DQ, zrealizowane w notatnikach Zeppelin;
DQ, zintegrowane w mapowaniu;
DQ w postaci oddzielnych dużych mapowań, zawierających cały zestaw kontroli dla pojedynczej encji;
Uniwersalne parametryzowane mapowania DQ, akceptujące jako wejście informacje o metadanych i kontrolach biznesowych.

Największą zaletą stworzenia serwisu parametryzowanych kontroli jest skrócenie czasu dostarczenia funkcjonalności na środowisko produkcyjne. Nowe kontrole jakości mogą pomijać klasyczny wzorzec dostarczania kodu pośrednio przez środowiska deweloperskie i testowe:

Wszystkie kontrole metadanych są generowane automatycznie przy zmianie modelu w EA;
Kontrole dostępności danych (określenie obecności jakichkolwiek danych w danym momencie) mogą być generowane na podstawie słownika, który przechowuje oczekiwaną synchronizację pojawienia się kolejnej partii danych w podziale na obiekty;
Kontrole biznesowe wiarygodności danych są tworzone przez analityków w notatnikach Zeppelin. Z nich są kierowane bezpośrednio do tabel konfiguracyjnych modułu DQ na środowisku produkcyjnym.

Ryzyko bezpośredniego wysyłania skryptów na produkcję praktycznie nie istnieje. Nawet przy błędzie składniowym maksymalne, co nam grozi, to niewykonanie jednej kontroli, ponieważ przepływ obliczania danych i przepływ uruchamiania kontroli jakości są od siebie oddzielone.

W istocie serwis DQ jest na stałe uruchomiony na środowisku produkcyjnym i gotowy do rozpoczęcia pracy w momencie pojawienia się kolejnej partii danych.

Zamiast zakończenia

Zaleta stosowania low-code jest oczywista. Programiści nie muszą tworzyć aplikacji „od podstaw”. A zwolniony od dodatkowych zadań programista osiąga wyniki szybciej. Szybkość z kolei uwalnia dodatkowy czas na rozwiązywanie problemów optymalizacji. W związku z tym, w tej sytuacji można liczyć na dostępność bardziej jakościowego i szybkiego rozwiązania.

Oczywiście, low-code nie jest panaceum i magia sama w sobie się nie wydarzy:

Przemysł low-code przechodzi etap „wzmocnienia”, i póki co brakuje w nim jednorodnych standardów przemysłowych;
Wiele rozwiązań low-code nie jest darmowych, a ich zakup powinien być świadomym krokiem, podjętym z pełną pewnością finansowych korzyści z ich wykorzystania;
Wiele rozwiązań low-code nie zawsze dobrze współpracuje z GIT / SVN. Albo są niewygodne w użyciu w przypadku ukrycia generowanego kodu;
Przy rozszerzaniu architektury może być konieczne dostosowanie rozwiązania low-code – co z kolei powoduje efekt „przywiązania i zależności” od dostawcy rozwiązania low-code.
Odpowiedni poziom zapewnienia bezpieczeństwa jest możliwy, ale bardzo pracochłonny i skomplikowany w realizacji silników systemów low-code. Platformy low-code powinny być wybierane nie tylko na podstawie poszukiwania korzyści z ich używania. W wyborze warto zadać sobie pytania o obecność funkcjonalności zarządzania dostępem oraz delegowaniem/eskalacją danych identyfikacyjnych na poziomie całego IT krajobrazu organizacji.

Jednakże jeśli wszystkie wady wybranego systemu są ci znane, a korzyści z jego wykorzystania mimo wszystko przeważają, przechodź do low-code bez obaw. Tym bardziej, że przejście na niego jest nieuniknione – tak jak każda ewolucja.

Jeśli jeden programista na platformie low-code wykonuje swoją pracę szybciej niż dwóch programistów bez low-code, to daje to firmie przewagę we wszystkich aspektach. Próg wejścia w rozwiązania low-code jest niższy niż w przypadku "tradycyjnych" technologii, co pozytywnie wpływa na problem braku personelu. Korzystając z narzędzi low-code, można przyspieszyć współpracę między zespołami funkcjonalnymi i szybciej podejmować decyzje o poprawności wybranego kierunku badań w zakresie data science. Platformy low-code mogą być przyczyną cyfrowej transformacji organizacji, ponieważ tworzone rozwiązania mogą być zrozumiane przez nietechnicznych specjalistów (w szczególności przez użytkowników biznesowych).

Jeśli masz napięte terminy, złożoną logikę biznesową, brak technologicznej ekspertyzy i musisz przyspieszyć time to market, to low-code jest jednym ze sposobów zaspokojenia Twoich potrzeb.

Nie można negować znaczenia tradycyjnych narzędzi programistycznych, jednak w wielu przypadkach stosowanie rozwiązań low-code jest najlepszym sposobem na zwiększenie efektywności rozwiązywanych problemów.

Źródło: habr.com