大数据之路-实时技术（第五章）

   在大数据系统中，离线批处理技术可以满足非常多的数据使用场景需求，但在 DT 时代， 每天面对的信息是瞬息万变的，越来越多的应用场景对数据的时效性提出了更高的要求。数据价值是具有时效性的，在一条数据产生的时候，如果不能及时处理并在业务系统中使用，就不能让数据保持最高的“新鲜度”和价值最大化。

5.1 简介

  相对于离线批处理技术，流式实时处理技术作为一个非常重要的技术补充，在阿里巴巴集团内被广泛使用。在大数据业界中，流计算技术的研究是近年来非常热门的课题。

  业务诉求是希望能在第一时间拿到经过加工后的数据，以便实时监控当前业务状态并做出运营决策，引导业务往好的方向发展。比如网站上一个访问量很高的广告位，需要实时监控广告位的引流效果，如果转化率非常低的话，运营人员就需要及时更换为其 广告 以避免流量资源的浪费。在这个例子中，就需要实时统计广告位的曝光和点击等指标作为运营决策的参考。

  按照数据的延迟情况，数据时效性一般分为三种（离线、准实时、实时）：

• 离线：在今天（ ）处理 天前 N, N > I ）的数据，延迟时间粒度为天。
• 准实时 ：在当前小时（ ）处理 小时前 H-N, N>O ，如 0.5小时、 小时等）的数据，延迟时间粒度为小时。
• 实时 ：在当前时刻处理当前的数据，延迟时间粒度为秒；

  离线和准实时都可以在批处理系统中实现（比如 HadoopMax Compute Spark 等系统），只是调度周期不一样而己，而实时数据则需要在流式处理系统中完成。简单来说，流式数据处理技术是指业务系统每产生一条数据，就会立刻被采集并实时发送到流式任务中进行处理，不需要定时调度任务来处理数据。
  整体来看 ，流式数据处理一般具有以下特征。

1. 时效性高

  数据实时采集、实时处理，延时粒度在秒级甚至毫秒级，业务方能够在第一时间拿到经过加工处理后的数据。

2. 常驻任务

  区别于离线任务的周期调度，流式任务属于常驻进程任务， 一旦启动后就会一直运行，直到人为地终止，因此计算成本会相对比较高。这一特点也预示着流式任务的数据源是无界的，而离线任务的数据源是有界的。这也是实时处理和离线处理最主要的差别，这个特性会导致实时任务在数据处理上有一定的局限性。

3. 性能要求高

  实时计算对数据处理的性能要求非常严格，如果处理吞吐量跟不上采集吞吐量，计算出来的数据就失去了实时的特性。比如实时任务1分钟只能处理 30 秒采集的数据，那么产出的数据的延时会越来越长，不能代表当前时刻的业务状态，有可能导致业务方做出错误的运营决策。在互联网行业中，需要处理的数据是海量的，如何在数据量快速膨胀的情况下也能保持高吞吐量和低延时，是当前面临的重要挑战。因此，实时处理的性能优化占了任务开发的很大一部分工作。

4. 应用局限性

  实时数据处理不能替代离线处理，除了计算成本较大这个因素外，对于业务逻辑复杂的场景（比如双流关联或者需要数据回滚的情况），其局限性导致支持不足。另外，由于数据源是流式的 在数据具有上下文关系的情况下，数据到达时间的不确定性导致实时处理眼离线处理得出来的结果会有一定的差异。

5.2 流式技术架构

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

1. 数据采集

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

2. 数据处理

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

3. 数据存储

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

4. 数据服务

  在存储系统上会架设一层统一的数据服务层（比如提供 HSF 接口、HTTP 服务 ），用于获取实时计算结果。
  整体技术架构如图 5.2 示。

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

