翻译|张峰策划|YunZhao不同的项目都有自己的难点，数据流、分析等软件开发都是一样的。下面显示了三个案例研究，它们具有截然不同的数据仓库现代化架构和技术。这些例子来自不同的垂直行业：软件和云业务、金融服务、物流和运输以及旅游和住宿。1、Confluent使用Stitch的batchETL，使用Kafka的streamingETL实现数据仓库的现代化。Confluent尝试使用自己的软件来实现内部数据仓库管道的现代化。在大多数组织中，此用例简单易行。标准：将Salesforce数据提取、转换和加载(ETL)到GoogleBigQuery数据仓库中，以便业务可以使用数据。但它实际上比听起来更复杂。组织通常依靠第三方ETL工具定期将数据从CRM和其他应用程序加载到他们的数据仓库中。这些批处理工具在Salesforce中捕获业务事件的时间与这些事件可用和处理的时间之间引入了延迟。批处理工作负载通常会导致Salesforce报告和内部仪表板之间出现差异，从而引发对数据完整性和可靠性的担忧。Confluent最初使用的是Talend的StitchBatchETL工具。旧架构是这样的：批处理ETL和中间第三方工具导致信息更新不足和不一致在过去的几年中，Confluent已投资在其内部数据仓库管道中构建流处理功能。Confluent利用自己完全托管的ConfluentCloud连接器（在本例中为SalesforceCDCSource和BigQuerySink连接器）、用于数据治理的SchemaRegistry和用于可靠流式传输ETL的KSQLDB+KafkaStreams将SFDC数据发送到BigQuery。这是现代架构：2.PayPal将每天300亿个事件的读取时间从12小时减少到几秒PayPal拥有大量用于许多关键和分析工作负载的Kafka项目。在此用例中，它将Kafka消费者扩展到每天30-350亿个事件，以将其分析工作负载迁移到GoogleCloudPlatform(GCP)。流式应用程序将事件从Kafka直接接收到BigQuery。这是PayPal的关键项目，因为大多数分析读数都基于它。数据仓库现代化和构建云原生架构的结果：将读取时间从12小时减少到几秒。3.Shippeo将本地数据库部署到多个云原生数据湖。Shippeo是法国供应链可视化管理平台，致力于为企业提供准确的物流配送预测信息和实时跟踪信息服务。平台搭载基于机器学习的ETA算法，可快速分析并提醒运输过程中出现的问题，帮助企业有效应对危机。Shippeo为物流供应商、托运人和承运人提供实时和多式联运的可见性。其软件使用自动化和人工智能来共享实时见解、实现更好的协作并释放供应链的全部潜力。该平台提供对每次交付的预测性实时信息的即时访问。下图描述了Shippeo如何将传统数据库（MySQL和PostgreSQL）和云原生数据仓库（Snowflake和BigQuery）与ApacheKafka和Debezium集成：这是云原生企业架构利用“同类最佳”的绝对必要条件”构建数据仓库和分析的方法。好例子。Kafka将分析工作负载与事务系统分开，并处理慢速消费者的背压。4.SykesCottages通过ConfluentCloud、KafkaConnect和Snowflake全面管理端到端管道SykesHolidayCottages是英国领先且发展最快的独立度假别墅租赁机构之一，在英国、爱尔兰拥有超过19,000间度假别墅和新西兰。网络上的客户体验是重中之重，也是保持竞争力的一种方式。我们的目标是让我们的客户在每个阶段都能拥有完美的度假小屋体验和享受。让数据管道为这项创新提供动力至关重要。数据仓库现代化和数据流提供了通过数据驱动方法进一步创新Web体验的新方法。5.永不不一致和缓慢的批处理工作负载虽然已经使用了几年，但现有的管道存在一些问题，影响了周期。在此管道的早期，ETL过程将数据转换为行和列（结构化数据）。制作了各种副本，并通过静态报告呈现结果。需要数据工程师来处理变化，例如新事件或上下文信息。缩放也具有挑战性，因为这主要是手动完成的。SykesHolidayCottages将数据严格保持半结构化格式，直到接收入库，然后使用ELT对数据进行一次转换，简化了流水线并使其更加灵活。6.基于事件的实时更新和连续流处理新的网络事件（以及与之关联的任何上下文）可以包装在消息中并一路流向仓库，而无需更改任何代码。然后，Web团队可以通过查询或可视化工具使用新事件。当前吞吐量约为每分钟50K（峰值超过300K）条消息。随着捕获新事件，这将显着增加。此外，上述每个组件都必须相应地缩放。新架构使网络团队能够使用自助服务工具捕获新事件并分析数据，而无需依赖数据工程。总而言之，这样做的商业案例很有说服力。根据我们的测试和预测，我们预计这项投资将在三年内获得至少10倍的投资回报率。7.DoorDash的数据流从多管道到Snowflake集成。即使是数字原住民，在他们自己的数据中心没有传统应用程序的情况下在云中开展业务，也需要对其企业架构进行现代化改造，以改进业务流程并降低成本，并为其下游应用程序提供实时信息。构建多个管道试图实现类似的目的是成本低效的。DoorDash使用云原生AWS消息传递和流数据处理系统（例如AmazonSQS和AmazonKinesis）将数据提取到Snowflake数据仓库中：混合不同类型的数据传输并通过多个消息传递/队列系统，而无需仔细设计其周围的可观察性，从而导致操作困难。这些问题导致DoorDash的数据延迟高、成本高和运营开销大。因此，DoorDash迁移到由ApacheKafka和ApacheFlink提供支持的云原生流平台，以便在将数据摄取到Snowflake之前进行连续流处理：迁移到数据流平台为DoorDash带来了许多好处：异构数据源和用途，包括RESTAPI使用ConfluentRESTProxy易于访问通过Schema约束进行端到端数据治理，通过ConfluentSchemaRegistry进行Schema演化可扩展、容错、易于小型团队操作关于这种云原生基础架构优化的细节很多，例如如何使用Kafka和Flink构建可扩展的实时事件处理等等。8.云原生项目的真实案例研究展示了它们的商业价值数据仓库和数据湖现代化只有在具有商业价值的情况下才有意义。Snowflake、Databricks或GoogleBigQuery等云服务的显着优势是弹性扩展、降低运营复杂性和加快上市时间。Dataflow在这些集成传统和云原生数据源、连续流ETL、数据源之间真正解耦以及多个数据接收器（数据湖、数据仓库、业务应用程序）的举措中发挥着至关重要的作用。来自Confluent、PayPal、Shippeo、SykesCottages和DoorDash的案例研究展示了他们在迁移到云原生基础架构以提高实时可见性和分析方面取得的各种成功。弹性扩展和完全托管的端到端管道是从持续更新的信息中获取业务价值的关键成功因素。原文链接：https://dzone.com/articles/case-studies-cloud-native-data-streaming-for-data译者介绍张峰，社区编辑，长期从事技术咨询工作，专注运营和维护/云原生领域，精通疑难网络故障分析，对大型银行运维工具建设有丰富的实践经验。
