Dans la première partie de notre série sur la tarification des entrepôts de données cloud , nous avons comparé et résumé les principales variables de calcul et de tarification pour BigQuery, Redshift et Snowflake. Revenez sur ce premier blog de la série pour consulter le tableau comparatif détaillé.
Dans la deuxième partie, nous commençons à examiner des scénarios hypothétiques qui fournissent un guide pour comprendre les opérations de prix. Nous sommes une solution iPaaS agnostique qui relie et orchestre les flux de données entre les applications et les données sur site, les applications SaaS cloud et une variété d'entrepôts de données cloud .
Ce qui suit est une configuration hypothétique, y compris un scénario courant d'informatique à la demande qui peut être utile pour illustrer le fonctionnement des différences de prix de base entre les entrepôts de données cloud . Les prochains blogs couvriront d'autres scénarios de tarification plus avancés.
Scénario hypothétique à la demande - BigQuery vs. Redshift vs. Snowflake Pricing
Plutôt qu'une configuration minimale, qui donnerait lieu à des comparaisons trompeuses, nous avons choisi une configuration hypothétique typique des opérations d'interrogation de données volumineuses à la demande - un cas d'utilisation idéal pour les outils d'interrogation basés sur le site cloud. De nos jours, les entreprises sont inondées de données, même avec des charges de travail de requêtes à la demande ou exploratoires, et il n'est pas rare qu'elles exigent un temps de réponse maximal spécifique pour les grands ensembles de données.
Par conséquent, dans notre scénario hypothétique, nous avons trois requêtes différentes, lourdes en termes de calcul. Chaque requête doit être retournée en 30 secondes (ou moins) et doit analyser un ensemble de données d'un demi-téraoctet (500 Go) pour produire le résultat de la requête. Les données proviennent d'un système d'enregistrement sur site et sont chargées dans l'entrepôt de données cloud via le SnapLogic Snap Pack correspondant - pour BigQuery, Redshift ou Snowflake. Pour ce scénario, les requêtes sont exécutées sporadiquement tout au long d'un mois - ce qui signifie qu'il ne s'agit pas d'un environnement fonctionnant en permanence 24×7, qui sera étudié dans un autre scénario hypothétique.
Pour illustrer les différences de prix, nous supposons que les tailles d'entrepôt de données suivantes cloud sont nécessaires pour atteindre le temps de réponse maximum de 30 secondes requis (on suppose que des configurations plus petites produiraient des résultats plus lents et inacceptables) :
- BigQuery : 2 000 créneaux, à la demande ou avec une tarification flexible
- Redshift : 8 nœuds x dc2.8xlarge ou 5 nœuds de ra3.xlarge, à la demande
- Flocon de neige : Édition standard, taille X-Large, à la demande
Différences de prix
Google BigQuery
Utilisez le Snap BigQuery dans votre pipeline SnapLogic pour déplacer les données vers BigQuery. Une fois sur place, avec la tarification à la demande, le prix d'exécution d'une des requêtes de 30 secondes est de 2,50 $ (0,5 * 1 To * 5 $ par To scanné). Exécutez les requêtes à chaque fois que - en les regroupant par lots ou en les exécutant de manière indépendante. Quoi qu'il en soit, vous paierez toujours 2,50 $ par requête en raison du demi-téraoctet de données analysées par requête.
Avec la tarification flexible de BigQuery, le coût est de 80 $ par heure pour 2 000 créneaux (4 $ par heure pour 100 créneaux * 20). Étant donné qu'une requête de 30 secondes consomme la totalité des 2 000 créneaux, si chaque requête arrive sporadiquement, vous paierez toujours le tarif minimum de 60 secondes, soit 1,34 $ par requête (60 secondes * (80 $ / 3 600 sec./hr.)) pour chaque requête individuelle.
Par conséquent, étant donné le minimum de 60 secondes, vous êtes motivé pour regrouper les requêtes, si possible, et espérer un certain niveau de simultanéité en espérant que le maximum que vous paierez sera de 90 secondes de calcul pour exécuter les trois requêtes à un coût de 2 $ (90 * 80 $ / 3 600 (sec./hr.)).
Notez toutefois que la tarification flexible pour BigQuery est en fait une tarification au comptant, et que la disponibilité des ressources en créneaux n'est pas garantie au moment de votre demande de requête. En outre, le compteur continue de tourner jusqu'à ce que vous annuliez les ressources du slot. Par conséquent, vos coûts de calcul réels peuvent être plus élevés que les estimations de la tarification flexible de BigQuery ci-dessus.
Notez également qu'étant donné que les données proviennent d'une source extérieure, vous devez également payer le stockage Google Cloud , qui s'élève à environ 9,80 $ par mois (500 Go - 10 Go (gratuit))/1 000 Go * 20 $), montant qui peut être réduit au prorata si les données ne sont pas en place pendant un mois entier.
Dans ce scénario informatique, la tarification forfaitaire de BigQuery, qui supprime la dépendance de la quantité de données analysées, peut ne pas être une option pratique en termes de prix car l'activité de requête est sporadique et ne suffit pas à occuper BigQuery pour justifier la tarification forfaitaire de 40 000 $ par mois (20 * 2 000 $ par mois pour 100 créneaux).
Redshift
Grâce aux fonctionnalités relativement nouvelles de pause et de reprise, lorsque vous utilisez Redshift à la demande, vous pouvez désormais mieux contrôler les coûts de Redshift. Utilisez le Redshift Snap Pack dans votre pipeline SnapLogic pour déplacer les données vers Redshift. Ensuite, tant que les trois requêtes sont exécutées par lots ou individuellement dans un délai d'une heure, vous serez en mesure de maintenir les coûts de Redshift à un niveau bas. Sinon, sans pause et reprise, pour les nœuds dc2.8xlarge, vous vous exposez à un coût horaire de 38,40 $ (8 nœuds * 4,80 $ par heure et par nœud) pour les trois requêtes. Ou, avec des nœuds ra3-16xlarge, un coût de 65 $ (5 nœuds * 13,04 $ par heure par nœud).
Le défi dans ce cas, cependant, est que la pause et la reprise de Redshift sont définies manuellement ou sont planifiées. Vous devrez savoir à l'avance quand les requêtes devront être exécutées sur le cluster Redshift. Si l'administrateur de Redshift a le contrôle sur ce point, le timing de la pause et de la reprise peut être étroitement lié au moment où les requêtes doivent être exécutées. Cela permet de limiter les coûts, car il est évident que les coûts cumulés sont inférieurs au taux horaire total. Si l'administrateur ne contrôle pas le timing, les coûts vont exploser à cause du temps d'inactivité lorsque le cluster Redshift est actif, mais qu'il n'exécute pas de requête.
Lorsque le cluster Redshift est mis en pause, vous devez toujours payer le prix du stockage. Pour les nœuds Redshift dc2.8xlarge, qui incluent 2,56 To de stockage en direct, votre coût estimé est de 492 $ par mois pour le stockage (8 nœuds * 2,56 To par nœud * 24 To par mois). Les frais de stockage pour les nœuds Redshift ra3-12xlarge sont calculés différemment. Avec les nœuds ra3, vous ne payez que pour le stockage que vous consommez, soit 12 $ par mois (.5 TB * 24 TB par mois).
Flocon de neige
Utilisez le Snap Snowflake dans votre pipeline SnapLogic pour déplacer les données vers Snowflake. Une fois les données déplacées vers Snowflake, les frais de stockage démarrent immédiatement au tarif à la demande de 40 $ par TB par mois, compressé. La compression typique des données pour Snowflake est supposée être de ~3:1, la compression réelle peut varier. Par conséquent, vos frais de stockage sont estimés à 7 $ par mois (.5 TB / 3 * 40 $ par TB par mois).
Snowflake a l'avantage de permettre la suspension et la reprise automatique, ce qui lui permet de fonctionner comme un moteur de requêtes, de la même manière que BigQuery. Activer la suspension et la reprise automatique au moment de la création d'un entrepôt Snowflake, ou à tout moment après la création via un script SQL.
Lorsque l'entrepôt est inactif, la suspension automatique se déclenche après un certain délai, que vous pouvez sélectionner. S'il est sélectionné dans le menu déroulant de la configuration "Create Warehouse" de Snowflake, le minimum est de cinq minutes. Ce délai peut être encore réduit grâce à des scripts SQL. Par exemple, "AUTO_SUSPEND = 60" (la valeur est toujours exprimée en secondes) réduit le délai à 1 minute. Bien qu'il puisse être tentant de réduire le temps le plus possible pour faire des économies, il faut être conscient des conséquences potentielles sur le fonctionnement de l'entrepôt si le temps de suspension est trop serré lorsque les requêtes arrivent fréquemment et sporadiquement, et que la taille de l'entrepôt de données est importante.
Snowflake impose des frais de calcul minimums d'une minute. Si les trois requêtes hypothétiques sont exécutées simultanément et que les trois requêtes se terminent dans les 30 secondes, vos frais de calcul estimés pour une édition standard de Snowflake à une taille X-Large sont de 0,53 $ (2 $ par heure pour le type Standard * 16 crédits pour la taille X-Large / 60 minutes par heure) + le coût du temps d'attente de la suspension automatique. Si le temps d'attente de la suspension automatique est fixé à deux minutes, le coût du temps d'attente est de 1,07 $ (arrondi). - ce qui donne un coût total de 1,60 $ (0,53 $ + 1,07 $).
Si les trois requêtes hypothétiques sont exécutées de manière séquentielle, le coût total est de 1,87 $ (90 secondes de temps de calcul (0,80 $) + 2 minutes de temps d'attente (1,07 $)).
En particulier pour les opérations à la demande, comme dans l'exemple de Redshift, il est important d'activer les fonctions de suspension automatique et de reprise automatique de Snowflake. Sinon, le compteur tourne alors que l'entrepôt de données est inactif, ce qui vous expose à des coûts plus élevés que nécessaire.
Soyez vigilant lorsque vous travaillez à la demande
Comme l'illustre le scénario hypothétique, Google BigQuery, Amazon Redshift et Snowflake permettent de fonctionner de manière autonome et à faible coût, ce qui est idéal lorsque les requêtes sont légères et sporadiques. Les coûts de calcul comparatifs sont similaires. Le fonctionnement on-off est la clé pour éviter l'emballement des coûts. BigQuery est plus naturel avec le fonctionnement on-off puisqu'il n'exécutera les requêtes que lorsqu'elles sont présentées, tandis que Redshift et Snowflake nécessiteront la mise en place de paramètres.
Dans le prochain article de cette série de blogs, nous examinerons des scénarios de fonctionnement en continu et nous comparerons les prix.
