摘要

本文深入探讨了大数据治理域中的实时数据开发，重点介绍了流式数据处理的核心价值、特点、技术挑战、典型能力和应用场景。同时，详细阐述了流式技术架构，包括数据采集、处理、存储和服务等环节，并针对大促场景提出了相应的技术措施，如实时任务优化、数据链路高可用和系统压测等，旨在为实时业务提供高效、稳定的数据支持。

1. 实时数据开发简介

实时数据开发的爆发是业务需求与技术能力共同作用的结果，未来随着AIoT和元宇宙等场景深化，实时数据处理将逐步成为企业数据架构的默认选项，而非补充方案。开发者需掌握流式技术栈，同时关注实时与离线系统的协同设计。实时数据开发是近年来随着大数据、物联网、人工智能等技术快速发展而兴起的重要领域，其背景和驱动力主要来自以下几个方面：

1.1. 业务需求的实时化

• 即时决策需求：金融交易、电商促销、交通调度等领域需要毫秒级响应，传统批处理（TSP）无法满足。
• 用户体验升级：如推荐系统（抖音、淘宝）、实时风险控制（反欺诈）等场景要求数据“新鲜度”。
• IoT与边缘计算：传感器、工业设备等产生的数据需实时处理（如预测性维护）。

1.2. 技术演进推动

• 流式计算框架成熟：Apache Kafka（消息队列）、Flink（低延迟计算）、Spark Streaming等开源技术的普及。
• 云原生与Serverless：AWS Kinesis、Google Pub/Sub等托管服务降低了实时开发门槛。
• 硬件性能提升：SSD、高速网络（5G）、GPU/TPU加速了数据处理效率。

1.3. 行业场景爆发

• 互联网：实时用户行为分析（点击流）、A/B测试、广告竞价（RTB）。
• 工业4.0：生产线监控、设备异常检测。
• 智慧城市：交通流量预测、应急事件响应。
• 金融科技：高频交易、实时风控、反洗钱（AML）。

1.4. 数据架构变革

• Lambda/Kappa架构的争议：从批流分离到流批一体（如Flink的统一计算模型）。
• 实时数仓兴起：替代传统T+1离线数仓，支持实时OLAP（如Apache Doris、ClickHouse）。
• 数据湖仓一体化：Delta Lake、Iceberg等支持实时数据更新。

1.5. 挑战与趋势

• 技术复杂度：需平衡一致性（Exactly-Once）、延迟和吞吐量。
• 成本问题：实时集群资源消耗远高于离线处理。
• 新兴方向：实时AI（在线模型推理）、时序数据库（Prometheus、InfluxDB）、联邦学习（边缘实时协作）。

2. 流式数据处理特点

流式数据处理的核心价值在于用更低的延迟挖掘数据时效性，但需权衡准确性、一致性和系统复杂度。现代流式计算框架（如Flink）通过事件时间语义、精确一次（Exactly-Once）等机制逐步解决了早期流处理的缺陷，使其成为实时业务的核心支撑技术。流式数据处理（Stream Processing）是针对连续无界数据流的实时计算模式，与传统的批处理（Batch Processing）有显著差异。其核心特点如下：

2.1. 数据特征

• 无界性（Unbounded）：数据流理论上无限持续，没有明确的终点（如传感器数据、用户点击流）。
• 时序性（Time-Series）：数据严格依赖时间顺序，乱序或延迟会影响结果准确性。
• 高吞吐（High Throughput）：数据可能以极高速率生成（如IoT设备每秒百万条记录）。

2.2. 处理模式

• 实时/近实时（Low Latency）：处理延迟从毫秒到秒级，远快于批处理的分钟/小时级。
• 增量计算（Incremental）：每条或每批数据到达时立即处理，无需等待全量数据。
• 持续运行（Continuous）：任务长期运行，7x24小时不间断（需容错机制保障）。

2.3. 技术挑战

• 乱序与迟到数据：需通过水位线（Watermark）、事件时间（Event Time）等机制处理。
• 状态管理：需维护中间状态（如窗口聚合结果），并支持故障恢复（如Checkpoint）。
• 资源动态调整：应对流量突增（如电商大促）需弹性扩缩容（如K8s+Flink）。

