摘要：本文整理自 Flink Forward Asia 2023 中闭门会的分享。主要分享实时计算在各行业的应用实践，对回归实时计算的重点场景进行介绍以及企业如何使用实时计算技术，并且提供一些在技术架构上的参考建议。内容分为以下四个部分：
业务需求变化推动架构演进
实时计算在各行业的应用与实践
从数据看实时计算在各行业的趋势
总结
一、业务需求变化推动架构演进
任何技术的发展都是随着业务需求而推动。那么随着业务技术的需求推动，是如何发展到当前的技术形态呢？
在早期，企业依靠数据分析和数据仓库查看到最近的数据，如昨天、一个月前乃至三个月前的数据。许多企业的数据仓库是基于像 MySQL、Oracle、DB2 这样的传统单机数据库系统搭建的。随着时间推移，企业对历史数据的分析需求增加，需要分析的数据也越来越多，时间跨度也扩大到了三年、五年，甚至十年，导致单机架构在这种海量数据分析需求面前也显得力不从心。因此，分布式数据库如 Teradata、Greenplum (GP) 应运而生，帮助解决在海量数据情况下企业快速数据分析的需求，并且解决了第二个问题："大"和"快"的问题。 从2006 年 Hadoop 成为开源社区的顶级项目开始，企业大规模使用 Hadoop 来做离线分析，标志着数据处理能力的一个重要进步。
随着互联网技术的发展，传统的数据仓库已经不仅限于关系数据，可能来自于互联网的行为日志数据，也可能来自不同设备的终端时序数据，这些数据在传统数据仓库中没有办法基于 SQL、存储过程来分析，而是需要基于 MapReduce、 Spark 以及 Python 方式对数据进行预处理和分析。在这种情况下就需要一种新的系统 Hadoop，目前大多数企业已经在这个阶段过渡。后来业务需求对实质性的要求越来越高，需要的不再是 T+1 的数据，而是需要根据前一个小时、前一分钟、前一秒的业务动态来判断下一个角色。所以对时效性要求越来越高，这促使着现在的流计算技术发展，使 Flink 成为企业的一个在实时计算的事实标准。
二、实时计算在各行业的应用与实践
接下来分享四个实时计算使用比较多的行业，分别是金融、汽车，交通物流以及零售行业。分享一下在这些行业场景中是如何使用大数据实时计算相关的技术，以及近几年实时计算使用的比例变化。
1. 金融行业
金融业在实时计算的应用里基本上处于百花齐放的状态。不仅可以收到实时推荐的消息、股票交易的动态变化等，而且除了这些情况外，金融机构还会做 To B 端企业服务和私募基金的相关服务。对大客营销需要针对性的监管报送，实时将企业、金融机构的风险提供给监管部门，这些都需要大量的实时计算技术。
接下来举两个行业场景的例子，金融行业是如何使用相关大数据实时计算技术的？下图是一个案例证券交易行为。
在当前股市中，对交易监控的实时性要求极高，主要是因为市场价格波动迅速，股民的交易行为需要得到即时的监管。例如，在实施注册制之前，如果股票的交易价格为 100 元，投资者可以挂出 110 元的买单。在极短的时间内，可能价格就会涨到 110 元，从而使投资者获得 10% 的收益。但注册制实行后，挂单价格的上限受到限制，不得超过当前卖出价格溢价的 2%，也就是说最高只能挂 102 元。这样的变化意味着对交易行为实施实时监控和告警，以及在必要时进行阻断变得更加重要。如果阻断措施延迟，可能会引发数据合规性问题。因此，为了确保合规并保护投资者的利益，对于交易行为的监控系统必须做到快速反应。
举个例子，在股市交易监控方面，各种订单数据，如股票的买入量、当前报价及股票代码，以实时数据的形式流入系统并进入消息队列。除了这些流式数据，还需要引入与所购股票相关的基本信息，比如客户购买的财报数据、昨日的涨停价和开盘价等。这些基础数据存储于 Hologres 中，以维表的形式存在，用于与流式数据进行关联。数据关联之后，再利用 Flink 对这些信息进行加工和判断分析。如果检测到用户在近几分钟内挂出的订单价格超过了当下价格的 2%，系统会立即采取阻断措施并发出告警。考虑到场景架构图中存在众多的风险和交易规则，我们采用基于复杂事件处理（CEP）的方法来实现风控规则，而上述只描述了其中一条规则。同时，还可能需要引入离线数据来补充用户信息。这些离线数据每天按照T+1模式更新，通过分析这些历史数据并将它们与实时数据结合，可以对交易情况做出更加细致的判断。
下面第二个案例是零售银行面向 c 端的用户推荐。
银行和许多金融机构会定期发布各种促销活动，包括针对股票和基金的活动。作为用户，当通过 APP 或 H5 页面点击参与活动时，就会生成一条实时触发的消息流。接下来，系统需要判断这个用户应该得到多少优惠券，并且通过积分奖励的方式鼓励用户完成购买，形成销售的闭环。为了处理这个流程，整个链路会使用 Flink+Hologres 来协助客户做处理。
2. 汽车行业
近年来，随着新能源汽车产业的快速发展，汽车行业对数据的依赖日益增加，数据量的增长速度非常迅猛。可以看到一个现象，在云上的多数企业 CPU 和内存的使用成本远远高于数据存储成本，在云上的来说存储相对廉价。然而，汽车行业的情况颇为独特，由于数据涌现速度极快，特别是新能源汽车产生的数据已经在云平台上造成存储成本超过计算成本的现象。
汽车行业从初期的研发制造、供应链、销售、再到对外的服务，整个链路都包含了众多的实时场景与应用。包括在研发阶段需要对研发过程的实时监控、研发参数的实时告警。在供应链环节，对零部件进行实时预警同样关键，每一个供应链环节都可能直接影响到一个企业的业务目标和销售业绩。在销售环节，针对C端用户的商品推荐和行为分析也极为重要。
另一个场景是在服务阶段，如何提供良好的汽车服务以促进二次销售也是企业需要关注的场景。下文将介绍一个重要的行业应用：新能源汽车的车联网场景。随着车辆上装配的摄像头、传感器和雷达数量的增多，这背后采集到的数据量也在相应增加。
我们有一个客户，每天要采集大约 42 亿条数据，采集频率是每秒一次。相比之下，在一年前他们可能是每天只采集一次数据。随后这个频率提高到了每10分钟一次，继而因为业务需求，他们需要将采集频率从原先的每 10 秒逐步过渡到每秒采集。此外，我们还有汽车行业的客户，现在已经需要达到每 500 毫秒采集一次数据。以 30 万辆运行中的车为例，如果每秒采集数据一次，就意味着每秒需要采集 30 万条数据。然而，这些数据与其他行业的数据有所不同，一条数据就可能包含多达 3,000 到 4,000 个字段的信号数据
在车联网场景中，前端设备可能是 TBOX 或 TSB 这样的车载平台，它们通常采集的是二进制数据。许多企业首要的工作是利用 Flink 将这些车载二进制信号数据转换成后续可进行分析的结构化数据，这是处理流程的第一步。接下来，他们可能会使用 Hologres 进行实时的在线分析服务。针对汽车行业高昂的存储成本问题，Hologres也推出了价格更低廉的存储产品，包括低频访问的存储解决方案，帮助客户在处理海量数据时实现存储分层，从而帮助降低整体成本。
下面是介绍新能源汽车行业，结合刚才的实时数据可以做的哪些场景。
在这一场景中，我们可以采集到多种车辆数据，包括车辆所处的车道、驾驶员是否双手握方向盘、车速以及车辆是左转还是右转等信息。通过分析这些数据，系统能够判断驾驶员是否存在危险驾驶行为。例如，如果一个驾驶员在五分钟内持续双手脱离方向盘，或者在高速公路上连续五分钟的速度超过 150 公里/小时，那么系统就会将其归类为危险驾驶，并可能采取相应措施向客户发出预警。
同时，还可以根据这些数据对用户进行画像。如果数据显示用户偏好激烈的驾驶行为，那么在下一次购车时，系统可能会向该用户推荐性能更强的车型。如今，无论是传统主机厂还是排名前十的新能源汽车制造商，超过 70% 的车联网平台都在运行于阿里云上。结合这些企业的实践经验，阿里云推出了一套面向车联网行业的推荐参考架构。许多领先的汽车厂家都按照这套架构实施其车联网平台。
下图左侧是实时架构，右侧是离线架构。
实时数仓与实时计算的主要区别在于数据的处理和管理方式。在传统的数仓中，数据通常会进行层次化处理，涉及到离线数据的不同层级，比如 DWD、DWS 和 ADS。然而，在实时计算中，进行层次化分隔较为困难，因为它缺乏统一的存储层次。例如，ODS 层的数据可能存放在 Kafka 中，加工后的 DWD 层数据可能放在 RDS 中，这些数据难以统一管理。目前，阿里云通过整合 Flink 和 Hologres 技术，使接入的数据在消息队列中存储，并经过 Flink 的处理转化成宽表格式，之后统一存放在 Hologres 中，实现了数据流的实时处理与分析。
很多业务部门早期将数据存放在消息队列中，但这样做无法执行查询，也无法使用 SQL 语句进行数据操作。现在，可以将宽表格式的数据直接存储在 Hologres 中，并且借助 Flink 按照离线数仓的层次化架构，加工形成指标数据后统一存放入 Hologres 引擎。将 Hologres 定义为面向业务的唯一数据出口，避免了对其他关系数据库和 Key-Value 数据库的依赖。将所有数据集中存储在 Hologres 中后，前端应用、报表和各种数据产品都能基于 Hologres 实现数据的统一访问与输出，这样不仅简化了数据架构还提升了数据处理的效率。
3. 物流行业
预计今年，许多物流企业采用实时计算的比例将超过50%。
物流行业在数据流转方面与零售行业相似，都是围绕着人、货和场所进行。一个显著特点是物流行业对位置信息的要求日益增高。用户在下单之后会时刻关注快递的位置，因此，物流企业开始围绕位置信息展开实时计算的数据加工与处理。数据的生成起始于用户通过手机APP下单或电话联系快递员上门这样的环节，从而形成一套订单信息。这些订单在物流企业内部经过分发处理后，转换为具体的运单信息。运单形成后，进一步贯穿于派送和签收等环节。在整个流程中，对链路时效性的要求越来越高，用户对数据更新的容忍度逐渐降低，希望能够实时、每秒钟都能看到最新的快递信息。
下面举几个简单的场景，第一个场景是大件物流。与小件快递不同，大件物流主要是做快运。
快运服务的一个特点是车辆类型的多样性，包括大、中、小型车辆，此外还有许多特定的标签，比如载重能力。例如，如果一个客户需要运输两吨重的物品，但是分配了一个能承载十吨重的车辆，这显然会有些浪费。背后的匹配逻辑相当复杂，因为有时两吨重的货物实际上可能因体积较大而需要更大的车辆。那么，该如何有效地进行车辆与货物间的匹配呢？这就需要通过数据对车辆和货物进行精确的标记，随后实时计算技术便可以根据用户货物的变化和位置变化进行合适的匹配与推荐。
接下来看第二个场景：
疫情期间所带来的挑战可能让人感受更为明显，比如一个企业负责从杭州到北京的大件物流运输。在这种情况下，可能会遇到运至某城市时发现该城市正处于疫情管控，无法通过。这样原本确定的物流单可能被迫取消，导致货主双方都面临一系列问题。为了解决这类问题，借助实时计算技术，司机可以实时上报自己的位置和其他相关信息，这通常需要硬件的支持；同时，货主端也能实时监控货物的状态变化。通过这种方式，能够有效提高整个物流过程的效率和响应时效。
以下就是围绕刚才讲的两个场景，物流行业场景的整个技术架构图。
总体来看，涉及的数据包括订单数据、货源数据、司机数据以及用户会员数据等。这些数据如何进行有效匹配呢？在这样的数据架构背后，不仅包括了实时的流消息，还涉及到离线的用户标签数据、车辆的静态维度表数据等多种数据类型。利用 Flink 技术，可以综合处理这些不同来源的流数据和静态维表数据进行必要的加工处理。加工后的数据可以应用于多种业务场景，例如智能匹配车辆与货物、实时监控路线以及提供最优路线推荐等，有效地优化物流配送的效率和服务质量。
针对这个场景，我们提出了一个参考架构。前端的埋点数据、用户端数据以及 APP 上报的数据将会统一推送到消息队列 Data Hub 中。数据一旦推送到 Data Hub，就会通过 Flink 进行实时的接入和加工处理。处理完成的数据随后会统一存储到 Hologres 中。前端应用可能直接从 Hologres 中执行 OLAP 分析，或者在这基础上进行实时决策支持。 Hologres 可以提供实时的运力匹配关系、供需动态以及实时轨迹分析等关键业务信息，这些功能在需要快速响应市场变化和用户需求的业务场景应用中特别重要。在架构的右侧，主要针对的是离线场景，同样会将实时处理的数据写入离线的对象存储中，以便用于离线数据的进一步补充和处理。
4. 零售行业
零售行业是最早开始采用实时计算的行业之一。阿里巴巴在最初开展双11大促活动时，就已经能够通过大屏实时展示当前的销售动态数据。企业的决策者们需要了解当前的销售情况，并依据这些实时数据进行相关的决策。接下来，我会举两个具体的例子来说明。
第一个例子是，在特别是像双十一、双十二这样的大型促销中，许多零售企业会准备大量促销活动。假设企业需要准备 1,000 万优惠券，它们需要对这 1,000 万的优惠券的动向进行实时监控。接着，根据优惠券的发放情况，需要进行动态的调整。如果在最开始的五分钟内 1,000 万优惠券就被抢光了，企业需要立刻决策是否再追加 1,000 万以增加用户转化率？这些都是在营销的全过程中，包括营销前、营销中、营销后，业务流程中需要考虑的因素。
在技术实现方面，离线场景涉及到大量的历史数据，包括用户的行为、他们偏好的服装类型、年龄和性别等信息，这些都会被储存在历史数据平台上。当出现购买信息或潜在的点击行为时，基于 Flink 引擎可以帮助实时作出判断。它能预测用户是否可能在接下来的两分钟内下单，并且识别出哪种优惠券对用户来说更有吸引力。整个过程需要 Flink 利用技术手段来进行评估和决策。下图是实施营销的一个决策方案架构：
下面是第二个场景：
很多企业依赖实时数据分析来强化其商业决策，这需要能够迅速向企业决策者和各个业务部门提供关键信息。例如，精确追踪某个用户在特定页面的停留时间及其带来了多少转化率。基于一款提供相关查询和分析的平台，简而言之，用户需要进行查询，尽管这背后可能涉及海量的数据，可能是几亿甚至几十亿条记录。那么如何解决这一挑战呢？解决方案是通过 Hologres。我们可以看到，底层的数据被存储在 Hologres 中，并且可能存在各种检索条件。基于这些检索条件系统需要快速地给业务提供决策支持和响应能力。比如，可能需要查询特定品类、用户当前行为、某个商品占位信息或广告投放的效率等。基于多样的检索条件，Hologres 提供的 OLAP 查询能力可以满足这些需求，从而实现客户对于数据的快速查询。
下面是在线做电商的一个客户，基本上几十 TB 级的数据。自助分析的响应速度控制在 3 秒以内，基本上 99% 的查询都是在 3 秒以内响应，业务方认为这样的速度能够非常快捷地帮助他们提高决策效率。
零售行业也提出了一个参考架构。
在零售行业中，数据仓库通常包含了如商品、会员、销售、售后和运营等多个标准化领域，这些分域和层次结构一般来说都非常规范和通用。基于这样的架构，可以借助阿里云的 MaxCompute 来执行离线数据仓库的分层处理。对于实时计算需求，则可以通过结合 Flink 和 Hologres 来实现实时数据仓库的操作，以及构建统一的架构。至于调度管理层，可以使用 DataWorks 来提供统一的工作流程调度和数据加工服务。这是一个在零售行业常见的推荐架构。上述四个方面是对实时计算依赖性较高且使用效果良好的行业中的典型应用场景。
三、从数据看实时计算在各行业的趋势
根据阿里云发布的公有云数据报告，中国大约有 50% 的大数据用户选择使用阿里云服务，拥有数万名大数据客户。从这些客户数据中做出的简单分析显示，在四年前的 2020 年，实时计算的普及率还相对较低，基本都在 10% 以内。大部分企业当时仍然主要依赖于 T+1 的小时级离线分析。然而，预计下一年，金融行业实时计算的使用比例将超过 25%，物流行业的比例可能会超过 50%。因此，实时计算成为未来发展的一个关键考虑点。整个行业实时计算的用例预计都会超过 30%，这表明实时计算的普及率正处于一个迅速上升的阶段。
四、总结
作为阿里云计算平台的成员之一，除了今天讨论的实时计算技术之外，还基于服务数万+客户的经验，沉淀出了面向未来的一套云上数据仓库参考架构。这一架构的设计旨在为客户提供一套高效、可靠、可扩展的数据处理与分析平台，以支撑大数据、人工智能和数据仓库等多种复杂应用场景。
在未来的交流和分享中，我们将基于这一推荐的参考架构，深入探讨如何有效地利用大数据技术、人工智能能力以及数据仓库功能，来帮助客户解锁数据价值，推动业务成长和创新。通过这些互动，我们希望与客户共同探索和实践最佳的云计算解决方案，以满足客户不断变化的业务需求。
