Récapitulatif des heures de bureau : optimisez les coûts et la latence des requêtes grâce aux transformations SQL et aux cumuls en temps réel

Visitez notre Communauté Rockset pour revoir les heures de bureau précédentes ou pour voir ce qui s’en vient.

Pendant notre Heures de travail Il y a quelques semaines, Tyler et moi avons expliqué ce que sont les transformations SQL et les cumuls en temps réel, remark les appliquer et remark ils affectent les performances de vos requêtes et la taille de stockage de l’index. Ci-dessous, nous couvrirons certains des faits saillants.

Les transformations SQL et les cumuls en temps réel se produisent au second de l’ingestion avant que la assortment Rockset ne soit remplie de données. Voici le diagramme que j’ai fait pendant les heures de bureau de Rockset.

Tyler a démontré remark les performances et le stockage des requêtes sont impactés lorsque vous utilisez des transformations SQL et des cumuls en temps réel avec trois requêtes différentes. Ci-dessous, je décrirai remark nous avons construit la assortment et ce que nous faisons dans les requêtes.

Requête initiale sans transformations SQL ni cumuls appliqués

Dans cette requête, nous construisons un objet de série chronologique qui récupère les tweeters les plus actifs au cours de la dernière journée. Il n’y a pas de transformations ou de cumuls SQL, de sorte que la assortment contient uniquement les données brutes.

-- Preliminary question towards the plain assortment 1day: 12sec
with _data as (
    SELECT
        depend(*) tweets,
        forged(DATE_TRUNC('HOUR',PARSE_TIMESTAMP('%a %h %d %H:%M:%S %z %Y', t.created_at)) as string) as event_date_hour,
        t.person.id,
        arbitrary(t.person.title) title
    FROM
        officehours."twitter-firehose" t trace(access_path=column_scan)
    the place
        t.person.id just isn't null
        and t.person.id just isn't undefined
        and PARSE_TIMESTAMP('%a %h %d %H:%M:%S %z %Y', t.created_at) > CURRENT_TIMESTAMP() - DAYS(1)
    group by
        t.person.id,
        event_date_hour
    order by
        event_date_hour desc
),
_intermediate as (
    choose
        array_agg(event_date_hour) _keys,
        array_agg(tweets) _values,
        id,
        arbitrary(title) title
    from
        _data
    group by
        _data.id
)
choose
    object(_keys, _values) as timeseries,
    id,
    title
from
    _intermediate
    order by size(_keys) desc
restrict 100

Supply: L’essentiel de GitHub

• Sur la ligne 4, nous comptons le whole des tweets
• Sur la ligne 7, nous tirons l’ARBITRAIRE pour t.person.title — vous pouvez en savoir plus sur ARBITRAIRE
• Aux lignes 15 et 16, nous faisons des agrégations sur t.person.id et event_date_hour
• À la ligne 5, nous créons le event_date_hour en faisant un CAST
• Sur la ligne 11-12, nous filtrons ID de l’utilisateur qui n’est pas nul ou indéfini
• Sur la ligne 13, nous recevons les derniers tweeters du dernier jour
• Sur les lignes 14-16, nous faisons un GROUP BY avec t.person.id et event_date_hour
• Aux lignes 20 à 37, nous construisons notre objet de série chronologique
• A la ligne 38 on renvoie les 100 meilleurs tweeters

Cette requête artificielle inefficace a été exécutée sur des données en direct avec un VI moyen et a pris environ 7 secondes pour s’exécuter.

Deuxième requête avec transformation SQL appliquée uniquement

Dans la deuxième requête, nous avons appliqué des transformations SQL lors de la création de la assortment.

SELECT
  *
  , forged(DATE_TRUNC('HOUR', PARSE_TIMESTAMP('%a %h %d %H:%M:%S %z %Y', i.created_at)) as string) as event_date_hour
  , PARSE_TIMESTAMP('%a %h %d %H:%M:%S %z %Y', i.created_at) as _event_time
  , forged(i.id as string) as id
FROM
  _input i
the place
  i.person.id just isn't null
  and that i.person.id just isn't undefined

Supply: L’essentiel de GitHub

• Sur la ligne 3, nous créons un event_date_hour
• A la ligne 4, on crée un event_time
• À la ligne 5, nous créons un identifiant sous forme de chaîne
• Aux lignes 9 et 10, nous sélectionnons person.id qui n’est pas nul ou indéfini

Après avoir appliqué les transformations, notre requête SQL semble plus simplifiée que la requête initiale :

with _data as (
    SELECT
        depend(*) tweets,
        event_date_hour,
        t.person.id,
        arbitrary(t.person.title) title
    FROM
        officehours."twitter-firehose_sqlTransformation" t trace(access_path=column_scan)
    the place
        _event_time > CURRENT_TIMESTAMP() - DAYS(1)
    group by
        t.person.id,
        event_date_hour
    order by
        event_date_hour desc
),
_intermediate as (
    choose
        array_agg(event_date_hour) _keys,
        array_agg(tweets) _values,
        id,
        arbitrary(title) title
    from
        _data
    group by
        _data.id
)
choose
    object(_keys, _values) as timeseries,
    id,
    title
