#Azure et #Snowflake votre PaaS vers la modernisation BI – #1 ingestion des données

Snowflake est la seule solution de Data Warehousing entièrement pensée et conçue pour le cloud :

  • Plus performante qu’un Amazon Redshift ou un Azure SQL Datawarehouse, de performances équivalentes à Google Big Query mais avec un véritable respect de la norme SQL ANSI 2016
  • D’une grande simplicité de gestion ; pas besoin de jouer au plombier et de mettre en œuvre des usines à gaz pour effectuer des opérations de scale up/down, scale in/out, suspend/ resume
  • Permet de manipuler toutes vos données CSV | JSON | AVRO | ORC | PARQUET | XML avec un seul langage : le SQL. Et ce qu’elle que soit la volumétrie et la vélocité des données
  • Cela reste un entrepôt de données et non un moteur OLTP, les bonnes pratiques à adopter sont donc une modélisation en ETOILE| FLOCON | DATAVAULT et d’opter pour des traitement ELT et non ETL pour profiter de l’élasticité de calcul de la plateforme. N.B: pour éviter les goulets d’étranglement des ETL traditionnels, il est aussi possible de faire du Data Engineering At Scale avec Azure Databricks (ce dernier possède un connecteur natif Snowflake), mais cela fera l’objet d’un autre article.

Il y a un de cela un peu plus d’un an, nous (Infeeny) étions en compétition face à GCP et Snowflake chez un client voulant moderniser son DWH on-premises tout en conservant son ETL Talend.

De notre côté, les armes étaient simples : Microsoft Azure + VM IaaS Talend + Azure SQL Db/DW. Nous avons bien lutté jusqu’à être short-listé mais il faut se l’avouer, la solution présentée par Snowflake était bien meilleure. Afin de comprendre les raisons de cet échec, nous avons commencé à nous intéresser de très près à ce service allant même jusqu’à monter un partenariat avec cet éditeur dont nous sommes fiers de porter haut les couleurs.

Suite à un précédent post sur linkedIn présentant très succinctement une architecture de Modern Datawarehousing sur Azure avec Snowflake, voyons comment mettre en place une solution BI de bout en bout avec Snowflake sur Microsoft Azure.

Concentrons nous, dans un premier temps, sur la mise en place d’une solution d’ingestion de données en mode batch.

Le jeu de données utilisé sont les courses des taxis New Yorkais Jaune disponibles en Open Data répondant aux caractéristiques suivantes

  • Volumétrie : environ 1,5 milliards de lignes, 113 fichiers pour env. 237 Go
  • Format CSV non compressé
  • 1 fichier par année/mois de janvier 2009 à juin 2018 accessible en https et respectant la convention de nommage suivante :

https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_<AAAA-MM>.csv

Commençons par créer un compte d’évaluation Snowflake sur Azure, cela ne vous prendra que 5 minutes. Ce compte est gratuit et à une durée de validité de 30 jours. Pour cela rendez-vous sur https://www.snowflake.com

Snowflake n’est présent actuellement que sur 2 régions Azure : East US 2 et West Europe. Il faut être vigilent lors de création de vos ressources Azure de façon à ce qu’elles soient dans la même région que votre compte Snowflake (pour ma part West Europe); cela vous évitera d’avoir des charges d’Egress Azure.

Dans un premier temps, nous allons nous atteler à copier les données sources dans un Blob Storage Account avec Azure Data Factory.

nycltc_adf_copy

Pour effectuer cette opération, il faut :

  • 1 blob storage account
  • 1 data factory (ADF)

Sur le blob storage account je crée le container « snowflake-stage » dans lequel je crée l’arborescence suivante :

  • /nyctlc/manifest : contiendra un fichier de manifest en json me permettant de lister les fichiers à charge
  • /nyctlc/trips : dossier dans lequel seront copiés les fichiers sources et qui servira de stockage externe de staging pour charger les données dans Snowflake

nycltc_sta_folders

