从离线向实时迭代

当下，瞬息万变的市场环境要求企业更快的做出商业决策，一个大型企业可能要在一分钟内做出上千个商业决策。“双十一 ”和春晚直播的实时大屏、银行和证券交易行为的实时监控、电商和短视频的实时个性化推荐等场景不断涌现，说明各行业都在向实时在线化发展。以短视频的实时个性化推荐为例，基于用户在前1分钟或者30秒内观看的视频情况，在后续浏览中系统就要根据算法测算用户特征偏好，然后实时向用户推荐其可能会喜欢的视频内容。

通过这样的在线化趋势，我们可以发现，企业除了传统离线数据分析还有大量不断出现的实时数据处理的需求。从用户角度，实时数据处理在营销、风控、运营和物联网等不同细分场景中都有应用。

实时营销：实时事件营销、实时产品推荐、实时画像

实时风控：实时授信申请、实时反欺诈、实时舆情监控等

实时运营：实时业务统计、实时监控、动态定价

实时IoT：设备质量预测、设备异常检测、产品缺陷检测

如何理解实时？

当开发工程师说“实时”，通常的意思是系统会在指定的时间内完成数据处理任务。不同场景和任务所指定的时间是不一样的，因此将时效提升到实时的目标也就存在差异。

比如，传统报表的跑批时间是10个小时左右，通过数据处理技术的改进将处理时间缩短至10分钟，时效大幅提高，很多用户认为这已经是实时的了。类似的，网购用户查看物流信息通常会有一天延迟，当时效提升至几分钟的话，也可以认为是实时的。然而，在金融机构的量化交易、交易风险监控等场景中，数据处理的时效要求是毫秒级，如果其时效也是几分钟的话，别说算不上是“实时”，相关场景和业务恐怕也会难以开展。

因此，不同场景对实时的需求差异较大。那么，针对实时数据处理，我们能否形成共识和统一的标准呢？

实时标准为何？

世界上的决策都是以事件驱动的，我们将一个事件发生的时点设为T，将事件发生后等待数据更新可用的时长设为x，那么T+x则代表在一个事件发生后我们得到可用数据的时点。传统离线数据处理方式中，x通常为1天，当企业由离线数据分析逐步转向实时数据分析时，x取值也就随之缩短至几分钟、几秒钟。

那么，实时对应的x取值应该是多少？我们将x的取值范围视作一个连续数轴，x取值可无限接近于0，也可以达到几周甚至几个月。Gartner的研究按照不同时效，也就是x取值的分布，将企业涉及的全部场景分为了四类：战略决策、战术分析、业务运营、自动处理。

● 战略决策：比如收购一家公司、进行海外市场扩张，通常要花数月到半年进行分析和决策，分析的频率、对数据的实时要求非常低。

● 战术分析：比如细分市场的定价、某款产品的目标人群分析，相比战略决策的分析时间要短，通常要几周到一个月，分析频率和数据的时效也要高一些。

● 业务运营：在前文所提到的营销、风控、运营等场景中很常见，比如审批一笔贷款、修改合同报价、客服中心的动态排班等。在这些场景中，负责“盯数据”的人要每天都要与数据进行交互和分析，时效要求较高，分析频率也较高。

● 自动处理：比较典型的自动化数据处理场景，像股市的高频量化交易、信用卡自动审批、为被拒载的网约车乘客重新匹配车辆，都是都是非常高频和迅速的，通常是在毫秒级。

我们可以发现，相比自动处理的无人工参与，业务运营既有人工的交互分析，又要求很高的时效，因此，业务运营是我们定义和划分实时标准的关键。Gartner对实时的研究显示，事件被触发后的15分钟或更短的时间内发生的活动被定义为实时业务。也就是当x<=15分钟，我们认为算是实时或准实时场景。按照Gartner的标准划分，我们也可以发现业务运营有一部分是实时的，一部分是非实时的。

由于以往数据处理技术的局限性，很多企业在业务运营场景的数据处理时效都超过了15分钟，这种过长的数据处理耗时却是一个无奈之举。根据我们的观察和实践，十几分钟的数据滞后对一些分析决策场景其实是难以忍受的，尤其是当分析人员需要做实时交互式分析的场景。因此我们有必要将泛实时进一步划分为准实时和强实时：x<=10秒为强实时，10秒<x<=15分钟为准实时。

实时数据处理的挑战在哪里？