from
    _intermediate
    order by size(_keys) desc
restrict 100

Supply: L’essentiel de GitHub

• Sur la ligne 3, on compte le whole des tweets
• Sur la ligne 6, nous tirons l’ARBITRAIRE pour t.person.title
• A la ligne 10, le filtre est maintenant sur l’horodatage
• Sur les lignes 11-13, nous faisons toujours un GROUP BY avec t.person.id et event_date_hour
• Aux lignes 17 à 34, nous créons toujours notre objet de série chronologique

Fondamentalement, nous avons exclu tout ce que nous avons appliqué lors des transformations SQL dans la requête elle-même. Lorsque nous exécutons la requête, la taille de l’index de stockage ne change pas trop, mais les performances de la requête passent de sept secondes à trois secondes environ. En effectuant des transformations SQL, nous économisons sur le calcul, et cela se voit : la requête s’exécute beaucoup plus rapidement.

Troisième requête avec transformation SQL et cumuls appliqués

Dans la troisième requête, nous avons effectué des transformations SQL et des cumuls lors de la création de la assortment.

SELECT
  depend(*) tweets,
  forged(DATE_TRUNC('HOUR', PARSE_TIMESTAMP('%a %h %d %H:%M:%S %z %Y', i.created_at)) as string) as event_date_hour_str,
  DATE_TRUNC('HOUR', PARSE_TIMESTAMP('%a %h %d %H:%M:%S %z %Y', i.created_at)) as event_date_hour,
  forged(i.person.id as string) id,
  arbitrary(i.person.title) title
FROM
  _input i
the place
  i.person.id just isn't null
  and that i.person.id just isn't undefined
group by
  i.person.id,
  event_date_hour_str,
  event_date_hour

Supply: L’essentiel de GitHub

En plus de ce que nous avons appliqué précédemment pour les transformations SQL, nous appliquons désormais également des cumuls.

• Sur la ligne 2, on compte tous les tweets
• Sur la ligne 6, nous tirons l’ARBITRAIRE
• Aux lignes 12 à 15, nous appliquons le GROUP_BY

Alors maintenant, notre requête SQL finale ressemble à ceci :

with _data as (
    SELECT
        tweets,
        event_date_hour_str,
        event_date_hour,
        id,
        title
    FROM
        officehours."twitter-firehose-rollup" t trace(access_path=column_scan) 
    the place
        t.event_date_hour > CURRENT_TIMESTAMP() - DAYS(1)
    order by
        event_date_hour desc
),
_intermediate as (
    choose
        array_agg(event_date_hour_str) _keys,
        array_agg(tweets) _values,
        id,
        arbitrary(title) title
    from
        _data
    group by
        _data.id
)
choose
    object(_keys, _values) as timeseries,
    id,
    title
from
    _intermediate
order by size(_keys) desc
Restrict 100

Supply: L’essentiel de GitHub

Lorsque nous appliquons les transformations SQL avec les cumuls, notre requête passe de sept secondes à deux secondes. De plus, la taille de notre index de stockage passe désormais de 250 Gio à 11 Gio !

Avantages/Considérations pour les transformations SQL et les cumuls en temps réel

Transformations SQL

Avantages :

• Améliore les performances des requêtes
• Peut supprimer et masquer des champs au second de l’ingestion
• Améliorer le coût de calcul

Considération:

• Besoin de savoir à quoi ressemblent vos données

Cumuls en temps réel

Avantages :

• Améliore les performances des requêtes et la taille de l’index de stockage
• Les données sont mises à jour dans la seconde
• Vous n’avez pas à vous soucier des arrivées en rupture de inventory
• Sémantique exactement une fois
• Améliorer le coût de calcul

Considérations :

• Résolution des données — Vous perdrez la résolution des données brutes. Si vous avez besoin d’une copie des données brutes, créez une autre assortment sans cumuls. Si vous souhaitez éviter le double stockage, vous pouvez définir une politique de rétention lorsque vous créez une assortment.

Les transformations et cumuls basés sur SQL de Rockset vous permettent d’effectuer une transformation de données qui améliore les performances des requêtes et réduit la taille de l’index de stockage. La transformation finale des données est ce qui est conservé dans la assortment Rockset. Il est vital de noter que les cumuls en temps réel s’exécuteront en continu sur les données entrantes. En ce qui concerne les arrivées dans le désordre, Rockset les traitera et mettra à jour les données requises exactement comme si ces événements étaient réellement arrivés dans l’ordre et à l’heure. Enfin, Rockset garantit une sémantique distinctive pour les sources de streaming, comme Kafka et Kinésis.

Vous pouvez voir la rediffusion de Tyler’s Séance sur les heures de bureau sur la communauté Rockset. Si vous avez d’autres questions, veuillez trouver Tyler et Nadine dans le Communauté Rockset.

Contenu intégré : https://youtu.be/dUrHqoVKC34

Ressources:

Fusée est le chief analyse en temps réel plate-forme conçue pour le cloud, fournissant des analyses rapides sur des données en temps réel avec une efficacité surprenante. En savoir plus sur rockset.com.