每个大型企业组织都在尝试加速其数字化转型战略，以更加个性化、相关和动态的方式与客户互动。在创建和收集数据时对数据执行分析（也称为实时数据流）并生成即时洞察以加快决策制定的能力为组织提供了竞争优势。
组织越来越多地从实时数据流构建低延迟、数据驱动的应用程序、自动化和智能。欺诈检测、网络威胁分析、制造智能、商务优化、实时报价、即时贷款批准等用例现在可以通过将数据处理组件向上移动来满足这些实时需求。
Cloudera 流处理 (CSP) 通过提供分析流数据的复杂模式并获得可操作的情报的功能，使客户能够将流转化为数据产品。例如，一家大型生物技术公司使用 CSP 通过分析和警告超出规格的分辨率颜色不平衡来制造符合精确规格的设备。许多大型金融服务公司使用 CSP 为其全球欺诈处理管道提供动力，并防止用户在贷款审批过程中利用竞争条件。
2015 年，Cloudera 成为首批为 Apache Kafka 提供企业支持的供应商之一，这标志着 Cloudera 流处理 (CSP) 产品的起源。在过去七年中，Cloudera 的流处理产品不断发展，以满足我们 700 多家企业客户及其多样化用例不断变化的流分析需求。如今，
CSP 最近在2022 GigaOm 雷达流数据平台报告中被公认为领导者。
本博客旨在回答两个问题，如下图所示：
- 随着越来越多的组织转向“流优先”架构并尝试构建流分析管道，流处理需求和用例如何演变？
- Cloudera 流处理 (CSP) 如何与客户不断变化的需求保持同步？
图 1：Cloudera 流处理产品的演变基于客户不断演变的流用例和需求。
更快的数据摄取：流式摄取管道
随着客户开始为多功能分析构建数据湖和湖仓（甚至在它被命名之前），围绕数据摄取开始出现大量期望的结果：
- 支持流数据的规模和性能需求：用于将数据移动到数据湖中的传统工具（传统的 ETL 工具，Sqoop）仅限于批量摄取，不支持流数据源的规模和性能需求。
- 减少摄取延迟和复杂性：需要多点解决方案将数据从不同的数据源移动到下游系统。这些工具的批处理性质增加了分析的整体延迟。需要更快的摄取来减少整体分析延迟。
- 应用程序集成和微服务：实时集成用例要求应用程序能够订阅这些流并与下游系统实时集成。
这些期望的结果引发了对分布式流存储基板的需求，该基板针对实时摄取和处理流数据进行了优化。Apache Kafka 专为满足这一需求而构建，Cloudera 是最早提供支持的供应商之一。分别由 Apache Kafka 和 NiFi 提供支持的 Cloudera 流处理和 DataFlow 的结合帮助数百名客户构建了实时摄取管道，并通过如下架构实现了上述预期结果。
图 2：将数据流引入湖中：Apache Kafka 用于支持微服务、应用程序集成，并实现对各种静态数据分析服务的实时摄取。
Kafka盲区：Kafka对企业管理能力的需求
随着 Kafka 成为企业内部流存储基板的标准，Kafka 失明开始了。什么是Kafka失明？谁受到影响？Kafka 失明是企业为 Apache Kafka 集群监控、故障排除、修复、治理、保护和提供灾难恢复的斗争。
失明不会歧视并影响不同的团队。对于平台运营团队来说，缺乏集群和代理级别的可见性以及代理对其运行的基础架构的影响，反之亦然。而对于 DevOps/应用程序团队，用户主要对与其应用程序关联的实体感兴趣。这些实体是与其应用程序关联的主题、生产者和消费者。DevOps/app 开发团队想知道这些实体之间的数据如何流动，并了解这些实体的关键性能指标 (KPM)。对于治理和安全团队，问题围绕监管链、审计、元数据、访问控制和沿袭展开。站点可用性团队专注于满足其灾难恢复集群中严格的恢复时间目标 (RTO)。
Cloudera 流处理通过提供一套全面的企业管理功能来解决模式治理、管理和监控、灾难恢复、简单的数据移动、智能重新平衡、自我修复以及强大的访问控制和审计，为我们的客户治愈了 Kafka 的失明。
图 3：Cloudera 流处理为 Apache Kafka 提供了一套全面的企业管理服务。
超越传统的静态数据分析：使用 Apache Flink 进行下一代流处理
到 2018 年，我们看到大多数客户采用 Apache Kafka 作为其流式摄取、应用程序集成和微服务架构的关键部分。客户开始明白，为了更好地为客户服务并保持竞争优势，他们需要实时完成分析，而不是几天或几小时，而是几秒钟或更短的时间。
加拿大最大的保险公司之一的建筑和工程副总裁在最近的一次客户会议上总结得很好：
“我们迫不及待地等待数据保留并稍后运行作业，当数据流经我们的管道时，我们需要实时洞察力。我们必须构建流数据管道，新数据必须通过它才能被持久化，然后为业务团队提供对该管道的访问权限，以便他们构建数据产品。”
换句话说，Kafka 提供了一种更快地摄取流数据的机制，但传统的静态数据分析对于实时用例来说太慢了，并且需要尽可能接近数据来源进行分析。
2020 年，为了满足这一需求，Apache Flink 被添加到 Cloudera 流处理产品中。Apache Flink 是一个用于有状态计算的分布式处理引擎，非常适合实时、事件驱动的应用程序。构建实时数据分析管道是一个复杂的问题，我们看到客户在使用 Apache Storm、Spark Streaming 和 Kafka Streams 等处理框架时遇到了困难。
添加 Apache Flink 是为了解决我们的客户在构建生产级流分析应用程序时面临的难题，包括：
- 有状态的流处理：如何在处理多个流数据源的同时有效地大规模处理需要上下文状态的业务逻辑？例如：通过同时分析多个流来检测车辆中的灾难性碰撞事件：车速在两秒内从 60 变为零，前轮胎压力从 30 psi 变为错误代码，在不到一秒的时间内，座椅传感器从100 磅归零。
- 只处理一次：如何确保数据在任何时候都只处理一次，即使在错误和重试期间也是如此？例如：当消费者支付房屋抵押贷款时，一家金融服务公司需要使用流处理来协调数百个后台交易系统。
- 处理迟到的数据：我的应用程序如何检测和处理乱序的流事件？例如：实时欺诈服务，即使数据迟到也需要确保数据以正确的顺序处理。
- 超低延迟：如何实现内存中、一次一次的流处理性能？例如：金融机构需要处理 3000 万活跃用户的信用卡支付、转账和余额查询请求，延迟时间为毫秒。
- 有状态事件触发器：在处理数百个流源和每个流每秒数百万个事件时如何触发事件？例如：需要支持外部触发器的医疗保健提供者，以便当患者进入急诊室候诊室时，系统会与外部系统联系，从数百个来源提取患者特定数据，并在电子医疗中提供该数据患者走进检查室时的记录 (EMR) 系统。
Apache Kafka 作为流处理的流存储基础至关重要，而 Apache Flink 是处理流的最佳计算引擎。随着客户从静态数据分析转向为低延迟实时数据产品提供动力的动态数据分析，Apache Kafka 和 Flink 的结合至关重要。
图 4：对于需要低延迟的实时用例，Apache Flink 支持流内分析，无需保留数据然后执行分析。
让世界的 Lailas 获得成功：使用 SQL 实现流式分析民主化
虽然 Apache Flink 通过多种语言的简单高级 API 为 CSP 产品添加了强大的功能，但对于大多数开发人员来说，流处理的构造（如状态处理、恰好一次语义、窗口化、水印、事件之间的细微差别和系统时间）都是新概念为数据分析师、DBA 和数据科学家提供新颖的概念。
认识 Laila，一位非常有主见的 Cloudera 流处理实践者。她是一名智能数据分析师和前 DBA，在一家全球规模的制造公司工作。她需要测量来自多个制造站点的流式遥测元数据，以进行容量规划以防止中断。Laila 想使用 CSP，但没有时间复习 Java 或学习 Scala，但她非常了解 SQL。
2021 年，SQL Stream Builder (SSB) 被添加到 CSP 中，以满足 Laila 和许多喜欢她的人的需求。SSB 为开发人员、数据分析师和数据科学家提供了一个全面的交互式用户界面，以使用行业标准 SQL 编写流式应用程序。通过使用 SQL，用户可以简单地声明过滤、聚合、路由和改变数据流的表达式。当流式 SQL 执行时，SSB 引擎将 SQL 转换为优化的 Flink 作业。
批处理和流式的融合变得容易
在一次客户研讨会上，作为经验丰富的前 DBA，Laila 发表了以下我们经常从客户那里听到的评论：
“除非我可以轻松地将这些流与我的仓库、关系数据库和数据湖中的其他数据源集成、连接和网格化，否则流数据几乎没有价值。没有上下文，流数据就毫无用处。”
SSB 使用户能够使用开箱即用的连接器或他们自己的连接器到任何数据源来配置数据提供者。创建数据提供者后，用户可以使用 DDL 轻松创建虚拟表。多个流和批处理数据源之间的复杂集成变得更加容易，如下例所示。
图 6：流式和批处理的融合：使用 SQL Stream Builder (SSB)，用户可以轻松地为流式和批处理数据源创建虚拟表，然后使用 SQL 声明过滤、聚合、路由和变异数据流的表达式。
我们用户的另一个常见需求是简化将流分析管道的结果提供给他们正在创建的数据产品的过程。这些数据产品可以是 Web 应用程序、仪表板、警报系统，甚至是数据科学笔记本。
SSB 可以将流式 SQL 查询的结果具体化为可通过 REST API 读取的数据的持久视图。这种高度消耗的数据集称为物化视图 (MV)，BI 工具和应用程序可以使用 MV REST 端点来查询数据流，而不依赖于其他系统。Kafka 作为存储流式传输基板，Flink 作为核心流式处理引擎，SQL 可以更快地构建数据应用程序，以及 MV 来使流式传输结果普遍可用，从而实现了下面描述的混合流式数据管道。
图 7：Cloudera 流处理 (CSP) 使用户能够创建端到端混合流数据管道。
那么我们让莱拉成功了吗？当 Laila 开始使用 SSB 后，她迅速利用她的 SQL 技能来解析和处理来自 Kafka 的复杂遥测元数据流，以及来自其数据中心和云中的制造数据湖的上下文信息，以创建混合流管道。然后，她使用物化视图在 Grafana 中创建了一个仪表板，该仪表板提供了制造现场产能规划需求的实时视图。
在随后的博客中，我们将深入探讨多个垂直领域的用例，并讨论如何使用 CSP 实现它们。
结论
Cloudera 流处理已经从实现对湖泊的实时摄取发展到提供复杂的流内分析，同时使其可供世界各地的莱拉斯人使用。正如莱拉准确地说的那样，“没有上下文，流数据毫无用处。” 在 CSP 的帮助下，您可以确保您的数据管道跨数据源连接，以在您的数据上下文中考虑实时流数据，这些数据跨越您的数据仓库、数据湖、湖仓、运营数据库等。更好的是，它适用于任何云环境。依靠行业标准 SQL，您可以确信您现有的资源拥有成功部署 CSP 的专业知识。
不在制造领域？不用担心。在随后的博客中，我们将深入探讨多个垂直领域的用例，并讨论如何使用 CSP 实现它们。
今天开始
Cloudera 流处理可在您的私有云或 AWS、Azure 和 GCP 上的公共云中运行。查看我们新的Cloudera 流处理交互式产品导览，在 AWS 上创建端到端混合流数据管道。
了解有关 Cloudera 流处理的更多信息并试一试的最快方法是什么？首先，访问我们新的Cloudera 流处理主页。然后在您的桌面或开发节点上下载Cloudera 流处理社区版，并在五分钟内部署您的第一个流处理管道并体验您的兴奋时刻。
原文作者：George Vetticaden
原文link：https://blog.cloudera.com/turning-streams-into-data-products/
