Zastosowanie low-code w platformach analitycznych

Drodzy czytelnicy, dzień dobry!

Zadanie budowy platform informatycznych służących do gromadzenia i analizowania danych prędzej czy później pojawia się przed każdą firmą, której biznes opiera się na intelektualnie obciążonym modelu świadczenia usług lub tworzeniu skomplikowanych technicznie produktów. Budowa platform analitycznych jest zadaniem złożonym i czasochłonnym. Jednak każde zadanie można uprościć. W tym artykule chcę podzielić się swoim doświadczeniem w wykorzystaniu narzędzi niskokodowych do tworzenia rozwiązań analitycznych. Doświadczenie to zostało zdobyte podczas realizacji szeregu projektów w kierunku Big Data Solutions firmy Neoflex. Od 2005 roku kierunek Big Data Solutions w firmie Neoflex zajmuje się problematyką budowy hurtowni i jezior danych, rozwiązywaniem problemów optymalizacji szybkości przetwarzania informacji oraz pracą nad metodologią zarządzania jakością danych.

Nikt nie będzie w stanie uniknąć świadomego gromadzenia słabo i/lub silnie ustrukturyzowanych danych. Być może nawet jeśli mówimy o małych firmach. Przecież skalując biznes, obiecujący przedsiębiorca stanie przed problemami opracowania programu lojalnościowego, będzie chciał przeanalizować efektywność punktów sprzedaży, pomyśli o reklamie ukierunkowanej i będzie zdziwiony popytem na produkty towarzyszące . W pierwszym przybliżeniu problem można rozwiązać „na kolanie”. Jednak w miarę rozwoju firmy przejście na platformę analityczną jest nadal nieuniknione.

Jednak w jakim przypadku zadania związane z analizą danych mogą przerodzić się w problemy klasy „Rocket Science”? Być może w momencie, gdy mówimy o naprawdę big data.
Aby ułatwić naukę o rakietach, możesz jeść słonia kawałek po kawałku.

Im bardziej dyskretne i autonomiczne są Twoje aplikacje/usługi/mikrousługi, tym łatwiej będzie Tobie, Twoim współpracownikom i całej firmie przetrawić słonia.

Do tego postulatu doszli niemal wszyscy nasi klienci, przebudowując krajobraz w oparciu o praktyki inżynieryjne zespołów DevOps.

Ale nawet przy „oddzielnej, słoniowej” diecie mamy duże szanse na „przesycenie” krajobrazu IT. Warto w tym momencie zatrzymać się, zrobić wydech i spojrzeć w bok platforma inżynierska o niskim kodzie.

Wielu programistów boi się perspektywy ślepego zaułka w swojej karierze, gdy odejdą od bezpośredniego pisania kodu na rzecz „przeciągania” strzałek w interfejsach UI systemów o niskim kodzie. Ale pojawienie się obrabiarek nie doprowadziło do zniknięcia inżynierów, ale wyniosło ich pracę na nowy poziom!

Zastanówmy się dlaczego.

Analiza danych z zakresu logistyki, branży telekomunikacyjnej, badań mediów, sektora finansowego zawsze wiąże się z następującymi pytaniami:

• Szybkość automatycznej analizy;
• Możliwość przeprowadzania eksperymentów bez wpływu na główny przepływ produkcji danych;
• Rzetelność przygotowanych danych;
• Śledzenie zmian i wersjonowanie;
• Pochodzenie danych, pochodzenie danych, CDC;
• Szybkie dostarczanie nowych funkcji do środowiska produkcyjnego;
• I notoryczne: koszt rozwoju i wsparcia.

Oznacza to, że inżynierowie mają ogromną liczbę zadań wysokiego poziomu, które można wykonać z wystarczającą wydajnością jedynie poprzez oczyszczenie świadomości z zadań programistycznych niskiego poziomu.