2.4. 典型能力

• 窗口计算（Window）：

• • 时间窗口（Tumbling/Sliding/Session）。
  • 计数窗口（每N条数据触发）。

• 流式关联（Stream Joins）：如双流Join（支付+订单流）、维表关联（实时查询Redis）。
• 复杂事件处理（CEP）：模式匹配（如检测“连续登录失败”）。

2.5. 与批处理的对比

维度	流式处理	批处理
数据范围	无界数据流	有界数据集
延迟	毫秒~秒级	分钟~小时级
计算逻辑	增量处理	全量处理
资源占用	长期占用（需高可用）	短期占用（任务结束释放）
典型框架	Flink、Kafka Streams	Spark（批模式）、MapReduce

2.6. 应用场景

• 实时监控：服务器指标异常检测（如Prometheus）。
• 实时推荐：用户行为即时分析（如抖音“划一推一”）。
• 金融风控：信用卡欺诈交易实时拦截。
• 物流调度：网约车订单动态派单。

3. 流式技术架构

在流式计算技术中，需要各个子系统之间相互依赖形成一条数据处理链路，才能产出结果最终对外提供实时数据服务。在实际技术选型时，可选的开源技术方案非常多，但是各个方案的整体架构是类似的，只是各个子系统的实现原理不太一样。另外，流式技术架构中的系统跟离线处理是有交叉的，两套技术方案并不是完全独立的，并且在业界中有合并的趋势。各个子系统按功能划分的话，主要分为以下几部分。

1. 数据采集

数据的源头，一般来自于各个业务的日志服务器（例如网站的浏览行为日志、订单的修改日志等)，这些数据被实时采集到数据中间件中，供下游实时订阅使用。

1. 数据处理

数据被采集到中间件中后，需要下游实时订阅数据，并拉取到流式计算系统的任务中进行加工处理。这里需要提供流计算引擎以支持流式任务的执行。

1. 数据存储

数据被实时加工处理（比如聚合、清洗等）后，会写到某个在线服务的存储系统中，供下游调用方使用。这里的写操作是增量操作，并且是源源不断的。

1. 数据服务

在存储系统上会架设一层统一的数据服务层（比如提供HSF接口、HTTP服务等)，用于获取实时计算结果。

从图5.2可以看出，在数据采集和数据服务部分实时和离线是公用的，因为在这两层中都不需要关心数据的时效性。这样才能做到数据源的统一，避免流式处理和离线处理的不一致。

3.1. 数据采集

数据采集是整个数据处理链路的源头，是所有数据处理链路的根节点，既然需要做到实时计算，那么自然就需要做到实时采集了。所采集的数据都来自于业务服务器，从所采集的数据种类来看，主要可以划分为两种：

• 数据库变更日志，比如MySQL的binlog日志、HBase的hlog日志、OceanBase的变更日志、Oracle的变更日志等。
• 引擎访问日志，比如用户访问网站产生的Apache引擎日志、搜索引擎的接口查询日志等。

不管是数据库变更日志还是引擎访问日志，都会在业务服务器上落地成文件，所以只要监控文件的内容发生变化，采集工具就可以把最新的数据采集下来。一般情况下，出于吞吐量以及系统压力上的考虑，并不是新增一条记录就采集一次，而是基于下面的原则，按批次对数据进行采集。

• 数据大小限制：当达到限制条件时，把目前采集到的新数据作为一批（例如512KB写一批）
• 时间阈值限制：当时间达到一定条件时，也会把目前采集到的新数据作为一批，避免在数据量少的情况下一直不采集（例如30秒写一批)

只要上面的其中一个条件达到了，就会被作为一批新数据采集到数据中间件中。这两个条件的参数需要根据业务的需求来设定，当批次采集频繁时，可以降低延时，但必然会导致吞吐量下降。

