实时分析：处理流数据以获得即时洞察

业务决策一直存在延迟问题。周二运营的数据在周三晚上进行处理，周四由分析团队进行分析，在周五的会议上进行审查，并在下周采取行动 - 到那时运营情况再次发生变化。事件和响应之间长达一周的滞后是市场的结构性竞争劣势，因为拥有更好数据基础设施的竞争对手可以在几分钟内响应信号。

实时分析将这种延迟从几天缩短到几秒，或者在最先进的实施中缩短到几毫秒。流数据处理不是一夜之间进行批处理，而是在事件发生时对其进行分析，不断更新仪表板，并在条件允许时触发自动响应。

在企业规模上实现这一目标的技术已经显着成熟。 Apache Kafka、Apache Flink 和现代云流服务使 Google、LinkedIn 或 Netflix 以外的组织也可以进行实时数据处理。实时洞察的竞争优势（十年前需要数十亿美元的基础设施投资）现在对于中型市场组织来说已经触手可及。

要点

• 实时分析将决策延迟从几天缩短到几秒钟，从而实现更快的运营响应
• 流数据处理堆栈分为三层：摄取（Kafka）、处理（Flink/Spark Streaming）和服务（实时 OLAP 数据库）
• Apache Kafka 是企业事件流事实上的标准，每天在全球处理数万亿个事件
• 实时 OLAP 数据库（Druid、Pinot、ClickHouse）可实现流数据的亚秒级查询
• 运营分析 - 实时监控业务运营 - 比分析报告提供更快的投资回报
• Power BI 流数据集和 Azure 流分析为以 Microsoft 为中心的组织提供可访问的实时仪表板
• “lambda 架构”（结合批处理和流媒体）正在被“kappa 架构”（仅流媒体）取代
• 使用案例：欺诈检测、运营监控、客户行为分析、供应链可视性、金融市场风险

---

为什么实时分析很重要

数据的价值迅速衰减。顾客现在放弃购物车是一个干预机会；昨天放弃购物车的客户是重定向受众。现在出现故障迹象的机器是一个预测性维护的机会；今天早上发生故障的机器属于意外停机事件。

衰减率因用例而异：

• 金融欺诈：数据价值以毫秒为单位衰减 - 欺诈决策必须在交易完成之前实时做出
• 机器监控：数据价值在几秒到几分钟内衰减 - 设备干预必须在发生故障之前发生
• 客户行为：价值在几分钟到几小时内衰减 - 购物车放弃恢复在 30-60 分钟内具有最高转化率
• 供应链可见性：价值在数小时内衰减 - 在客户影响之前解决交付异常
• 业务绩效监控：价值在几小时到几天内衰减 - 日常运营决策受益于当天的数据

不同的用例需要不同的延迟目标，从而推动不同的架构选择。

---

流数据架构堆栈

构建实时分析能力需要组装一系列互补技术：

第 1 层：事件摄取 — Apache Kafka

Apache Kafka 是企业事件流事实上的标准。 Kafka 于 2011 年在 LinkedIn 创建并开源，目前已成为全球数千家企业实时数据的中枢神经系统——仅 LinkedIn 每天就处理超过 7 万亿条消息。

Kafka 的作用：Kafka 是一个分布式、持久、高吞吐量的发布-订阅消息系统。制作者将事件发布到主题；消费者订阅主题并处理事件。事件存储可配置的保留期（通常为 7-30 天），从而支持重播和多个独立的消费者组。

为什么选择 Kafka：吞吐量（每秒数百万个事件）、持久性（事件保存到磁盘、跨代理复制）、容错（如果消费者失败，消费者组会自动重新平衡）以及它在生产者和消费者之间提供的解耦。

托管 Kafka 选项：运行 Kafka 需要丰富的操作专业知识。托管选项包括 Confluence Cloud（完全托管的商业 Kafka）、AWS MSK（Amazon Managed Streaming for Kafka）和 Azure Event Hubs（与 Kafka 兼容的托管服务）。对于没有深厚 Kafka 专业知识的组织，托管服务可以极大地减轻运营负担。

Kafka 的替代品：Amazon Kinesis（AWS 原生，比 Kafka 更简单，吞吐量上限更低）、Google Pub/Sub（Google Cloud 原生、完全托管、全球规模强大）、Apache Pulsar（较新，在基准测试中吞吐量比 Kafka 更高，生态系统成熟度较低）。

第 2 层：流处理

来自 Kafka 的原始事件流需要进行处理——转换、丰富、聚合和分析——然后才能产生可​​操作的见解。