Warunkiem przejścia programistów na nowy poziom była ewolucja i cyfryzacja biznesu. Zmienia się także wartość programisty: zauważalnie brakuje programistów, którzy potrafią zagłębić się w koncepcje automatyzacji biznesu.

Narysujmy analogię z językami programowania niskiego i wysokiego poziomu. Przejście od języków niskiego poziomu do języków wysokiego poziomu to przejście od pisania „bezpośrednich dyrektyw w języku sprzętu” do „dyrektyw w języku ludzi”. Czyli dodanie warstwy abstrakcji. W tym przypadku przejście na platformy niskokodowe z języków programowania wysokiego poziomu jest przejściem od „dyrektyw w języku ludzi” do „dyrektyw w języku biznesu”. Jeśli są programiści, którzy są zasmuceni tym faktem, być może są zasmuceni od chwili narodzin Java Script, który wykorzystuje funkcje sortowania tablic. Funkcje te mają oczywiście implementację oprogramowania pod maską za pomocą innych środków tego samego programowania wysokiego poziomu.

Dlatego low-code to tylko pozory innego poziomu abstrakcji.

Zastosowane doświadczenie przy użyciu niskiego kodu

Temat low-code jest dość szeroki, ale teraz chciałbym poruszyć temat praktycznego zastosowania „koncepcji low-code” na przykładzie jednego z naszych projektów.

Dział Big Data Solutions firmy Neoflex specjalizuje się bardziej w finansowym sektorze biznesu, budując hurtownie i jeziora danych oraz automatyzując różne raporty. W tej niszy stosowanie low-code od dawna stało się standardem. Wśród innych narzędzi niskokodowych można wymienić narzędzia do organizacji procesów ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Albo Oracle Apex, który pełni rolę środowiska do szybkiego rozwoju interfejsów dostępu i edycji danych. Jednak korzystanie z narzędzi programistycznych wymagających niewielkiej ilości kodu nie zawsze wiąże się z tworzeniem wysoce ukierunkowanych aplikacji w oparciu o komercyjny stos technologii z wyraźną zależnością od dostawcy.

Wykorzystując platformy niskokodowe można także organizować orkiestrację przepływów danych, tworzyć platformy data science czy np. moduły sprawdzające jakość danych.

Jednym z zastosowanych przykładów doświadczeń w korzystaniu z narzędzi programistycznych typu low-code jest współpraca Neoflex z firmą Mediascope, jednym z liderów rosyjskiego rynku badań mediów. Jednym z celów biznesowych tej spółki jest wytwarzanie danych, na podstawie których reklamodawcy, platformy internetowe, kanały telewizyjne, stacje radiowe, agencje reklamowe i marki podejmują decyzje o zakupie reklam i planują swoją komunikację marketingową.

Badania mediów to obciążony technologicznie obszar biznesu. Rozpoznawanie sekwencji wideo, zbieranie danych z urządzeń analizujących oglądalność, mierzenie aktywności w zasobach sieciowych – to wszystko sprawia, że ​​firma dysponuje dużą kadrą informatyczną i ogromnym doświadczeniem w budowaniu rozwiązań analitycznych. Jednak wykładniczy wzrost ilości informacji, liczby i różnorodności jej źródeł wymusza ciągły rozwój branży danych IT. Najprostszym rozwiązaniem skalowania już funkcjonującej platformy analitycznej Mediascope mogłoby być zwiększenie kadry IT. Ale o wiele skuteczniejszym rozwiązaniem jest przyspieszenie procesu rozwoju. Jednym z kroków prowadzących w tym kierunku może być wykorzystanie platform niskokodowych.

W momencie rozpoczęcia projektu firma posiadała już funkcjonujące rozwiązanie produktowe. Jednakże wdrożenie rozwiązania w MSSQL nie było w stanie w pełni spełnić oczekiwań w zakresie skalowania funkcjonalności przy zachowaniu akceptowalnych kosztów rozwoju.