5.2.1 数据采集

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

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

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

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

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

  对于采集到的数据需要 个数据交换平台分发给下游，这个平台就是数据中间件。数据中间件系统有很多实现方式，比如开源的系统有Kafka ，而阿里巴巴集团内部用得比较多的是 TimeTunnel （原理和 Kafka类似），还有 MetaQ Notify 等消息系统。

  从图 .3 可以看出，消息系统是数据库变更节点的上游，所以它的延时比数据中间件低很多，但是其支持的吞吐量有限。因此，消息系统一般会用作业务数据库变更的消息中转，比如订单下单、支付等消息。对于其他较大的业务数据（每天几十 容量）， 般会通过数据中间件系统来中转，虽然它的延时在秒级，但是其支持的吞吐量高。消息系统和数据中间件的性能对比如表 5.1 所示。


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

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

5.2.2 数据处理

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

  下面以 Stor 为例，简单讲一下流数据处理的原理。实时应用的整个拓扑结构是 个有向无环图（详情可参考 Apache Storm 的官网：http 😕/ storm.apache.org index.html ），如图 5.4 所示。

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

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

  下面就实时任务遇到的几个典型问题进行讲解。

1. 去重指标

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

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

（1）布隆过滤器
  该算法是位数组算法的应用 不保存真实的明细数据，只保存明细数据对应哈希值的标记位。当然，会出现哈希值碰撞的情况，但是误差率可以控制，计算出来的去重值比真实值小。采用这个算法存储 亿条数据只需要 100 MB 空间。
  适用场景 统计精度要求不高，统计维度值非常多的情况。比如统计全网各个商家的 UV 数据，结果记录数达到上千万条。因为在各个维度之间，布隆过滤器是可以共用的。

（2）基数估计
  该算法也是利用哈希的原理，按照数据的分散程度来估算现有数集的边界，从而得出大概的去重值总和。这里估算的去重值可能比真实值大，也可能比真实值小。采用这个算法存储 亿条数据只需要几 KB的内存。
  适用场景：统计精度要求不高，统计维度非常粗的情况。比如整个大盘的 UV 数据，每天的结果只有一条记录。基数估计在各个维度值之间不能共用，比如统计全天小时的 UV 数据，就需要有 个基数估计对象，因此不适合细粒度统计的场景。

2. 数据倾斜

  数据倾斜是 ETL 中经常遇到的问题，比如计算一天中全网访客数或者成交额时，最终的结果只有一个，通常应该是在一个节点上完成相关的计算任务。在数据量非常大的时候，单个节点的处理能力是有限的，必然会遇到性能瓶颈。这时就需要对数据进行分桶处理 分桶处理和离线处理的思路是一样的。
  对于集群系统，一般缓存是分布式的，即不同节点负责一定范围的缓存数据。我们把缓存数据分散度不够，导致大量的缓存数据集中到了一台或者几台服务节点上，称为数据倾斜。一般来说数据倾斜是由于负载均衡实施的效果不好引起的。
（1）去重指标分桶
  通过对去重值进行分桶 Has ，相同 值一定会被放在同一个桶中去重，最后再把每个桶里面的值进行加和就得到总值，这里 用了每个桶的 PU 和内存资源。
（2）非去重指标分桶
  数据随机分发到每个桶中，最后再把每个桶的值汇总，主要利用的是各个桶的CPU能力。
参考资料：数据倾斜的原因及解决方案

3. 事务处理

  由于实时计算是分布式处理的，系统的不稳定性必然会导致数据的处理有可能出现失败的情况。比如网络的抖动导致数据发送不成功、机器重启导致数据丢失等。在这些情况下，怎么做到数据的精确处理呢？上面提到的几个流计算系统几乎都提供了数据自动 ACK 、失败重发以及事务信息等机制。

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

5.2.3 数据存储

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

