Prise en charge de JSON dans Snowflake | Billet de blog flocon de neige

Prise en charge de JSON dans Snowflake | Billet de blog flocon de neige


J’espère que vous avez eu la chance de lire nos précédents 10 meilleurs articles. Comme promis, nous continuons la série avec une plongée plus profonde dans une autre des 10 fonctionnalités les plus intéressantes de Snowflake : la prise en charge de JSON.

#6 Prise en charge de JSON avec Snowflake

L’une des choses qui a attiré les gens à #Strata Hadoop excité cette semaine était notre soutien pour JSON support et d’autres types de données semi-structurées. Pour les utilisateurs d’entrepôts de données traditionnels, le monde du Big Data peut être difficile. Nous sommes habitués à utiliser SQL pour interroger les données, à avoir un modèle de données bien défini et à savoir à quoi ressemblent les schémas source et cible. Nous avions besoin d’un moyen plus simple de gérer facilement les schémas flexibles qui accompagnent l’utilisation de données semi-structurées comme les documents JSON. Même s’ils essaient, les systèmes d’entrepôt de données hérités ne fournissent pas une prise en charge étendue des données JSON, et les systèmes de Big Data nécessitent l’apprentissage de nouvelles compétences de programmation étendues.

Lorsque nos fondateurs sont partis de zéro pour créer un entrepôt de données pour le cloud, ils voulaient une solution capable de combiner toutes vos données en un seul endroit sans avoir à recourir à plusieurs plates-formes ou paradigmes de programmation. Par conséquent, combiner structuré et semi-structuré en un seul endroit et le rendre disponible via le standard ANSI SQL est une caractéristique forte du service Snowflake et largement utilisé par nos clients.



Snowflake a été conçu avec des fonctionnalités pour simplifier l’accès aux données JSON et offrir la possibilité de les combiner avec des données structurées ! Avec Snowflake, vous pouvez apprendre à interroger des données JSON à l’aide de SQL et à les joindre facilement à des données tabulaires traditionnelles dans des tables relationnelles. Notre approche innovante permet à l’utilisateur de stocker les documents JSON dans une table relationnelle en utilisant un nouveau type de données (VARIANT) optimisé automatiquement en arrière-plan pour le MPP et l’accès en colonne.

C’est un excellent moyen d’éliminer le fossé entre le monde du big data et le monde relationnel et de simplifier l’accès pour les utilisateurs. La plupart des bases de données héritées (avec leur base de code héritée) ne peuvent pas le faire efficacement. Certains fournisseurs d’entrepôts de données hérités ne prennent pas du tout en charge les données JSON, et vous devrez peut-être acquérir et gérer un système de Big Data distinct. D’autres peuvent nécessiter une sorte de prétraitement des données telles que la conversion en données de type CSV simplifiées. Cela peut faciliter l’intégration des données, mais nécessite du temps et des ressources. Et cela limite également la capacité à intégrer facilement les changements potentiels qui accompagnent un type de données de schéma flexible dans le modèle de données relationnel. De plus, les données JSON peuvent être stockées dans un champ de texte, plutôt que dans un type de données optimisé, ce qui a un coût en termes de vitesse d’exécution des requêtes et de stockage des données.

Snowflake rend les données semi-structurées disponibles au sein du service d’entrepôt de données de manière transparente. Les données peuvent être ingérées directement dans une table dans Snowflake et peuvent ensuite être interrogées facilement. Et toute modification du schéma du JSON entrant est automatiquement prise en compte sans impact sur les requêtes existantes.

Exemple de code

Dans ce scénario, nous allons utiliser les extensions Snowflake SQL pour interroger des données semi-structurées, et notre type de données innovant (VARIANT) pour joindre des données à d’autres tables purement relationnelles. Nous allons combiner les données Twitter (données JSON) avec les données produit dans des tables relationnelles.

La table principale qui stocke les données Twitter JSON, twitter.data.tweetscomporte deux colonnes : tweeter et créé à. La colonne Tweeter est défini comme un UNE VARIANTE tapez et détient le JSON à partir d’un flux Twitter, tandis que créé à est une colonne relationnelle avec un type de données TIMESTAMP_NTZ (NTZ = pas de fuseau horaire).

Tableau des tweets

Voici un exemple montrant une requête SQL assez simple avec les extensions JSON. Dans cette requête, nous joignons certaines données Twitter à des données produit dans des tables relationnelles afin d’obtenir le nombre de Tweets contenant des hashtags liés à un produit particulier :

select extract('day',created_at) janday,count(*) cnt
  from
    twitter.data.tweets t,

     -- unnest a tweet on the hashtags of each entities
     lateral flatten (input=> t.tweet,'entities.hashtags')tags,
     (select distinct ph_hashtag
        from 
          sales.public.producthashtags,
          sales.public.product
        where p_name="Blue Sky"
        and   p_productkey = ph_productkey) p

     where tags.value:text::string = p.ph_hashtag
     and   created_at >= '2014-01-01 00:00:00'
     and   created_at >= '2014-02-01 00:00:00'

    group by 1
    order by 1

La section suivante du code fait pivoter les éléments de la chaîne JSON dans un ensemble de lignes afin que nous puissions effectuer des jointures traditionnelles :

     -- unnest a tweet on the hashtags of each entities
     lateral flatten (input=> t.tweet,'entities.hashtags')tags,

Plus précisément, il extrait un tableau imbriqué de hastags dans le entités élément. Ensuite, le prédicat est l’endroit où nous joignons ces valeurs de hashtag dans la chaîne Tweet à la colonne de hashtag dans la table Product (alias « p ») :

     where tags.value:text::string = p.ph_hashtag

Dans ce cas « Mots clés” est égal à l’alias de table virtuelle créé par la fonction FLATTEN et au mot-clé “évaluer” indique que nous voulons le contenu de cette ligne. Le reste de la spécification indique que ce sont des données textuelles que nous voulons convertir en STRING afin qu’elles correspondent au type de données de la colonne p.ph_hastag.

Ensuite, la dernière partie du prédicat est un filtre normal pour une plage de dates utilisant la colonne de date dans le TWEETS table:

     and   created_at >= '2014-01-01 00:00:00'
     and   created_at >= '2014-02-01 00:00:00'

Et voilà, en utilisant SQL pour combiner des données semi-structurées avec des données structurées traditionnelles dans un entrepôt de données relationnelles dans le cloud. Aucun système Big Data requis.

Pas mal!

Mais ce n’est qu’un aperçu de la façon dont vous pouvez utiliser Snowflake pour tirer facilement parti de vos données JSON. Il y a bien plus que ce que nous pouvons couvrir dans un simple article de blog (comme la création de vues relationnelles sur le JSON par exemple).

Voulez-vous en savoir plus? Demandez-nous une démo ou Découvrez le présentation de Grega Kaspret (@gregakespret) de Celtra Mobile à Strata Hadoop World (San Jose) cette semaine, parlant de la simplification d’un pipeline de données JSON à l’aide de Snowflake. Et suivez nos fils Twitter : (@SnowflakeDB), (@kentgraziano), et (@cloudsommelier) pour plus de Top 10 des choses cool à propos de Snowflake et des mises à jour sur toute l’action chez Snowflake Computing.

Kent Graziano et Saqib Mustafa

Liens supplémentaires

Laisser un commentaire

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