Résumé:
- DataBrain, une société SaaS, utilisait PostgreSQL by way of Amazon RDS pour atterrir et interroger les données consumer entrantes.
- Cependant, PostgreSQL ne pouvait pas évoluer, ingérer rapidement des données sans schéma ou exécuter efficacement des analyses à mesure que les données de DataBrain augmentaient.
- De plus, les données consumer entrantes avaient un schéma dynamique, ce qui rendait difficile et coûteux pour DataBrain de nettoyer les données pour PostgreSQL et d’exécuter des requêtes.
- Rockset a résolu ces problèmes de données, retardant le besoin d’embaucher un ingénieur de données et réduisant les coûts de stockage de DataBrain en déchargeant certaines données sur Amazon S3.
Le système d’exploitation pour les équipes GTM
Les organisations comprennent que leur capacité à rendre leurs shoppers heureux et prospères est directement corrélée à la qualité des informations qu’elles peuvent tirer de chaque consumer. Et ces informations doivent non seulement être pertinentes, mais également exploitables en temps réel. Savoir qu’un consumer est confus aujourd’hui au lieu de demain peut faire la différence entre garder le consumer heureux et garder le consumer, level ultimate. Ce problème est particulièrement aigu pour les équipes dont le travail consiste à interagir de manière proactive avec les shoppers. C’est là que DataBrain intervient.
DataBrain fournit aux équipes de mise sur le marché des informations basées sur les données sur la santé de leurs comptes en exploitant les données shoppers en temps réel. En se connectant à un giant éventail d’outils SaaS existants, puis en analysant les données, le tableau de bord de DataBrain suggest des recommandations aux équipes de compte, et leur permet d’approfondir les données pour découvrir des informations précieuses.
Peut-être que le compte n’a pas adopté de nouvelles fonctionnalités ou qu’il a récemment eu des factors de contact importants avec le assist. Cela met en évidence un risque de désabonnement potentiel. Ou peut-être que le compte a profité de nouvelles fonctionnalités, mettant en évidence une opportunité de vente incitative. DataBrain analyse un giant éventail de factors de données sur le système du consumer et recommande des actions potentielles.
Avec DataBrain, les équipes GTM telles que la réussite consumer, les opérations de vente et même les produits savent remark concentrer leur temps et élaborer leur communication en fonction des données de compte en temps réel. Le PDG et fondateur Rahul Pattamatta décrit DataBrain comme « le système d’exploitation pour les équipes GTM ».
Mais en tant qu’entreprise à croissance rapide dans un espace concurrentiel, DataBrain rencontrait plusieurs défis avec sa pile de données.
Défi 1 : Mettre à l’échelle PostgreSQL pour l’analyse
DataBrain utilisait PostgreSQL by way of Amazon RDS pour atterrir et interroger à la fois les données consumer entrantes et les données internes de l’entreprise. Cela avait du sens lorsque DataBrain n’avait pas de grandes quantités de données ou de requêtes complexes à exécuter. PostgreSQL dans le cloud était également easy à configurer et bien établi en tant que technologie.
Cependant, la clientèle et l’utilisation de DataBrain augmentaient rapidement. Un consumer générait déjà 60 tens of millions de lignes de données. C’est alors que DataBrain a commencé à rencontrer les limites naturelles de PostgreSQL: latence de requête élevée pour tout sort de requête analytique. PostgreSQL n’est tout simplement pas optimisé pour l’analyse. Cela était particulièrement évident à grande échelle.
« Écrire du SQL sur une occasion RDS était tout simplement not possible », a déclaré Pattamatta. « Nos requêtes prenaient trop de temps et notre utility a commencé à expirer. C’était inacceptable pour nos shoppers.
DataBrain a initialement expérimenté Amazon Redshift, plus optimisé pour l’analyse, mais l’a trouvé trop lent pour son cas d’utilisation, les requêtes prenant près de 10 secondes.
Défi 2 : Gérer un schéma en constante évolution sur les données consumer
Un autre problème rencontré par DataBrain était l’ingestion réussie des données consumer semi-structurées dans PostgreSQL.
« Nous devons gérer un schéma dynamique et des personnes définissant un tas de métriques différentes dans leur JSON », a déclaré Pattamatta. « C’était vraiment difficile pour nous de comprendre ce qu’ils nous envoyaient. »
Chaque fois que de nouvelles colonnes ont été ajoutées à JSON, les ingénieurs de DataBrain se sont efforcés d’analyser et d’identifier les modifications apportées au schéma avant de mettre à jour les données. Ce n’était pas sturdy. DataBrain avait besoin d’un moyen plus automatisé pour détecter et gérer les modifications de schéma.
« Je ne voulais pas embaucher un ingénieur de données pour écrire des scripts ETL pour effectuer ces transformations à chaque fois », a déclaré Pattamatta.
Défi 3 : Accélérer le retour sur investissement des shoppers
Enfin, DataBrain avait besoin de booster ses performances.
« Il s’agit d’un espace concurrentiel et pour me démarquer, je voulais m’assurer que notre produit offre l’expérience utilisateur la plus rapide et que nos shoppers vivent le moins de temps potential avant leur second aha sur le marché », a déclaré Pattamatta.
Cela signifiait être en mesure d’indexer automatiquement les données lors de l’ingestion initiale afin que les shoppers puissent obtenir immédiatement et sans effort des informations sur toutes les questions qu’ils se posaient.
« Je veux que notre produit soit aussi libre-service que potential », a déclaré Pattamatta. « J’ai vu d’autres options qui obligeaient les shoppers à passer quarter-hour avec un ingénieur pour mettre en place les intégrations initiales. Je veux que mes shoppers pointent simplement leurs intégrations vers nous et qu’elles fonctionnent en quelques secondes.
Aider DataBrain à évoluer et à accélérer
Pattamatta a entendu parler de Rockset sur un podcast avec le CTO de Rockset et co-fondateur Dhruba Borthakur.
« J’ai d’abord été attiré par Rockset automobile il semblait offrir une resolution élégante à mon problème de schéma », a déclaré Pattamatta. « Le fait qu’il puisse effectuer des analyses rapidement était également vital. »
Pattamatta a été impressionné par la facilité de déploiement de Rockset.
« La nature sans serveur de Rockset a rendu le démarrage incroyablement easy », a-t-il déclaré. « Il ne nous a fallu que quelques jours pour configurer nos pipelines de données dans Rockset et après cela, c’était assez easy. Les docs étaient tremendous.
Resolution 1 : mise à l’échelle à l’aide de l’intégration PostgreSQL de Rockset
DataBrain a profité de la intégration native de Rockset avec PostgreSQL. Les ensembles de données souhaités sont instantanément et automatiquement synchronisés dans Rockset, qui prépare les données pour les requêtes en quelques secondes. Rockset renvoie ensuite les résultats de la requête, même pour les analyses complexes, en quelques millisecondes.
Plus vital encore, Rockset est évolutif horizontalement. Le calcul et le stockage sont complètement découplés dans Rockset, ce qui permet à DataBrain d’optimiser les coûts pour le niveau de performances souhaité. En plus de permettre à DataBrain d’éviter de faire des analyses dans PostgreSQL coûteux, Rockset a également permis à DataBrain de décharger une grande partie de ses données de PostgreSQL dans un lac de données S3, ce qui a permis d’économiser considérablement sur les coûts de stockage. Et avec un connecteur similaire pour S3 (et de nombreuses autres sources), Rockset peut automatiquement rester synchronisé avec les deux bases de données supply en lisant leurs flux de modifications.
Resolution 2 : ingérer des données dynamiques et semi-structurées
Rockset prend en cost l’ingestion sans schéma de données brutes semi-structurées. Le schéma n’a pas besoin d’être connu ou défini à l’avance, et aucun pipeline ETL encombrant n’est requis. Autrement dit, Rockset ne nécessite pas de schéma mais est néanmoins conscient du schéma, associant la flexibilité de l’ingestion sans schéma au second de l’écriture à la possibilité de déduire le schéma au second de la lecture. C’est exactement ce que Databrain recherchait. En adoptant Rockset, DataBrain n’a pas eu besoin d’embaucher un ingénieur de données uniquement pour gérer les scripts ETL.
Resolution 3 : l’indice convergé de Rockset™
DataBrain avait besoin que les données semi-structurées de ses shoppers soient indexées rapidement afin de pouvoir interroger les données immédiatement et montrer immédiatement des informations aux shoppers. Rockset résout ce problème grâce à son Index convergé optimisée pour différents modèles d’accès, y compris les requêtes de valeur clé, de série chronologique, de doc, de recherche et d’agrégation.
Alors que la plupart des bases de données ne sont optimisées que pour certains sorts de données ou de requêtes, Rockset peut renvoyer des résultats de requête très rapides sans connaître à l’avance la forme des données ou le sort de requêtes. Les recherches ponctuelles et les requêtes agrégées peuvent être extrêmement rapides. La latence P99 de Rockset pour les requêtes de filtrage sur des téraoctets de données est de l’ordre de quelques millisecondes.
Cela a donné à DataBrain à la fois la vitesse et la flexibilité nécessaires pour augmenter considérablement les performances de son service, même si sa clientèle s’agrandit.
Rockset offre à DataBrain flexibilité et rapidité
En résumé, DataBrain a pu tirer parti de l’intégration prête à l’emploi de Rockset avec PostgreSQL pour décharger ses expenses de travail analytiques dans le Rockset plus rapide et plus rentable. La fonctionnalité Good Schema de Rockset était également essentielle, permettant à DataBrain d’utiliser des requêtes SQL en temps réel pour extraire des informations significatives à partir de données brutes semi-structurées ingérées sans schéma prédéfini. Enfin, l’index convergé de Rockset permet une faible latence des données et une faible latence des requêtes, donnant à DataBrain la vitesse nécessaire pour garder une longueur d’avance sur ses concurrents.