传统数据平台的数据处理流程一般是这样的。首先，从业务系统 CRM、ERP 或者其他数据源把这些业务数据收集过来，然后经过离线数据 ETL 对数据进行数据清洗、数据加工。在这个过程中会涉及数据建模和分层，最终会把加工后的数据提供给 BI 工具，或者写到数据库并推到一个在线服务系统，供用户进行访问，这些用户包括客户、运营人员或管理团队等等。

我们发现，即便在没有做实时数据处理的情况下，这样的数据处理链路就已经很冗长了。然而，当我们不解决既有离线问题的情况下就向实时转型，问题将更加复杂。

那么，实时数据是如何处理的？

目前主要采用传统 Lambda 和 Kappa 架构。以 Lambda 架构的实现方法为例，Lambda 以传统的离线数仓为主，然后引入了实时数据的处理链路。T+1 数据仍然是走传统离线数仓链路，然后再加上一个实时的数据链路，把这些实时数据和离线数据汇总到一起，然后再通过一个服务层提供数据服务，对外提供的服务可能是点查询，也可能是做复杂分析。

离线链路用 Hive/Spark，实时用 Flink。但在实际的落地中，如果需要引入实时查询，可能要再加上 ClickHouse/Drill/Presto；如果需要做数据的离线归档，还需要 Hive；为了满足一些高并发点查询需求，还要再引入了 HBase 和 MySQL。引入这么多产品组件，本质原因还是缺少一个在并发、性能和开放性兼顾的产品。

因此 Lambda 架构并没有从源头上解决传统离线数仓的问题，而是在传统离线数仓上加了一条链路，让整个系统变得更加复杂。数据可能会存两份或者存多份，实时链路和离线链路数据也不统一。除此之外，架构维护复杂，学习和开发成本也非常高。

实时数据处理如何破局？

为了实现实时数据处理，很多企业不惜选择冗长的数据处理链路，造成多份数据和多个计算引擎烟囱林立。我们不得不思考：实时数据处理如何破局？

Lambda 架构复杂、数据的一致性弱，Kappa 架构实际落地困难，两个架构又都很难处理可变更数据（如关系数据库中不停变化的实时数据），那么自然需要一种新的架构满足企业实时分析的全部需求，偶数给出的破局方案就是 Omega 全实时架构。Omega 架构由偶数科技于 2021 年初提出，同时满足实时流处理、实时按需分析和离线分析。

Omega 架构是基于实时数据管理和数据分析的框架，它涵盖了从数据收集、存储、处理到分析和应用的全过程。利用OushuDB实时数仓的优势，Omega 超越Lambda和Kappa架构的局限，更强调对实时能力的边界拓展，兼容传统数据湖和数据仓库，主张对全部数据（结构化和非机构化数据）进行实时处理，以满足企业的实时企业由离线数据分析逐步转向实时数据分析需求。

Omega 架构通过着陆层、整合层和交付层三个数据层次，以及元数据和业务数据两个维度去进行架构的设计，进而实现实时数据处理和传统离线数据处理。结合如下的架构图，概括Omega 的实时数据架构的实现方式和特点。

1.    流计算引擎可以实时ETL，也可以实时做汇聚后结果输出到湖仓

2.    湖仓平台每个数据层次都可以分为 T+0 实时数据和 T+x 批量数据。

3.    每个数据层次的 T+0 数据和 T+x 数据可以根据业务需求（尤其是对历史数据的分析需求）采取不同的数据存储更新策略（增量追加表、变更日志表 、拉链表）

4.   每个数据层次的 T+x 数据可以通过定时调度计划或者SQL 视图方式算从前一层 T+x 得到；每个数据层次的 T+0 可以通过实时 Flink 计算从前一层 T+0 得到。

5.  数据应用可以直接访问着陆数据层、明细数据层、汇总数据层和交付数据层中的任意一层。

Omega 架构无需额外引入 MySQL、HBase 等组件，极大简化了数据架构，实现了湖仓市一体化（数据湖、数仓、集市一体化）。实现了全实时 Omega 架构的湖仓一体，我们也称之为实时湖仓一体。

偶数 Omega 架构兼容了离线和实时处理的数据架构，在实现层面，可以细分为时间驱动的微批架构、事件驱动架构、全场景架构。如果有对架构的具体设计和实现感兴趣的小伙伴，我们可以再后续的分享中详细介绍。

从离线转型实时，正在以肉眼可见的速度成为企业数字化转型的焦点。了解实时、走向实时、成为实时，将是企业在数字化竞争中的重要筹码。作为企业，选择前瞻性的实时数据处理技术也将有助于企业更快更稳的通向这场数字变革的终局。