三个案例告诉你，数仓数据流如何搭建？

译文 精选
作者： 张锋 2022-11-25 10:07:12

云计算

云原生 Confluent尽量多用自身开发的软件来实现内部数据仓库管道的现代化的做法，该使用案例在大多数组织中都是简单和标准的：将Salesforce数据提取、转换和加载（ETL）到Google BigQuery数据仓库中，以便企业可以使用这些数据。

​译者 | 张锋

策划 | 云昭

不同项目都有各自的难点，数据流、分析和其他软件开发都是如此。下面显示了三个案例研究，它们具有显著不同的数据仓库现代化体系结构和技术。这些例子来自不同的垂直行业：软件和云业务，金融服务，物流和运输，以及旅游住宿业。

1、Confluent从使用Stitch的批量ETL到使用Kafka的流式ETL的数据仓库现代化

Confluent尽量多用自身开发的软件来实现内部数据仓库管道的现代化的做法，该使用案例在大多数组织中都是简单和标准的：将Salesforce数据提取、转换和加载（ETL）到Google BigQuery数据仓库中，以便企业可以使用这些数据。但实际上它要比听起来更为复杂。

组织通常依靠第三方ETL工具定期将数据从CRM和其他应用程序加载到其数据仓库中。这些批处理工具在Salesforc中捕获业务事件的时间与这些事件可供使用和处理的时间之间引入了延迟。批处理工作负载通常会导致Salesforce报告和内部仪表板之间出现差异，从而导致对数据完整性和可靠性的担忧。

Confluent一开始使用了Talend的Stitch Batch ETL工具。旧架构是这样的：

批处理ETL和中间的第三方工具

导致信息更新不充分和不一致

在过去几年中，Confluent投资于在内部数据仓库管道中构建流处理功能。Confluent利用其自己的完全托管的Confluent Cloud连接器（在本例中为Salesforce CDC Source和BigQuery Sink连接器）、用于数据治理的Schema Registry和用于可靠流式ETL的KSQLDB+Kafka Streams将SFDC数据发送到BigQuery。这里是现代化的架构：

2、PayPal将每天300亿个事件的读取时间从12小时缩短到几秒钟

PayPal有大量的Kafka项目，用于许多关键和分析工作负载。在此使用案例中，它将Kafka消费者扩展为每天300-350亿个事件，以将其分析工作负载迁移到Google云平台（GCP）。

流应用程序将来自Kafka的事件直接接收到BigQuery。这是PayPal的一个关键项目，因为大多数分析读数都基于此。数据仓库现代化和构建云原生架构的成果是：将读取时间从12小时缩短到几秒钟。

3、Shippeo从本地部署数据库到多个云原生数据湖

Shippeo是一个法国供应链可视化管理平台，致力于为企业提供准确的物流配送预测信息以及实时跟踪信息服务。平台配备有基于机器学习的ETA算法，可以快速分析和提醒运输途中出现的问题，帮助企业有效地应对危机。

Shippeo为物流提供商、托运人和承运商提供实时和多式联运可见性。它的软件使用自动化和人工智能来分享实时洞察，实现更好的协作，并释放您的供应链的全部潜力。该平台可以即时访问每次交付的预测性实时信息。

下图描述了Shippeo如何将传统数据库（MySQL和PostgreSQL）和云原生数据仓库（Snowflake和BigQuery）与Apache Kafka和Debezium集成：

这是云原生企业架构利用“单项优势”方法构建数据仓库和分析的绝佳示例。Kafka将分析工作负载从事务系统中分离出来，并为缓慢的消费者处理背压。

4、Sykes Cottages通过Confluent Cloud、Kafka Connect和Snowflake全面管理端到端管道

Sykes Holiday Cottages是英国领先且发展最快的独立度假别墅租赁机构之一，在英国、爱尔兰和新西兰拥有超过19000间度假别墅。

客户在网络上的体验是重中之重，也是保持竞争力的一种方式。我们的目标是让客户在每个阶段都能获得完美的度假小屋体验和乐趣。让数据管道为这一创新提供动力至关重要。数据仓库现代化和数据流提供了通过数据驱动的方法进一步创新Web体验的新方法。

5、从不一致和缓慢的批处理工作负载

虽然已经使用了几年，但现有的管道出现了一些问题，影响了这个循环。在这个管道的早期，ETL过程将数据转换为行和列（结构化数据）。制作了各种副本，并通过静态报告呈现结果。需要数据工程师来处理变化，如新事件或上下文信息。规模也具有挑战性，因为这主要是手动完成的。

Sykes Holiday Cottages严格地将数据保存在半结构化格式中，直到将其接收到仓库中，然后使用ELT对数据进行一次转换，这样可以简化管道并使其更加灵活。

6、基于事件的实时更新和连续流处理

新的Web事件（以及与之相关的任何上下文）都可以包装在消息中，并且可以一直流到仓库，而不需要进行任何代码更改。然后，Web团队可以通过查询或可视化工具获得新事件。

当前吞吐量约为每分钟50K（峰值超过300K）条消息。随着新事件的捕获，这将大大增加。此外，上述每个组件都必须相应地进行缩放。

新的体系结构使Web团队能够捕获新事件并使用自助服务工具分析数据，而不依赖于数据工程。

总之，这样做的商业案例是令人信服的。根据我们的测试和预测，我们预计这项投资在三年内至少有10倍的投资回报率。

7、DoorDash从多管道到Snowflake集成的数据流

即使是数字原生代，在自己的数据中心没有传统应用程序的情况下在云中开展业务，也需要实现企业架构的现代化，以改进业务流程、降低成本并为其下游应用程序提供实时信息。

构建多条试图实现类似目的的管道是成本效率低下的。DoorDash使用云原生AWS消息传递和流数据处理系统（如Amazon SQS和Amazon Kinesis）将数据接收到Snowflake数据仓库中：

混合不同类型的数据传输并通过多个消息传递/排列系统，而没有仔细设计其周围的可观察性，导致操作困难。

这些问题导致了DoorDash的高数据延迟、巨大的成本和运营开销。因此，DoorDash迁移到由Apache Kafka和Apache Flink提供支持的云原生流平台，以便在将数据接收到Snowflake之前进行连续的流处理：

向数据流平台的迁移为DoorDash带来了许多好处：

• 异构数据源和目的，包括使用Confluent REST代理的REST API
• 易于访问
• 具有Schema约束的端到端数据治理和具有Confluent Schema Registry的Schema演变
• 可扩展，容错，易于小型团队操作

关于这种云原生基础设施优化有很多细节，比如如何使用Kafka和Flink构建可扩展的实时事件处理等等。

8、云原生项目的真实案例研究证明了其商业价值

数据仓库和数据湖现代化，只有在有业务价值的情况下才有意义。Snowflake、Databricks或Google BigQuery等云服务的显著优势是弹性扩展、降低操作复杂性和加快上市时间。

数据流在这些计划中发挥着至关重要的作用，以集成传统和云原生数据源、连续流ETL、数据源之间的真正解耦以及多个数据接收器（数据湖、数据仓库、业务应用程序）。

Confluent、PayPal、Shippeo、Sykes Cottages和DoorDash的案例研究展示了他们迁移到云原生基础架构以提高实时可见性和分析能力的不同成功案例。弹性扩展和全面管理的端到端管道是通过不断更新的信息获取业务价值的关键成功因素。

原文链接：https://dzone.com/articles/case-studies-cloud-native-data-streaming-for-data

译者介绍

张锋，51CTO社区编辑，长期从事技术顾问工作，专注于运维/云原生领域，精通网络疑难故障分析，有很丰富的大型银行运维工具建设实践经验。​