Apache Flink：用于实时分析工作负载的领先流处理框架。 Flink 提供一次性处理语义、事件时间处理（正确处理无序事件）和有状态流处理（跨事件维护状态）。最成熟的流处理框架；需要大量的专业知识来操作。

Apache Spark Streaming / Structured Streaming：Spark 的流功能可处理微批次的流数据。比 Flink 更容易学习（特别是对于有批量 Spark 经验的团队）；延迟比真正的流媒体稍高，但对于大多数用例来说是可以接受的。

Apache Kafka Streams：用于构建在 Kafka 消费者进程中运行的流处理应用程序的库。比 Flink 或 Spark 更简单的部署（无需单独的集群）；复杂处理能力较差。

Apache Storm：传统的流处理框架，很大程度上被 Flink 和 Spark 取代。已维护，但不建议用于新部署。

云托管流处理：AWS Kinesis Data Analytics（支持 Flink）、Azure Stream Analytics（基于 SQL 的专有流处理）、Google Dataflow（托管 Apache Beam）。这些托管服务降低了运营复杂性，但牺牲了一定的灵活性。

第 3 层：实时 OLAP — 提供查询服务

实时分析需要针对新获取的数据进行快速查询而优化的数据库，这与事务数据库 (OLTP) 或传统分析数据库 (OLAP) 的优化不同。

Apache Druid：专为实时 OLAP 构建。 Druid 从 Kafka 获取流数据，以针对分析查询优化的列式格式存储，并支持对数十亿行的亚秒级查询。 Netflix、Airbnb、Lyft 和其他数百家公司将其用于实时分析仪表板。

Apache Pinot：在 LinkedIn 开发并开源。与 Druid 类似的功能，具有强大的面向用户分析性能（大规模为最终用户提供实时分析）。由 LinkedIn（用于“谁查看了您的个人资料”分析）、Uber 和其他公司使用。

ClickHouse：开源的列式OLAP数据库，具有极高的查询性能。支持流式摄取和实时查询。作为 Druid/Pinot 的替代品，操作更简单，迅速发展。 Cloudflare、字节跳动等许多公司都在使用。

Apache Pinot vs. Druid vs. ClickHouse：这三个都是强有力的选择；该决定通常取决于操作偏好、生态系统适合度和特定查询模式。 ClickHouse操作最简单； Druid 和 Pinot 对时间序列特定优化有更强的支持。

TimescaleDB：针对时间序列数据优化的 PostgreSQL 扩展。吞吐量比 Druid/ClickHouse 低，但熟悉 SQL 接口和操作模型。中等规模实时分析的不错选择。

---

流式架构模式

Lambda 架构

Lambda 架构（由 Nathan Marz 创造）通过运行两个并行处理路径解决了实时分析和批量分析相结合的挑战：

批处理层：定期（每小时、每天）处理所有历史数据，生成准确但潜在的数据视图。

速度层：实时处理最近的流数据，生成低延迟但可能不完整或近似的视图。

服务层：合并批处理和速度层输出，提供完整的、近似实时的视图。

Lambda 架构是 2012-2018 年的主导方法。它的主要缺点：维护两个独立的处理代码库（批处理和流式处理）在操作上很复杂，并且服务层中的合并逻辑引入了额外的复杂性。

Kappa 架构

Kappa 架构（由 Jay Kreps 提出）通过对所有内容（实时处理和历史批处理）使用流来简化 lambda。

单一处理路径：所有数据都流经流管道。历史处理是通过流作业重播Kafka持久存储中的历史事件来实现的。

操作更简单：一种处理框架、一种代码库、一种操作基础设施。

Kappa 架构要求您的流框架能够有效地处理完整的历史数据集重播 - Kafka 的保留和 Flink 的功能使这一点变得可行。大多数新的实时分析系统都是基于 kappa 架构构建的。

实时数据 Lakehouse

新兴模式将实时流与 data Lakehouse 架构集成在一起：

流式传输到 Delta Lake / Apache Iceberg：事件流直接写入 Lakehouse 表格式（Delta Lake、Apache Iceberg、Apache Hudi），支持 ACID 事务、模式演化和高效的增量处理。

统一批流数据：同一个lakehouse表中同时包含历史批量数据和最近的流数据，可通过单一接口查询。无需协调单独的流式存储和批处理存储。

Databricks Delta Live Tables、AWS Lake Formation + Kinesis 和 Apache Iceberg + Flink 是此模式的主要实现。

---

按行业划分的用例

金融服务：欺诈检测

实时欺诈检测是风险最高的流分析用例。欺诈决策必须在交易进行时以毫秒为单位做出，因为撤销已完成的交易成本高昂，有时甚至是不可能的。

