Dremio: analisi dei dati più semplice e veloce

Jacques Nadeau è il CTO e cofondatore di Dremio.

Ora è un ottimo momento per essere uno sviluppatore. Negli ultimi dieci anni, le decisioni sulla tecnologia sono passate dalla sala del consiglio a sviluppatori innovativi, che stanno costruendo con l'open source e prendendo decisioni basate sui meriti del progetto sottostante piuttosto che sulle relazioni commerciali fornite da un fornitore. Sono emersi nuovi progetti che si concentrano sul rendere gli sviluppatori più produttivi e che sono più facili da gestire e scalare. Questo è vero praticamente per ogni livello dello stack tecnologico. Il risultato è che oggi gli sviluppatori hanno opportunità pressoché illimitate di esplorare nuove tecnologie, nuove architetture e nuovi modelli di implementazione.

Osservando in particolare il livello dati, i sistemi NoSQL come MongoDB, Elasticsearch e Cassandra hanno spinto i limiti in termini di agilità, scalabilità e prestazioni per le applicazioni operative, ciascuno con un diverso modello di dati e approccio allo schema. Lungo la strada molti team di sviluppo sono passati a un modello di microservizi, diffondendo i dati delle applicazioni su molti sistemi sottostanti diversi.

In termini di analisi, le origini dati vecchie e nuove hanno trovato la loro strada in un mix di data warehouse tradizionali e data lake, alcuni su Hadoop, altri su Amazon S3. E l'ascesa della piattaforma di streaming di dati Kafka crea un modo completamente diverso di pensare al movimento dei dati e all'analisi dei dati in movimento.

Con i dati in così tante tecnologie diverse e formati sottostanti, l'analisi dei dati moderni è difficile. Gli strumenti di BI e analisi come Tableau, Power BI, R, Python e modelli di machine learning sono stati progettati per un mondo in cui i dati risiedono in un unico database relazionale ad alte prestazioni. Inoltre, gli utenti di questi strumenti - analisti aziendali, data scientist e modelli di machine learning - desiderano la possibilità di accedere, esplorare e analizzare i dati da soli, senza alcuna dipendenza dall'IT.

Presentazione del data fabric Dremio

Gli strumenti di BI, i sistemi di data science e i modelli di machine learning funzionano meglio quando i dati risiedono in un unico database relazionale ad alte prestazioni. Sfortunatamente, non è lì che vivono i dati oggi. Di conseguenza, l'IT non ha altra scelta che colmare questa lacuna attraverso una combinazione di sviluppo ETL personalizzato e prodotti proprietari. In molte aziende, lo stack di analisi include i seguenti livelli:

  • Staging dei dati . I dati vengono spostati da vari database operativi in ​​una singola area di gestione temporanea come un cluster Hadoop o un servizio di cloud storage (ad esempio, Amazon S3).
  • Magazzino dati . Sebbene sia possibile eseguire query SQL direttamente su Hadoop e sul cloud storage, questi sistemi semplicemente non sono progettati per fornire prestazioni interattive. Pertanto, un sottoinsieme di dati viene solitamente caricato in un data warehouse relazionale o in un database MPP.
  • Cubi, tabelle di aggregazione ed estratti BI . Per fornire prestazioni interattive su set di dati di grandi dimensioni, i dati devono essere pre-aggregati e / o indicizzati creando cubi in un sistema OLAP o tabelle di aggregazione materializzate nel data warehouse.

Questa architettura multistrato introduce molte sfide. È complesso, fragile e lento e crea un ambiente in cui i consumatori di dati dipendono interamente dall'IT.

Dremio introduce un nuovo livello nell'analisi dei dati che chiamiamo fabric dati self-service. Dremio è un progetto open source che consente ad analisti aziendali e scienziati di dati di esplorare e analizzare qualsiasi dato in qualsiasi momento, indipendentemente dalla sua posizione, dimensione o struttura. Dremio combina un'architettura scale-out con esecuzione e accelerazione a colonne per ottenere prestazioni interattive su qualsiasi volume di dati, consentendo al contempo a IT, data scientist e analisti aziendali di modellare senza problemi i dati in base alle esigenze dell'azienda.

Costruito su Apache Arrow, Apache Parquet e Apache Calcite

Dremio utilizza archiviazione ed esecuzione a colonne ad alte prestazioni, con tecnologia Apache Arrow (a colonne in memoria) e Apache Parquet (a colonne su disco). Dremio utilizza anche Apache Calcite per l'analisi SQL e l'ottimizzazione delle query, basandosi sulle stesse librerie di molti altri motori basati su SQL, come Apache Hive.

Apache Arrow è un progetto open source che consente l'elaborazione e lo scambio di dati in memoria a colonne. Arrow è stato creato da Dremio e include committer di varie società tra cui Cloudera, Databricks, Hortonworks, Intel, MapR e Two Sigma.