对于采集到的数据需要一个数据交换平台分发给下游，这个平台就是数据中间件。数据中间件系统有很多实现方式，比如开源的系统有Kafka,而阿里巴巴集团内部用得比较多的是TimeTunnel(原理和Kafka类似)，还有MetaQ、Notify等消息系统。从图5.3可以看出，消息系统是数据库变更节点的上游，所以它的延时比数据中间件低很多，但是其支持的吞吐量有限。因此，消息系统一般会用作业务数据库变更的消息中转，比如订单下单、支付等消息。对于其他较大的业务数据（每天几十TB的容量），一般会通过数据中间件系统来中转，虽然它的延时在秒级，但是其支持的吞吐量高。消息系统和数据中间件的性能对比如表5.1所示。

另外，在一些情况下，有些业务并没有通过消息系统来对数据库进行更新（比如有些子业务的订单数据是通过同步方式导入MySQL的）。

也就是说，从消息系统中获取的数据并不是最全的，而通过数据库变更日志拿到的业务变更过程数据肯定是全的。因此，为了和离线数据源保持一致，一般都是通过数据中间件来采集数据库变更数据这种形式来获取实时数据的（这需要在数据处理层对业务主键进行merge处理，比如一笔订单可能会被变更多次，会有多条变更记录，这时就需要进行merge拿到最新的数据)。

时效性和吞吐量是数据处理中的两个矛盾体，很多时候需要从业务的角度来权衡使用什么样的系统来做数据中转

3.2. 数据处理

实时计算任务部署在流式计算系统上，通过数据中间件获取到实时源数据后进行实时加工处理。在各大互联网公司中，有各种开源的和非开源的流计算引擎系统在使用。在业界使用比较广泛的是Twitter开源的Storm系统、雅虎开源的S4系统、Apache的Spark Streaming,以及最近几年兴起的Flik。这些系统的整体架构大同小异，但是很多细节上的实现方式不太一样，适用于不同的应用场景。

在阿里巴巴集团内使用比较多的是阿里云提供的StreamCompute系统，作为业界首创的全链路流计算开发平台，涵盖了从数据采集到数据生产各个环节，力保流计算开发严谨、可靠。其提供的SQL语义的流式数据分析能力(StreamSQL),让流数据分析门槛不再存在。它在Storm的基础上包装了一层SQL语义，方便开发人员通过写SQL就可以实现实时计算，不需要关心其中的计算状态细节，大大提高了开发效率，降低了流计算的门槛。当然，它也支持传统模式的开发，就像Hadoop中的Hive和MapReduce的关系一样，根据不同的应用场景选择不同的方式。另外，StreamCompute还提供了流计算开发平台，在这个平台上就可以完成应用的相关运维工作，不需要登录服务器操作，极大地提高了运维效率。

下面以Storm为例，简单讲一下流数据处理的原理。实时应用的整个拓扑结构是一个有向无环图（详情可参考Apache Storm的官网：

• spout:拓扑的输入，从数据中间件中读取数据，并且根据自定义的分发规则发送给下游的bolt,可以有多个输入源。
• bot:业务处理单元，可以根据处理逻辑分为多个步骤，其相互之间的数据分发规则也是自定义的。

实时数据处理应用出于性能考虑，计算任务往往是多线程的。一般会根据业务主键进行分桶处理，并且大部分计算过程需要的数据都会放在内存中，这样会大大提高应用的吞吐量。当然，为了避免内存溢出，内存中过期的数据需要定时清理，可以按照LRU（最近最少使用)算法或者业务时间集合归类清理（比如业务时间属于T1的，会在今天凌晨进行清理)。下面就实时任务遇到的几个典型问题进行讲解。

3.2.1. 去重指标

在BI(商业智能)统计类实时任务中，对于资源的消耗有一类指标是非常高的，那就是去重指标。由于实时任务为了追求处理性能，计算逻辑一般都是在内存中完成的，中间结果数据也会缓存在内存中，这就带来了内存消耗过多的问题。在计算去重时，势必要把去重的明细数据保存下来，当去重的明细数据达到上亿甚至几十亿时，内存中放不下了，怎么办？这时需要分两种情况去看：