典型的实时欺诈检测架构： 1.交易事件进入支付系统时发布到Kafka 2. Flink 流作业处理事件 - 丰富客户历史记录、设备指纹和行为特征 3. ML 欺诈评分模型评估丰富事件（通过实时推理 API 提供的模型） 4. 50-200ms内决定返回支付系统 5. 事件和决策存储在实时OLAP中，用于运行监控和模型再训练

Visa 的欺诈检测系统每秒处理 65,000 笔交易，决策延迟低于 100 毫秒，每年可防止约 250 亿美元的欺诈行为。

电子商务：实时个性化

实时行为分析可以实现个性化，响应客户现在正在做的事情，而不是他们在上一次会话中所做的事情。

当客户浏览产品时，事件流向流处理器：

• 更新客户的实时兴趣档案
• 识别客户未见过的类似产品
• 评估当前的促销资格
• 生成个性化推荐集

推荐在浏览事件发生后几秒钟内就准备好，从而实现实时页面个性化，而不是很快就会过时的会话启动个性化。

制造：运营监控

制造运营的实时流分析可以：

• 连续 OEE（整体设备效率）跟踪每分钟根据机器信号更新
• 警报管理仪表板实时显示当前机器状态和警报历史记录
• 质量控制信号 — SPC（统计过程控制）发生失控警报
• 生产绩效与进度跟踪不断更新

这种实时操作可视性是现代智能工厂中 MES（制造执行系统）功能的基础。

供应链：发货可见性

来自车辆、船舶和设施的实时 GPS 和物联网数据可实现持续的供应链可视性 — 显示每批货物目前的位置，并提供预计到达时间 (ETA) 预测和异常警报。

亚马逊的内部物流可视性（同时了解数百万个包裹的实时状态）是一项核心运营能力，可确保其交付承诺的准确性。

---

用于实时分析的 Power BI

对于已经投资于 Microsoft 生态系统的组织，Power BI 提供了可访问的实时分析功能，而无需完整的流数据架构。

Power BI 流数据集

Power BI 支持流数据集，即在新数据到达时实时更新报表的数据连接。三种类型：

推送流式传输：数据通过推送 API（对 Power BI 数据集端点的 REST API 调用）推送到 Power BI。数据被存储并可以历史查询。适用于历史背景很重要的操作仪表板。

仅流式传输：数据通过 Power BI 流式传输，无需持久存储。极低的延迟；没有历史查询。适用于监控仅当前状态重要的仪表板。

PubNub 流：连接到 PubNub 实时数据流。主要用于物联网和社交媒体监控用例。

Azure 流分析 + Power BI

Azure 流分析是 Microsoft 的托管流处理服务 - 基于 SQL，无需深入的分布式系统专业知识的分析师即可使用。本机 Power BI 输出适配器将聚合的流式查询结果直接发送到 Power BI 数据集。

架构：

1. IoT 中心或事件中心摄取流数据
2. Azure 流分析通过流运行 SQL 窗口查询
3. 结果被推送到 Power BI 推送数据集
4. Power BI 报告实时数据集并自动刷新

商业智能团队无需 Kafka 或 Flink 专业知识即可使用此架构，从而使中型企业可以实现实时操作仪表板。

Power BI 实时仪表板示例

制造 OEE 仪表板：机器信号 → Azure IoT 中心 → 流分析（计算 OEE 组件）→ Power BI 实时数据集 → 每 30 秒更新一次的实时 OEE 仪表板。

物流跟踪：GPS 事件 → 事件中心 → 流分析（计算货运状态和预计到达时间） → Power BI 地图可视化以及实时车辆位置。

电子商务运营：订单事件 → 事件中心 → 流分析（按 SKU、区域、每小时趋势划分的销售）→ 运营团队的 Power BI 订单监控仪表板。

---

实施指南

何时构建实时、近实时、批处理

并非每个分析用例都需要真正的实时处理。将延迟与实际业务需求相匹配可以避免过度设计：

真正的实时（亚秒级）：欺诈检测、工业安全监控、实时竞价、金融市场风险。需要 Kafka + Flink 或同等产品。

近实时（1-5 分钟）：运营监控仪表板、客户服务队列、供应链异常警报。可以通过更简单的流架构或微批处理来实现。

频繁批量（每小时）：日常业务监控、日内分析、定期报告。标准批量ETL到数据仓库；比流媒体更简单、更便宜。

每日批次：大多数分析报告、绩效评估、预测。标准数据仓库模式。

入门：实用之路