Zadanie stojące przed nami było naprawdę ambitne – Neoflex i Mediascope musiały stworzyć rozwiązanie przemysłowe w niecały rok, pod warunkiem wydania MVP w pierwszym kwartale od daty rozpoczęcia.

Jako podstawę do budowy nowej platformy danych opartej na przetwarzaniu niskokodowym wybrano stos technologii Hadoop. HDFS stał się standardem przechowywania danych przy użyciu plików parkietowych. Do dostępu do danych znajdujących się w platformie wykorzystano Hive, w którym wszystkie dostępne witryny sklepowe prezentowane są w formie zewnętrznych tabel. Ładowanie danych do magazynu zostało zrealizowane przy użyciu Kafki i Apache NiFi.

Narzędzie Lowe-code w tej koncepcji zostało wykorzystane do optymalizacji najbardziej pracochłonnego zadania przy budowie platformy analitycznej – zadania obliczania danych.

Jako główny mechanizm mapowania danych wybrano niskokodowe narzędzie Datagram. Datagram Neoflexu to narzędzie do opracowywania przekształceń i przepływów danych.
Korzystając z tego narzędzia, możesz obejść się bez ręcznego pisania kodu Scala. Kod Scala jest generowany automatycznie przy użyciu podejścia Model Driven Architecture.

Oczywistą zaletą takiego podejścia jest przyspieszenie procesu rozwoju. Jednak oprócz szybkości istnieją również następujące zalety:

• Przeglądanie zawartości i struktury źródeł/odbiorników;
• Śledzenie pochodzenia obiektów przepływu danych do poszczególnych pól (pochodzenie);
• Częściowe wykonanie przekształceń z podglądem wyników pośrednich;
• Przegląd kodu źródłowego i dostosowanie go przed wykonaniem;
• Automatyczna walidacja transformacji;
• Automatyczne pobieranie danych 1 w 1.

Bariera wejścia w niskokodowe rozwiązania do generowania transformacji jest dość niska: programista musi znać SQL i mieć doświadczenie w pracy z narzędziami ETL. Warto wspomnieć, że generatory transformacji sterowane kodem nie są narzędziami ETL w szerokim tego słowa znaczeniu. Narzędzia wymagające niewielkiej ilości kodu mogą nie mieć własnego środowiska wykonywania kodu. Oznacza to, że wygenerowany kod zostanie wykonany w środowisku, które istniało w klastrze jeszcze przed zainstalowaniem rozwiązania o małej zawartości kodu. Być może jest to kolejny plus karmy o niskim kodzie. Ponieważ równolegle z zespołem low-code może pracować zespół „klasyczny”, który implementuje funkcjonalność na przykład w czystym kodzie Scala. Wprowadzanie ulepszeń obu zespołów do produkcji będzie proste i bezproblemowe.

Być może warto zauważyć, że oprócz rozwiązań niskokodowych istnieją również rozwiązania bezkodowe. W istocie są to różne rzeczy. Low code pozwala programiście na większą ingerencję w wygenerowany kod. W przypadku Datagramu istnieje możliwość przeglądania i edycji wygenerowanego kodu Scala, brak kodu może nie zapewniać takiej możliwości. Różnica ta jest bardzo znacząca 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 dokładnie dowiedzieć się, w jaki sposób narzędzie o niskim kodzie pomaga rozwiązać problem optymalizacji szybkości tworzenia funkcjonalności obliczania danych. Na początek przyjrzyjmy się architekturze funkcjonalnej systemu. Przykładem w tym przypadku jest model produkcji danych do badań mediów.

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

