Concepts de Zerobus Ingest
Cette page décrit les concepts fondamentaux de Zerobus Ingest dans Lakeflow Connect : le fonctionnement du service, ses streams, son serveur et ses clients, ainsi que les types de données qu'il prend en charge.
Accéder à un concept :
- Comment fonctionne Zerobus Ingest: le flux de bout en bout, du producteur à la table interrogeable.
- Server: ce dont le service Zerobus Ingest est responsable.
- Client: ce dont votre producteur est responsable.
- Streams: la connexion que votre client ouvre pour ingérer des données.
- Comment Zerobus Ingest évolue: pourquoi il évolue sans planification de capacité.
- Exigences relatives aux tables: ce que votre table cible et votre Workspace doivent satisfaire.
- Limitations: types de tables non pris en charge, opérations sur les tables et tri inter-Stream.
- Types de données pris en charge: le mappage de type Delta-to-Protobuf.
Comment fonctionne Zerobus Ingest
Un producteur de données se connecte d’abord à une API Zerobus Ingest et spécifie une table Delta cible, construit un message correspondant à son schéma, puis envoie le message. Le service rend les données durables et, pour les interfaces qui fournissent des confirmations de durabilité, accuse réception du message du client. Il matérialise ensuite les données dans la table Delta, de manière optimisée, lors d'une étape distincte. Une confirmation de durabilité confirme la durabilité, et non la possibilité d'interrogation. Consultez la section Communication asynchrone pour savoir comment cela fonctionne et ce que cela implique pour votre client.
Zerobus Ingest est un service Serverless qui monte en charge de manière élastique avec votre charge de travail. Pour savoir comment il monte en charge, voir Comment Zerobus Ingest monte en charge ci-dessous.
Cette section couvre également les manières de vous connecter à Zerobus Ingest et les formes que peuvent prendre vos données :
- Protocoles d’API: les protocoles d’API, gRPC avec les SDK, REST, OpenTelemetry, MQTT et les APIs compatibles Kafka, ainsi que les cas d’utilisation de chacun d’eux.
- Types de messages: les formats d'enregistrement, JSON, Protocol Buffers (protobuf) et Apache Arrow, ainsi que les cas d'utilisation de chacun.
Serveur
Le service Zerobus Ingest ne crée ni ne manipule automatiquement les tables. Les utilisateurs doivent créer la table eux-mêmes. Les tables et leurs schémas sont les sources faisant autorité pour les attentes concernant les données entrantes.
Le serveur Zerobus Ingest accepte les données qui lui sont envoyées par les clients et valide qu'elles correspondent au schéma de la table cible. Si l'enregistrement convient, le serveur le rend durable et, lorsque l'interface fournit un accusé de réception de durabilité, il le confirme au client. La matérialisation de l'enregistrement dans la table Delta, de manière à ce qu'elle puisse être interrogée, s'effectue peu après lors d'une étape distincte.
Les responsabilités du service incluent :
- Validation du schéma du message par rapport à la table.
- Rendre l'enregistrement durable et, lorsque l'interface fournit une confirmation de durabilité, l'en informer le client. La confirmation atteste de la durabilité, et non du fait que l'enregistrement peut déjà être interrogé.
- Matérialisation des données dans la table cible en temps opportun, moment à partir duquel elles deviennent interrogeables. Pour les chiffres de latence, consultez Latence.
Client
Un client se connecte à Zerobus Ingest, envoie des enregistrements et, lorsque l'interface le prend en charge, confirme qu'ils sont durables. Lorsque vous utilisez un SDK Zerobus Ingest, celui-ci gère la majeure partie de cette tâche pour vous ; il est donc utile de distinguer ce que vous configurez de ce que le SDK effectue automatiquement.
Vous configurez ou implémentez :
- Sélection d'une table cible.
- Ouverture d'un Stream vers le service Zerobus Ingest.
- Construction d’un message compatible avec le schéma et envoi de celui-ci.
Voici les opérations dont le SDK se charge automatiquement :
- Confirmations de message. Le SDK exécute la boucle de confirmation pour vous et fait remonter les confirmations de durabilité via des offsets ou un callback de confirmation. Vous ne bloquez sur un enregistrement spécifique que lorsque votre application en a besoin. Voir Communication asynchrone.
- Récupération. Par default, le SDK se reconnecte et rejoue les enregistrements non acquittés en cas d’erreurs temporaires.
- Vous pouvez désactiver la récupération intégrée et implémenter votre propre mécanisme de récupération à la place. Pour savoir ce qui Trigger la récupération, les options de configuration et les modèles de récupération personnalisés, consultez Modèles de récupération et de nouvelle tentative.
Vous n'avez pas à écrire manuellement la logique d'accusé de réception ou de récupération lorsque vous utilisez un SDK. Pour les intégrations personnalisées qui n'utilisent pas de SDK, le repository du SDK Zerobus sert de référence pour la structure d'intégration et la gestion de la récupération.
Stream
Un Stream est une connexion directe entre votre client et le serveur Zerobus Ingest, établie via une connexion gRPC persistante et bidirectionnelle. Les SDK utilisent des Stream pour faciliter les connexions longue durée à throughput élevé.
- Les flux (Streams) ne sont utilisés que dans l'API gRPC avec les SDK.
- Un Stream ingère des données vers une table cible unique.
- Ouvrez des streams supplémentaires pour écrire dans différentes tables, ou pour monter en charge le throughput d'un seul client aussi haut que vos charges de travail l'exigent.
Les Stream sont également l'unité de classement (voir Garanties de classement) et l'unité par laquelle Zerobus Ingest monte en charge (voir Comment Zerobus Ingest monte en charge).
Garanties d'ordre
L'ordre est garanti par Stream. Les enregistrements sont validés dans la table cible dans l'ordre où ils sont mis en file d'attente sur un seul Stream. Il n'y a pas d'ordre global entre les différents Streams. Plusieurs points de conception en découlent :
- Si vous répartissez les enregistrements sur plusieurs streams (par exemple, round-robin), il n'y a aucune garantie de classement entre ces streams.
- Si votre cas d’utilisation nécessite un ordre total unique parmi de nombreux producteurs ou Stream, imposez cet ordre dans votre application (par exemple, avec un timestamp ou un numéro de séquence sur lequel vous effectuez une query) plutôt que de vous fier à l’ordre d’ingestion.
Pourquoi le streaming gRPC
Étant donné qu'une connexion gRPC de stream reste ouverte, le client évite le coût de configuration par requête d'un protocole stateless et peut pousser un flux continu et à volume élevé d'enregistrements le long d'un seul canal de distribution. C'est ce qui fait des SDK le moyen d'ingestion offrant le plus haut throughput. Pour les autres interfaces (REST, OpenTelemetry, MQTT et APIs compatibles avec Kafka) et pour savoir quand choisir chacune d'elles, consultez Protocoles d'API.
Comment Zerobus Ingest monte en charge
Zerobus Ingest est conçu pour une haute évolutivité, et il atteint cette échelle sans vous demander de planifier la capacité. Deux choix de conception rendent cela possible :
- C'est du Serverless. Le service ajoute et supprime automatiquement de la capacité en fonction de l'évolution de la charge, vous n'avez donc pas à dimensionner les brokers ni à effectuer le provisionnement des partitions. Vous pouvez ouvrir autant de Streams simultanés et écrire dans autant de tables que votre charge de travail l'exige.
- Les streams sont des unités de partitionnement dynamiques. Plutôt qu’un ensemble fixe de partitions devant être repartitionnées et rééquilibrées pour monter en charge, les streams peuvent être ouverts, fermés et alternés. L’alternance des streams permet au service de rééquilibrer la capacité et les ressources à mesure que la demande évolue ; vous pouvez ainsi monter en charge en ouvrant davantage de streams et en exécutant plus de producteurs, tandis que le service absorbe le reste.
Le résultat pratique est qu’un client « hello world » et une charge de travail à l’échelle du pétaoctet exécutent essentiellement le même code. La différence réside dans le nombre de producteurs et de streams que vous exécutez. Cette conception a permis une ingestion soutenue de plus de 1 000 milliards d’enregistrements dans une table Delta unique. Pour le contexte technique, consultez le billet de blog Ingesting the Milky Way: Petabyte-Scale with Zerobus Ingest.
Exigences relatives aux tables
Zerobus Ingest écrit dans une table Delta que vous créez et possédez. La table cible et le Workspace doivent répondre aux exigences suivantes :
- La table cible doit être une table Delta gérée ou une table de streaming.
- Les noms de table ne peuvent utiliser que des lettres ASCII, des chiffres et des tirets bas.
- Le Workspace et la table cible doivent tous deux se trouver dans l'une des régions prises en charge.
Pour savoir comment les enregistrements sont validés par rapport au schéma de la table, consultez Gestion des schémas. Pour les fonctionnalités de table telles que le partitionnement et le clustering liquide, consultez Fonctionnalités des tables Delta. Pour connaître les types de tables et les opérations non pris en charge, consultez Limitations.
Limitations
Zerobus Ingest présente les limitations suivantes :
- Zerobus Ingest n’écrit pas dans des tables ou des vues externes.
- Zerobus Ingest n'écrit pas dans un stockage sécurisé via un Endpoint.
- Zerobus Ingest ne crée pas de tables cibles et ne modifie pas leur schéma. Vous créez la table et faites évoluer son schéma. Voir Évolution des schémas.
- Zerobus Ingest ne prend pas en charge la recréation d'une table cible.
- Zerobus Ingest doesn't support renaming or replacing a target table while ingestion is active. See Rename or replace a target table.
- Zerobus Ingest ne prend pas en charge les noms de table contenant des caractères autres que des lettres ASCII, des chiffres et des traits de soulignement.
- Zerobus Ingest ne garantit pas l’ordre entre les Stream. L’ordre n’est garanti que dans le cadre d’un seul Stream. Voir Garanties d’ordre.
Pour connaître les limites numériques telles que le throughput, la taille des enregistrements et le fan-out des partitions, consultez la page Quotas de Zerobus Ingest.
Renommer ou remplacer une table cible
Ne renommez pas, ne supprimez pas et ne recréez pas, et ne remplacez pas non plus une table cible par un autre objet, tel qu’une vue, pendant que des Stream y écrivent des données. Zerobus Ingest ne peut pas vider les données mises en mémoire tampon vers une table qui a été renommée ou remplacée. Par conséquent, les flux concernés cessent de progresser et les enregistrements qui ne sont pas encore accusés réception ne peuvent pas être vidés. Les données qui restent non vidées sont supprimées après la période de conservation des données en mémoire tampon.
Les modifications de schéma, telles que l'ajout d'une colonne avec ALTER TABLE, sont prises en charge. See évolution des schémas.
Pour renommer ou migrer une table cible en toute sécurité :
- Arrêtez vos producteurs, puis videz et fermez chaque Stream qui écrit dans la table. Consultez Flushing and graceful close.
- Confirmez que les enregistrements les plus récents apparaissent dans la table.
- Renommez ou migrez la table.
- Accordez au Service Principal qui ingère les données
USE CATALOG,USE SCHEMA,SELECTetMODIFYsur la nouvelle table. Consultez la section Créer un Service Principal et accorder des autorisations. - Mettez à jour vos producteurs pour utiliser le nouveau nom de table, puis ouvrez de nouveaux Stream. Si vos producteurs demandent des jetons OAuth associés à une table, demandez-les pour la nouvelle table.
Types de données pris en charge
Le tableau suivant présente les types Delta pris en charge et leurs types Protobuf correspondants pour l'ingestion.
Types Delta | Types Protobuf |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Texte décimal, par ex. « 123,45 », « 1e2 », etc. |
|
|
|
|
|
|
|
Doit être converti en |
|
Doit être converti en |
|
Doit être converti en |
|
|
|
|
Le sucre syntaxique Protobuf |
|
|
Via les SDK gRPC et REST, ingérez une valeur Variant sous forme de chaîne encodée en JSON avec des clés de type Les formats pris en charge sont les suivants :
|
|