• 中间计算结果一一在实时应用处理过程中，会有一些状态的保存（比如去重指标的明细数据），用于在发生故障时，使用数据库中的数据恢复内存现场。
• 最终结果数据一一指的是通过 ETL 处理后的实时结果数据，这些数据是实时更新的，写的频率非常高，可以被下游直接使用。
• 维表数据一一在离线计算系统中，通过同步工具导人到在线存储系统中，供实时任务来关联实时流数据。后面章节中会讲到维表的使用方式。

  数据库分为很多种类型，比如关系型数据库、列式数据库、文档数据库等，那么在选择实时任务所使用的数据库时应该注意哪些特征呢？前面提到实时任务是多线程处理的，这就意味着数据存储系统必须能够比较好地支持多并发读写，并且延时需要在毫秒级才能满足实时的性能要求。在实践中，一般使用 Base Tair MongoDB 等列式存储系统。由于这些系统在写数据时是先写内存再落磁盘，因此写延时在毫秒级：读请求也有缓存机制，重要的是多并发读时也可以达到毫秒级延时。
  但是这些系统的缺点也是比较明显的，以 HBase 为例， 一张表必须要有 row key ，而 rowkey 是按照 ASCII 码来排序的，这就像关系型数据库的索引一样， row key 的规则限制了读取数据的方式。如果业务方需要使用另一种读取数据的方式，就必须重新输出 row key 。从这个角度来看， HBase 没有关系型数据库方便。但是 Base 张表能够存储几TB 甚至几十 TB 的数据，而关系型数据库必须要分库分表才能实现这个量级的数据存储。因此，对于海量数据的实时计算，一般会采用非关系型数据库，以应对大量的多并发读写。
下面介绍在数据统计中表名设计和 rowkey 设计的一些实践经验。

5.2.4 数据服务

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

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

5.3 流式数据模型

  数据模型设计是贯通数据处理过程的，流式数据处理也 样，需要对数据流建模分层。实时建模跟离线建模非常类似，数据模型整体上分为五层（ DS DWD DWS ADS DIM ）。
  由于实时计算的局限性，每一层中并没有像离线做得那么宽，维度和指标也没有那么多，特别是涉及回溯状态的指标，在实时数据模型中几乎没有。
  整体来看，实时数据模型是离线数据模型的 个子集，在实时数据处理过程中，很多模型设计就是参考离线数据模型实现的。
下面从数据分层、多流关联、维表使用这 个方面来详细说明。

5.3.1 数据分层

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

1.ODS层

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

2. DWD层

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

3. DWS层

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

4. ADS层

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

5. DIM层

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

• ODS层：订单粒度的变更过程， 一笔订单有多条记录。
• DWD层：订单粒度的支付记录，一笔订单只有一条记录。
• DWS 卖家的实时成交金额，一个卖家只有一条记录，并且指标在实时刷新。
• ADS层外卖地区的实时成交金额，只有外卖业务使用。
• DIM 层：订单商品类目和行业的对应关系维表。
  整体的数据流向如图 5.5 所示。
  
    其中， 层到 IM 层的 ETL 处理是在离线系统中进行的，处理完成后会同步到实时计算所使用的存储系统。 层和 DWD 层会放在数据中间件中，供下游订阅使用。而 DWS 层和 ADS 层会落地到在线存储系统中，下游通过接口调用的形式使用。

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

  另外，字段命名、表命名、指标命名是按照 OneData 规范来定义的，以便更好地维护和管理。具体 On Data 的说明见后续章节。

5.3.2 多流关联

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

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

  下面通过例子（订单信息表和支付信息表关联）来说明，如图5.6所示。

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

  另外，订单记录的变更有可能发生多次（比如订单的多个字段多次更新），在这种情况下 需要根据订单 ID 去重，避免 表和 表多次关联成功；否 输出到下游就会有多条记录，这样得到的数据是有重复的。

  以上是整体的双流关联流程，在实际处理时，考虑到查找数据的性能，实时关联这个步骤一般会把数据按照关联主键进行分桶处理，并且在故障恢复时也根据分桶来进行，以降低查找数据量和提高吞吐量。

5.3.3 维表使用

  在离线系统中，一般是根据业务分区来关联事实表和维表的，因为在关联之前维表的数据就已经就绪了。而在实时计算中，关联维表一般会使用当前的实时数据（ ）去关联 T-2 的维表数据，相当于在 的数据到达之前需要把维表数据准备好，并且 般是 份静态的数据。为什么在实时计算中这么做呢？主要基于以下几点的考虑。

1.数据无法及时准备好

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

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

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