• Liczniki osób (tzw. liczniki telewizyjne) to urządzenia programowo-sprzętowe, które odczytują zachowania użytkowników od respondentów panelu telewizyjnego – kto, kiedy i jaki kanał telewizyjny oglądał w gospodarstwie domowym biorącym udział w badaniu. Dostarczona informacja to strumień interwałów oglądania transmisji powiązany z pakietem multimedialnym i produktem medialnym. Dane na etapie ładowania do Data Lake mogą zostać wzbogacone o atrybuty demograficzne, geostratyfikację, strefę czasową i inne informacje niezbędne do analizy oglądalności telewizyjnej konkretnego produktu medialnego. Dokonane pomiary mogą posłużyć do analizy lub planowania kampanii reklamowych, oceny aktywności i preferencji odbiorców oraz tworzenia sieci nadawczej;
• Dane mogą pochodzić z systemów monitorowania strumieniowego przesyłania programów telewizyjnych i pomiaru oglądalności treści zasobów wideo w Internecie;
• Narzędzia pomiarowe w środowisku internetowym, w tym liczniki zorientowane na witrynę i użytkownika. Dostawcą danych dla Data Lake może być dodatek do przeglądarki typu Research Bar oraz aplikacja mobilna z wbudowaną siecią VPN.
• Dane mogą pochodzić także z serwisów konsolidujących wyniki wypełniania ankiet on-line oraz wyniki wywiadów telefonicznych w ankietach firmowych;
• Dodatkowe wzbogacenie jeziora danych może nastąpić poprzez pobranie informacji z logów firm partnerskich.

Implementację ładowania z systemów źródłowych do pierwotnej lokalizacji surowych danych można zorganizować na różne sposoby. Jeżeli do tych celów wykorzystany zostanie low-code, możliwe jest automatyczne generowanie skryptów ładujących na podstawie metadanych. W tym przypadku nie ma potrzeby schodzenia do poziomu opracowania mapowań źródłowych na docelowych. Aby zaimplementować automatyczne ładowanie, musimy nawiązać połączenie ze źródłem, a następnie zdefiniować w interfejsie ładowania listę podmiotów do załadowania. Struktura katalogów w HDFS zostanie utworzona automatycznie i będzie odpowiadać strukturze przechowywania danych w systemie źródłowym.

Jednak w kontekście tego projektu zdecydowaliśmy się nie wykorzystywać tej funkcjonalności platformy low-code ze względu na fakt, że firma Mediascope samodzielnie rozpoczęła już prace nad stworzeniem podobnej usługi z wykorzystaniem kombinacji Nifi + Kafka.

Warto od razu zaznaczyć, że narzędzia te nie są wymienne, a raczej uzupełniają się. Nifi i Kafka mogą pracować zarówno w połączeniu bezpośrednim (Nifi -> Kafka), jak i w połączeniu odwrotnym (Kafka -> Nifi). W przypadku platformy badań mediów wykorzystano pierwszą wersję pakietu.

W naszym przypadku NayFi musiało przetworzyć różnego rodzaju dane z systemów źródłowych i przesłać je do brokera Kafki. W tym przypadku wiadomości zostały wysłane do konkretnego tematu Kafki przy użyciu procesorów PublishKafka Nifi. Koordynacja i konserwacja tych rurociągów odbywa się za pomocą interfejsu wizualnego. Narzędzie Nifi i wykorzystanie kombinacji Nifi + Kafka można nazwać także niskokodowym podejściem do rozwoju, które ma niską barierę wejścia w technologie Big Data i przyspiesza proces tworzenia aplikacji.

Kolejnym etapem realizacji projektu było sprowadzenie szczegółowych danych do formatu pojedynczej warstwy semantycznej. Jeżeli jednostka posiada cechy historyczne, kalkulacja dokonywana jest w kontekście danego podziału. Jeżeli podmiot nie jest historyczny, wówczas opcjonalnie możliwe jest albo przeliczenie całej zawartości obiektu, albo całkowita odmowa przeliczenia tego obiektu (ze względu na brak zmian). Na tym etapie generowane są klucze dla wszystkich podmiotów. Klucze przechowywane są w katalogach Hbase odpowiadających obiektom głównym, które zawierają powiązania pomiędzy kluczami na platformie analitycznej a kluczami z systemów źródłowych. Konsolidacji jednostek atomowych towarzyszy wzbogacanie o wyniki wstępnych obliczeń danych analitycznych. Ramą do obliczania danych był Spark. Opisana funkcjonalność sprowadzania danych do pojedynczej semantyki została również zaimplementowana w oparciu o mapowania z niskokodowego narzędzia Datagram.