Dremio è il primo motore di esecuzione costruito da zero su Apache Arrow. Internamente, i dati in memoria vengono mantenuti off-heap nel formato Arrow e presto sarà disponibile un'API che restituisce i risultati delle query come buffer di memoria Arrow.

Anche una serie di altri progetti hanno abbracciato Arrow. Python (Pandas) e R sono tra questi progetti, consentendo ai data scientist di lavorare in modo più efficiente con i dati. Ad esempio, Wes McKinney, creatore della popolare libreria Pandas, ha recentemente dimostrato come Arrow consente agli utenti di Python di leggere dati in Pandas a oltre 10 GB / s.

Come Dremio abilita i dati self-service

Oltre alla capacità di lavorare in modo interattivo con i loro set di dati, ingegneri di dati, analisti aziendali e scienziati di dati hanno anche bisogno di un modo per curare i dati in modo che siano adatti alle esigenze di un progetto specifico. Si tratta di un cambiamento fondamentale rispetto al modello incentrato sull'IT, in cui i consumatori di dati avviano una richiesta per un set di dati e attendono che l'IT soddisfi la loro richiesta settimane o mesi dopo. Dremio abilita un modello self-service, in cui i consumatori di dati utilizzano le capacità di gestione dei dati di Dremio per scoprire, curare, accelerare e condividere i dati in modo collaborativo senza fare affidamento sull'IT.

Tutte queste funzionalità sono accessibili tramite un'interfaccia utente moderna, intuitiva e basata sul Web:

  • Scopri . Dremio include un catalogo dati unificato in cui gli utenti possono scoprire ed esplorare set di dati fisici e virtuali. Il catalogo dati viene aggiornato automaticamente quando vengono aggiunte nuove origini dati e con l'evoluzione delle origini dati e dei set di dati virtuali. Tutti i metadati vengono indicizzati in un indice ricercabile ad alte prestazioni ed esposti agli utenti tramite l'interfaccia Dremio.
  • Curato . Dremio consente agli utenti di curare i dati creando set di dati virtuali. È supportata una varietà di trasformazioni punta e clicca e gli utenti avanzati possono utilizzare la sintassi SQL per definire trasformazioni più complesse. Man mano che le query vengono eseguite nel sistema, Dremio apprende i dati, consentendogli di consigliare varie trasformazioni come join e conversioni di tipi di dati.
  • Dremio è in grado di accelerare i set di dati fino a 1000 volte rispetto alle prestazioni del sistema di origine. Gli utenti possono votare per i set di dati che pensano dovrebbero essere più veloci e l'euristica di Dremio terrà conto di questi voti per determinare quali set di dati accelerare. Facoltativamente, gli amministratori di sistema possono determinare manualmente quali set di dati accelerare.
  • Dremio consente agli utenti di condividere in modo sicuro i dati con altri utenti e gruppi. In questo modello un gruppo di utenti può collaborare a un set di dati virtuale che verrà utilizzato per un particolare lavoro analitico. In alternativa, gli utenti possono caricare i propri dati, come fogli di calcolo Excel, per unirsi ad altri set di dati dal catalogo aziendale. I creatori di set di dati virtuali possono determinare quali utenti possono eseguire query o modificare i loro set di dati virtuali. È come Google Docs per i tuoi dati.

Come funziona l'accelerazione dei dati Dremio

Dremio utilizza rappresentazioni fisiche altamente ottimizzate dei dati di origine chiamate Data Reflections. Il Reflection Store può vivere su HDFS, MapR-FS, cloud storage come S3 o Direct-Attached Storage (DAS). La dimensione dell'archivio Reflection può superare quella della memoria fisica. Questa architettura consente a Dremio di accelerare più dati a un costo inferiore, con un conseguente rapporto di riscontro della cache molto più elevato rispetto alle tradizionali architetture di sola memoria. Le riflessioni dei dati vengono utilizzate automaticamente dall'ottimizzatore basato sui costi al momento della query.

Le riflessioni dei dati sono invisibili agli utenti finali. A differenza dei cubi OLAP, delle tabelle di aggregazione e delle estrazioni BI, l'utente non si connette esplicitamente a un Data Reflection. Invece, gli utenti eseguono query sul modello logico e l'ottimizzatore di Dremio accelera automaticamente la query sfruttando le riflessioni dei dati adatte alla query in base all'analisi dei costi dell'ottimizzatore.

Quando l'ottimizzatore non è in grado di accelerare la query, Dremio utilizza il suo motore di esecuzione distribuito ad alte prestazioni, sfruttando l'elaborazione in memoria a colonne (tramite Apache Arrow) e push-down avanzati nelle origini dati sottostanti (quando si tratta di origini RDBMS o NoSQL).

Come Dremio gestisce le query SQL

Le applicazioni client inviano query SQL a Dremio su ODBC, JDBC o REST. Una query potrebbe coinvolgere uno o più set di dati, potenzialmente residenti in origini dati diverse. Ad esempio, una query può essere un join tra una tabella Hive, Elasticsearch e diverse tabelle Oracle.

