Gentili lettori, buon giorno!
Il compito di costruire piattaforme IT per la raccolta e l'analisi dei dati prima o poi si presenta a qualsiasi azienda, la cui attività si basa su un modello di servizi intellettualmente impegnativo o sulla creazione di prodotti tecnicamente complessi. La costruzione di piattaforme analitiche è un compito complesso e dispendioso in termini di risorse. Tuttavia, qualsiasi compito può essere semplificato. In questo articolo voglio condividere l'esperienza nell'uso di strumenti low-code che aiutano nella creazione di soluzioni analitiche. Questa esperienza è stata acquisita durante la realizzazione di vari progetti nel campo delle Big Data Solutions dell'azienda "Neoflex". Il settore delle Big Data Solutions dell'azienda "Neoflex" si occupa dal 2005 della costruzione di archivi e laghi di dati, affrontando le sfide della velocità di elaborazione delle informazioni e lavorando sulla metodologia di gestione della qualità dei dati.
Evitare l'accumulo consapevole di dati poco e/o molto strutturati non sarà possibile per nessuno. Probabilmente, anche se si tratta di piccole imprese. Infatti, con la scala dell'attività, un imprenditore prospettico si troverà ad affrontare questioni come la creazione di un programma di fidelizzazione, desidererà analizzare l'efficacia dei punti vendita, penserà alla pubblicità targetizzata e si interesserà alla domanda di prodotti accessori. In una prima approssimazione, il problema può essere risolto "alla buona". Ma con la crescita dell'azienda, l'approdo a una piattaforma analitica è comunque inevitabile.
Tuttavia, in quale caso le attività di analisi dei dati possono trasformarsi in compiti di "Rocket Science"? Probabilmente nel momento in cui si parla di dati veramente grandi.
Per semplificare il compito di "Rocket Science", si può mangiare un elefante a pezzi.
Maggiore è la discrezionalità e l'autonomia delle vostre applicazioni/servizi/microservizi, più semplice sarà per voi, per i vostri colleghi e per l'intera azienda elaborare l'elefante.
A questa conclusione sono giunti praticamente tutti i nostri clienti, ristrutturando il panorama basandosi sulle pratiche ingegneristiche dei team DevOps.
Ma anche con una dieta "separata, da elefante" abbiamo buone probabilità di "sovraccarico" nel panorama IT. In questo momento vale la pena fermarsi, respirare e guardare verso low-code engineering platform.
Molti sviluppatori sono spaventati dalla prospettiva di un vicolo cieco nella loro carriera, passando dalla scrittura diretta di codice al "trascinamento" di elementi nelle interfacce utente dei sistemi low-code. Tuttavia, l'arrivo delle macchine non ha portato all'estinzione degli ingegneri, ma ha portato il loro lavoro a un nuovo livello!
Vediamo perché.
L'analisi dei dati nei settori della logistica, delle telecomunicazioni, nella ricerca di mercato e nel settore finanziario è sempre associata alle seguenti domande:
- Velocità nell'esecuzione dell'analisi automatizzata;
- Possibilità di eseguire esperimenti senza influenzare il flusso principale di produzione dei dati;
- Affidabilità dei dati preparati;
- Monitoraggio delle modifiche e versioning;
- Data provenance, Data lineage, CDC;
- Rapidità nella consegna di nuove funzionalità nell'ambiente di produzione;
- E la famosa: costo di sviluppo e supporto.
Ciò significa che gli ingegneri hanno un'enorme quantità di compiti ad alto livello, che possono essere svolti con sufficiente efficienza solo liberando la mente dai compiti di sviluppo a basso livello.
Le premesse per il passaggio degli sviluppatori a un nuovo livello sono state l'evoluzione e la digitalizzazione del business. Il valore dello sviluppatore cambia anche: c'è una notevole carenza di sviluppatori in grado di immergersi nella sostanza dei concetti di business automatizzati.
Facciamo un'analogia tra i linguaggi di programmazione a basso livello e quelli ad alto livello. Il passaggio dai linguaggi a basso livello verso quelli ad alto livello è il passaggio dalla scrittura di "direttive dirette nella lingua della macchina" a "direttive nella lingua delle persone". Cioè, l'aggiunta di uno strato di astrazione. In questo caso, passare dalle piattaforme low-code a linguaggi di programmazione ad alto livello significa passare da "direttive nella lingua delle persone" a "direttive nella lingua del business". Se ci sono sviluppatori a cui questo fatto dispiace, allora sono dispiaciuti, forse, fin dal momento in cui è apparso JavaScript, dove vengono utilizzate funzioni di ordinamento degli array. E queste funzioni, ovviamente, hanno dietro di esse un'implementazione software attraverso altri mezzi della stessa programmazione ad alto livello.
Di conseguenza, il low-code è semplicemente l'emergere di un ulteriore livello di astrazione.
Esperienza pratica nell'utilizzo del low-code
Il tema low-code è abbastanza ampio, ma ora vorrei parlare dell'applicazione pratica dei «concetti low-code» attraverso un esempio di uno dei nostri progetti.
La divisione Big Data Solutions di Neoflex si specializza principalmente nel settore finanziario, costruendo archivi e laghi di dati e automatizzando vari report. In questo ambito, l'uso del low-code è diventato uno standard da tempo. Tra gli altri strumenti low-code, possiamo citare strumenti per la gestione dei processi ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. O Oracle Apex, che funge da ambiente di sviluppo rapido per interfacce di accesso e modifica dei dati. Tuttavia, l'uso di strumenti di sviluppo low-code non è sempre associato alla costruzione di applicazioni dedicate su stack tecnologici commerciali con una chiara dipendenza dal fornitore.
Con le piattaforme low-code è possibile anche organizzare l'orchestrazione dei flussi di dati, creare piattaforme di data science o, ad esempio, moduli di verifica della qualità dei dati.
Uno degli esempi pratici di utilizzo di strumenti di sviluppo low-code è la collaborazione tra Neoflex e la società Mediascope, uno dei leader nel mercato russo delle ricerche sui media. Uno degli obiettivi di business di questa società è la creazione di dati, sulla base dei quali gli inserzionisti, le piattaforme online, le emittenti televisive, le stazioni radio, le agenzie pubblicitarie e i marchi prendono decisioni sull'acquisto di pubblicità e pianificano le loro comunicazioni di marketing.
Le ricerche sui media sono un settore aziendale tecnologicamente complesso. Il riconoscimento delle immagini video, la raccolta di dati da dispositivi che analizzano la visione, la misurazione dell'attività su risorse web: tutto ciò implica che la società disponga di un ampio personale IT e di un'eccezionale esperienza nella costruzione di soluzioni analitiche. Ma la crescita esponenziale della quantità di informazioni, del numero e della varietà delle sue fonti richiede un costante progresso nell'industria dei dati IT. La soluzione più semplice per scalare una piattaforma analitica già funzionante di Mediascope potrebbe essere l'aumento del personale IT. Ma una soluzione molto più efficace è l'accelerazione del processo di sviluppo. Uno dei passi verso questa direzione potrebbe essere l'adozione di piattaforme low-code.
Al momento dell'avvio del progetto, l'azienda disponeva già di una soluzione di prodotto funzionante. Tuttavia, l'implementazione della soluzione su MSSQL non poteva soddisfare pienamente le aspettative riguardo alla scalabilità delle funzionalità mantenendo un costo di modifica accettabile.
Il compito che ci si trovava di fronte era davvero ambizioso: «Neoflex» e Mediascope dovevano creare una soluzione industriale in meno di un anno, con la condizione di lanciare un MVP già durante il primo trimestre dalla data di inizio lavori.
Come fondamento per la costruzione della nuova piattaforma dati, basata su elaborazioni low-code, è stato scelto il stack tecnologico Hadoop. Lo standard per la memorizzazione dei dati è diventato HDFS utilizzando file nel formato parquet. Per accedere ai dati presenti nella piattaforma è stato utilizzato Hive, in cui tutte le vetrine disponibili sono presentate sotto forma di tabelle esterne. Il caricamento dei dati nel magazzino è stato realizzato con l'aiuto di Kafka e Apache NiFi.
Lo strumento low-code in questo concetto è stato applicato per ottimizzare il compito più dispendioso in termini di lavoro nella costruzione di una piattaforma analitica: il compito di calcolo dei dati.
Il meccanismo principale per la mappatura dei dati è stato scelto lo strumento low-code Datagram. Neoflex Datagram — è uno strumento per lo sviluppo di trasformazioni e flussi di dati.
Utilizzando questo strumento, è possibile evitare di scrivere codice Scala "manualmente". Il codice Scala viene generato automaticamente utilizzando un approccio Model Driven Architecture.
Un evidente vantaggio di questo approccio è l'accelerazione del processo di sviluppo. Tuttavia, oltre alla velocità, ci sono anche i seguenti vantaggi:
- Visualizzazione del contenuto e della struttura delle sorgenti/destinazioni;
- Tracciamento della provenienza degli oggetti del flusso dati fino ai singoli campi (lineage);
- Esecuzione parziale delle trasformazioni con visualizzazione dei risultati intermedi;
- Visualizzazione del codice sorgente e la sua correzione prima dell'esecuzione;
- Validazione automatica delle trasformazioni;
- Caricamento automatico dei dati 1 a 1.
La soglia di ingresso per le soluzioni low-code per la generazione di trasformazioni è abbastanza bassa: un sviluppatore deve conoscere SQL e avere esperienza con strumenti ETL. È importante precisare che i generatori di trasformazioni driven-by-code non sono strumenti ETL nel senso ampio della parola. Gli strumenti low-code potrebbero non avere un proprio ambiente per l'esecuzione del codice. In altre parole, il codice generato verrà eseguito nell'ambiente esistente nel cluster prima dell'installazione della soluzione low-code. E questo è, forse, un ulteriore punto a favore del low-code. Infatti, parallelamente al team low-code, può lavorare un team “classico” che implementa le funzionalità, ad esempio, usando puro codice Scala. L'integrazione delle modifiche di entrambi i team in produzione sarà semplice e “senza cuciture”.
Vale la pena notare che oltre al low-code, ci sono anche soluzioni no-code. E per sua natura, si tratta di cose diverse. Il low-code permette in larga misura allo sviluppatore di intervenire sul codice generato. Nel caso di Datagram è possibile visualizzare e modificare il codice Scala generato, mentre il no-code potrebbe non offrire questa possibilità. Questa differenza è piuttosto sostanziale non solo in termini di flessibilità della soluzione, ma anche in termini di comfort e motivazione per il lavoro degli ingegneri dei dati.
Architettura della soluzione
Provando a comprendere come lo strumento low-code aiuti a risolvere il problema dell'ottimizzazione della velocità di sviluppo delle funzionalità di calcolo dei dati. Per cominciare, analizziamo l'architettura funzionale del sistema. In questo caso, un esempio è il modello di produzione dei dati per le ricerche sui media.
Le fonti di dati nel nostro caso sono molto eterogenee e variegate:
- I meter di ascolto (TV-meter) sono dispositivi software e hardware che registrano il comportamento degli utenti nei panel televisivi - chi, quando e quale canale televisivo è stato guardato nelle famiglie partecipanti allo studio. Le informazioni fornite consistono in un flusso di intervalli di visione televisiva, collegati a pacchetti media e prodotti media. I dati durante la fase di caricamento nel Data Lake possono essere arricchiti con attributi demografici, collegamenti a geo-strategie, fuso orario e altre informazioni necessarie per condurre un'analisi della visione di specifici prodotti media. Le misurazioni effettuate possono essere utilizzate per l'analisi o la pianificazione di campagne pubblicitarie, per valutare l'attività e le preferenze del pubblico, e per la creazione di palinsesti.
- I dati possono provenire da sistemi di monitoraggio delle trasmissioni televisive in streaming e dalla misurazione della visione di contenuti su piattaforme video online.
- Strumenti di misurazione nell'ambiente web, che comprendono sia contatori site-centric che user-centric. Un'estensione del browser, la research bar, e un'applicazione mobile integrata possono servire come fornitori di dati per il Data Lake. VPN.
- I dati possono anche provenire da piattaforme che consolidano i risultati delle indagini online e dei colloqui telefonici condotti nelle ricerche aziendali.
- Un ulteriore arricchimento del lago dati può avvenire tramite il caricamento di informazioni dai log delle aziende partner.
L'implementazione del caricamento as is dai sistemi sorgente nei dati grezzi staging primari può essere organizzata in vari modi. Se si utilizza low-code per questi scopi, è possibile generare automaticamente scenari di caricamento basati sui metadati, evitando così di scendere a livello di sviluppo delle mappature source to target. Per realizzare un caricamento automatico, è necessario stabilire una connessione con la sorgente e quindi definire nell'interfaccia di caricamento l'elenco delle entità da caricare. La creazione della struttura delle directory in HDFS avverrà automaticamente e corrisponderà alla struttura di archiviazione dei dati nel sistema sorgente.
Tuttavia, nel contesto di questo progetto, abbiamo deciso di non utilizzare questa funzionalità delle piattaforme low-code, poiché l'azienda Mediascope ha già iniziato a lavorare autonomamente alla creazione di un servizio simile utilizzando Nifi + Kafka.
È importante sottolineare che questi strumenti non sono sostitutivi, ma piuttosto si completano a vicenda. Nifi e Kafka possono funzionare sia in direzione diretta (Nifi -> Kafka) che inversa (Kafka -> Nifi). Per la piattaforma di media analytics è stata utilizzata la prima opzione di collegamento.
Nel nostro caso, Nifi doveva elaborare vari tipi di dati da sistemi sorgente e inviarli al broker Kafka. In questo caso, l'invio dei messaggi verso un determinato topic Kafka avveniva tramite l'uso dei processori Nifi PublishKafka. L'orchestrazione e la gestione di questi pipeline avvengono in un'interfaccia visiva. Lo strumento Nifi e l'utilizzo della combinazione Nifi + Kafka possono essere chiamati anche approccio low-code allo sviluppo, con una bassa barriera d'ingresso nelle tecnologie Big Data che accelera il processo di sviluppo delle applicazioni.
La fase successiva nella realizzazione del progetto consisteva nell'allineare al formato di un unico livello semantico i dati dettagliati. In caso di presenza di attributi storici per un'entità, il calcolo viene effettuato nel contesto della partizione presa in considerazione. Se l'entità non è storica, è facoltativamente possibile effettuare il ricalcolo di tutto il contenuto dell'oggetto, oppure rinunciare completamente al ricalcolo di questo oggetto (a causa dell'assenza di modifiche). In questa fase vengono generati i chiavi per tutte le entità. Le chiavi vengono salvate nei relativi master oggetti degli indici Hbase, contenenti la corrispondenza tra le chiavi nella piattaforma analitica e le chiavi dai sistemi sorgente. La consolidazione delle entità atomiche è accompagnata dall'arricchimento con i risultati del calcolo preliminare dei dati analitici. Il framework per il calcolo dei dati era Spark. La funzionalità descritta per l'allineamento dei dati a un'unica semantica è stata realizzata anche sulla base delle mappature dello strumento low-code Datagram.
Nell'architettura di destinazione era necessario garantire l'accesso SQL ai dati per gli utenti business. Per questa opzione è stato utilizzato Hive. La registrazione degli oggetti in Hive avviene automaticamente attivando l'opzione "Registr Hive Table" nello strumento low-code.
Gestione del flusso di calcolo
Datagram ha un'interfaccia per la progettazione dei flussi di lavoro. L'esecuzione delle mappature può avvenire utilizzando il pianificatore Oozie. Nell'interfaccia dello sviluppatore dei flussi è possibile creare schemi di trasformazione dei dati paralleli, sequenziali o condizionati. È supportato l'uso di script shell e programmi Java. È possibile anche utilizzare server Apache Livy. Apache Livy è utilizzato per avviare applicazioni direttamente dall'ambiente di sviluppo.
Nel caso in cui un'azienda abbia già un proprio orchestratore di processi, è possibile utilizzare l'API REST per integrare le mappature nel flusso già esistente. Ad esempio, abbiamo avuto esperienze molto positive nell'integrazione di mappature in Scala in orchestratori scritti in PLSQL e Kotlin. L'API REST dello strumento low-code prevede operazioni come la generazione di un anno eseguibile basato sul design della mappatura, la chiamata delle mappature, la chiamata di sequenze di mappature e, naturalmente, il passaggio di parametri nell'URL per l'esecuzione delle mappature.
Insieme a Oozie, è possibile organizzare il flusso di calcolo utilizzando Airflow. Non mi soffermerò a lungo sul confronto tra Oozie e Airflow, ma dirò semplicemente che nel contesto dei lavori del progetto di ricerca sui media, la scelta è ricaduta su Airflow. I principali argomenti a favore sono stati una comunità più attiva nello sviluppo del prodotto e un'interfaccia + API più evoluta.
Airflow è anche vantaggioso perché utilizza Python, molto amato per la descrizione dei processi di calcolo. Inoltre, non ci sono molte piattaforme di gestione dei flussi di lavoro open source. L'esecuzione e il monitoraggio delle attività (comprese le viste delle diagrammi di Gantt) aggiungono ulteriori punti a favore di Airflow.
Il formato del file di configurazione per l'avvio delle mappature della soluzione low-code è diventato spark-submit. Ciò è avvenuto per due motivi. Innanzitutto, spark-submit consente di avviare direttamente un file jar dalla console. In secondo luogo, può contenere tutte le informazioni necessarie per configurare il flusso di lavoro (semplificando la scrittura di script che generano Dag).
L'elemento di flusso di lavoro di Airflow più comune nel nostro caso è diventato SparkSubmitOperator.
SparkSubmitOperator consente di eseguire file jar — mappature Datagram pacchettizzate con i parametri di ingresso già formati per loro.
Va notato che ogni task di Airflow viene eseguito in un thread separato e non ha conoscenza degli altri task. Pertanto, l'interazione tra i task avviene attraverso operatori di controllo, come DummyOperator o BranchPythonOperator.
L'uso combinato della soluzione low-code Datagram e dell'universalizzazione dei file di configurazione (che formano i Dag) ha portato a un notevole acceleramento e semplificazione del processo di sviluppo dei flussi di caricamento dei dati.
Calcolo delle vetrine
Probabilmente, la fase più complessa dal punto di vista intellettuale nella produzione di dati analitici è il processo di costruzione delle vetrine. Nel contesto di uno dei flussi di calcolo dei dati di una società di ricerca, in questa fase viene effettuata una conversione alla traduzione di riferimento tenendo conto delle correzioni per i fusi orari in relazione alla griglia di trasmissione. È anche possibile tenere conto della griglia locale di trasmissione (notizie e pubblicità locali). Tra l'altro, in questo passaggio si esegue la suddivisione degli intervalli di visione continua dei prodotti multimediali basata sull'analisi degli intervalli di visione. In questo momento avviene anche il
Un passaggio separato nella preparazione delle vetrine è la validazione dei dati. L'algoritmo di validazione è collegato all'applicazione di una serie di modelli matematici della scienza. Tuttavia, l'utilizzo di una piattaforma low-code consente di suddividere un algoritmo complesso in una serie di mappature visivamente leggibili. Ognuna di queste mappature svolge un compito specifico. Di conseguenza, è possibile effettuare un debug intermedio, il logging e la visualizzazione delle fasi di preparazione dei dati.
È stato deciso di discretizzare l'algoritmo di validazione nei seguenti sotto-passi:
- Costruzione delle regressioni delle dipendenze della visione della rete televisiva nella regione rispetto alla visione di tutte le reti nella regione negli ultimi 60 giorni.
- Calcolo dei residui studensizzati (deviazione dei valori effettivi da quelli previsti dal modello di regressione) per tutti i punti di regressione e per il giorno di calcolo.
- Selezione delle coppie anomale regione-rete televisiva, in cui il residuo studensizzato del giorno di calcolo supera la norma (impostata dalla configurazione dell'operazione).
- Il conteggio del residuo standardizzato corretto per le coppie anomale regione-rete televisiva per ogni rispondente che ha guardato la rete nella regione con la determinazione del contributo di tale rispondente (l'entità della variazione del residuo standardizzato) escludendo la visione di tale rispondente dal campione.
- Ricerca di candidati, la cui esclusione porta il residuo standardizzato del giorno di calcolo alla norma.
L'esempio sopra riportato è una conferma dell'ipotesi che un data engineer ha già un carico eccessivo di informazioni da gestire… E, se è davvero un 'ingegnere' e non un 'codificatore', la paura di una degradazione professionale nell'uso di strumenti low-code dovrebbe alla fine svanire.
Cosa può fare ancora il low-code?
L'ambito di applicazione dello strumento low-code per l'elaborazione dei dati in batch e in streaming senza la necessità di scrivere codice manualmente in Scala non finisce qui.
L'uso del low-code nello sviluppo dei datalake è diventato per noi uno standard. Si potrebbe dire che le soluzioni basate su Hadoop seguono il percorso di sviluppo dei tradizionali DWH basati su RDBMS. Gli strumenti low-code basati su Hadoop possono affrontare sia compiti di elaborazione dei dati che compiti di costruzione di interfacce BI finali. È importante notare che per BI si può intendere non solo la rappresentazione dei dati, ma anche la loro modifica da parte degli utenti business. Questa funzionalità è spesso utilizzata nella costruzione di piattaforme analitiche per il settore finanziario.
Tra le altre cose, grazie a low-code e, in particolare, a Datagram, è possibile affrontare la questione del tracciamento dell'origine degli oggetti nel flusso di dati con atomicità fino ai singoli campi (lineage). Per questo, nel tool low-code è stata implementata un'integrazione con Apache Atlas e Cloudera Navigator. In sostanza, lo sviluppatore deve registrare un set di oggetti nei dizionari di Atlas e fare riferimento agli oggetti registrati durante la creazione delle mappature. Il meccanismo di tracciamento dell'origine dei dati o di analisi delle dipendenze tra oggetti fa risparmiare molto tempo quando è necessario apportare modifiche agli algoritmi di calcolo. Ad esempio, nella redazione dei rendiconti finanziari, questa funzionalità consente di affrontare più agevolmente il periodo di cambiamenti legislativi. Infatti, più siamo consapevoli della dipendenza interformale in relazione agli oggetti del livello dettagliato, meno ci imbatteremo in difetti
Data Quality & Low-code
Un'altra sfida affrontata dal tool low-code nel progetto dell'azienda Mediascope è stata quella relativa alla qualità dei dati. Una delle peculiarità della realizzazione della pipeline di verifica dei dati per il progetto dell'azienda di ricerca è stata l'assenza di impatti sulla funzionalità e sulla velocità del flusso principale di calcolo dei dati. Per orchestrare flussi indipendenti di verifica dei dati è stato utilizzato l'ormai conosciuto Apache Airflow. Man mano che ciascun passaggio della produzione dei dati era pronto, veniva avviata in parallelo una parte separata della pipeline DQ.
È considerata una buona pratica monitorare la qualità dei dati sin dal loro inizio nella piattaforma analitica. Con le informazioni sui metadati, possiamo già controllare, fin dal momento in cui le informazioni entrano nel livello primario, il rispetto delle condizioni di base: not null, constraints, foreign keys. Questa funzionalità è stata implementata sulla base di mapping generati automaticamente della famiglia data quality in Datagram. Nel progetto dell'azienda Mediascope, l'integrazione si è svolta con i metadati del prodotto Enterprise Architect.
Grazie all'integrazione tra il tool low-code e Enterprise Architect, sono state generate automaticamente le seguenti verifiche:
- Verifica della presenza di valori 'null' nei campi con il modificatore 'not null';
- Verifica della presenza di duplicati della chiave primaria;
- Controllo della chiave esterna dell'entità;
- Controllo dell'unicità della riga in base a un insieme di campi.
Per controlli più complessi sulla disponibilità e l'affidabilità dei dati, è stata creata una mappatura con Scala Expression, che accetta un codice di controllo Spark SQL esterno, preparato dagli analisti in Zeppelin.
Naturalmente, l'autogenereazione dei controlli deve avvenire gradualmente. Nel contesto del progetto descritto, sono stati effettuati i seguenti passaggi:
- DQ, implementati nei notebook di Zeppelin;
- DQ, integrati nella mappatura;
- DQ sotto forma di singole mappature massicce, contenenti un insieme di controlli per singole entità;
- Mappature DQ universali parametriche, che accettano informazioni su metadati e controlli aziendali.
Probabilmente, il principale vantaggio della creazione di un servizio di controlli parametrici è la riduzione del tempo necessario per la consegna delle funzionalità nell'ambiente di produzione. I nuovi controlli della qualità possono bypassare il modello classico di consegna del codice passando attraverso ambienti di sviluppo e di test:
- Tutti i controlli dei metadati vengono generati automaticamente quando il modello viene modificato in EA;
- I controlli di disponibilità dei dati (determinazione della presenza di dati in un certo momento) possono essere generati sulla base di un registro che memorizza il timing atteso per l'arrivo della prossima porzione di dati suddivisa per oggetti;
- I controlli di business per l'affidabilità dei dati vengono creati dagli analisti nei notebook di Zeppelin. Da qui vengono diretti direttamente nelle tabelle di configurazione del modulo DQ nell'ambiente di produzione.
Non ci sono rischi associati al caricamento diretto di script in produzione. Anche in caso di errore sintattico, la cosa massima che possiamo temere è il fallimento di un controllo, poiché il flusso di calcolo dei dati e il flusso di avvio dei controlli di qualità sono separati.
In sostanza, il servizio DQ è permanentemente attivo nell'ambiente di produzione ed è pronto a iniziare il suo lavoro al momento dell'arrivo della prossima porzione di dati.
In conclusione
Il vantaggio dell'uso del low-code è evidente. Gli sviluppatori non devono sviluppare un'applicazione "da zero". Un programmatore liberato da compiti aggiuntivi produce risultati più velocemente. La velocità, a sua volta, libera risorse temporali aggiuntive per risolvere questioni di ottimizzazione. Pertanto, in questo caso, si può contare su soluzioni più efficienti e rapide.
Naturalmente, il low-code non è una panacea e la magia non accadrà da sola:
- L'industria low-code sta attraversando una fase di "consolidamento", e attualmente non esistono standard industriali omogenei;
- Molte soluzioni low-code non sono gratuite e il loro acquisto dovrebbe essere un passo consapevole da intraprendere solo con la completa certezza di un ritorno economico dal loro utilizzo;
- Molte soluzioni low-code non sono sempre ben integrate con GIT / SVN. Oppure possono risultare scomode in caso di oscuramento del codice generato;
- Durante l'espansione dell'architettura, potrebbe essere necessario modificare la soluzione low-code, cosa che provoca l'effetto di "attaccamento e dipendenza" dal fornitore della soluzione low-code.
- Un adeguato livello di sicurezza è possibile, ma è piuttosto laborioso e complicato da implementare nei motori delle soluzioni low-code. Le piattaforme low-code devono essere scelte non solo in base al principio di ricerca del profitto derivante dal loro utilizzo. Quando si sceglie, è importante considerare la presenza di funzionalità di gestione degli accessi e delega/escalation dei dati identificativi a livello di intero paesaggio IT dell'organizzazione.
Tuttavia, se conosci tutti i difetti del sistema scelto e i benefici del suo utilizzo sono comunque predominanti, allora passa al low-code senza timori. Soprattutto considerando che il passaggio a questo è inevitabile – così come ogni evoluzione.
Se un sviluppatore su una piattaforma low-code riesce a svolgere il proprio lavoro più rapidamente di due sviluppatori senza low-code, questo offre un vantaggio all'azienda in ogni aspetto. La barriera d'ingresso nelle soluzioni low-code è più bassa rispetto alle tecnologie "tradizionali", e questo ha un effetto positivo sulla questione della mancanza di personale qualificato. Utilizzando strumenti low-code è possibile accelerare l'interazione tra i team funzionali e prendere decisioni più rapidamente sulla correttezza della strada scelta per le ricerche in data science. Le piattaforme low-code possono essere la causa della trasformazione digitale dell'organizzazione, poiché le soluzioni prodotte possono essere comprese anche da specialisti non tecnici (in particolare, utenti aziendali).
Se avete scadenze serrate, logiche aziendali complesse, mancanza di expertise tecnologica, e avete bisogno di accelerare il time to market, allora il low-code è uno dei modi per soddisfare le vostre esigenze.
Non si può negare l'importanza degli strumenti di sviluppo tradizionali, tuttavia in molti casi l'uso di soluzioni low-code è il modo migliore per migliorare l'efficienza nelle attività da svolgere.
Fonte: habr.com
