Soluții de integrare a datelor Qlik Talend

Specificații

• Nume produs: Soluții de integrare a datelor Qlik Talend
• Platforma de integrare: Platforma Databricks Lakehouse
• Caracteristici: Change Data Capture (CDC), Tehnologia de transformare

Instrucțiuni de utilizare a produsului

Soluții de integrare a datelor Qlik Talend
Soluțiile Qlik Talend Data Integration accelerează inițiativele de învățare automată (ML), inteligență artificială (AI) și DataOps cu Change Data Capture (CDC) și tehnologia de transformare care asigură fluxuri continue de date din mai multe surse de date către Platforma Databricks Lakehouse, pregătită pentru AI și Consumul de analize.

Qlik Replicate
În această arhitectură, Qlik Replicate îndeplinește următoarele funcții:

1. Instanțiați ținta:
   • Creați tabele țintă în format DELTA cu tipuri de date adecvate traduse din sursă.
   • Efectuați o încărcare inițială/completă de la sursă și trimiteți datele în stratul de stocare.
   • Trimiteți Spark SQL către Databricks pentru a încărca datele din stratul de stocare și a le converti în tabele folosind formatul delta.
2. Capturați și aplicați modificări:
   • Capturați modificările folosind CDC bazat pe jurnal de la sursă.
   • Livrați și APLICAți modificări (Inserare / Actualizare / Ștergere) la tabelele DELTA țintă (folosind stratul de stocare ca intermediartaging).

Integrarea datelor Qlik Cloud
Qlik Cloud Data Integration este o ofertă iPaaS care oferă posibilitatea de a crea pipeline de proiecte de date pentru a efectua o varietate de sarcini de integrare a datelor în sprijinul arhitecturii dvs. de date și al cerințelor AI și Analytics.

Funcțiile Qlik Cloud Data Integration:

• Sarcini de aterizare:
  • Supraveghează transferul fără probleme de date din diverse surse către zona de aterizare desemnată folosind Qlik Data Gateway – Data Movement pentru accesarea surselor de date prin Change Data Capture (CDC).
  • Permite reîncărcări periodice programate prin executarea încărcărilor complete.
• Sarcini de transformare:
  • Generează transformări de date reutilizabile și bazate pe reguli în cadrul conductei de date.
  • Efectuează transformări la nivel de rând și creează seturi de date folosind SQL personalizat.
  • Se poate materializa ca tabele sau se poate manifesta ca dinamic views aplică transformări din mers.

Întrebări frecvente (FAQ)

• Qlik Replicate și Qlik Cloud Data Integration pot fi utilizate împreună?
  Da, ambele soluții sunt complementare și pot fi utilizate împreună sau separat, în funcție de cazul de utilizare a întreprinderii și de arhitectura datelor.
• Care sunt câteva dintre funcțiile principale ale Qlik Replicate?
  Qlik Replicate poate instanția ținta creând tabele în format DELTA, efectuează încărcări inițiale, capturează modificări folosind CDC și aplică modificări la tabelele țintă.
• Care este scopul Qlik Cloud Data Integration?
  Qlik Cloud Data Integration permite crearea de pipeline de proiecte de date pentru diverse sarcini de integrare a datelor pentru a susține arhitectura datelor și cerințele AI și Analytics.

Introducere

Soluțiile Qlik Talend Data Integration accelerează inițiativele de învățare automată (ML), inteligență artificială (AI) și DataOps cu Change Data Capture (CDC) și tehnologia de transformare care asigură fluxuri continue de date din mai multe surse de date către Platforma Databricks Lakehouse, pregătită pentru AI și Consumul de analize.

Soluții de integrare a datelor Qlik Talend

