共计 4899 个字符，预计需要花费 13 分钟才能阅读完成。
每个大型企业组织都在尝试减速其数字化转型策略，以更加个性化、相干和动静的形式与客户互动。在创立和收集数据时对数据执行剖析（也称为实时数据流）并生成即时洞察以放慢决策制定的能力为组织提供了竞争劣势。
组织越来越多地从实时数据流构建低提早、数据驱动的应用程序、自动化和智能。欺诈检测、网络威逼剖析、制作智能、商务优化、实时报价、即时贷款批准等用例当初能够通过将数据处理组件向上挪动来满足这些实时需要。
Cloudera 流解决 (CSP) 通过提供剖析流数据的简单模式并取得可操作的情报的性能，使客户可能将流转化为数据产品。例如，一家大型生物技术公司应用 CSP 通过剖析和正告超出规格的分辨率色彩不均衡来制作合乎准确规格的设施。许多大型金融服务公司应用 CSP 为其寰球欺诈解决管道提供能源，并避免用户在贷款审批过程中利用竞争条件。
2015 年，Cloudera 成为首批为 Apache Kafka 提供企业反对的供应商之一，这标记着 Cloudera 流解决 (CSP) 产品的起源。在过来七年中，Cloudera 的流解决产品一直倒退，以满足咱们 700 多家企业客户及其多样化用例一直变动的流剖析需要。现在，CSP 由 Apache Flink 和 Kafka 提供反对，并提供残缺的企业级流治理和状态解决解决方案。Kafka 作为存储流媒体基板，Flink 作为外围流解决引擎，以及对 SQL 和 REST 等行业标准接口的一流反对，使开发人员、数据分析师和数据科学家可能轻松构建实时数据管道为数据产品、仪表板、商业智能应用程序、微服务和数据迷信笔记本提供能源。
CSP 最近在 2022 GigaOm 雷达流数据平台报告中被公认为领导者。
本博客旨在答复两个问题，如下图所示：
1) 随着越来越多的组织转向“流优先”架构并尝试构建流剖析管道，流解决需要和用例如何演变？
2) 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 作业。
图 5：SQL Stream Builder (SSB) 是一个全面的交互式用户界面，用于应用 SQL 创立有状态的流解决作业。
批处理和流式的交融变得容易
在一次客户研讨会上，作为经验丰富的前 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
本文由 mdnice 多平台公布
