Réplication des données dans Snowflake avec Oracle GoldenGate

Réplication des données dans Snowflake avec Oracle GoldenGate


Flux continu, streaming, quasi-temps réel et réplication de données. Ce sont tous des termes utilisés pour identifier le besoin d’une entreprise d’accéder rapidement aux données. C’est une demande courante, surtout si le demandeur sait que la technologie existe pour y arriver. Flocon de neige, l’entrepôt de données conçu pour le cloud, peut se connecter à presque tout pour charger ou décharger des données. Quand je a commencé chez Snowflakej’ai tout de suite pensé à Oracle GoldenGate (OGG) comme moyen de diffuser des données en temps quasi réel d’Oracle vers Snowflake. Il n’y a actuellement aucun connecteur direct construit pour OGG vers Snowflake. Mais, GoldenGate for Big Data peut charger des fichiers dans Amazon S3 et le service d’ingestion continue de Snowflake, Snowpipe, peut récupérer ces fichiers et les aspirer dans la base de données. Tout cela se produit en quelques secondes et c’est ce sur quoi je vais me concentrer dans cet article.

Installer et configurer OGG

Commençons. Maintenant, ce ne sera pas un tutoriel complet sur l’installation et la configuration d’Oracle GoldenGate. Il existe de nombreuses ressources en ligne pour vous aider à passer à travers cette partie. je vais me concentrer sur dois savoir bits pour la configuration et comment tout s’emboîte, sans plonger dans tous les détails sanglants.

Après avoir installé et configuré Oracle GoldenGate pour Oracle (ou toute autre base de données source, d’ailleurs), nous allons configurer un processus d’extraction qui utilise un fichier de paramètres appelé hr.prm. Ceci est configuré pour extraire d’une seule table, rh.employé.

EXTRACT hr
USERIDALIAS ogg
LOGALLSUPCOLS
UPDATERECORDFORMAT COMPACT

EXTTRAIL /gghome/ogg/dirdat/hr

SOURCECATALOG orcl
TABLE hr.employee;

Ensuite, nous devons installer et configurer Oracle GoldenGate pour le Big Data. Étant donné que les processus d’extraction et de réplication s’exécutent sur une seule machine virtuelle, ils doivent être installés dans des répertoires distincts et doivent utiliser une variable d’environnement OGG_HOME unique pour chacun. Pour cet exemple, le processus d’extraction est configuré sous /gghome/ogg et le processus de réplication à /gghome/oggd.

GoldenGate for Big Data peut charger des transactions de réplication de données dans un certain nombre de cibles, y compris HDFS, Amazon S3 et d’autres qui nécessitent qu’un fichier soit écrit dans un certain type de répertoire ou de magasin d’objets. La Gestionnaire d’écriture de fichiers fournit la connexion entre le fichier de trace GoldenGate, essentiellement un journal des transactions au format propriétaire GoldenGate, et le format de sortie cible, tel que CSV, JSON, Parquet, ORC, etc. Lors du chargement dans une cible Big Data, la configuration du réplicat ne nécessite uniquement un fichier de paramètres de réplication, mais également un fichier de configuration de propriétés qui fournit à GoldenGate les types de gestionnaires et les paramètres spécifiques nécessaires pour charger cette cible. Dans ces propriétés de gestionnaire, nous spécifions le gestionnaire d’événements, qui permet au processus de savoir dans quel type d’emplacement cible le fichier sera chargé. Dans ce cas, j’utilise le Gestionnaire d’événements S3ce qui me permet de spécifier un compartiment S3 et des informations d’identification pour l’accès à l’aide de la clé d’accès et de la clé secrète AWS.

Ci-dessous l’intégralité hraws.propriétés fichier utilisé dans mon exemple. Je vais mettre en évidence quelques-unes des propriétés que vous voudrez être sûr de définir correctement.

gg.handlerlist=filewriter
gg.handler.filewriter.type=filewriter
gg.handler.filewriter.fileRollInterval=10s
gg.handler.filewriter.fileNameMappingTemplate=${tableName}_${currentTimestamp}.json
gg.handler.filewriter.pathMappingTemplate=ogg-load
gg.handler.filewriter.stateFileDirectory=ogg-load-state
gg.handler.filewriter.format=json
gg.handler.filewriter.finalizeAction=rename
gg.handler.filewriter.fileRenameMappingTemplate=${tableName}_${currentTimestamp}.json
gg.handler.filewriter.eventHandler=s3
goldengate.userexit.writers=javawriter