• 精确去重。在这种情况下，明细数据是必须要保存下来的，当遇到内存问题时，可以通过数据倾斜来进行处理，把一个节点的内存压力分到多个节点上。
• 模糊去重。在去重的明细数据量非常大，而业务的精度要求不高的情况下，可以使用相关的去重算法，把内存的使用量降到千分之一甚至万分之一，以提高内存的利用率。

1. 布隆过滤器

该算法是位数组算法的应用，不保存真实的明细数据，只保存明细数据对应哈希值的标记位。当然，会出现哈希值碰撞的情况，但是误差率可以控制，计算出来的去重值比真实值小。采用这个算法存储1亿条数据只需要100多MB的空间。

适用场景：统计精度要求不高，统计维度值非常多的情况。比如统计全网各个商家的UV数据，结果记录数达到上千万条。因为在各个维度之间，布隆过滤器是可以共用的。

1. 基数估计

该算法也是利用哈希的原理，按照数据的分散程度来估算现有数集的边界，从而得出大概的去重值总和。这里估算的去重值可能比真实值大，也可能比真实值小。采用这个算法存储1亿条数据只需要几KB的内存。

适用场景：统计精度要求不高，统计维度非常粗的情况。比如整个大盘的UV数据，每天的结果只有一条记录。基数估计在各个维度值之间不能共用，比如统计全天小时的UV数据，就需要有24个基数估计对象，因此不适合细粒度统计的场景。

3.2.2. 数据倾斜

数据倾斜是ETL中经常遇到的问题，比如计算一天中全网访客数或者成交额时，最终的结果只有一个，通常应该是在一个节点上完成相关的计算任务。在数据量非常大的时候，单个节点的处理能力是有限的，必然会遇到性能瓶颈。这时就需要对数据进行分桶处理，分桶处理和离线处理的思路是一样的。

1. 去重指标分桶

通过对去重值进行分桶Hash,相同的值一定会被放在同一个桶中去重，最后再把每个桶里面的值进行加和就得到总值，这里利用了每个桶的CPU和内存资源。

1. 非去重指标分桶

数据随机分发到每个桶中，最后再把每个桶的值汇总，主要利用的是各个桶的CPU能力。

1. 事务处理

由于实时计算是分布式处理的，系统的不稳定性必然会导致数据的处理有可能出现失败的情况。比如网络的抖动导致数据发送不成功、机器重启导致数据丢失等。在这些情况下，怎么做到数据的精确处理呢？

上面提到的几个流计算系统几乎都提供了数据自动ACK、失败重发以及事务信息等机制。

1. 超时时间：由于数据处理是按照批次来进行的，当一批数据处理超时时，会从拓扑的spout端重发数据。另外，批次处理的数据量不宜过大，应该增加一个限流的功能（限定一批数据的记录数或者容量等)，避免数据处理超时。
2. 事务信息：每批数据都会附带一个事务D的信息，在重发的情况下，让开发者自己根据事务信息去判断数据第一次到达和重发时不同的处理逻辑。
3. 备份机制：开发人员需要保证内存数据可以通过外部存储恢复，因此在计算中用到的中间结果数据需要备份到外部存储中。

上面的这些机制都是为了保证数据的幂等性。

3.3. 数据存储

实时任务在运行过程中，会计算很多维度和指标，这些数据需要放在一个存储系统中作为恢复或者关联使用。其中会涉及三种类型的数据：

中间计算结果一在实时应用处理过程中，会有一些状态的保存(比如去重指标的明细数据)，用于在发生故障时，使用数据库中的数据恢复内存现场。

最终结果数据一指的是通过ETL处理后的实时结果数据，这些数据是实时更新的，写的频率非常高，可以被下游直接使用。

维表数据一在离线计算系统中，通过同步工具导入到在线存储系统中，供实时任务来关联实时流数据。后面章节中会讲到维表的使用方式。

数据库分为很多种类型，比如关系型数据库、列式数据库、文档数据库等，那么在选择实时任务所使用的数据库时应该注意哪些特征呢？

前面提到实时任务是多线程处理的，这就意味着数据存储系统必须能够比较好地支持多并发读写，并且延时需要在毫秒级才能满足实时的性能要求。在实践中，一般使用HBase、Tair、MongoDB等列式存储系统。由于这些系统在写数据时是先写内存再落磁盘，因此写延时在毫秒级，读请求也有缓存机制，重要的是多并发读时也可以达到毫秒级延时。