• Qlik Replicate și Qlik Talend Cloud Data Integration sunt două soluții de la Qlik care permit companiilor să își gestioneze datele din diferite surse și platforme. Qlik Replicate este un software de integrare a datelor care permite utilizatorilor să reproducă și să actualizeze datele în timp real, de la surse on-premise și cloud până la depozitele de date în cloud, fără codificare manuală sau scripting. Qlik Cloud Data Integration este un serviciu bazat pe cloud care oferă capacitatea de a crea conducte de date pentru a efectua diverse sarcini de integrare a datelor, cum ar fi aterizarea, înregistrarea, transformarea și unificarea datelor. Ambele soluții acceptă o gamă largă de surse și destinații de date, cum ar fi baze de date relaționale, platforme de date mari, SAP, mainframe, stocare în cloud și aplicații SaaS. Cu toate acestea, există unele diferențe între ele în ceea ce privește caracteristicile, prețurile și opțiunile de implementare.
• Unele dintre principalele diferențe sunt:
  • Qlik Replicate este un produs independent care poate fi instalat on-premises sau pe cloud, în timp ce Qlik Talend Cloud Data Integration este un serviciu complet gestionat care rulează pe platforma Qlik Cloud.
  • Qlik Replicate oferă funcții mai avansate pentru replicarea datelor, cum ar fi capturarea datelor de modificare (CDC), îmbinări întârziate, evoluția schemei și rezolvarea conflictelor. În timp ce Qlik Talend Cloud Data Integration se concentrează mai mult pe transformarea și unificarea datelor, cum ar fi curățarea, îmbogățirea, combinarea și crearea de profiluri a datelor.
• Pe scurt, Qlik Replicate și Qlik Talend Cloud Data Integration sunt soluții complementare care pot fi utilizate împreună sau separat, în funcție de cazul de utilizare și de arhitectura de date a întreprinderii. Ambele soluții urmăresc să ofere capabilități rapide, fiabile și scalabile de integrare a datelor pentru nevoile moderne de AI și Analytics.

Qlik Replicate

• Qlik Replicate® automatizează continuu mișcarea datelor CDC din mai multe surse de date (de exemplu, Oracle, Microsoft SQL Server, SAP, Mainframe și altele) către Platforma Databricks Lakehouse. Ajută clientul să evite sarcinile grele asociate cu extragerea manuală a datelor, transferarea lor prin API/script și apoi tăierea, staging și importând-o.
• În această arhitectură, Qlik Replicate îndeplinește următoarele funcții:
  1. Instanțiați ținta
     • Creați tabele țintă în format DELTA cu tipuri de date adecvate traduse din sursă
     • Efectuați o încărcare inițială/completă de la sursă și trimiteți datele în stratul de stocare
     • Trimiteți Spark SQL către Databricks pentru a încărca datele din stratul de stocare și a le converti în tabele folosind formatul delta
  2. Capturați și aplicați modificări
     • Capturați modificările folosind CDC bazat pe jurnal de la sursă
     • Livrați și APLICAți modificări (Inserare / Actualizare / Ștergere) la tabelele DELTA țintă (folosind stratul de stocare ca intermediartaging)

Integrarea datelor Qlik Cloud

• Qlik Cloud Data Integration este o ofertă iPaaS (Integration Platform as a Service) care oferă posibilitatea de a crea pipeline de proiecte de date pentru a efectua o varietate de sarcini de integrare a datelor în sprijinul arhitecturii dvs. de date și al cerințelor AI și Analytics.
  • Conducte de date - Puteți profita de captarea datelor de modificare în timp real, bazată pe jurnal, cu conexiune securizată la sursele de date locale din spatele firewall-urilor sau puteți utiliza capabilitățile de încărcare completă pentru sursele de date SaaS. După ce ați încorporat datele, puteți aplica transformări pentru rezultate potrivite scopului sau puteți automatiza modele, cum ar fi faptele și dimensiunile data mart. Extern views și trăiesc viewsunt generate pentru consumul de date. Qlik Cloud Data Integration generează, de asemenea, un depozit de date istorice (HDS) complet de tip 2.
  • Sarcini de replicare a datelor – Replicați datele din orice sursă compatibilă către orice destinație acceptată. Datele pot fi transformate și rămân actualizate în mod constant utilizând tehnicile de captare a datelor de modificare (CDC). Există și capacitatea de a livra datele într-un lac de date, livrând date în Amazon S3, Azure Data Lake Storage sau Google Cloud Storage
• Ieșirea de date rafinată din Qlik Cloud Data Integration poate fi utilizată în mai multe scopuri:
  • Mișcare în timp real din toate sursele întreprinderii, inclusiv baze de date relaționale, aplicații SAP, mainframe și SaaS.
  • Transformarea datelor folosind ELT (Extract/Load/Transform) folosind o abordare fără cod, fără a fi nevoie de soluții suplimentare de la terți.
  • Crearea automată de datamart-uri pentru analiză în Databricks Lakehouse.
  • Modernizarea depozitului de date pentru a sprijini AI, Machine Learning și alte inițiative.
• În această arhitectură, Qlik Cloud Data Integration îndeplinește următoarele funcții:
  • Instanțiați ținta.
    • Creați tabele țintă în format DELTA cu tipuri de date adecvate traduse din tabelele sursă
    • Efectuați o încărcare inițială/completă de la sursă, trimițând datele la stratul de stocare
      • Aplicații SaaS – direct
      • Baze de date relaționale – folosind Data Gateway
    • Trimiteți Spark SQL către Databricks pentru a încărca datele din stratul de stocare și a le converti în tabele folosind formatul delta
  • Capturați și aplicați modificări.
    • Capturați modificările folosind CDC bazat pe jurnal de la sursă
      • Aplicații SaaS – direct
      • Baze de date relaționale – folosind Qlik Data Gateway
    • Livrați și APLICAți modificări (Inserare / Actualizare / Ștergere) la tabelele DELTA țintă (folosind stratul de stocare ca intermediartaging)
  • Executați transformările care trimit Sparksql către Databricks

Un alt mod de a vedea această arhitectură este prin conceptul de sarcini cu funcții specializate

1. Sarcini de aterizare - supraveghează transferul fără întreruperi de date din diverse surse către zona de aterizare desemnată. Diagrama ilustrativă ilustrează utilizarea Qlik Data Gateway – Data Movement pentru accesarea surselor de date prin Change Data Capture (CDC) pentru a se asigura că datele rămân actuale. În plus, conexiunile sursă Qlik Cloud Data Integration pot fi folosite pentru a executa încărcări complete, permițând reîncărcări periodice programate.
2. Sarcini de stocare - supraveghează aplicarea datelor la tabelele de stocare, inclusiv crearea și administrarea atât a tabelelor, cât și a celor externe views. Această sarcină crucială joacă un rol esențial în menținerea integrității și accesibilității datelor în mediul Qlik Cloud Data Integration. Sarcina de stocare nu guvernează numai timpul de aplicare a datelor, dar asigură și integrarea perfectă a informațiilor în infrastructura de stocare, sporind eficiența și funcționalitatea globală a platformei Qlik Cloud Data Integration.
3. Sarcini de transformare - În cadrul conductei de date, puteți genera transformări de date care sunt atât reutilizabile, cât și bazate pe reguli. Aceste transformări pot fi încorporate fără probleme în procesul dvs. de integrare a datelor sau configurate ca sarcini de date de transformare reutilizabile. Flexibilitatea se extinde la realizarea de transformări la nivel de rând și crearea de seturi de date folosind SQL personalizat, care se poate materializa fie ca tabele, fie se poate manifesta ca dinamic views aplică transformări din mers.
4. Sarcinile Data Mart - După integrarea cu succes a datelor, este posibil să se genereze magazine de date utilizând informațiile provenite din sarcinile Stocare sau Transformare. Adaptându-se la cerințele afacerii, pot fi create mai multe magazine de date. În mod ideal, aceste magazine de date ar trebui să servească drept depozite pentru date agregate, adunate în scopuri analitice în cadrul unui anumit departament sau unitate al unei organizații, cum ar fi departamentul de vânzări sau chiar expuse ca caracteristici care urmează să fie consumate de procesele ML.

Ghid de implementare

• După cum sa menționat anterior în acest document, Qlik Replicate și Qlik Cloud Data Integration sunt două soluții care pot fi utilizate fie împreună, fie separat. Decizia de a le folosi în combinație sau individual depinde de arhitectura de date și de nevoile întreprinderii. Este important să luăm în considerare cerințele clienților și cazurile de utilizare pentru a determina cea mai eficientă și eficientă arhitectură.
  • Una până la multe topologii necesită în prezent utilizarea Qlik Replicate
  • Sursele SaaS sunt acceptate numai de Qlik Cloud Data Integration
• Pot exista cazuri în care atât Replicate, cât și Qlik Cloud Data Integration pot fi utilizate împreună. De exemplu, Replicate poate fi folosit pentru a alimenta date în Databricks dintr-o sursă care nu este acceptată în prezent de Qlik Cloud Data Integration. Datele înregistrate pot fi apoi utilizate ca intrări pentru conductele de date create folosind Qlik Cloud Data Integration.

Platforma Databricks Data Intelligence

• Baza platformei Databricks Data Intelligence se află în arhitectura lakehouse, un amestec revoluționar de lacuri de date și depozite de date. Această abordare inovatoare este orientată spre minimizarea costurilor și accelerarea realizării obiectivelor de date și AI.
• Îmbrățișând principiile open-source și aderând la standardele deschise, arhitectura Lakehouse eficientizează infrastructura de date prin eliminarea barierelor istorice care complică adesea sferele datelor și AI. Procedând astfel, oferă un mediu mai coerent și mai eficient pentru gestionarea și valorificarea resurselor dvs. de date.

Unificat

O arhitectură unificată care cuprinde integrare, stocare, procesare, guvernare, partajare, analiză și AI. O metodologie singulară pentru manipularea datelor structurate și nestructurate. O perspectivă cuprinzătoare asupra descendenței și provenienței datelor de la început până la sfârșit. Un set de instrumente coeziv care găzduiește Python și SQL, notebook-uri și IDE-uri, procese în loturi și streaming, la toți furnizorii importanți de cloud.

Deschide

• În cadrul Databricks, controlul asupra datelor este menținut în mod constant, asigurând independența față de formatele proprietare și ecosistemele închise.
• Fundamentul arhitecturii lakehouse se bazează pe proiecte open-source acceptate pe scară largă, cum ar fi Apache Spark™, ​​Delta Lake și MLflow. Se bucură de sprijin global prin intermediul rețelei de parteneri Databricks. În plus, caracteristica Delta Sharing prezintă o soluție deschisă pentru partajarea în siguranță a datelor în timp real de la lakehouse către orice platformă de calcul. Acest lucru se realizează fără a fi nevoie de replicarea datelor sau procese complexe de extragere, transformare, încărcare (ETL).

Scalabil

• Optimizarea automată pentru performanță și stocare este concepută meticulos pentru a asigura cel mai scăzut cost total de proprietate (TCO) dintre platformele de date, realizând concomitent performanțe record mondiale pentru depozitarea datelor și cazurile de utilizare ale inteligenței artificiale (AI). Aceasta se extinde la aplicarea tehnicilor generative, cum ar fi modelele de limbaj mari (LLM).
• Indiferent de scara organizațională, Databricks este conceput pentru a răspunde în mod eficient cerințelor operaționale ale afacerilor, de la startup-uri la întreprinderi globale.

SQL Warehouses x Clustere de calcul generale

Soluțiile Qlik acceptă atât Databricks SQL Warehouses, cât și Clustere de calcul. Sunt două moduri diferite de procesare a datelor în cloud. În ambele cazuri, soluțiile Qlik vor trimite comenzi SparkSQL pentru a procesa datele, fără a se baza pe alte caracteristici acceptate (cum ar fi notebook-urile în Scala, de exempluample). Alegerea dintre depozitele SQL Databricks și clusterele generale de calcul depinde de cerințele și obiectivele specifice fiecărui proiect. Unii factori de luat în considerare sunt:

Volumul datelor

• Frecvența CDC: Depozitele SQL se învârt mai repede atunci când sunt acționate prima dată, iar clusterele pot fi mai lente pentru a răspunde la prima comandă.
• Scalabilitate și elasticitate: depozitele SQL se pot scala automat în sus sau în jos pentru a satisface cererea utilizatorilor și interogărilor concurente. Clusterele de calcul generale se pot scala, dar necesită mai multă intervenție manuală și reglare.
• Securitate și guvernare: depozitele SQL oferă caracteristici de securitate încorporate, cum ar fi criptarea, autentificarea, autorizarea, auditarea și conformitatea. Clusterele de calcul generale pot implementa, de asemenea, măsuri de securitate, dar necesită mai multă configurare și management.
• În rezumat, depozitele Databricks SQL și clusterele generale de calcul sunt atât soluții puternice, cât și fiabile pentru procesarea datelor în cloud. Cu toate acestea, ele au puncte forte și puncte slabe diferite care ar trebui evaluate cu atenție înainte de a alege unul față de celălalt.

Recomandări pentru clusterele generale de calcul pentru soluțiile Qlik

NOTA
Recomandările de mai jos sunt pentru referință și se bazează pe proiecte și POC-uri conduse de Qlik și partenerii săi cu privire la cerințe specifice. Mai mulți factori, cum ar fi topologia rețelei, latența, structura tabelului, frecvența de actualizare, versiunile driverului etc. pot afecta setările necesare pentru cazul dvs. de utilizare particular. Clienții sunt sfătuiți să efectueze controlul și diligența necesare pentru a-și determina configurațiile.