La structure du fichier nyctlc_manifest.json est la suivante :

nycltc_manifest_json

Cette structure va permettre de paramétrer et de rendre dynamique la copie en itérant sur toutes les occurrences.

J’upload ce fichier dans le container snowflake-stage/nyctlc/manifest

Passons côté Data Factory. Je commence par créer une Azure Integration Runtime (IR) en spécifiant la région West Europe pour ne pas me retrouver avec des charges d’Egress Azure indésirables.

adf_azure_ir_westeurope

Il est important de savoir qu’en utilisant l’IR par défaut, vous n’êtes pas assuré que le traitement soit effectué dans la même région que celle d’ADF (cf. https://bit.ly/2NSQtJu)

adf_azure_ir_autoresolve

Je dois ensuite créer les différentes connexions (linked services) qui me seront utiles :

  • le linked service « nyctlc_http_linkedservice » de type HTTP : pour extraire les fichiers sources du site fournisseur
  • le linked service « infeenylabsta01_sta_linkedservice » de type blob storage account  : pour lire le contenu du fichier manifest et copier les fichiers csv sources

nycltc_adf_linkedservices.png

Je peux dès à présent créer les jeux de données (datasets) sources et destination et les rattacher à leur connexion respective :

  • dataset source : « nyctlc_aws_dataset »
  • dataset destination : « nyctlc_snowflake_stg_sta_dataset »

L’opération désirée étant une copie binaire variabilisée permettant de spécifier la source de donnée souhaitée (yellow, green, fhv) et le mois, je déclare dans les datasets « nyctlc_aws_dataset »  et « nyctlc_snowflake_stg_sta_dataset » ces 2 paramètres :

adf_nyctlc_datasets_parameters

Une fois les paramètres saisis, il est possible de rendre dynamique chacun des datasets à l’aide d’expression dynamique:

  • pour le dataset source « nyctlc_aws_dataset », c’est l’url relative qui est évaluée dynamiquement par expression

adf_nyctlc_datasets_src

  • pour le dataset destination « nyctlc_snowflake_stg_sta_dataset » c’est le chemin et le nom de fichier qui sont évalué dynamiquement par expression

adf_nyctlc_datasets_dst

Je fais de même pour créer le dataset  sur le fichier de manifest en prenant soin de spécifier le chemin et nom de fichier du manifest, ainsi que les informations relatives au format du fichier. L’objectif étant de pouvoir parser, dans ADF, le contenu du fichier JSON contenant un tableau d’objet de type {« datasource »: »valeur, »month »: »annee-mois »}

adf_nyctlc_datasets_manifest

Le socle de base est là, il ne reste plus qu’à créer le pipeline « Copy NYTLC Trips To Snowflake Stage »  permettant de lire le manifest, de boucler sur chaque occurrence et d’exécuter une copie binaire depuis le dataset « nyctlc_aws_dataset » vers le dataset « nyctlc_snowflake_stg_sta_dataset ».

La première étape est la récupération du fichier manifest via une activité Lookup :

adf_nyctlc_copy_pipeline_lookup

La seconde est la mise en place d’une activité ForEach permettant de boucler sur l’ensemble des items récupérés sur la sortie du Lookup

adf_nyctlc_copy_pipeline_foreach_settings

Dans le Foreach, j’ajoute une activité de copie entre le dataset source « nyctlc_aws_dataset » et le dataset destination « nyctlc_snowflake_stg_sta_dataset ». Pour chacun d’eux, je variabilise les valeurs des paramètres « month » et « datasource » à l’aide de l’objet Item me permettant ainsi de manipuler une occurence du tableau d’objet JSON contenu dans le fichier de manifest

adf_nyctlc_copy_pipeline_foreach_activity

La durée d’exécution du pipeline est d’environ 10 minutes pour copier les 237 Go des 113 fichiers.

Nous verrons dans le prochain article comment copier les données dans Snowflake à partir du Blob Storage Account.

 

 

 

 

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s