但是这些系统的缺点也是比较明显的，以HBase为例，一张表必须要有rowkey,而rowkey是按照ASCII码来排序的，这就像关系型数据库的索引一样，rowkey的规则限制了读取数据的方式。如果业务方需要使用另一种读取数据的方式，就必须重新输出rowkey。从这个角度来看，HBase没有关系型数据库方便。但是HBase的一张表能够存储几TB甚至几十TB的数据，而关系型数据库必须要分库分表才能实现这个量级的数据存储。因此，对于海量数据的实时计算，一般会采用非关系型数据库，以应对大量的多并发读写。

1. 表名设计

设计规则：汇总层标识+数据域+主维度+时间维度例如：dws trd slr dtr,表示汇总层交易数据，根据卖家(slr)主维度+0点截至当日(dtr)进行统计汇总。这样做的好处是，所有主维度相同的数据都放在一张物理表中，避免表数量过多，难以维护。另外，可以从表名上直观地看到存储的是什么数据内容，方便排查问题。

1. rowkey设计

设计规则：MD5+主维度+维度标识+子维度1+时间维度子维度2，

例如：卖家ID的MD5前四位+卖家ID+app+一级类目ID+ddd+二级类目ID。以MD5的前四位作为rowkey的第一部分，可以把数据散列，让服务器整体负载是均衡的，避免热点问题。在上面的例子中，卖家D属于主维度，在查数据时是必传的。每个统计维度都会生成一个维度标识，以便在rowkey上做区分。

3.4. 数据服务

实时数据落地到存储系统中后，使用方就可以通过统一的数据服务获取到实时数据。比如下一章将要讲到的OneService,其好处是：

• 不需要直连数据库，数据源等信息在数据服务层维护，这样当存储系统迁移时，对下游是透明的。
• 调用方只需要使用服务层暴露的接口，不需要关心底层取数逻辑的实现。
• 屏蔽存储系统间的差异，统一的调用日志输出，便于分析和监控下游使用情况。

4. 流式数据模型

数据模型设计是贯通数据处理过程的，流式数据处理也一样，需要对数据流建模分层。实时建模跟离线建模非常类似，数据模型整体上分为五层(ODS、DWD、DWS、ADS、DIM)。

由于实时计算的局限性，每一层中并没有像离线做得那么宽，维度和指标也没有那么多，特别是涉及回溯状态的指标，在实时数据模型中几乎没有。

整体来看，实时数据模型是离线数据模型的一个子集，在实时数据处理过程中，很多模型设计就是参考离线数据模型实现的。下面从数据分层、多流关联、维表使用这三个方面来详细说明。

4.1. 数据分层

在流式数据模型中，数据模型整体上分为五层。

1. ODS层

跟离线系统的定义一样，ODS层属于操作数据层，是直接从业务系统采集过来的最原始数据，包含了所有业务的变更过程，数据粒度也是最细的。在这一层，实时和离线在源头上是统一的，这样的好处是用同一份数据加工出来的指标，口径基本是统一的，可以更方便进行实时和离线间数据比对。例如：原始的订单变更记录数据、服务器引擎的访问日志。

1. DWD层

DWD层是在ODS层基础上，根据业务过程建模出来的实时事实明细层，对于访问日志这种数据（没有上下文关系，并且不需要等待过程的记录)，会回流到离线系统供下游使用，最大程度地保证实时和离线数据在ODS层和DWD层是一致的。例如：订单的支付明细表、退款明细表、用户的访问日志明细表。

1. DWS层

订阅明细层的数据后，会在实时任务中计算各个维度的汇总指标。如果维度是各个垂直业务线通用的，则会放在实时通用汇总层，作为通用的数据模型使用。比如电商网站的卖家粒度，只要涉及交易过程，就会跟这个维度相关，所以卖家维度是各个垂直业务的通用维度，其中的汇总指标也是各个业务线共用的。例如：电商数据的几大维度的汇总表(卖家、商品、买家)。