Docelowa architektura wymagała dostępu SQL do danych dla użytkowników biznesowych. W tej opcji użyto Hive. Obiekty są rejestrowane w Hive automatycznie po włączeniu opcji „Zarejestruj tabelę Hive” w narzędziu o niskim kodzie.

Kontrola przepływu obliczeń

Datagram posiada interfejs do tworzenia projektów przepływu pracy. Mapowania można uruchomić za pomocą harmonogramu Oozie. W interfejsie dewelopera strumieniowego możliwe jest tworzenie schematów transformacji danych równoległych, sekwencyjnych lub zależnych od wykonania. Obsługiwane są skrypty powłoki i programy Java. Możliwe jest także wykorzystanie serwera Apache Livy. Apache Livy służy do uruchamiania aplikacji bezpośrednio ze środowiska programistycznego.

Jeśli firma posiada już własnego koordynatora procesów, istnieje możliwość wykorzystania REST API w celu osadzenia mapowań w istniejącym przepływie. Na przykład mieliśmy całkiem udane doświadczenie w osadzaniu mapowań w Scali w orkiestratorach napisanych w PLSQL i Kotlinie. Interfejs API REST narzędzia o niskim kodzie obejmuje operacje takie jak generowanie roku wykonywalnego na podstawie projektu mapowania, wywoływanie mapowania, wywoływanie sekwencji mapowań i oczywiście przekazywanie parametrów do adresu URL w celu uruchomienia mapowań.

Wraz z Oozie możliwe jest zorganizowanie przepływu obliczeń za pomocą Airflow. Być może nie będę się długo rozwodzić nad porównaniem Oozie i Airflow, ale powiem po prostu, że w kontekście pracy nad projektem badania mediów wybór padł na Airflow. Głównymi argumentami tym razem była bardziej aktywna społeczność rozwijająca produkt oraz bardziej rozwinięty interfejs + API.

Airflow jest również dobry, ponieważ wykorzystuje ukochany Python do opisu procesów obliczeniowych. Ogólnie rzecz biorąc, nie ma zbyt wielu platform do zarządzania przepływem pracy typu open source. Uruchamianie i monitorowanie realizacji procesów (w tym wykresu Gantta) tylko dodaje punkty do karmy Airflow.

Format pliku konfiguracyjnego do uruchamiania mapowań rozwiązań wymagających niewielkiej ilości kodu stał się systemem Spark-Submit. Stało się to z dwóch powodów. Po pierwsze, spark-submit umożliwia bezpośrednie uruchomienie pliku jar z konsoli. Po drugie, może zawierać wszystkie informacje niezbędne do skonfigurowania przepływu pracy (co ułatwia pisanie skryptów generujących Dag).
W naszym przypadku najczęstszym elementem przepływu pracy Airflow był SparkSubmitOperator.

SparkSubmitOperator umożliwia uruchamianie jars – spakowanych mapowań datagramów z wygenerowanymi dla nich wstępnie parametrami wejściowymi.

Warto wspomnieć, że każde zadanie Airflow działa w osobnym wątku i nie wie nic o innych zadaniach. Dlatego interakcja pomiędzy zadaniami odbywa się za pomocą operatorów sterujących, takich jak DummyOperator czy BranchPythonOperator.

Podsumowując, zastosowanie niskokodowego rozwiązania Datagram w połączeniu z uniwersalizacją plików konfiguracyjnych (tworząc Dag) doprowadziło do znacznego przyspieszenia i uproszczenia procesu opracowywania przepływów ładowania danych.

