大数据之路_实时技术

实时技术：实时流式技术。

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

实时）

离线：在今天（ ）处理 天前 N, N > I ）的数据，延迟时间粒度为天。

准实时 ：在当前小时（ ）处理 小时前 H-N, N>O ，如 0.5小时、 小时等）的数据，延迟时间粒度为小时。

实时 ：在当前时刻处理当前的数据，延迟时间粒度为秒；

离线和准实时都可以在批处理系统中实现（比如 HadoopMax Compute Spark 等系统），只是调度周期不一样而己，而实时数据则需要在流式处理系统中完成。

简单来说，流式数据处理技术是指业务系统每产生一条数据，就会立刻被采集并实时发送到流式任务中进行处理，不需要定时调度任务来处理数据。

 

流式数据处理：

时效性高

常驻任务：区别于离线任务的周期调度，流式任务属于常驻进程任务， 一旦启动后就会一直运行，直到人为地终止，因此计算成本会相对比较高。

性能要求高：实时计算对数据处理的性能要求非常严格，如果处理吞吐量眼不上采集吞吐量，计算出来的数据就失去了实时的特性。

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

 

流式技术架构：

在流式计算技术中，需要各个子系统之间相互依赖形成一条数据处理链路，才能产出结果最终对外提供实时数据服务。

1 数据采集

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

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

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

 

 

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

 

 

数据采集：不管是数据库变更日志还是引擎访问日志，都会在业务服务器上落地成文件，所以只要监控文件的内容发生变化，采集工具就可以把最新的数据采集下来 。

一般情况下，出于吞吐量以及系统压力上的考虑，并不是新增一条↓己录就采集 次，而是基于下面的原则，按批次对数据进行采集。

 

数据大小限制：

时间阈值限制：可能这个更合理。

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

 

数据处理：

 

 

1.去重指标

对于资源的消耗有一类指标是非常高的，那就是去重指标。由于实时任务为了追求处理性能，计算逻辑一般都是在内存中完成的，中间结果数据也会缓存在内存中，这就带来了内存消耗过多的问题。

精确去重：在这种情况下，明细数据是必须要保存下来的，当遇到内存问题时，可以通过数据倾斜来进行处理，把一个节点的内存压力分到多个节点上。

模糊去重：在去重的明细数据量非常大，而业务的精度要求不高的情况下，可以使用相关的去重算法，把内存的使用 量降到千分之一甚至万分之一 ，以提高内存的利用率。

 

2.数据倾斜

比如计算一天中全网访客数或者成交额时，最终的结果只有一个，通常应该是在一个节点上完成相关的计算任务。在数据量非常大的时候，单个节点的处理能力是有限的，

必然会遇到性能瓶颈。这时就需要对数据进行分桶处理 分桶处理和离线处理的思路是一样的。

 

 

3.事务处理

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

 

数据存储

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

 

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

 

流式数据模型

分层：分五层（ DS DWD DWS ADS DIM ）。

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

 

ODS层：和离线系统的定义一样， ODS 层属于操作数据层，是直接从业务系统采集过来的最原始数据，包含了所有业务的变更过程，数据粒度也是最细的。

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

DWS层：订阅明细层的数据后，会在实时任务中计算各个维度的汇总指标。如果维度是各个垂直业务线通用的，则会放在实时通用汇总层，作为通用的数据模型使用。

ADS层：个性化维度汇总层，对于不是特别通用的统计维度数据会放在这一层中，这里计算只有自身业务才会关注的维度和指标，眼其他业务线一般没有交 集，常用于一 些垂直创新业务中。

DIM层：实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线系统中供实时应用调用。这一层对实时应用来说是静态的，所有的 ETL处理工作会在离线系统中完成。

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

 

多流关联：

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

中间状态的保存和恢复机制等细节问题。

多流关联的一个关键点就是需要相互等待，只有双方都到达了，才能关联成功。

 

 

 

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

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

 

由于实时任务是常驻进程的，因此维表的使用分为两种形式。

( I ）全量加载

(2 ）增量加载

 

大促保障

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

( 1） 共享资源的策略

(2 ）合理选择缓存机制，尽量降低读写库次数

(3 ）计算单元合并，降低拓扑层级

(4 ）内存对象共享，避免字符拷贝

(5 ）在高吞吐量和低延时间取平衡

 

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

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

进行多链路搭建，做到多机房容灾，甚至异地容灾。

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

 

3. 如何进行压测

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

 

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

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

(1 ）产品本身压测

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

(2 ）前端页面稳定性测试

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