Bonjour Will, merci pour ta video, elle est vraiment concise neanmois j'ai quelques questions. 1-- Puisque tu utilises S3 comme source de stockage, n'est-il pas adequat de construire un data lake avec pour stockage S3 ?? je pense à un combo AWS Lake Formation + S3 ou alors AWS EMR + (Spark + Flink + Trino) + iceberg. Qu'en penses-tu ?? 2-- Comment transmets tu les données de S3 vers Snowflake ? (à l'aide de kafka) ? 3-- N'est-il pas interessant de diposé d'une BD analytics et orienté colonne telle que Druid ?? 4-- Data quality -- as-tu eu à tester great expectations ?? 5 -- N'aurait-il pas de place pour du sematic layer dans cette architecture ?? Donnes moi ton avis sur ces diffents points stp
Hello Willis je ne peux pas te répondre pour DBT de mon côté je gère la partie transformation avec Semarchy xdi et quant à ta question concernant sa capacités à gérer de fortes volumétrie cela dépend totalement de la capacités mémoires du runtime et de la performance du SGBD. Donc par exemple si tu es sur un linux on premises bases Postgres tu vas avoir de gros soucis par rapport à un runtime déployé sur GCP qui attaque une base bigquery, mais la contrepartie sera alors le coup de requetage sur bigquery.
Bonne vidéo. De mon côté, j'aurais plutôt utilisé Scala et le framework Spark pour la partie transformation "technique" réalisée par des Data Engineers, et dbt pour les transformations impliquant une logique métier par les Analytics Engineers/Data Analysts. Cela rajoute une couche, mais permet de mieux répartir la charge et scinder les périmètres. Et pour la partie liée à la qualité de données, tu peux effectivement utiliser Great Expectations et/ou la librarie dbt-expectations qui évite de rédiger des macros custom 😉 Il faudrait aussi que je creuse les outils OS de dashboarding (evidence, Rill...) car Tableau coûte une blinde 😂
Merci beaucoup! J’adore vraiment le format. Juste curieux, pour la partir data Storage, pourquoi stores-tu les données en tant que flat files, au lieu de choisir une base de donnée e.g. sql server ?
Je me permets de donner mon avis. S3 est probablement meilleur pour les raisons suivantes: permet de garder les donnes brutes au contraire d une BDD(schema on write), on parle d injecter 80TB par jour donc SQL server n est pas adapte pour ce type de scenario ( c est d ailleurs pour ca il choisit Snowflake entre autre)
Toujours concis et précis dans tes explications, un grand big up à toi 😉😉.Une question pourrais-tu nous faire une prez sur les BD Vectorielles et les cas d'usages? merci d'avance
Merci bcp Willis , je comprends mieux l'architecture data. Quel est l'intérêt de faire une présentation à partir des données récupérées dans snowflake, vu que la transformation se fait avec dbt? Merci.
Par présentation il veut dire visualisation. Une fois les données nettoyé, il faut les présenter sous formes de graphiques afin d’aider à la prise de décision
@DataFromScratchWillis ah OK à ce stade même si le données sont brut c'est pas grave puisque c'est après que l'on peut faire la transformation. Merci 👌💪
Bonjour Will, merci pour ta video, elle est vraiment concise neanmois j'ai quelques questions.
1-- Puisque tu utilises S3 comme source de stockage, n'est-il pas adequat de construire un data lake avec pour stockage S3 ?? je pense à un combo AWS Lake Formation + S3 ou alors AWS EMR + (Spark + Flink + Trino) + iceberg. Qu'en penses-tu ??
2-- Comment transmets tu les données de S3 vers Snowflake ? (à l'aide de kafka) ?
3-- N'est-il pas interessant de diposé d'une BD analytics et orienté colonne telle que Druid ??
4-- Data quality -- as-tu eu à tester great expectations ??
5 -- N'aurait-il pas de place pour du sematic layer dans cette architecture ??
Donnes moi ton avis sur ces diffents points stp
Hello Willis je ne peux pas te répondre pour DBT de mon côté je gère la partie transformation avec Semarchy xdi et quant à ta question concernant sa capacités à gérer de fortes volumétrie cela dépend totalement de la capacités mémoires du runtime et de la performance du SGBD. Donc par exemple si tu es sur un linux on premises bases Postgres tu vas avoir de gros soucis par rapport à un runtime déployé sur GCP qui attaque une base bigquery, mais la contrepartie sera alors le coup de requetage sur bigquery.
Bonne vidéo. De mon côté, j'aurais plutôt utilisé Scala et le framework Spark pour la partie transformation "technique" réalisée par des Data Engineers, et dbt pour les transformations impliquant une logique métier par les Analytics Engineers/Data Analysts. Cela rajoute une couche, mais permet de mieux répartir la charge et scinder les périmètres.
Et pour la partie liée à la qualité de données, tu peux effectivement utiliser Great Expectations et/ou la librarie dbt-expectations qui évite de rédiger des macros custom 😉 Il faudrait aussi que je creuse les outils OS de dashboarding (evidence, Rill...) car Tableau coûte une blinde 😂
C'est un banger cette vidéo, MERCI !
Merci beaucoup Willis ❤😊
T'es le meilleur. Thks !
Par contre je rajouterai trino en dessus de dbt pour interagir avec s3 ^^ à moins que dans ton airflow tu fais un COPY STAGE de s3 vers snowflake
Super intéressant, merci pour cet exercice
Merci à toi
niveau data transformation on peut utiliser databricks aussi pour les gros volumes de donnée c'est nickel
Merci beaucoup! J’adore vraiment le format. Juste curieux, pour la partir data Storage, pourquoi stores-tu les données en tant que flat files, au lieu de choisir une base de donnée e.g. sql server ?
Je me permets de donner mon avis. S3 est probablement meilleur pour les raisons suivantes: permet de garder les donnes brutes au contraire d une BDD(schema on write), on parle d injecter 80TB par jour donc SQL server n est pas adapte pour ce type de scenario ( c est d ailleurs pour ca il choisit Snowflake entre autre)
Cette vidéo est géniale !
Infiniment Merci pour la Video
Super vidéo Willis est ce que tu aurais des ressources pour les entretiens de System Design mais pour ML Engineer
Super 👍
super intéressant mais comment avoir cette culture business ?
Toujours concis et précis dans tes explications, un grand big up à toi 😉😉.Une question pourrais-tu nous faire une prez sur les BD Vectorielles et les cas d'usages? merci d'avance
Merci pour le commentaire ! C'est noté !
Merci bcp Willis , je comprends mieux l'architecture data.
Quel est l'intérêt de faire une présentation à partir des données récupérées dans snowflake, vu que la transformation se fait avec dbt?
Merci.
Par présentation il veut dire visualisation.
Une fois les données nettoyé, il faut les présenter sous formes de graphiques afin d’aider à la prise de décision
Du coup les données dans S3 vont être importées dans snowflake et c’est la qu’on utilisera dbt non?
Oui, dbt servira à gérer la partie Transformation de l'ELT
Pourquoi pas spark au lieu de dbt?
Ça rajouterait un layer en plus.
Vaut mieux utiliser la puissance du data warehouse pour faire les transformations
Par contre je rajouterai trino en dessus de dbt pour interagir avec s3 ^^ à moins que dans ton airflow tu fais un COPY STAGE de s3 vers snowflake
J’ai exactement la même question. On peut même les utiliser ensemble mais ils semblent presque inévitables d’utiliser du « compute distributed »
@@ruddynzita1540 le data warehouse est déjà un “compute distributed”
Mais si tu utilises Kafka pour l’ingestion, tu risques de stocker des données sales dans Snowflake, non ?
Oui, tu stockes les données sur du S3 ou/et Snowflake pour la transformation
@DataFromScratchWillis ah OK à ce stade même si le données sont brut c'est pas grave puisque c'est après que l'on peut faire la transformation. Merci 👌💪