Pokaż obliczenia

Być może najbardziej obciążonym intelektualnie etapem tworzenia danych analitycznych jest etap budowania prezentacji. W kontekście jednego z przepływów obliczeń danych firmy badawczej, na tym etapie dane są redukowane do transmisji referencyjnej, z uwzględnieniem poprawek na strefy czasowe i połączone z siatką nadawczą. Możliwe jest także dostosowanie do lokalnej sieci nadawczej (wiadomości lokalne i reklamy). Na tym etapie między innymi rozbijane są interwały ciągłego oglądania produktów medialnych na podstawie analizy interwałów oglądania. Natychmiast oglądane wartości są „ważone” na podstawie informacji o ich znaczeniu (obliczenie współczynnika korygującego).

Osobnym krokiem w przygotowaniu prezentacji jest walidacja danych. Algorytm walidacji obejmuje wykorzystanie szeregu modeli matematycznych. Jednak zastosowanie platformy o niskim kodzie pozwala rozbić złożony algorytm na szereg oddzielnych, czytelnych wizualnie mapowań. Każde z mapowań wykonuje wąskie zadanie. Dzięki temu możliwe jest pośrednie debugowanie, rejestrowanie i wizualizacja etapów przygotowania danych.

Zdecydowano się na dyskretyzację algorytmu walidacji na następujące podetapy:

• Budowanie regresji zależności oglądalności sieci telewizyjnych w regionie z oglądaniem wszystkich sieci w regionie przez 60 dni.
• Obliczenie studentyzowanych reszt (odchyłek wartości rzeczywistych od przewidywanych przez model regresji) dla wszystkich punktów regresji i dla obliczonej doby.
• Wybór anomalnych par region-sieć, gdzie studentyzowane saldo dnia rozliczeniowego przekracza normę (określoną w ustawieniach operacji).
• Ponowne obliczenie skorygowanej studentyzowanej reszty dla anomalnych par region-sieć telewizyjna dla każdego respondenta, który oglądał sieć w regionie, określenie wkładu tego respondenta (wielkość zmiany studentyzowanej reszty) przy wykluczeniu oglądania tego respondenta z próby .
• Szukaj kandydatów, których wykluczenie przywróci studentowi saldo wypłaty do normy.

Powyższy przykład potwierdza hipotezę, że inżynier danych ma już za dużo na głowie... A jeśli to rzeczywiście jest „inżynier”, a nie „koder”, to obawa przed degradacją zawodową przy korzystaniu z narzędzi niskokodowych trzeba się w końcu wycofać.

Co jeszcze potrafi low-code?

Na tym nie kończy się zakres zastosowania niskokodowego narzędzia do przetwarzania danych wsadowych i strumieniowych bez konieczności ręcznego pisania kodu w Scali.

Stosowanie low-code przy tworzeniu datalake stało się już dla nas standardem. Można chyba powiedzieć, że rozwiązania bazujące na stosie Hadoop podążają ścieżką rozwoju klasycznych DWH bazujących na RDBMS. Narzędzia niskokodowe na stosie Hadoop mogą rozwiązać zarówno zadania przetwarzania danych, jak i zadanie budowy ostatecznych interfejsów BI. Ponadto należy zaznaczyć, że BI może oznaczać nie tylko reprezentację danych, ale także ich edycję przez użytkowników biznesowych. Często korzystamy z tej funkcjonalności budując platformy analityczne dla sektora finansowego.