第 1 阶段：确定最高价值的实时用例。映射需要什么数据、需要什么延迟以及它支持什么决策或操作。在投资基础设施之前验证业务价值。

阶段 2：从托管服务开始。使用 Confluence Cloud for Kafka（非自管理）、Azure Stream Analytics 或 Kinesis Data Analytics 进行流处理（非自管理 Flink）。用于仪表板的 Power BI 流。这显着减轻了初始操作负担。

阶段 3：端到端构建第一个用例。衡量延迟、吞吐量和业务影响。

阶段 4：扩展到已建立的基础设施上的其他用例。第二个用例比第一个用例便宜得多，因为基础设施已经存在。

---

常见问题

流式分析和实时分析有什么区别？

尽管技术上不同，但这些术语经常互换使用。流分析是指对无限数据流的连续处理——数据连续到达而没有定义的终点。实时分析是指延迟极低的分析，可实现近乎即时的洞察。流分析是技术方法；实时分析是延迟特性。并非所有流分析都需要“实时”（每 5 分钟运行一次的流作业是流式的，但不是实时的）；并非所有实时分析都使用流式传输（数据库查询可以针对静态数据进行实时）。在实践中，大多数企业“实时分析”实施都使用流式架构。

Kafka 与 RabbitMQ 等传统消息队列相比如何？

传统消息队列（RabbitMQ、ActiveMQ）将消息从生产者路由到消费者，并在消费后将其删除。 Kafka 有着根本的不同：​​它是一个分布式日志，其中的消息存储可配置的保留期，并且多个消费者组可以独立读取相同的消息。这可以实现：重播（重新处理某个时间点的所有事件）、多个独立使用者（分析、监控和归档都可以使用相同的事件）和高吞吐量（Kafka 在商用硬件上实现每秒 100 MB 的速度，而传统队列则达到每秒 10 MB 的速度）。使用 Kafka 进行高吞吐量事件流和分析用例；将 RabbitMQ 用于低容量、复杂的路由和工作队列场景。

在生产环境中运行 Apache Kafka 的主要运营挑战是什么？

Kafka 的主要运营挑战：分区管理（确定每个主题的正确分区数量，这会影响吞吐量和排序）、消费者滞后监控（检测消费者何时落后于生产者，表明存在处理瓶颈）、复制因子配置（平衡持久性与存储成本）、偏移量管理（确保消费者不会丢失其在流中的位置）以及模式演化（在不破坏消费者的情况下管理消息格式的更改）。这些挑战解释了为什么托管 Kafka 服务（Confluence Cloud、AWS MSK）快速增长——它们处理大多数操作复杂性，使团队能够专注于应用程序逻辑。

我们如何确保流分析中的一次性处理以避免多次计数事件？

一次性处理——确保每个事件在失败的情况下都只处理一次——在技术上具有挑战性。 Apache Flink 通过检查点和事务接收器提供原生的一次性语义。 Kafka 的事务生产者 API 在 Kafka 中提供一次性交付。对于端到端的恰好一次（从源系统通过处理到输出），管道中的所有组件都必须支持恰好一次语义，并且必须相应地设计架构。在实践中，许多流系统接受至少一次处理（可能多次处理同一事件）并使下游处理幂等（多次处理同一事件产生与处理一次相同的结果）。这更简单，并且通常足以满足分析用例的需要。

我们如何处理流分析中的迟到数据？

迟到数据（在处理所属时间窗口之后到达的事件）是一个基本的流处理挑战。 Apache Flink 和 Spark Streaming 都提供具有可配置水印的事件时间处理：水印定义事件可以晚到多长时间到达并且仍然包含在其正确的时间窗口中。水印之后到达的事件由后期数据处理程序处理 - 通常写入侧面输出以进行单独处理或删除。水印值是一种权衡：更宽的水印可以正确处理更多后期数据，但会增加结果延迟；较窄的水印速度更快，但可能会错过一些后期事件。设置适当的水印需要了解数据源的延迟特征。

---

后续步骤

实时分析正在将业务运营从被动转变为主动，使组织能够在事件发生时做出响应，而不是在事件发生几天后做出响应。愿意投资于架构和运营能力的中端市场组织现在可以使用实现这一点的技术堆栈。

ECOSIRE 的 Power BI 和分析服务 涵盖从可访问的实时仪表板到 Power BI 流数据集到企业流架构设计的全方位。我们的团队可以帮助您确定适合您业务的最高价值的实时分析用例并实施正确的架构 - 从简单的 Power BI 流式传输到企业 Kafka + Flink 部署。

联系我们的分析团队 讨论您的实时分析需求并设计正确的实施方法。