1. ADS层

个性化维度汇总层，对于不是特别通用的统计维度数据会放在这一层中，这里计算只有自身业务才会关注的维度和指标，跟其他业务线一般没有交集，常用于一些垂直创新业务中。例如：手机淘宝下面的某个爱逛街、微淘等垂直业务。

1. DIM层

实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线系统中供实时应用调用。这一层对实时应用来说是静态的，所有的ETL处理工作会在离线系统中完成。维表在实时应用的使用中跟离线稍有区别，后面章节中会详细说明。例如：商品维表、卖家维表、买家维表类目维表。

下面通过简单的例子来说明每一层存储的数据。

1. ODS层：订单粒度的变更过程，一笔订单有多条记录。
2. DWD层：订单粒度的支付记录，一笔订单只有一条记录。
3. DWS层：卖家的实时成交金额，一个卖家只有一条记录，并且指标在实时刷新。
4. ADS层：外卖地区的实时成交金额，只有外卖业务使用。
5. DM层：订单商品类目和行业的对应关系维表。

其中，ODS层到DM层的ETL处理是在离线系统中进行的，处理完成后会同步到实时计算所使用的存储系统。ODS层和DWD层会放在数据中间件中，供下游订阅使用。而DWS层和ADS层会落地到在线存储系统中，下游通过接口调用的形式使用。

在每一层中，按照重要性划分为P0、P1、P2、P3等级，P0属于最高优先级保障。根据不同的优先级给实时任务分配不同的计算和存储资源，力求重要的任务可以得到最好的保障。

4.2. 多流关联

在流式计算中常常需要把两个实时流进行主键关联，以得到对应的实时明细表。在离线系统中两个表关联是非常简单的，因为离线计算在任务启动时已经可以获得两张表的全量数据，只要根据关联键进行分桶关联就可以了。但流式计算不一样，数据的到达是一个增量的过程，并且数据到达的时间是不确定的和无序的，因此在数据处理过程中会涉及中间状态的保存和恢复机制等细节问题。

比如A表和B表使用D进行实时关联，由于无法知道两个表的到达顺序，因此在两个数据流的每条新数据到来时，都需要到另外一张表中进行查找。如A表的某条数据到达，到B表的全量数据中查找，如果能查找到，说明可以关联上，拼接成一条记录直接输出到下游；但是如果关联不上，则需要放在内存或外部存储中等待，直到B表的记录也到达。多流关联的一个关键点就是需要相互等待，只有双方都到达了，才能关联成功。

在上面的例子中，实时采集两张表的数据，每到来一条新数据时都在内存中的对方表截至当前的全量数据中查找，如果能查找到，则说明关联成功，直接输出；如果没查找到，则把数据放在内存中的自己表数据集合中等待。另外，不管是否关联成功，内存中的数据都需要备份到外部存储系统中，在任务重启时，可以从外部存储系统中恢复内存数据，这样才能保证数据不丢失。因为在重启时，任务是续跑的，不会重新跑之前的数据。

另外，订单记录的变更有可能发生多次（比如订单的多个字段多次更新)，在这种情况下，需要根据订单D去重，避免A表和B表多次关联成功；否则输出到下游就会有多条记录，这样得到的数据是有重复的。以上是整体的双流关联流程，在实际处理时，考虑到查找数据的性能，实时关联这个步骤一般会把数据按照关联主键进行分桶处理，并且在故障恢复时也根据分桶来进行，以降低查找数据量和提高吞吐量。

4.3. 维表使用

在离线系统中，一般是根据业务分区来关联事实表和维表的，因为在关联之前维表的数据就已经就绪了。而在实时计算中，关联维表一般会使用当前的实时数据(T)去关联T-2的维表数据，相当于在T的数据到达之前需要把维表数据准备好，并且一般是一份静态的数据。

为什么在实时计算中这么做呢？主要基于以下几点的考虑。

1. 数据无法及时准备好