Między innymi za pomocą low-code, a w szczególności Datagramu, możliwe jest rozwiązanie problemu śledzenia pochodzenia obiektów strumienia danych z atomowością aż do poszczególnych pól (pochodzenie). W tym celu narzędzie niskokodowe implementuje interfejs z Apache Atlas i Cloudera Navigator. Zasadniczo programista musi zarejestrować zestaw obiektów w słownikach Atlas i odwoływać się do zarejestrowanych obiektów podczas tworzenia mapowań. Mechanizm śledzenia pochodzenia danych czy analizy zależności obiektów pozwala zaoszczędzić dużo czasu, gdy konieczne jest wprowadzenie ulepszeń w algorytmach obliczeniowych. Na przykład podczas sporządzania sprawozdań finansowych funkcja ta pozwala wygodniej przetrwać okres zmian legislacyjnych. Przecież im lepiej rozumiemy zależności międzyformowe w kontekście obiektów warstwy szczegółowej, tym rzadziej będziemy napotykać „nagłe” defekty i zmniejszać liczbę przeróbek.

Jakość danych i niski kod

Kolejnym zadaniem realizowanym przez narzędzie niskokodowe w projekcie Mediascope było zadanie klasy Data Quality. Cechą szczególną wdrożenia rurociągu weryfikacji danych dla projektu firmy badawczej był brak wpływu na wydajność i szybkość głównego przepływu obliczeń danych. Aby móc koordynować niezależne przepływy weryfikacji danych, wykorzystano znany już Apache Airflow. Gdy każdy etap wytwarzania danych był gotowy, równolegle uruchomiono oddzielną część rurociągu DQ.

Za dobrą praktykę uważa się monitorowanie jakości danych od momentu ich powstania na platformie analitycznej. Mając informacje o metadanych, możemy sprawdzić zgodność z podstawowymi warunkami już od momentu wejścia informacji do warstwy podstawowej - nie null, ograniczenia, klucze obce. Funkcjonalność ta jest realizowana w oparciu o automatycznie generowane mapowania rodziny jakości danych w Datagramie. Generowanie kodu w tym przypadku również opiera się na metadanych modelu. W projekcie Mediascope przeprowadzono interfejs z metadanymi produktu Enterprise Architect.

Po sparowaniu narzędzia o niskim kodzie z Enterprise Architect automatycznie wygenerowano następujące kontrole:

• Sprawdzanie obecności wartości „null” w polach z modyfikatorem „not null”;
• Sprawdzanie obecności duplikatów klucza podstawowego;
• Sprawdzanie klucza obcego podmiotu;
• Sprawdzanie unikalności ciągu znaków na podstawie zestawu pól.

W przypadku bardziej złożonych kontroli dostępności i wiarygodności danych stworzono mapowanie za pomocą Scala Expression, które jako dane wejściowe przyjmuje zewnętrzny kod kontrolny Spark SQL przygotowany przez analityków Zeppelin.

Oczywiście automatyczne generowanie czeków należy osiągać stopniowo. W ramach opisywanego projektu zostało to poprzedzone następującymi etapami:

• DQ zaimplementowane w notebookach Zeppelin;
• DQ wbudowane w mapowanie;
• DQ w formie oddzielnych, masowych mapowań zawierających cały zestaw kontroli dla oddzielnego podmiotu;
• Uniwersalne sparametryzowane mapowania DQ, które akceptują jako dane wejściowe informacje o metadanych i kontrolach biznesowych.

Być może główną zaletą stworzenia sparametryzowanej usługi sprawdzania jest skrócenie czasu potrzebnego na dostarczenie funkcjonalności do środowiska produkcyjnego. Nowe kontrole jakości mogą ominąć klasyczny wzorzec dostarczania kodu pośrednio poprzez środowiska programistyczne i testowe:

• Wszystkie kontrole metadanych są generowane automatycznie po modyfikacji modelu w EA;
• Kontrole dostępności danych (określające obecność dowolnych danych w danym momencie) można wygenerować w oparciu o katalog przechowujący oczekiwany moment pojawienia się kolejnej porcji danych w kontekście obiektów;
• Kontrole walidacji danych biznesowych są tworzone przez analityków w notatnikach Zeppelin. Stamtąd są wysyłane bezpośrednio do tabel konfiguracyjnych modułu DQ w środowisku produkcyjnym.

