How Snowflake has helped customers in the Service Industry
This, our second entry in for the series on approaching things from a vertical perspective, is an obviously gigantic industry to try and cover, so let’s just look at a couple very different use case histories, from two totally different service industry enterprises:
Capital One ~ Financial Services
Capital One is a bank with typical financial business applications like credit application analysis, default rate analysis, fraud detection, risk analysis, digital analytics.
They have more than 10 Lines of Business, each had their own systems. There’s a total of 415 TB of data in 220,000 tables, and a total of 6,000 users, of whom 400 could be concurrently active. Plus they have the security concerns you’d expect from a bank regarding PII and financial data in the public cloud.
The impact of this is that their Lines of Business struggled to provide timely analytics due to workload contention and high user concurrency. The on-prem appliances for these lines of business were expensive, and Capital One had no cost-effective Disaster Recovery strategy.
These requirements led to a decision to move to the cloud and then to use Snowflake as their solution.
With Snowflake, each business group gets its own cluster, right-sized for their workload, with MCWH for concurrency spikes. A single copy of the data, shared by all lines of business, reduces cost and eliminates the latency of data replication and synchronization. Because Snowflake operates in multiple AWS regions, Capital One now has a multi-region DR strategy.
In fact, their plan is to intentionally fail-over on a weekly basis from Region A to Region B to know that their DR is working. And finally, Capital One uses Virtual Private Snowflake, a single-tenant version of our multi-tenant deployments that retains all the benefits of Snowflake as a service in the public cloud.
Deliveroo ~ Food Delivery Services
Deliveroo operates in 12 countries. They deliver food each day and collect transactional data in an OLTP database. At 4am each morning they unload this OLTP data and load it into a DW to prepare it for analytics about client and restaurant activity, routes, etc.
More people order food on Friday, Saturday, and Sunday than the rest of the week. That leads to dual surges in workload on Monday mornings:
• there’s more data to process than any other day of the week
• and there’s more analyst interest in the data than any other day of the week
The impact this had was that the ETL and data preparation always ran slower on Monday mornings. But if it ran too slow or if it failed, the data team would need to lock out some or all of the business users until the processing was complete. Otherwise the queries by the business users would further slow the loading and preparation. Obviously, management would be unhappy they couldn’t see how the weekend went, and analysts were delayed in their planning for the week ahead.
The data team referred to this as “Monday Mayhem”.
Their solution was to be found in Snowflake’s ability to separate the ETL and BI workloads, thereby eliminating the primary cause of contention. The data team scales the ETL cluster to match the Monday data surge, which means they no longer miss their data preparation SLA. And they scale their BI cluster both by T-shirt size – for data surge – and using MCWH – for concurrency surge to make their analysts happy.
No more lockouts, management and analysts were happy! If fact, Deliveroo was able to learn that certain neighborhoods had a lot of orders for cuisines not available in that neighborhood. So Deliveroo created pop-up kitchens in those neighborhoods to host teams from partner restaurants to provide those cuisines locally, thus creating a new source of revenue.