当到达零点时，实时流数据必须去关联维表（因为不能等待，如果等就失去了实时的特性)，而这个时候T1的维表数据一般不能在零点马上准备就绪（因为T-1的数据需要在T这一天加工生成)，因此去关联T-2维表，相当于在T-1的一天时间里加工好T-2的维表数据。

1. 无法准确获取全量的最新数据

维表一般是全量的数据，如果需要实时获取到当天的最新维表数据，则需要T-1的数据+当天变更才能获取到完整的维表数据。也就是说，维表也作为一个实时流输入，这就需要使用多流实时关联来实现。但是由于实时数据是无序的并且到达时间不确定，因此在维表关联上有歧义。

1. 数据的无序性

如果维表作为实时流输入的话，获取维表数据将存在困难。比如10:00点的业务数据成功关联维表，得到了相关的维表字段信息，这个时候是否就已经拿到最新的维表数据了呢？其实这只代表拿到截至10:00点的最新状态数据（实时应用永远也不知道什么时候才是最新状态，因为不知道维表后面是否会发生变更)。因此在实时计算中维表关联一般都统一使用T-2的数据，这样对于业务来说，起码关联到的维表数据是确定的（虽然维表数据有一定的延时，但是许多业务的维表在两天之间变化是很少的)。在有些业务场景下，可以关联T1的数据，但T-1的数据是不全的。比如在T1的晚上22：00点开始对维表进行加工处理，在零点到达之前，有两个小时可以把数据准备好，这样就可以在T的时候关联T1的数据了，但是会缺失两个小时的维表变更过程。另外，由于实时任务是常驻进程的，因此维表的使用分为两种形式。

• 全量加载：在维表数据较少的情况下，可以一次性加载到内存中，在内存中直接和实时流数据进行关联，效率非常高。但缺点是内存一直占用着，并且需要定时更新。例如：类目维表，每天只有几万条记录，在每天零点时全量加载到内存中。
• 增量加载：维表数据很多，没办法全部加载到内存中，可以使用增量查找和LRU过期的形式，让最热门的数据留在内存中。其优点是可以控制内存的使用量；缺点是需要查找外部存储系统，运行效率会降低。例如：会员维表，有上亿条记录，每次实时数据到达时，去外部数据库中查询，并且把查询结果放在内存中，然后每隔一段时间清理一次最近最少使用的数据，以避免内存溢出。

在实际应用中，这两种形式根据维表数据量和实时性能要求综合考虑来选择使用。

5. 大促挑战与保障

5.1. 大促特征

大促和日常比较，在数据量以及要求上有非常大的区别，日常不怎么关注的点，在大促的时候会被放大，并且一天中的峰值特别明显，数据量是其他时间点的几倍甚至数十倍，这对系统的抗压能力要求非常高，不能因为洪流的到来而把系统压垮。

1. 毫秒级延时

大促期间，业务方和用户都会对实时数据非常关注，特别是在跨过零点的时候，第一个实时数字的跳动对业务方来说意义重大，预示着大促狂欢节真正开始。其他的产品，例如全球媒体直播大屏，更是要求延时达到毫秒级。这种要求吞吐量和延时兼得的情况，必须要做一些有针对性的优化工作才能满足要求。

1. 洪峰明显

大促就是全国乃至全世界的狂欢节，零点开售时的峰值陡峰是非常明显的，一般是日常峰值的几十倍，这对数据处理链路的每个系统都是巨大的挑战。因此，在大促前会进行多次全链路压测和预案梳理，确保系统能够承载住洪峰的冲击。

1. 高保障性

由于关注的人非常多，只要出现数据延迟或者数据质量的问题，业务方的反弹就比较大，并且会第一时间感知到数据异常。因此，在大促期间一般都要求高保障性，一些特殊的情况甚至需要做到强保障。对于强保障的数据，需要做多链路冗余（从采集、处理到数据服务整个数据链路都需要做物理隔离)（见图5.7）。当任何一条链路出现问题时，都能够一键切换到备链路，并且需要对业务方透明，让下游感知不到有链路上的切换（由于各个链路计算的速度有一定的差异，会导致数据在切换时出现短时间下跌的情况，使用方需要做指标大小的判断，避免指标下跌对用户造成困扰)。

1. 公关特性