Dremio utilizza due tecniche principali per ridurre la quantità di elaborazione richiesta per una query:

  • Push-down nell'origine dati sottostante . L'ottimizzatore considererà le capacità dell'origine dati sottostante e i relativi costi. Quindi genererà un piano che esegue le fasi della query nell'origine o nell'ambiente di esecuzione distribuito di Dremio per ottenere il piano globale più efficiente possibile.
  • Accelerazione tramite Data Reflection . L'ottimizzatore utilizzerà le riflessioni dei dati per parti della query quando questo produce il piano generale più efficiente. In molti casi l'intera query può essere gestita da Data Reflections in quanto possono essere ordini di grandezza più efficienti rispetto all'elaborazione delle query nell'origine dati sottostante.

Query push-down

Dremio è in grado di inviare l'elaborazione a origini dati relazionali e non relazionali. Le origini dati non relazionali in genere non supportano SQL e hanno capacità di esecuzione limitate. Un file system, ad esempio, non può applicare predicati o aggregazioni. MongoDB, d'altra parte, può applicare predicati e aggregazioni, ma non supporta tutti i join. L'ottimizzatore Dremio comprende le capacità di ogni origine dati. Quando è più efficiente, Dremio invierà il maggior numero possibile di query all'origine sottostante ed esegue il resto nel proprio motore di esecuzione distribuito.

Scaricamento di database operativi

La maggior parte dei database operativi sono progettati per carichi di lavoro ottimizzati per la scrittura. Inoltre, queste implementazioni devono soddisfare rigorosi SLA, poiché eventuali tempi di inattività o prestazioni ridotte possono avere un impatto significativo sull'azienda. Di conseguenza, i sistemi operativi sono spesso isolati dall'elaborazione di query analitiche. In questi casi, Dremio può eseguire query analitiche utilizzando Data Reflections, che forniscono l'elaborazione delle query più efficiente possibile riducendo al minimo l'impatto sul sistema operativo. Le riflessioni dei dati vengono aggiornate periodicamente in base a criteri che possono essere configurati tabella per tabella.

Fasi di esecuzione della query

La vita di una query include le seguenti fasi:

  1. Il client invia la query al coordinatore tramite ODBC / JDBC / REST
  2. Pianificazione
    1. Il coordinatore analizza la query nel modello relazionale universale di Dremio
    2. Il coordinatore considera le statistiche disponibili sulle origini dati per sviluppare il piano di query, nonché le capacità funzionali della fonte
  3. Il coordinatore riscrive il piano di query da utilizzare
    1. le riflessioni dei dati disponibili, considerando l'ordine, il partizionamento e la distribuzione delle riflessioni dei dati e
    2. le capacità disponibili dell'origine dati
  4. Esecuzione
  1. Gli esecutori leggono i dati nei buffer Arrow da sorgenti in parallelo
    1. Gli esecutori eseguono il piano di query riscritto.
    2. Un esecutore unisce i risultati di uno o più esecutori e trasmette i risultati finali al coordinatore
  1. Il cliente riceve i risultati dal coordinatore

Tieni presente che i dati possono provenire da Data Reflections o dalle origini dati sottostanti. Durante la lettura da un'origine dati, l'esecutore invia le query native (ad es. MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL) come determinato dall'ottimizzatore nella fase di pianificazione.

Tutte le operazioni sui dati vengono eseguite sul nodo executor, consentendo al sistema di scalare a molti client simultanei utilizzando solo pochi nodi coordinator.

Esempio di query push-down

Per illustrare come Data Fabric si adatta alla tua architettura di dati, diamo un'occhiata più da vicino all'esecuzione di una query SQL su un'origine che non supporta SQL.

Una delle fonti di dati moderne più popolari è Elasticsearch. C'è molto da apprezzare su Elasticsearch, ma in termini di analisi non supporta SQL (inclusi i join SQL). Ciò significa che strumenti come Tableau ed Excel non possono essere utilizzati per analizzare i dati dalle applicazioni create su questo archivio dati. Esiste un progetto di visualizzazione chiamato Kibana che è popolare per Elasticsearch, ma Kibana è progettato per gli sviluppatori. Non è proprio per gli utenti aziendali.

Dremio semplifica l'analisi dei dati in Elasticsearch con qualsiasi strumento basato su SQL, incluso Tableau. Prendiamo ad esempio la seguente query SQL per i dati aziendali di Yelp, che è archiviata in JSON:

SELEZIONA stato, città, nome, review_count

DA elastic.yelp.business

DOVE

  stato NOT IN ('TX', 'UT', 'NM', 'NJ') AND

  review_count> 100

ORDINA PER review_count DESC, stato, città

LIMITE 10

Dremio compila la query in un'espressione che Elasticsearch può elaborare: