Ga naar hoofdinhoud Ga naar aanvullende inhoud

Qlik Open Lakehouse-architectuur.

Qlik Open Lakehouse biedt een volledig beheerde, end-to-end oplossing in Qlik Talend Cloud voor het opnemen, verwerken en optimaliseren van gegevens in een Iceberg-gebaseerd lakehouse. Deze oplossing levert queryprestaties met lage latentie en efficiënte gegevensbewerkingen op schaal.

De Qlik Open Lakehouse-architectuur combineert veilige communicatie, schaalbare rekenkracht en efficiënte gegevensverwerking om een moderne lakehouse-ervaring te leveren. Qlik Open Lakehouse maakt gebruik van AWS-native componenten, waaronder EC2, S3 en Kinesis.

Belangrijkste componenten

De volgende entiteiten zijn vereist om een Qlik Open Lakehouse te maken.

Data Movement gateway (CDC)

De Data Movement Gateway draait in uw on-premises of cloudomgeving. Deze legt wijzigingen vast van bronsystemen, zoals RDBMS, SAP of mainframes, en stuurt de gegevens naar een Amazon S3-tussenopslag.

Netwerkintegratie-agent (EC2-exemplaar)

De netwerkintegratie-agent is een EC2-exemplaar dat veilige communicatie mogelijk maakt tussen Qlik-services in de cloud en lakehouse-clusters binnen uw omgeving. De agent wordt automatisch geïmplementeerd als een On-Demand Instance tijdens het netwerkintegratieproces en volledig beheerd door Qlik. Nieuwe versies worden automatisch geïmplementeerd bij de release.

Als de netwerkintegratie correct functioneert, wordt de status Verbonden weergegeven in de weergave Lakehouse-clusters in het Beheer-activiteitencentrum. De status verandert in Verbinding verbroken als er verbindingsproblemen optreden.

Lakehouse-cluster (EC2 Auto-Scaling-groep)

Het lakehouse-cluster is een groep AWS EC2-exemplaren die verantwoordelijk zijn voor gegevensverwerking. De clusterexemplaren coördineren en voeren de werklasten uit om inkomende gegevens van de tussenopslag te verwerken en slaan de gegevens na verwerking in de Iceberg-indeling op de doellocatie op.

Een lakehouse-cluster met een enkele AWS Spot Instance wordt automatisch aangemaakt tijdens het instellen van uw netwerkintegratie. U kunt extra clusters beheren en aanmaken om aan uw voortdurende behoeften aan lakehouses te voldoen. Wanneer u een cluster configureert, geeft u Qlik toestemming om servers aan te maken, te starten, stoppen, schalen of vervangen om aan de vereisten voor gegevensverwerking te voldoen. Elk cluster wordt gekoppeld met een enkele netwerkintegratie, hoewel meerdere clusters binnen dezelfde netwerkintegratie kunnen draaien. Een enkel cluster kan vele lakehouse-taken uitvoeren.

Een AWS Spot Instance gebruikt reserve Amazon EC2-capaciteit tegen lagere kosten dan gewone exemplaren, maar kan op korte termijn door AWS worden onderbroken. Qlik stelt standaard tijdelijke Spot Instances beschikbaar voor gegevensverwerking. Als er onvoldoende Spot Instances beschikbaar zijn in de AWS Spot market, gebruikt Qlik automatisch On-Demand Instances om de continuïteit te waarborgen. Het systeem keert terug naar Spot Instances wanneer deze beschikbaar worden. De lakehouse-clustertechnologie is ontworpen om soepel over te schakelen tussen Spot- en On-Demand Instances, waarbij taken tussen knooppunten worden verplaatst. Dit proces verloopt automatisch, zonder handmatige tussenkomst. In de clusterinstellingen kunt u configureren hoeveel Spot- en On-Demand Instances in de cluster gebruikt moeten worden. Door Spot Instances te gebruiken, kunt u de lopende kosten voor rekenkracht van uw Qlik Open Lakehouse verlagen.

Naast het definiëren van het aantal Spot en On-Demand Instances die u wilt gebruiken, kunt u een schaalstrategie configureren die het beste past bij de werklast en het budget van uw project. De volgende schaalstrategieën kunnen op een cluster worden toegepast:

  • Lage kosten: ideaal voor ontwikkel- of QA-omgevingen en werklasten die niet afhankelijk zijn van nieuwe, realtime gegevens. Qlik streeft ernaar om de kosten zo laag mogelijk te houden, wat resulteert in incidentele perioden van hoge latentie.

  • Lage latentie: ontworpen voor werklasten die niet kritisch zijn voor uw bedrijfsmissie waarbij de actualiteit van gegevens in bijna realtime acceptabel is. Hoewel deze strategie gericht is op een lage latentie, kunnen er korte pieken optreden.

  • Consistente lage latentie: geschikt voor productieomgevingen met gegevens op grote schaal die behoefte hebben aan realtime actualiteit van gegevens. Qlik schaalt de exemplaren proactief om een lage latentie te garanderen, wat hogere kosten met zich mee kan brengen.

  • Niet schalen: een goede optie voor werklasten die een consistent volume aan gegevens verwerken. Selecteer deze keuze om een statisch aantal exemplaren te behouden zonder automatische schaling en voorspelbare kosten.

Kinesis-stream (coördinatie van de werkbelasting)

Qlik heeft een Kinesis-stream nodig om de status van elke server in het lakehouse-cluster te verzamelen en door te geven. De servers rapporteren de status van taken en operationele statistieken zoals CPU en geheugen rechtstreeks aan Kinesis, aangezien de servers niet met elkaar communiceren. Elke server raadpleegt gegevens van de Kinesis-stream om informatie over de andere servers binnen het cluster te ontdekken. Deze informatie-uitwisseling maakt de synchronisatie van werk mogelijk.

Amazon S3-buckets

Amazon S3-buckets worden als volgt gebruikt:

  • Gegevens tijdelijk opslaan in bucket: ruwe CDC-gegevens worden tijdelijk opgeslagen in een S3-bucket vóór de transformatie.

  • Configuratiebucket: slaat metagegevens en configuraties op die gebruikt worden door het lakehouse-systeem.

  • Opslag in Iceberg-tabellen: gegevens worden opgeslagen en geoptimaliseerd in Iceberg-tabellen.

Flow op hoog niveau

Eerste installatie

  1. Inrichting van VPC en infrastructuur - Configureer een VPC in uw AWS-account samen met subnetten, S3-buckets, Kinesis-streams en IAM-rollen door de instructies in de Qlik-documentatie te volgen.

  2. Netwerkintegratie configuratie - De tenantbeheerder maakt een netwerkintegratie in Qlik Talend Cloud met behulp van eerder ingestelde infrastructuurgegevens.

  3. Implementatie van Qlik-componenten - Qlik implementeert automatisch de data-plane gateway en een lakehouse-cluster binnen uw VPC.

  4. Communicatie tot stand brengen - De data-plane gateway brengt een veilige communicatie tot stand met Qlik Talend Cloud.

  5. Implementatie van gateway - Implementeer een Data Movement Gateway (CDC), hetzij op locatie of in uw cloudomgeving, inclusief de data-plane VPC.

  6. Gebruiksklaar - Na de installatie kunt u Qlik Open Lakehouse-projecten en -taken aanmaken en beheren op basis van hun toegangsrechten.

Een Qlik Open Lakehouse-project maken

De volgende taaktypen zijn beschikbaar:

Tussenopslag-gegevenstaak

  1. Bronconfiguratie - De Data Movement Gateway wordt geconfigureerd om wijzigingen van bronsystemen vast te leggen, inclusief RDBMS, SAP, mainframes en meer.

  2. Tussenopslag van gegevens - De CDC-taak stuurt voortdurend onbewerkte wijzigingsgegevens naar de aangewezen S3-bucket in uw AWS-account.

Opslaggegevenstaak

  1. Registreer een verbinding met een Iceberg-catalogusverbinding, bijv. AWS Glue Data Catalog.

  2. Definieer een opslagtaak in Qlik Talend Cloud.

  3. Qlik Talend Cloud stuurt taakdefinities naar de data-plane gateway.

  4. De data-plane gateway stuurt de taakinstructies veilig door naar het Qlik-lakehouse-cluster.

  5. Het cluster leest continu ruwe gegevens uit een tussenopslagbucket in S3, verwerkt deze en schrijft de uitvoer naar Iceberg-tabellen in S3.

  6. Het lakehouse-cluster schaalt automatisch op of af op basis van belasting, volgens vooraf gedefinieerde voorkeuren in de instellingen van het lakehouse-cluster.

  7. Monitoringgegevens worden verzonden naar Qlik Talend Cloud, en logboekbestanden en statistieken worden doorgestuurd naar Qlik.

Gegevens spiegelen-taak

U kunt externe Iceberg-tabellen maken om gegevens die in uw datalake zijn opgeslagen, vanuit Snowflake op te vragen zonder dat de gegevens gedupliceerd hoeven te worden. Hierdoor kunt u de Snowflake analyse-engine gebruiken bovenop door Iceberg beheerde gegevens die zijn opgeslagen in indelingen zoals Parquet in S3. Door naar externe tabellen te verwijzen in plaats van gegevens naar Snowflake te dupliceren, worden de opslagkosten verlaagd, wordt één bron van waarheid gehandhaafd en wordt consistentie tussen de lakehouse- en warehouse-omgevingen gegarandeerd.

Communicatie tussen uw netwerkintegratie en Qlik Talend Cloud

De netwerkintegratie maakt een uitgaande beveiligde verbinding (HTTPS) met Qlik Talend Cloud. Na een succesvolle acceptatie wordt de verbinding geconverteerd naar een beveiligde websocket (WSS). Er wordt een extra, speciaal communicatiekanaal (WSS) opgezet tussen de netwerkintegratie en Qlik Talend Cloud om lakehouse-specifieke taakopdrachten en besturingselementen te ontvangen. Periodiek brengt de netwerkintegratie een beveiligde verbinding (HTTPS) met Qlik Talend Cloud tot stand om gegevensgerelateerde gebeurtenissen te ontvangen en verzenden. Statistieken en logboeken worden vanaf de lakehouse-clusters naar Qlik gestuurd.

De volgende maatregelen worden genomen om ervoor te zorgen dat uw gegevens veilig zijn:

  • Alle verbindingen van uw netwerkintegratie naar Qlik Talend Cloud zijn uitgaand. Er is geen inkomende toegang nodig.

  • Metagegevens, opdrachten en besturingsverzoeken worden verzonden via communicatiekanalen die beveiligd zijn met HTTPS, waardoor een extra laag van versleuteling ontstaat tussen de netwerkintegratie en Qlik Talend Cloud.

  • Alle gegevensstromen tussen bronnen die uw eigendom zijn. Gegevens worden nooit naar Qlik Talend Cloud verzonden. Metagegevens, zoals namen van tabellen en kolommen, worden bijvoorbeeld naar Qlik Talend Cloud gestuurd om taakdefinities mogelijk te maken.

  • De gegevens worden geanonimiseerd voordat ze naar Qlik worden verzonden. Qlik gebruikt geanonimiseerde gegevens om u proactief te ondersteunen als de logboeken of statistieken op een probleem wijzen.

Was deze pagina nuttig?

Als u problemen ervaart op deze pagina of de inhoud onjuist is – een tikfout, een ontbrekende stap of een technische fout – laat het ons weten!