大促期间，数据及时对公众披露是一项重要的工作，这时候要求实时计算的数据质量非常高。这里面涉及主键的过滤、去重的精准和口径的统一等一系列问题，只有把每一个环节都做好才能保障和离线的数据一致。大促是一场对数据计算的高吞吐量、低延时、高保障性、高准确性的挑战。

5.2. 大促技术措施

5.2.1. 实时任务优化

大促前的优化工作在实时计算中显得尤为重要，如果吞吐量跟不上的话，也就失去了实时的特性。吞吐量不佳原因非常多，有些跟系统资源有关，有些跟实现方式有关，以下几点是实时任务优化中经常需要考虑的要素。

1. 独占资源和共享资源的策略

在一台机器中，共享资源池可以被多个实时任务抢占，如果一个任务在运行时80%以上的时间都需要去抢资源，这时候就需要考虑给它分配更多的独占资源，避免抢不到CPU资源导致吞吐量急剧下降。

1. 合理选择缓存机制，尽量降低读写库次数

内存读写性能是最好的，根据业务的特性选择不同的缓存机制，让最热和最可能使用的数据留在内存中，读写库次数降低后，吞吐量自然就上升了。

1. 计算单元合并，降低拓扑层级

拓扑结构层级越深，性能越差，因为数据在每个节点间传输时，大部分是需要经过序列化和反序列化的，而这个过程非常消耗CPU和时间。

1. 内存对象共享，避免字符拷贝

在海量数据处理中，大部分对象都是以字符串形式存在的，在不同线程间合理共享对象，可以大幅降低字符拷贝带来的性能消耗，不过要注意不合理使用带来的内存溢出问题。

1. 在高吞吐量和低延时间取平衡

高吞吐量和低延时这两个特性是一对矛盾体，当把多个读写库操作或者ACK操作合并成一个时，可以大幅降低因为网络请求带来的消耗，不过也会导致延时高一些，在业务上衡量进行取舍。

5.2.2. 数据链路高可用

实时数据的处理链路非常长（数据同步一→数据计算一数据存储一数据服务)，每一个环节出现问题，都会导致实时数据停止更新。实时计算属于分布式计算的一种，而单个节点故障是常态的，这种情况在直播大屏中表现特别明显，因为数据不再更新，所有的用户都会发现数据出现了问题。因此，为了保障实时数据的可用性，需要对整条计算链路都进行多链路搭建，做到多机房容灾，甚至异地容灾（见图5.8）。

由于造成链路问题的情况比较多，并且一般不能在秒级定位到原因，因此会通过工具比对多条链路计算的结果数据，当某条链路出现问题时，它一定会比其他链路计算的值小，并且差异会越来越大。这时候会一键切换到备链路，并且通过推送配置的形式让其秒级生效，所有的接口调用会立刻切换到备链路，对直播大屏完全透明，并且用户也感知不到故障的发生。

5.2.3. 系统进行压测

在大促备战中，会对实时链路进行多次压测，主要是模拟“双11的峰值情况，验证系统是否能够正常运行。压测都是在线上环境中进行的，分为数据压测和产品压测。

数据压测主要是蓄洪压测，就是把几个小时甚至几天的数据积累下来，并在某个时刻全部放开，模拟“双11”洪峰流量的情况，这里面的数据是真实的。比如通过把实时作业的订阅数据点位调到几个小时或者几天前，这时候每一批读到的数据都是最多的，对实时计算的压力也最大。

产品压测还细分为产品本身压测和前端页面稳定性测试。

1. 产品本身压测

收集大屏服务端的所有读操作的URL,通过压测平台进行压测流量回放，按照QPS:500次/秒的目标进行压测。在压测过程中不断地迭代优化服务端的性能，提升大屏应用处理数据的性能。

1. 前端页面稳定性测试

将大屏页面在浏览器中打开，并进行8~24小时的前端页面稳定性测试。监控大屏前端JS对客户端浏览器的内存、CPU等的消耗，检测出前端JS内存泄漏等问题并修复，提升前端页面的稳定性。

6. 博文参考

• 《阿里巴巴大数据实战》