4. 数据的无序性

  如果维表作为实时流输入的话，获取维表数据将存在困难。比如10:00 点的业务数据成功关联维表，得到了相关的维表字段信息，这个时候是否就已经拿到最新的维表数据了呢？其实这只代表拿到截至10:00 点的最新状态数据（实时应用永远也不知道什么时候才是最新状态，因为不知道维表后面是否会发生变更）。
  因此在实时计算中维表关联一般都统一使用 T-2 的数据，这样对于业务来说，起码关联到的维表数据是确定的（虽然维表数据有一定的延时，但是许多业务的维表在两天之间变化是很少的）。
  在有些业务场景下，可以关联 T-1 的数据，但 T-1 的数据是不全的。比如在 斗的晚上 22:00 点开始对维表进行加工处理，在零点到达之前，有两个小时可以把数据准备好，这样就可以在T的时候关联 T-1 的数据了，但是会缺失两个小时的维表变更过程。
另外，由于实时任务是常驻进程的，因此维表的使用分为两种形式。
（1）全量加载
  在维表数据较少的情况下，可以一次性加载到内存中，在内存中直接和实时流数据进行关联，效率非常高。但缺点是内存一直占用着，并且需要定时更新。例如：类目维表，每天只有几万条记录，在每天零点时全量加载到内存中。
（2）增量加载
  维表数据很多，没办法全部加载到内存中，可以使用增量查找和LRU 过期的形式，让最热门的数据留在内存中。其优点是可以控制内存的使用量；缺点是需要查找外部存储系统，运行效率会降低。例如：会员维表，有上亿条记录，每次实时数据到达时，去外部数据库中查询，并且把查询结果放在内存中，然后每隔一段时间清理一次最近最少使用的数据，以避免内存溢出。

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

5.4 大促保障

1.如何进行实时任务优化

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

（1）独占资源和共享资源的策略
  在一台机器中，共享资源池可以被多个实时任务抢占，如果 个任务在运行时 以上的时间都需要去抢资源，这时候就需要考虑给它分配更多的独占资源，避免抢不到 资源导致吞吐量急剧下降。
（2）合理选择缓存机制，尽量降低读写库次数
  内存读写性能是最好的，根据业务的特性选择不同的缓存机制，让最热和最可能使用的数据留在内存中，读写库次数降低后，吞吐量自然就上升了。
（3）计算单元合并，降低拓扑层级
  拓扑结构层级越深 性能越差，因为数据在每个节点间传输时，大部分是需要经过序列化和反序列化的，而这个过程非常消耗 CPU 和时间。
（4）内存对象共享，避免字符拷贝
  在海量数据处理中，大部分对象都是以字符串形式存在的，在不同线程间合理共享对象，可以大幅降低字符拷贝带来的性能消耗，不过要注意不合理使用带来的内存溢出问题。
（5）在高吞吐量和低延时间取平衡
  高吞吐量和低延时这两个特性是一对矛盾体，当把多个读写库操作或者 ACK 操作合并成一个时，可以大幅降低因为网络请求带来的消耗，不过也会导致延时高一些，在业务上衡量进行取舍。

2. 如何进行数据链路保障

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

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

3. 如何进行压测

  在大促备战中，会对实时链路进行多次压测，主要是模拟“双11”的峰值情况，验证系统是否能够正常运行。压测都是在线上环境中进行的，分为数据压测和产品压测。
  数据压测主要是蓄洪压测，就是把几个小时甚至几天的数据积累下来，并在某个时刻全部放开，模拟“双 11 ”洪峰流量的情况，这里面的数据是真实的。比如通过把实时作业的订阅数据点位调到几个小时或者几天前，这时候每一批读到的数据都是最多的，对实时计算的压力也最大。
  产品压测还细分为产品本身压测和前端页面稳定性测试。
（1）产品本身压测
  收集大屏服务端的所有读操作的 URL ，通过压测平台进行压测流量回放，按照 QPS: 500 ／秒的目标进行压测。在压测过程中不断地迭代优化服务端的性能，提升大屏应用处理数据的性能。
（2）前端页面稳定性测试
  将大屏页面在浏览器中打开，并进行 24 小时的前端页面稳定性测试。监控大屏前端 JS 对客户端浏览器的内存、 CPU 等的消耗，检测出前端 JS 内存泄漏等问题并修复，提升前端页面的稳定性。