1. Databricks Runtime
   Verificați întotdeauna Qlik Replicate și Qlik Cloud Data Integration (http://help.qlik.com) pentru a vedea ce Databricks Runtime este acceptat atunci când vă configurați clusterul.
2. Versiunea Databricks Runtime care acceptă Photon
   Când vă configurați clusterul, selectați „Photon” pentru versiunea de execuție Databricks care va accepta clusterul dvs. de uz general. Photon este motorul nativ de interogare vectorizat pe Databricks, scris pentru a fi compatibil direct cu Apache Spark. Photon face parte dintr-un timp de execuție de înaltă performanță care rulează apelurile API existente SQL și DataFrame mai rapid și reduce costul total pe sarcină de lucru. Pentru o discuție suplimentară despre Photon, vă rugăm să consultați acest document https://docs.databricks.com/runtime/photon.html
3. Selectați „Memorie optimizată – Delta cache accelerată”
   Când vă configurați clusterul, asigurați-vă că selectați tipul de lucrător „Memory optimizated – Delta cache accelerated”.
   (*) lista de mai sus se bazează pe Azure Databricks, acest lucru se poate schimba dacă utilizați AWS sau GCP

   

4. Configurați opțiunile de optimizare automată
   Adăugați o configurație în cluster pentru a activa optimizeWrite și a dezactiva autoCompact. Dezactivarea autoCompact este necesară pentru a preveni declanșarea compactării în serie de actualizări CDC în timp real (care pot duce la o latență crescută). Pentru a face acest lucru, adăugați liniile de mai jos la secțiunea Spark din Opțiuni avansate a clusterului dvs.
   scânteie. date bricks.delta.properties.defaults. auto-optimize.optimizeScrie adevărat
   spark.databricks.delta.properties.defaults.autoOptimize.autoCompact false
   Vă rugăm să verificați https://docs.databricks.com/clusters/configure.html pentru mai multe informații despre configurarea clusterului dvs.
5. Optimizați tabelele în mod regulat
   Este important să programați un caiet pentru a OPTIMIZA mesele din Delta Lake. Acest lucru va îmbunătăți viteza de interogare pentru datele debarcate. Vă rugăm să consultați această documentație: https://docs.microsoft.com/en-us/azure/databricks/delta/optimizations/file-mgmt pentru sampfișiere de caiete pentru a optimiza tabelele.
6. Autoscaling
   Datorită volumelor variabile ale volumului de muncă pe care le prezintă CDC, recomandarea este să review configurația dvs. bazată pe volumul de lucru și testarea cu sarcinile dvs., monitorizarea și apoi creșterea sau scăderea în funcție de utilizare. Vă rugăm să consultați documentația Databricks (https://docs.databricks.com/clusters/clusters-manage.html#monitor-performance) pentru cum să monitorizați performanța clusterului.

Recomandări pentru SQL Warehouses pentru soluții Qlik

NOTA

Recomandările de mai jos sunt pentru referință și se bazează pe proiecte și POC-uri conduse de Qlik și partenerii săi cu privire la cerințe specifice. Mai mulți factori, cum ar fi topologia rețelei, latența, structura tabelului, frecvența de actualizare, versiunile driverului etc. pot afecta setările necesare pentru cazul dvs. de utilizare particular. Clienții sunt sfătuiți să efectueze controlul și diligența necesare pentru a-și determina configurațiile.
Depozitele SQL au mult mai puține opțiuni de configurat la nivel de depozit (comparativ cu clusterele). Configurații disponibile.

1. Tip Depozit
   • În momentul în care a fost redactat acest document, există trei tipuri de depozite. Vă rugăm să consultați acest document Ce sunt depozitele SQL? pentru o discuție generală despre ele
   • Din punct de vedere al performanței și al concurenței, recomandarea generală este să utilizați un depozit fără server pentru a crește performanța generală a sarcinii dvs. Unele medii și conturi nu au această opțiune, în această situație, recomandat este un depozit Pro.
2. Scalare
   Ajustați acest parametru pentru a crește pe baza parametrului de activități „Numărul maxim de tabele de încărcat în paralel” (Replicare) sau „Numărul maxim de conexiuni la baze de date” (Qlik Cloud Data Integration). Regula generală este să existe un grup de depozite pentru a procesa 2 până la 3 mese sau conexiuni în paralel.
3. Dimensiunea clusterului
   • Acest parametru depinde foarte mult de datele procesate. Mai mulți parametri pot afecta performanța generală, cum ar fi mai multe tabele, numărul și tipurile de coloane ale fiecărui tabel, frecvența de actualizare etc.
   • Recomandarea generală este să începeți cu o dimensiune care are un cost x performanță așteptat bun (cum ar fi un mediu de example) și efectuați unele teste ajustând acest parametru (în sus sau în jos) în comparație cu linia de bază.

Comparație de performanță între SQL Warehouses x Clustere de calcul generale

NOTA
Acest test a fost efectuat într-un mediu de laborator și nu reprezintă niciun mediu real real. Rezultatele pot varia în funcție de tipul de surse, topologie, volume, dimensiunea înregistrării, reglarea bazei de date sursă și alte variabile.

Mediu:

• Sursă
  • PostgreSQL rulează pe o VM
  • 1 Tabel cu 7 coloane și 36 de milioane de înregistrări
  • Cheie primară (1 coloană)
  • Testarea scriptului CDC cu un profesionistfile de mai jos
• Ținte (Databricks pe Azure) – Staging pe ADLS gen2
• Qlik Replicate noiembrie 2023 (2023.11.0.149) pe Windows
• Proces
  • Două sarcini (aceeași sursă și puncte finale țintă diferite)
  • A început încărcarea completă a sarcinii 1 și a așteptat finalizarea.
  • A început încărcarea completă a sarcinii 2 și a așteptat finalizarea.
  • Am pornit scriptul SQL care simulează modificările. Ambele sarcini rulează în paralel și se livrează la scheme diferite pe Databricks
    Rezultate:
    Folosind Qlik Enterprise Manager pentru a colecta toate statisticile, am observat că nu există o diferență semnificativă de performanță între utilizarea SQL Warehouses și Clustere. Din perspectiva costurilor, depozitele SQL sunt de obicei mai rentabile, ceea ce poate indica utilizarea lor peste clustere.

Recomandări pentru Qlik Cloud Data Integration

1. Selecții de tabel într-o sarcină
   Databricks recomandă izolarea tabelelor mari sau late (multe coloane) care fac multă procesare pentru sarcinile lor. Utilizarea acestei abordări facilitează monitorizarea performanței sau alocarea unui depozit unei sarcini specifice.
2. Transformări într-o sarcină
   Dacă obiectivul dvs. este de a optimiza debitul de date foarte tranzacționale care sunt ingerate în lakehouse, este recomandat să minimizați transformările la nivel de sarcină. Această abordare vă permite să aterizați datele așa cum sunt în casa lacului și apoi să utilizați toate capacitățile disponibile de inginerie a datelor pentru a efectua transformările. Acest proces este denumit din punct de vedere tehnic conversia unui ETL (Extract-Transform-Load) într-un ELT (Extract-Load-Transform).
3. Magazin de date istorice (Tip 2) la Stocare/Transformare
   Qlik Cloud Data Integration va crea în mod prestabilit activele Historical Data Store (Tip 2) care păstrează și gestionează datele curente și istorice de-a lungul timpului, pe baza conceptului SCD de tip 2 (Slowly Changing Dimension). Toate versiunile unei înregistrări sunt păstrate, inclusiv ștergerile, cu date care indică perioada în care fiecare înregistrare a fost activă. Dacă aceste informații nu sunt relevante, puteți dezactiva această caracteristică în secțiunea Stocare sau Transformare din setările proiectului. Acest lucru va economisi resurse (spațiu și calcul) din spațiul dvs. de lucru.
4. Materializarea sarcinilor de transformare
   Datele generate dintr-o sarcină de transformare pot fi expuse în două moduri:
   • Views – unde toate interogările împotriva acestei entități vor fi executate împotriva tabelelor originale din zona de stocare
   • Mesele – unde tabelele vor fi populate într-un mod programat pe baza datelor din zona de stocare.
     Alegerea dintre ele se va baza pe cât de frecvent vor fi accesate datele transformate. Datele transformate mai puțin frecvent vor fi probabil expuse ca views, datele transformate mai frecvent ar trebui să fie păstrate ca tabele. Dacă este nevoie să folosiți ambele, există opțiunea de a avea două (sau mai multe) sarcini de transformare, una bazată pe views și celălalt(e) pe baza de tabele.
5. Folosind Live Views
   • Trăi views încorporează date din tabelele de modificare care nu au fost încă aplicate la tabelele curente sau anterioare. Această caracteristică permite utilizatorilor să acceseze datele cu o latență redusă, fără a fi nevoie de aplicarea frecventă a modificărilor.
   • Întârzierea operațiunii de fuziune duce, de asemenea, la economii de costuri și la scăderea cererilor de procesare pe platforma țintă.
   • În plus, live views ofera avansultage de a nu solicita ca nivelul de calcul să fie întotdeauna operațional. Latența poate fi îmbunătățită, deoarece nu mai este necesară aplicarea modificărilor pe parcursul zilei. Înregistrările nou introduse devin imediat disponibile în live views odată ce sunt accesibile în tabelul de modificări și sarcina de stocare ar putea rula mai rar, salvând clustere/resurse de depozit.
6. Timeout la nivel de conexiune
   Pentru a asigura funcționarea optimă a Qlik Cloud Data Integration, este crucial să configurați o proprietate internă numită executeTimeout cu o valoare mai mare de 300. Această configurație asigură că sistemul Qlik Cloud Data Integration va menține o perioadă de așteptare de cel puțin 5 minute înainte de înregistrare. un eşec. În consecință, aceasta oferă suficient timp pentru ca depozitul să se inițialeze dacă anterior a fost într-o stare oprită. Acest lucru este deosebit de important în scenariile în care depozitul necesită un timp de pornire mai lung.

Recomandări pentru Qlik Replicate

1. Selecții de tabel într-o sarcină
   Databricks recomandă izolarea tabelelor mari sau late (multe coloane) care fac multă procesare pentru sarcinile lor. Utilizarea acestei abordări facilitează monitorizarea performanței sau alocarea unui cluster unei anumite sarcini.
2. Transformări într-o sarcină
   Dacă obiectivul dvs. este de a optimiza debitul de date foarte tranzacționale care sunt ingerate în Lakehouse, este recomandat să minimizați transformările la nivel de activitate. Această abordare vă permite să plasați datele așa cum sunt în Lakehouse și apoi să utilizați toate capabilitățile disponibile de inginerie a datelor pentru a efectua transformările. Acest proces este denumit din punct de vedere tehnic conversia unui ETL (Extract-Transform-Load) într-un ELT (Extract-Load-Transform).
3. File Configurare dimensiune
   • Există un parametru Qlik Replicate la nivelul conexiunii care ar putea crește debitul de date. Se numește Maximum file dimensiune (MB) și se află sub Setările avansate ale conexiunii dvs
   • Valoarea implicită este 100Mb și acest parametru indică file dimensiunea care este încărcată în stagzonă înainte de a fi încărcat într-o masă. Puteți vedea mai jos impactul modificării acestui parametru pentru un tabel cu 100 de milioane de înregistrări (aproximativ 3.8 GB date pe sursă). Nu există o „regulă de aur” pentru acest parametru, dar de obicei, o regulă mai mare file dimensiunea crește performanța transferului de date, ceea ce este foarte important în timpul încărcării complete inițiale.
   • Configurare cluster:
   • Tabel sursă (Azure RDS Mysql) 

     
     După cum se arată mai sus, a existat o îmbunătățire foarte bună la creșterea file dimensiunea de la valoarea implicită (100MB) la 500MB, deși creșterile suplimentare de peste 500MB în acest test au avut un impact mult mai mic asupra performanței.
4. Setări de reglare în lot
   Modificările Qlik Replicate micro-loturi pentru livrare optimizată către Databricks Delta și configurația de reglare a lotului pentru o sarcină influențează dimensiunea micro-loturii trimise către Databricks.
   • Schimbați modul de procesare: Numai aplicația optimizată în loturi este acceptată pentru ținte Databricks.
   • Aplicați modificări în lot la mai multe tabele simultan: Această opțiune configurează numărul de fire care vor funcționa în paralel pentru a încărca și aplica date la Databricks. Valoarea implicită este 5, cu un maxim de 50. Mărirea acestei valori vă poate îmbunătăți debitul atunci când există multe tabele cu CDC într-un anumit lot, dar poate necesita resurse suplimentare de cluster. Te rog review limitările acestui mod din ghidul de ajutor Replicate.
   • Aplicați modificări grupate în setările de interval: Configurați timpul și dimensiunea micro-lotului.
   • Mai lung decât (secunde): Aceasta specifică perioada minimă de așteptare între fiecare aplicare a modificărilor lotului. Valoarea implicită este 1 și, de obicei, este o valoare prea mică pentru procesele de aplicare delta Databricks. Mărirea acestei valori scade frecvența cu care modificările sunt aplicate țintei în timp ce crește dimensiunea loturilor, creând în esență loturi mai mari în detrimentul unei latențe suplimentare. Se recomandă să începeți cu o valoare de 60 și să creșteți și mai mult dacă este acceptabilă o latență suplimentară. În unele cazuri, așteptarea unor loturi mai mari poate îmbunătăți debitul și latența
   • Dar mai puțin de (secunde): Această valoare specifică perioada maximă de așteptare între fiecare aplicare a modificărilor lotului (înainte de declararea unui timeout). Cu alte cuvinte, latența maximă acceptabilă. Valoarea implicită este 30. Această valoare determină perioada maximă de așteptare înainte de a aplica modificările după ce valoarea Mai mult decât (secunde) a fost atinsă. Este recomandat să configurați această valoare la 120 (combinată cu o valoare Mai lung decât 60 și să reglați valoarea și mai mare dacă este acceptabilă o latență mai mare.
   • Forțați aplicarea unui lot atunci când memoria de procesare depășește (MB): această setare specifică cantitatea maximă de memorie de utilizat pentru preprocesare în modul de aplicare optimizat în lot. Valoarea implicită este 500. Pentru dimensiunea maximă a lotului, setați această valoare la cea mai mare cantitate de memorie pe care o puteți aloca Qlik Replicate. Se recomandă să începeți cu o valoare de 2000 și să luați în considerare reglarea mai mare dacă există suficiente resurse pe serverul Qlik Replicate.
   • Aplicați modificări utilizând Îmbinare: aceasta permite sarcinii să utilizeze comenzi SQL MERGE pentru a accelera introducerea în Lakehouse.
5. Separați mesele mari
   • Databricks oferă posibilitatea de a partiționa tabele Delta. Se recomandă să partiționați tabele mari care ar putea constitui un blocaj în procesul de aplicare. Qlik Replicate nu acceptă în prezent configurarea partiționării țintei în cadrul sarcinii. Tabelul Delta țintă ar trebui creat de Qlik Replicate și apoi re-creat cu coloanele de partiție corespunzătoare. Dacă un tabel este definit ca fiind partiționat, este recomandat să setați sarcina pentru a efectua un TRUNCATE pentru încărcări complete.
   • În timp ce partiționarea este un concept simplu, determinarea celei mai bune coloane de partiționare necesită o înțelegere solidă a modului în care datele sunt modificate de aplicație. Nu este recomandat să partiționați cheia primară din cauza problemelor de cardinalitate. Tabelele mari care necesită partiţionare sunt de obicei
     de natură „tranzacțională” – de exemplu, date de vânzări. De obicei, selectarea unei coloane de dată sau adăugarea unei coloane YEAR_MONTH la setul de date țintă din Replicare oferă o metodă bună de partiționare. Mai jos este un exampa impactului partiționării asupra utilizării clusterului și, prin urmare, asupra latenței. În acest example, un tabel de aproximativ 68 de milioane de rânduri sursă / 655 GB de date procesa un volum de lucru CDC de producție. Partiționarea tabelului delta folosind o coloană DATE a obținut o reducere cu 73% a latenței și o reducere mare a consumului de memorie și CPU pe cluster.

Utilizare cluster – Nepartiționat

Anexa I – Crearea conexiunilor

Este foarte recomandat să verificați documentația disponibilă pe help.qlik.com pentru cele mai recente cerințe și configurații acceptate pentru mediul dvs. Databricks
Pentru a crea o conexiune de date în Qlik Replicate la o instanță Databricks, veți avea nevoie de:

1. Nume gazdă server
2. Port
3. Calea HTTP
4. Jeton

Clustere
Informațiile 1, 2 și 3 pot fi extrase din consola Databricks accesând configurația clusterului sau configurația SQL Endpoint, iar în secțiunea Opțiuni avansate veți găsi fila JDBC/ODBC

Databricks SQL Warehouse
Informațiile 1, 2 și 3 pot fi extrase din consola Databricks accesând secțiunea SQL Warehouse din fila „Detalii conexiune”

Pentru a obține un token de acces, trebuie să mergeți la Utilizator
Secțiunea Setări a consolei dvs. Databricks și utilizați butonul Generați un nou token.

Este important să stocați jetonul generat într-un loc sigur, deoarece nu îl puteți recupera din nou după ce închideți acest dialog

Documente/Resurse

Soluții de integrare a datelor Qlik Talend [pdfGhid de utilizare Soluții de integrare a datelor Talend, Soluții de integrare a datelor, Soluții de integrare, Soluții

Referințe

• Manual de utilizare