gg.eventhandler.s3.type=s3
gg.eventhandler.s3.region=us-west-2
gg.eventhandler.s3.bucketMappingTemplate=meroggload
gg.eventhandler.s3.pathMappingTemplate=${tableName}_${currentTimestamp}
gg.classpath=/gghome/oggd/dirprm/:/home/oracle/aws-java-sdk-
1.11.395/lib/aws-java-sdk-1.11.395.jar:/home/oracle/aws-java-sdk-1.11.395/lib/*:/home/oracle/aws-java-sdk-1.11.395/third-
party/lib/*:/u01/userhome/oracle/aws-java-sdk-1.11.395/third-
party/lib/jackson-annotations-2.6.0.jar
gg.log=log4j
gg.log.level=DEBUG
javawriter.bootoptions=-Xmx512m -Xms32m -
Djava.class.path=.:ggjava/ggjava.jar -
Daws.accessKeyId=my_access_key_id -Daws.secretKey=my_secret_key

Le premier bit important est le format de fichier gg.handler.filewriter.format=json. Nous allons charger les fichiers au format JSON pour me donner un certain nombre d’options sur la façon d’interroger les données une fois qu’elles sont chargées dans Snowflake.

Dans le gestionnaire d’écriture de fichier, spécifiez S3 en tant que gestionnaire d’événements. Nous pouvons ensuite configurer les propriétés du gestionnaire d’événements, telles que le bucketMappingTemplate (nom du compartiment), pathMappingTemplatepathMappingTemplate (modèle de nom de fichier) et le chemin de classe spécifique pour le fichier requis Pilotes du SDK AWS S3. C’est également là que la clé d’accès et la clé secrète AWS sont ajoutées pour permettre à GoldenGate d’accéder au compartiment S3. Assurez-vous que l’utilisateur qui fournit ces informations dispose des autorisations appropriées dans S3, telles que la possibilité de répertorier et de créer des compartiments.

Il y avait quelques des pièges que j’ai rencontré lors de la configuration qui m’a amené à demander l’aide de mon ami Bobby Curtis, chef de produit GoldenGate et un gars formidable. Avec l’aide de l’équipe GoldenGate (merci Tom !), J’ai pu surmonter quelques problèmes de documentation qui m’ont fait m’arracher les cheveux.

Tout d’abord, après les propriétés du gestionnaire de fichiers, cela doit être ajouté goldengate.userexit.writers=javawriter. Selon l’équipe produit OGG, « cela doit être là pour croiser les options de démarrage et les rendre visibles ». Sans cela, le javawriter.bootoptions ne peut pas être lu par le processus. Mais, même lorsque cela a été réglé correctement, j’ai continué à avoir des problèmes. La Documentation affiche les options de démarrage avec des retours durs après chaque ligne.properties bootoptions

Malheureusement, cela ne fonctionne pas. Le paramètre entier doit être sur une seule ligne, avec seulement des espaces entre les deux. Merci encore à l’équipe produit Oracle GoldenGate pour l’aide apportée à la résolution de ces problèmes et à la continuité de mon test. Au moment de la rédaction de cet article, la documentation affiche toujours de manière incorrecte les options javawriter.boot sur plusieurs lignes.

Après avoir configuré le fichier de propriétés, nous pouvons ajouter le réplicat et tout démarrer du côté GoldenGate.

REPLICAT hraws
SETENV(GGS_JAVAUSEREXIT_CONF = 'dirprm/hraws.properties')
getEnv (JAVA_HOME)
SETENV(LD_LIBRARY_PATH = 
'/home/oracle/java/jdk1.8.0_131/jre/lib/amd64/server:/u01/app/oracle/
product/12.2/db_1/lib:/u01/app/oracle/product/12.2/db_1/jdk/jre/lib/
amd64/server/:/gghome/oggd')

TARGETDB LIBFILE libggjava.so SET property=dirprm/hraws.properties

GROUPTRANSOPS 1000
MAP orcl.hr.*, TARGET *.*;

Ingérer des données de streaming avec Snowpipe

Une fois les fichiers chargés dans S3, il est temps pour Snowpipe de passer à l’action et d’ingérer les fichiers dans une table de base de données Snowflake. Il y a une superbe vidéo qui montre le processus de Ingérer automatiquement des données de streaming avec Snowpipemais nous allons quand même passer en revue les détails de configuration ici.

La première étape consiste à créer un objet de scène dans Snowflake qui pointe vers le répertoire S3 où les fichiers produits par GoldenGate atterriront. L’objet stage autorise la commande d’ingestion de données Snowflake, COPIER DANSpour accéder aux données stockées dans le compartiment S3.

--create external stage. pass in aws key / secret as credentials
create or replace stage public.oggstage
url="s3://meroggload/"
credentials = (AWS_KEY_ID = 'AKEYYOUWILLNOTKNOW' 
               AWS_SECRET_KEY = 'THIS34IS8/A8akdjSECRET8/AS8WELL');

Nous pouvons ensuite créer une table qui capturera les données chargées via Snowpipe. Le tableau est simple, avec une colonne de type de données VARIANT pour capturer le JSON. Le type de données VARIANT dans Snowflake peut être interrogé directement sans nécessiter le chargement des données dans une structure plus relationnelle. Comme bonne pratique, nous ajouterons également une colonne TIMESTAMP pour capturer la date et l’heure auxquelles les données ont été chargées par micro-lot dans la table par Snowpipe.

Enfin, nous allons créer l’objet PIPE pour copier les données dans la table Snowflake à partir de l’emplacement de l’étape. Ici, nous pourrions effectuer des transformations de données mineures ou des contrôles de qualité des données, ou même aplatir le JSON dans une structure relationnelle, si nécessaire. Réglage de l’option auto_ingest=vrai permettra à Snowpipe d’écouter les notifications d’événements d’AWS Simple Queue Service (SQS), en lançant le processus d’ingestion chaque fois qu’un événement est détecté.

--create table with variant column to store JSON and timestamp
--to track each micro batch load.
create or replace table public.oggtarget
(
    oggdata variant,
    batch_ts timestamp_ltz(9)

);

--create snowpipe, loading table from stage with auto ingest.
create or replace pipe public.snowpipe auto_ingest=true as
    copy into public.oggtarget

    from (select x.*, current_timestamp()
          from @public.oggstage x)
    file_format = (type="JSON");

Configuration des notifications SQS

Pour configurer les notifications SQS, nous devons d’abord capturer la valeur AWS Amazon Resource Name (ARN) à partir du notification_channel colonne dans les métadonnées de l’étape. Cette valeur identifie le compartiment S3, reliant essentiellement l’objet d’étape Snowflake au compartiment. Exécutez le montrer les scènes ; commande dans Snowflake pour trouver cette valeur.

arn

Dans le compartiment S3, cliquez sur Propriétés, puis sur Événements. Ajoutez une nouvelle notification d’événement, cochez le bouton ObjectCreate (All) pour capturer l’événement pour tous les nouveaux objets ajoutés au bucket, puis saisissez la valeur ARN à partir des métadonnées de l’étape Snowflake. Nous sommes maintenant prêts à démarrer l’extraction et la réplication de GoldenGate et à commencer le chargement continu des données dans Snowflake.

Au fur et à mesure que les transactions sont capturées sur la base de données Oracle source, GoldenGate les extrait dans le fichier de trace source, puis le réplicat récupère ces transactions et les transmet à S3 au format JSON. Enfin, la notification d’événement SQS déclenche Snowpipe pour copier les nouveaux fichiers JSON dans la table Snowflake. Tout cela se produit en quelques secondes, garantissant une réplication continue des transactions de données d’Oracle vers Snowflake.

En fonction de la configuration de l’objet PIPE, chaque transaction est chargée dans la colonne Snowflake VARIANT en tant que JSON, capturant les données de transaction source, l’opération (insertion, mise à jour, suppression), l’horodatage de la transaction, la position de la transaction et d’autres métadonnées. La sortie GoldenGate for Big Data vers S3 en JSON est similaire à l’utilisation de INSÉRER TOUS LES ENREGISTREMENTS paramètre lors de la réplication vers une cible Oracle, en insérant essentiellement toutes les transactions au fur et à mesure qu’elles se sont produites et en conservant un journal des transactions, si vous le souhaitez.

json structure

Maintenant que les données sont dans Snowflake, nous pouvons travailler avec la nature transactionnelle des données selon les besoins en utilisant un processus de mise à jour incrémentielle. Nous enregistrerons les détails de celui-ci pour un autre article. Cependant, l’avantage du type de données VARIANT dans Snowflake est la possibilité de interroger les données directement depuis le format semi-structuré sans aucune transformation. En utilisant la structure JSON comme chemin d’accès à la colonne, il est facile d’aplatir les données dans un format tabulaire. Le type de données de colonne peut même être casté pour garantir que le format de données est correct en sortie.

json output

Conclusion sur la réplication des données

Il existe de nombreux cas d’utilisation différents pour ce type de chargement continu de données dans Snowflake, y compris le stockage de tout l’historique transactionnel dans un lac de donnéeschargement de la source d’un modèle dimensionnel dans le entrepôt de données, ou même répliquer des données pour les maintenir synchronisées pendant la migration vers Snowflake. Tous ces scénarios peuvent tirer parti d’une technologie de réplication de données telle qu’Oracle GoldenGate. J’espère pouvoir prévisualiser quelques autres types d’outils à l’avenir, tels que HVR, DBVisit, Attunity, etc. Ensuite, nous verrons comment utiliser les données chargées en tant que JSON dans les tables Snowflake.

Liens supplémentaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.