Nie ma ryzyka bezpośredniego wysyłania skryptów do produkcji. Nawet przy błędzie składniowym grozi nam maksymalnie niewykonanie jednego sprawdzenia, gdyż przepływ obliczeń danych i przebieg uruchomienia kontroli jakości są od siebie oddzielone.

Zasadniczo usługa DQ działa stale w środowisku produkcyjnym i jest gotowa do rozpoczęcia pracy w momencie pojawienia się kolejnej porcji danych.

Zamiast zawierania

Zaleta stosowania niskiego kodu jest oczywista. Programiści nie muszą tworzyć aplikacji od zera. A programista uwolniony od dodatkowych zadań szybciej daje rezultaty. Szybkość z kolei uwalnia dodatkowy czas na rozwiązywanie problemów optymalizacyjnych. Dlatego w tym przypadku możesz liczyć na lepsze i szybsze rozwiązanie.

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

• Branża low-code przechodzi etap „coraz silniejszego” i nie ma jeszcze jednolitych standardów przemysłowych;
• Wiele rozwiązań niskokodowych nie jest darmowych, a ich zakup powinien być krokiem świadomym, który należy podejmować z pełnym przekonaniem o korzyściach finansowych płynących z ich stosowania;
• Wiele rozwiązań niskokodowych nie zawsze działa dobrze z GIT/SVN. Lub są niewygodne w użyciu, jeśli wygenerowany kod jest ukryty;
• Rozbudowując architekturę, może zaistnieć konieczność udoskonalenia rozwiązania low-code – co z kolei wywołuje efekt „przywiązania i uzależnienia” od dostawcy rozwiązania low-code.
• Odpowiedni poziom bezpieczeństwa jest możliwy, ale jest bardzo pracochłonny i trudny do wdrożenia w silnikach systemowych o niskim kodzie. Platformy low-code należy wybierać nie tylko kierując się zasadą poszukiwania korzyści z ich wykorzystania. Przy wyborze warto zadać sobie pytanie o dostępność funkcjonalności kontroli dostępu i delegowania/eskalacji danych identyfikacyjnych na poziom całego krajobrazu IT organizacji.

Jeśli jednak znasz wszystkie mankamenty wybranego systemu, a korzyści z jego stosowania mimo wszystko są w przeważającej większości, to bez obaw przejdź do małego kodu. Co więcej, przejście do tego jest nieuniknione - tak jak każda ewolucja jest nieunikniona.

Jeśli jeden programista na platformie low-code wykona swoją pracę szybciej niż dwóch programistów bez low-code, daje to firmie przewagę pod każdym względem. Próg wejścia w rozwiązania niskokodowe jest niższy niż w technologie „tradycyjne”, co pozytywnie wpływa na problem niedoborów kadrowych. Wykorzystując narzędzia niskokodowe, możliwe jest przyspieszenie interakcji pomiędzy zespołami funkcjonalnymi i szybsze podejmowanie decyzji co do poprawności obranej ścieżki badań data science. Platformy niskiego poziomu mogą napędzać cyfrową transformację organizacji, ponieważ tworzone rozwiązania mogą być zrozumiałe dla specjalistów nietechnicznych (szczególnie użytkowników biznesowych).

Jeśli masz napięte terminy, napiętą logikę biznesową, brak specjalistycznej wiedzy technologicznej i chcesz przyspieszyć czas wprowadzenia produktu na rynek, jednym ze sposobów zaspokojenia Twoich potrzeb jest niski poziom kodu.

Nie można zaprzeczyć, jak ważne są tradycyjne narzędzia programistyczne, jednak w wielu przypadkach zastosowanie rozwiązań niskokodowych jest najlepszym sposobem na zwiększenie efektywności rozwiązywanych zadań.

Źródło: www.habr.com