在过去十年中，实时报告对于根据最新数据做出决策变得非常重要。客户和产品团队要求报告包含实时数据，以便他们能够做出最新的明智决策。GumGum使用实时数据 (1) 在为我们的活动提供服务时做出快速决策，(2) 实时监控我们的广告行是否存在异常和服务问题，以及 (3) 在 Lambda 架构中补充和验证我们的批处理数据。我们目前使用时间序列数据库Apache Druid来完成此任务。
然而，实时报告伴随着数据工程团队最难管理的基础设施之一。它成本高昂，需要大量维护，并且需要更多的基础设施资源来管理。此外，如果更多数据位于摄取点，则需要构建更多分布式集群。如果您的数据是半结构化的，则更加困难。半结构化数据在存储到数据库以供报告使用之前，需要在流级别进行更多转换。无论您选择哪种系统进行实时报告，都将面临这些挑战，因此该工具的灵活性和可扩展性非常重要。
许多数据仓库都支持实时报告，但满足报告 SLA 只是整体情况的一小部分。数据准确性、成本效益、可扩展性，以及对我们来说最重要的可维护性，似乎都比 5 秒和 15 秒延迟测量之间的差异更重要。
情况
GumGum 8 年来一直使用 Apache Druid 作为主要的实时和历史数据存储。我们自行管理集群——运行数百个节点，以复制因子 2 为数百 TB 提供服务，并处理 10 多个传入的流作业。表现非常好！用户很乐意根据该数据构建报告并做出决策来服务于我们的业务功能。
但是，管理这个报告系统变得困难。当我们开始收到更多功能丰富的报告请求时，我们需要连接到新的数据集和临时查询请求——这两者都很难在 Druid 中适应。此外，随着我们的数据量不断扩大，保持集群正常运行的压力一直存在。即使使用用离线批处理数据替换流数据的 Lambda 架构，我们仍然面临如下所述的几个问题。虽然技术 SLA 仍然是实时的——但功能开发或维护的速度并不快。
我们每周看到的常见问题：
- 需要手动更新对源和目标的架构更改。
- 当一个历史节点被 AWS 销毁时，所有正在进行的查询和子查询都将失败。代理将继续路由到被破坏的节点，直到Zookeeper拾取更改。
- 中间管理器在不处理线程和内核的情况下给出 OOM 错误。它会导致实时数据丢失。
- 某些查询在历史节点的JVM进程中抛出OutOfMemoryError，需要重启节点。
- 尽管 Druid 是一个大规模并行查询系统，但单个查询最终可能会在数百个历史节点上进行处理；它在查询执行路径上完全没有任何容错能力。
- Druid 组件之间的网络故障。
- 当代理向历史发送子查询时，它需要所有这些子查询都成功完成，然后才能将任何内容返回给客户端。如果任何子查询失败，则整个查询失败。
Druid 是一个很棒的工具——但具有许多移动部件的复杂架构使其成为管理或自动化的一项艰巨任务。我们一直在寻找一种完全托管的解决方案，以便在我们快速扩展业务和数据集量时为我们提供近乎零的维护。
任务
作为 Lambda 架构的一部分，我们已经将Snowflake用于我们的批处理数据集（我们之前使用的是 Redshift——在此处阅读更多关于我们从 Redshift 到 Snowflake 的旅程）。在寻找我们的实时替代品时，我们发现 Snowflake 的Snowpipe技术可能再次成为一个不错的选择，并将为所有数据生成一个统一的数据仓库。拥有一个数据报告源可以更轻松地构建通用工具集。它使基于单个数据库上实时和批处理数据的可用性为 BI 开发人员创建报告变得简单明了。最重要的是，拥有一个单一的数据仓库工具可以让工程师轻松地自动化和维护我们的数据架构。
Snowpipe 是一种数据摄取服务，可将实时数据加载到 Snowflake 表中。如果您在 S3 中有新数据，它将在数据到达 S3 存储桶时运行复制语句。
在 GumGum，我们有 Spark 流作业在 Databricks 上运行，这些作业使用来自 Kafka 的不同数据结构的数据。我们可以在小批量期间将该输出数据汇入 S3。然后 Snowpipe 将进入画面以将该数据加载到表中。这些数据将准备好从 Snowflake 进行报告。
我们的工程任务是开始将 Spark Streaming 输出数据下沉到 S3（而不是将数据下沉到 Druid Tranquility 节点——也就是中间管理器）。为了将 S3 数据推送到 Snowflake，我们创建了一个匹配输出数据的表、 [url=https://docs.snowflake.com/en/user-guide/data-load-snowpipe-intro.html]Snowpipe[/url]定义、具有 S3 存储桶路径的阶段和文件格式。
详细点击标题
结论/结果
我们现在有十多个 Snowpipes 以自动摄取方式运行，每天存储 TB 的数据。移除德鲁伊是 GumGum 一个时代的终结。简单的架构和低维护有助于工程团队扩展以满足业务需求。它还使我们的整体数据更容易被新工程师理解和采用。我们已经实现了简化实时架构的目标。在 Druid 中，我们有很多基础设施组件，现在我们有简单的 Snowpipe DDL 语句。在自动维护 Snowflake 实时系统方面，我们还有很长的路要走，但我们有一个简单且可扩展的数据平台可以做到这一点。
关闭我们所有的 Druid 集群节省了大量成本和维护时间。我们将摄取成本降低了 10 倍。此外，我们过去每周进行一次维护，而在过去 6 个月中，我们只需要执行一次维护（由于意外的架构更改）。在迁移中，我们失去了 Druid 以低延迟聚合时间序列数据的主要特性。但对我们来说，Snowpipe 的性能非常出色，仍然可以让我们实时为业务做出决策。