Gentili lettori, buon pomeriggio!
La necessità di costruire piattaforme IT per la raccolta e l'analisi dei dati si presenta, prima o poi, a ogni azienda il cui business si basa su un modello di servizi intellettualmente complesso o sulla creazione di prodotti tecnologicamente avanzati. Costruire piattaforme analitiche è un compito difficile e dispendioso in termini di tempo. Tuttavia, ogni sfida può essere semplificata. In questo articolo voglio condividere l'esperienza nell'uso di strumenti low-code che aiutano nella creazione di soluzioni analitiche. Questa esperienza è stata acquisita nell'ambito dell'implementazione di diversi progetti della divisione Big Data Solutions della società "Neoflex". Dal 2005, la divisione Big Data Solutions di "Neoflex" si occupa di costruire archivi e laghi di dati, affrontando questioni relative all'ottimizzazione della velocità di elaborazione delle informazioni e sviluppando metodologie per la gestione della qualità dei dati.
Nessuno può evitare l'accumulo consapevole di dati poco e/o fortemente strutturati. Forse, anche nel caso di una piccola impresa. Infatti, con la crescita dell'attività, un imprenditore promettente si troverà ad affrontare questioni come lo sviluppo di un programma di fidelizzazione, vorrà analizzare l'efficacia dei punti vendita, penserà alla pubblicità mirata e rifletterà sulla domanda di prodotti correlati. In un primo momento, il problema può essere risolto "alla buona". Ma con la crescita dell'attività, l'approdo a una piattaforma analitica diventa inevitabile.
Ma in quale caso le sfide dell'analitica dei dati possono trasformarsi in problemi di "Rocket Science"? Forse nel momento in cui si tratta 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'intero business "mandare giù" l'elefante.
Questa conclusione è stata raggiunta praticamente da tutti i nostri clienti, ristrutturando il paesaggio sulla base delle pratiche ingegneristiche dei team DevOps.
Ma anche con una dieta "separata e pachidermica", abbiamo buone possibilità di "saturazione" del panorama IT. È il momento di fermarsi, respirare e guardare verso piattaforma di ingegneria low-code.
Molti sviluppatori temono la prospettiva di trovarsi in un vicolo cieco nella carriera allontanandosi dalla scrittura diretta di codice a favore del "trascinamento" di elementi nelle interfacce utente dei sistemi low-code. Ma l'emergere di macchinari non ha portato all'estinzione degli ingegneri, ma ha portato il loro lavoro a un nuovo livello!
Vediamo perché.
L'analisi dei dati nel settore della logistica, delle telecomunicazioni, nella ricerca mediatica e nel settore finanziario è sempre associata alle seguenti domande:
- La velocità con cui viene eseguita l'analisi automatizzata;
- La possibilità di condurre esperimenti senza influenzare il flusso principale di produzione dei dati;
- L'affidabilità dei dati preparati;
- Monitoraggio delle modifiche e versionamento;
- Provenienza dei dati, tracciamento dei dati, CDC;
- Rapidità di consegna di nuove funzionalità nell'ambiente di produzione;
- E il famigerato: il costo di sviluppo e supporto.
Cioè, gli ingegneri hanno a disposizione un'enorme quantità di compiti ad alto livello, che possono essere portati a termine con un adeguato livello di efficienza solo liberando la mente dai compiti di sviluppo a basso livello.
Le premesse per il passaggio dei programmatori a un nuovo livello sono state l'evoluzione e la digitalizzazione del business. Il valore dello sviluppatore sta anche cambiando: c'è una significativa scarsità di sviluppatori in grado di immergersi nella sostanza dei concetti di business automatizzabile.
Facciamo un'analogia tra i linguaggi di programmazione a basso e alto livello. Il passaggio dai linguaggi a basso livello verso quelli ad alto livello rappresenta il passaggio dalla scrittura di "istruzioni dirette nel linguaggio della macchina" a "istruzioni nel linguaggio umano". In altre parole, si tratta di aggiungere un certo livello di astrazione. Pertanto, il passaggio verso piattaforme low-code costituirebbe un'evoluzione da "istruzioni nel linguaggio umano" a "istruzioni nel linguaggio del business". Se ci sono sviluppatori che si rattristano per questo fatto, potrebbero essere stati già delusi dal momento stesso in cui è nato JavaScript, che utilizza funzioni di ordinamento degli array. E queste funzioni, ovviamente, hanno dietro di sé un'implementazione software realizzata con altri mezzi, sempre nello stesso contesto di programmazione ad alto livello.
Di conseguenza, il low-code rappresenta semplicemente l'emergere di un ulteriore livello di astrazione.
Esperienza pratica nell'uso del low-code
Il tema del low-code è abbastanza ampio, ma ora vorrei parlare dell'applicazione pratica dei "concetti a basso codice" prendendo ad esempio uno dei nostri progetti.
La divisione Big Data Solutions di «Neoflex» si concentra principalmente sul settore finanziario, creando data warehouse e data lake, automatizzando vari report. In questo settore, l'uso del low-code è divenuto uno standard. Tra gli strumenti low-code spiccano quelli per l'organizzazione dei processi ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. O anche Oracle Apex, che funge da ambiente per lo sviluppo rapido di interfacce per l'accesso e la modifica dei dati. Tuttavia, l'uso di strumenti di sviluppo low-code non è sempre legato alla creazione di applicazioni specifiche su un insieme tecnologico commerciale con una chiara dipendenza dal fornitore.
Con le piattaforme low-code è possibile anche organizzare l'orchestrazione dei flussi di dati, creare ambienti di data science o, ad esempio, moduli per il controllo della qualità dei dati.
Uno degli esempi pratici di utilizzo di strumenti di sviluppo low-code è la collaborazione tra «Neoflex» e l'azienda Mediascope, uno dei leader nel mercato russo delle ricerche sui media. Una delle sfide aziendali di questa compagnia è la produzione di dati su cui inserzionisti, piattaforme online, canali televisivi, emittenti radiofoniche, agenzie pubblicitarie e marchi basano le loro decisioni d'acquisto e pianificano le loro comunicazioni di marketing.
La ricerca media è un settore affollato di tecnologia. Il riconoscimento del video, la raccolta di dati da dispositivi che analizzano la visualizzazione, la misurazione dell'attività sui siti web — tutto questo richiede che l'azienda abbia un ampio staff IT e una vasta esperienza nello sviluppo di soluzioni analitiche. Ma la crescita esponenziale del volume delle informazioni, così come la varietà delle sue fonti, costringe il settore IT dei dati a progredire costantemente. La soluzione più semplice per scalare una piattaforma analitica già funzionante come Mediascope poteva essere l'aumento del personale IT. Tuttavia, una soluzione molto più efficace è l'accelerazione del processo di sviluppo. Uno dei passi in questa direzione può essere l'uso di piattaforme low-code.
Al momento dell'avvio del progetto, l'azienda disponeva già di una soluzione di prodotto funzionante. Tuttavia, l'implementazione di una soluzione su MSSQL non poteva soddisfare pienamente le aspettative in termini di scalabilità delle funzionalità mantenendo un costo accettabile per le modifiche.
La sfida che ci si presentava era veramente ambiziosa: Neoflex e Mediascope dovevano creare una soluzione industriale in meno di un anno, con il rilascio di un MVP già nel primo trimestre dalla data di inizio dei lavori.
Per la costruzione di una nuova piattaforma dati, basata su computazione low-code, è stato scelto il stack tecnologico Hadoop. Lo standard per l'archiviazione dei dati è diventato HDFS utilizzando file in formato parquet. Per accedere ai dati presenti nella piattaforma, è stato utilizzato Hive, in cui tutte le vetrine disponibili sono presentate come tabelle esterne. Il caricamento dei dati nel deposito è stato realizzato con Kafka e Apache NiFi.
Lo strumento low-code in questo concetto è stato applicato per ottimizzare il compito più dispendioso in termini di tempo nella costruzione della piattaforma analitica: il calcolo dei dati.
Il meccanismo principale per il mapping dei dati è stato scelto lo strumento low-code Datagram. Neoflex Datagram è uno strumento per sviluppare trasformazioni e flussi di dati.
Utilizzando questo strumento, è possibile evitare di scrivere codice Scala 'a mano'. Il codice Scala viene generato automaticamente utilizzando l'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 fonti/destinazioni;
- Tracciamento della provenienza degli oggetti del flusso di dati fino ai singoli campi (lineage);
- Esecuzione parziale delle trasformazioni con visualizzazione dei risultati intermedi;
- Visualizzazione e correzione del codice sorgente prima dell'esecuzione;
- Validazione automatica delle trasformazioni;
- Caricamento automatico dei dati 1 a 1.
La soglia di ingresso nelle soluzioni low-code per la generazione di trasformazioni è piuttosto bassa: uno sviluppatore deve conoscere SQL e avere esperienza con strumenti ETL. Va comunque precisato che i generatori di trasformazioni code-driven non sono strumenti ETL nel senso ampio del termine. Gli strumenti low-code potrebbero non avere un proprio ambiente di esecuzione per il codice. Ciò significa che il codice generato verrà eseguito sull'ambiente esistente nel cluster prima dell'installazione della soluzione low-code. E questo è probabilmente un ulteriore vantaggio per le soluzioni low-code, poiché parallelamente al team low-code può operare un team 'classico' che implementa funzionalità, ad esempio, in codice Scala puro. L'inserimento delle modifiche di entrambi i team in produzione sarà semplice e 'senza cuciture'.
Vale la pena sottolineare che oltre alle soluzioni low-code esistono anche quelle no-code. E per sua natura, si tratta di due concetti diversi. Il low-code consente in misura maggiore agli sviluppatori di intervenire nel codice generato. Nel caso di Datagram, è possibile visualizzare e modificare il codice Scala generato, mentre il no-code potrebbe non offrire tale possibilità. Questa differenza è significativa non solo in termini di flessibilità della soluzione, ma anche per quanto riguarda il comfort e la motivazione nel lavoro dei data engineer.
Architettura della soluzione
Cerchiamo di capire come esattamente uno strumento low-code aiuti a ottimizzare la velocità di sviluppo della funzionalità di calcolo dei dati. Iniziamo analizzando l'architettura funzionale del sistema. In questo caso, un esempio è fornito dal modello di produzione dei dati per ricerche sui media.
Le fonti di dati nel nostro caso sono piuttosto eterogenee e variegate:
- I meter di ascolto (TV-meter) sono dispositivi hardware e software che registrano il comportamento degli utenti in un panel televisivo, identificando chi, quando e quale canale televisivo viene guardato in un nucleo familiare partecipante alla ricerca. Le informazioni fornite comprendono flussi di intervalli di visione televisiva legati a pacchetti media e prodotti. I dati caricati nel Data Lake possono essere arricchiti con attributi demografici, associazioni geografiche, fusi orari e altre informazioni necessarie per l'analisi del consumo di media. Le misurazioni effettuate possono essere utilizzate per l'analisi o la pianificazione di campagne pubblicitarie, la valutazione dell'attività e delle preferenze del pubblico, la creazione della programmazione;
- I dati possono provenire da sistemi di monitoraggio delle trasmissioni streaming e da misurazioni delle visualizzazioni di contenuti su risorse video in internet;
- Strumenti di misurazione nel web, tra cui contatori sia site-centric che user-centric. Un'estensione del browser o un'applicazione mobile con funzionalità integrate può servire come fornitore di dati per il Data Lake. VPN.
- I dati possono anche provenire da piattaforme che consolidano i risultati della compilazione dei questionari online e i risultati delle interviste telefoniche nelle indagini condotte dall'azienda;
- L'arricchimento aggiuntivo del lago dati può avvenire tramite il caricamento di informazioni dai log delle aziende partner.
L'implementazione as is del caricamento dai sistemi sorgente nel primo staging dei dati grezzi può essere organizzata in vari modi. Se si utilizza per questi scopi un approccio low-code, è possibile la generazione automatica di script di caricamento basati su metadati. Non è necessario scendere al livello di sviluppo delle mappature da source a target. Per realizzare il 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 opportunità delle piattaforme low-code, poiché l'azienda Mediascope ha già iniziato autonomamente a lavorare alla creazione di un servizio analogo utilizzando la combinazione Nifi + Kafka.
È importante notare fin da subito che questi strumenti non sono intercambiabili, 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 ricerca media è stata utilizzata la prima variante della combinazione.
Nel nostro caso, Nifi doveva elaborare diversi tipi di dati provenienti da sistemi sorgente e inoltrarli al broker Kafka. In questo processo, l'invio dei messaggi a un determinato topic Kafka avveniva tramite i processori PublishKafka di Nifi. L'orchestrazione e la manutenzione di questi pipeline avvengono attraverso un'interfaccia visiva. Lo strumento Nifi e l'uso della combinazione Nifi + Kafka possono essere considerati anche un'approccio low-code allo sviluppo, con una bassa barriera all'ingresso nelle tecnologie Big Data e un'accelerazione del processo di sviluppo delle applicazioni.
Il prossimo passo nell'implementazione del progetto era quello di adottare un formato di strato semantico unificato per i dati dettagliati. In presenza di attributi storici per un'entità, il calcolo viene effettuato nel contesto della partizione considerata. Se l'entità non è storica, è possibile opzionalmente effettuare un ricalcolo di tutto il contenuto dell'oggetto, oppure rinunciare del tutto al ricalcolo di quest'oggetto (in assenza di modifiche). In questa fase vengono generati le chiavi per tutte le entità. Le chiavi vengono memorizzate nei corrispondenti master oggetti delle directory Hbase, contenenti la corrispondenza tra le chiavi nella piattaforma analitica e quelle provenienti dai sistemi sorgente. La consolidazione delle entità atomiche è accompagnata dall'arricchimento con i risultati del calcolo preliminare dei dati analitici. Il framework utilizzato per il calcolo dei dati era Spark. La funzionalità descritta per l'unificazione delle semantiche dei dati è stata implementata anche tramite i mapping dello strumento low-code Datagram.
Nell'architettura target, era necessario garantire l'accesso SQL ai dati per gli utenti aziendali. Per questa opzione è stata utilizzata 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 creazione del design dei flussi workflow. L'esecuzione delle mappature può essere gestita utilizzando il pianificatore Oozie. Nell'interfaccia dello sviluppatore di flussi è possibile creare schemi di trasformazione dati paralleli, sequenziali o condizionati. È supportato l'uso di shell script e programmi Java. È inoltre possibile utilizzare server Apache Livy. Apache Livy viene utilizzato per eseguire applicazioni direttamente dall'ambiente di sviluppo.
Se un'azienda ha già un proprio orchestratore di processi, è possibile utilizzare le API REST per integrare i mapping nel flusso esistente. Ad esempio, abbiamo avuto un'esperienza piuttosto positiva nell'integrazione di mapping in Scala in orchestratori scritti in PLSQL e Kotlin. Le API REST dello strumento low-code prevedono operazioni come la generazione dell'anno eseguibile basata sul design del mapping, la chiamata del mapping, la chiamata della sequenza di mapping e, naturalmente, la trasmissione di parametri nell'URL per attivare i mapping.
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 del progetto di ricerca mediatica, abbiamo optato per Airflow. I principali argomenti a favore sono stati una comunità più attiva che sviluppa il prodotto e un'interfaccia + API più avanzate.
Airflow è particolarmente apprezzato perché utilizza Python, un linguaggio molto amato per descrivere i processi di calcolo. Inoltre, non ci sono molte piattaforme per la gestione dei flussi di lavoro con codice sorgente aperto. L'avvio e il monitoraggio dell'esecuzione dei processi (inclusa la visualizzazione tramite diagrammi di Gantt) aggiungono punteggi alla reputazione di Airflow.
Il formato del file di configurazione per l'esecuzione delle mappature della soluzione low-code è diventato spark-submit. Questo è avvenuto per due motivi. In primo luogo, 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 (il che facilita la scrittura di script che creano Dag).
L'elemento di flusso di lavoro Airflow più comune nel nostro caso è stato il SparkSubmitOperator.
Il SparkSubmitOperator consente di eseguire file jar, che contengono mappature Datagram con parametri di input già pre-formattati.
È importante notare che ogni attività di Airflow viene eseguita in un thread separato e non conosce le altre attività. Pertanto, l'interazione tra le attività avviene tramite operatori di controllo, come il DummyOperator o il BranchPythonOperator.
L'uso combinato della soluzione low-code Datagram insieme alla generalizzazione 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ù intellettualmente impegnativa nella produzione dei dati analitici è quella della costruzione delle vetrine. Nel contesto di uno dei flussi di calcolo dei dati di un'azienda di ricerca, in questa fase avviene l'allineamento alla trasmissione standard, tenendo conto delle correzioni per i fusi orari in relazione alla rete di trasmissione. È inoltre possibile applicare una correzione per la rete locale di trasmissione (notizie locali e pubblicità). Tra l'altro, in questo passaggio viene effettuata la suddivisione degli intervalli di visione continua dei prodotti media basata sull'analisi degli intervalli di visione. Qui avviene anche il 'pesi' dei valori di visione basato sulle informazioni riguardanti la loro rilevanza (calcolo del coefficiente di correzione).
Un passaggio fondamentale nella preparazione dei cataloghi è la validazione dei dati. L'algoritmo di validazione è associato all'applicazione di diversi modelli matematici. Tuttavia, l'uso di piattaforme low-code consente di suddividere un complesso algoritmo in una serie di mapping visivamente leggibili. Ognuno di questi mapping svolge un compito specifico, consentendo così il debug intermedio, il logging e la visualizzazione delle fasi di preparazione dei dati.
Si è deciso di discretizzare l'algoritmo di validazione nei seguenti sotto-passi:
- Costruzione delle regressioni delle dipendenze delle visualizzazioni della televisione nella regione rispetto alle visualizzazioni di tutte le reti nella regione negli ultimi 60 giorni.
- Calcolo dei residui studentizzati (scostamenti tra i valori effettivi e quelli previsti dal modello di regressione) per tutti i punti di regressione e per il giorno calcolato.
- Campionamento delle coppie anomale regione-rete televisiva, dove il residuo studentizzato del giorno calcolato supera la norma (definita nelle impostazioni dell'operazione).
- Ricalcolo del saldo standardizzato corretto per coppie anomale regione-rete televisiva per ogni rispondente che ha visualizzato la rete nella regione, definendo il contributo di questo rispondente (variazione del saldo standardizzato) escludendo la visione di questo rispondente dal campione.
- Ricerca di candidati la cui esclusione riporta il saldo standardizzato del giorno di calcolo nella norma.
L'esempio sopra riportato è una conferma dell'ipotesi che un data engineer ha già troppe informazioni da gestire nella sua mente... E, se davvero si tratta di un 'ingegnere' e non di un 'coder', la paura della degradazione professionale nell'uso di strumenti low-code dovrebbe definitivamente svanire.
Cosa può fare ancora il low-code?
L'ambito di applicazione degli strumenti low-code per l'elaborazione di batch e streaming di dati senza la necessità di scrivere codice in Scala manualmente non si esaurisce qui.
L'utilizzo del low-code nello sviluppo di datalake è diventato ormai un certo standard per noi. Si può dire che le soluzioni basate su Hadoop seguono il percorso di sviluppo dei classici DWH basati su DBMS. Gli strumenti low-code sulla stack Hadoop possono affrontare sia i task di elaborazione dati che le sfide nella costruzione di interfacce BI finali. Va sottolineato che per BI si intende non solo la rappresentazione dei dati, ma anche la loro modifica da parte degli utenti business. Questa funzionalità è spesso utilizzata da noi nella realizzazione di piattaforme analitiche per il settore finanziario.
Tra le altre cose, con il low-code e, in particolare, con Datagram è possibile affrontare la questione della tracciabilità della provenienza degli oggetti nei flussi di dati con un'atomicità fino ai singoli campi (lineage). Per questo, nello strumento low-code è stata implementata un'integrazione con Apache Atlas e Cloudera Navigator. In sostanza, lo sviluppatore deve registrare un insieme di oggetti nei dizionari di Atlas e fare riferimento agli oggetti registrati durante la costruzione dei mapping. Il meccanismo di tracciamento della provenienza dei dati o di analisi delle dipendenze degli oggetti consente di risparmiare molto tempo quando è necessario apportare modifiche agli algoritmi di calcolo. Ad esempio, nella preparazione della rendicontazione finanziaria, questa funzionalità permette di affrontare con maggiore serenità i periodi di cambiamenti legislativi. Infatti, più siamo consapevoli della dipendenza interformale in relazione agli oggetti del dettaglio, meno ci troveremo ad affrontare difetti “improvvisi” e ridurremo il numero di rework.
Data Quality & Low-code
Un altro compito realizzato con lo strumento low-code nel progetto dell'azienda Mediascope è stato il compito di classe Data Quality. Una caratteristica della realizzazione del pipeline di verifica dei dati per il progetto della società di ricerca è stata l'assenza di impatto sulla funzionalità e sulla velocità del flusso principale di calcolo dei dati. Per orchestrare flussi indipendenti di verifica dei dati, è stato utilizzato il già noto Apache Airflow. Man mano che ciascun passaggio della produzione di dati era pronto, si attivava parallelamente una parte separata del pipeline DQ.
È considerata una buona pratica monitorare la qualità dei dati sin dal loro nascere nella piattaforma analitica. Avere informazioni sui metadati ci consente già di verificare il rispetto delle condizioni di base - not null, constraints, foreign keys - sin dal momento in cui le informazioni entrano nel layer primario. Questa funzionalità è stata realizzata sulla base di mappature generate automaticamente della famiglia data quality in Datagram. La generazione del codice in questo caso si basa anche sui metadati del modello. Nel progetto dell'azienda Mediascope, l'integrazione avveniva con i metadati del prodotto Enterprise Architect.
Grazie all'integrazione dello strumento low-code e di 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 nella chiave primaria;
- Verifica della chiave esterna dell'entità;
- Verifica dell'unicità della riga in base a un insieme di campi.
Per controlli più complessi di disponibilità e validità dei dati, è stata creata una mappatura con Scala Expression, che accetta come input codice Spark SQL esterno di verifica, preparato dagli analisti in Zeppelin.
Certo, l'auto-generazione delle verifiche deve avvenire gradualmente. Nell'ambito del progetto descritto, sono stati preceduti dai seguenti passaggi:
- DQ, realizzati nei notebook Zeppelin;
- DQ, incorporati nella mappatura;
- DQ in forma di mappature massive separate, contenenti un insieme di verifiche per ogni entità;
- Mappature DQ parametrizzate universali, che accettano informazioni su metadati e verifiche aziendali.
Uno dei principali vantaggi della creazione di un servizio di controlli parametrici è la riduzione dei tempi di consegna delle funzionalità nell'ambiente di produzione. I nuovi controlli di qualità possono bypassare il classico modello di consegna del codice attraverso gli ambienti di sviluppo e test:
- Tutti i controlli dei metadati vengono generati automaticamente quando si modifica il modello in EA;
- I controlli di disponibilità dei dati (determinazione della presenza di dati in un determinato momento) possono essere generati sulla base di un catalogo che conserva il timing atteso per l'apparizione della prossima serie di dati per oggetti specifici;
- I controlli di business per la validità dei dati vengono creati dagli analisti nei notebook Zeppelin. Da lì, vengono inviati direttamente alle tabelle di configurazione del modulo DQ nell'ambiente di produzione.
I rischi legati al caricamento diretto degli script in produzione sono praticamente assenti. Anche in caso di errore sintattico, il massimo che possiamo rischiare è il mancato completamento di un controllo, poiché il flusso di calcolo dei dati e il flusso di attivazione dei controlli di qualità sono separati.
In sostanza, il servizio DQ è permanentemente attivo in un ambiente di produzione ed è pronto a iniziare a funzionare non appena arriva un nuovo insieme di dati.
In conclusion
Il vantaggio dell'utilizzo del low-code è evidente. Gli sviluppatori non devono costruire l'applicazione 'da zero'. Un programmatore sollevato da compiti aggiuntivi produce risultati più rapidamente. La velocità, a sua volta, libera risorse aggiuntive di tempo per affrontare questioni di ottimizzazione. Pertanto, in questo caso, ci si può aspettare soluzioni di qualità superiore e più rapide.
Certamente, il low-code non è una panacea e la magia non avverrà da sola:
- L'industria del low-code sta attraversando una fase di 'rafforzamento' e non ci sono ancora standard industriali uniformi;
- Molte soluzioni low-code non sono gratuite e l'acquisto deve essere un passo consapevole, da fare con piena fiducia nel beneficio finanziario del loro uso;
- Molte soluzioni low-code non sempre si integrano bene con GIT / SVN. Possono anche essere scomode da utilizzare nel caso si desideri nascondere il codice generato;
- L'espansione dell'architettura potrebbe richiedere un'implementazione aggiuntiva di una soluzione low-code, il che a sua volta provoca un effetto di "attaccamento e dipendenza" dal fornitore della soluzione low-code.
- Un adeguato livello di sicurezza è possibile, ma è piuttosto laborioso e complesso da attuare per i motori dei sistemi low-code. Le piattaforme low-code non dovrebbero essere selezionate solo in base all'aspettativa di un vantaggio dall'uso. È importante porsi domande riguardo alla disponibilità di funzionalità per la gestione degli accessi e per la delega/escalation delle credenziali a livello dell'intero IT landscape dell'organizzazione.
Tuttavia, se sei a conoscenza di tutti gli svantaggi del sistema scelto e i benefici del suo utilizzo sono comunque largamente predominanti, passa al low-code senza timore. Soprattutto perché la transizione è inevitabile, così come ogni evoluzione.
Se un sviluppatore su una piattaforma low-code riesce a lavorare più velocemente di due sviluppatori senza low-code, questo dà all'azienda un vantaggio sotto molti aspetti. La soglia di ingresso nelle soluzioni low-code è più bassa rispetto alle tecnologie "tradizionali", e questo influisce positivamente sulla questione della carenza di personale. Utilizzando strumenti low-code, è possibile accelerare la collaborazione tra i team funzionali e prendere decisioni più rapidamente sulla correttezza dell'approccio scelto nelle ricerche di data science. Le piattaforme low-code possono essere un fattore trainante per la trasformazione digitale dell'organizzazione, poiché le soluzioni create possono essere comprensibili anche per specialisti non tecnici (in particolare, utenti di business).
Se avete scadenze ravvicinate, complessità nella logica aziendale, mancanza di esperienze tecnologiche e necessitate di accelerare il time to market, allora il low-code è uno dei modi per soddisfare le vostre esigenze.
È innegabile l'importanza degli strumenti di sviluppo tradizionali, ma in molti casi l'uso di soluzioni low-code è il modo migliore per aumentare l'efficienza nella risoluzione delle problematiche.
Fonte: habr.com
