文章实时采集(数据技术篇——实时技术5.1简介流计算（下）)

　　文章实时采集(数据技术篇——实时技术5.1简介流计算（下）)

　　五、数据技术篇-实时技术

　　5.1 简介

　　流计算，业务希望第一时间拿到处理后的数据，实时监控状态，做出运营决策，引导业务往好的方向发展。

　　特征：

　　效率高，延迟可达到毫秒级常驻任务。流式任务数据属于常驻进程任务，启动后会一直运行（数据源无界）。高性能要求，高吞吐低时延，性能有待优化 应用限制，无法替代离线处理（计算成本高），数据是流式处理，在context上下文中，到达时间的不确定性导致一定的实时和离线处理结果的区别

　　根据数据的时延，有3种时效

　　5.2 流技术架构@

　　5.2.1 个数据采集

　　数据从日志服务器采集到数据中间件供下游实时订阅使用

　　及时性和吞吐量是数据处理的矛盾

　　数据类型采集：

　　如何对数据执行采集（按批次）：

　　消息系统是数据库变更节点的上游，特点是：低延迟和有限的吞吐量。有些业务不通过消息系统更新数据库，所以从消息系统获取的数据是不完整的，但是从数据库变更日志中获取的数据必须是完整的。

　　5.2.2 数据处理

　　提供流计算引擎，将其拉入流计算系统的任务中进行处理。实时应用的拓扑结构是一个有向无环图

　　任务计算往往是多线程的，会根据业务主键分桶处理，数据在内存中（需要定时处理，可以根据LRU清理）。封装了一层SQL语义，降低了门槛。以下是一些经典问题：

　　1. 去重指标：

　　在计算重复数据删除时，必须保存重复数据删除的详细数据，这会导致内存消耗过多。这里有两种情况：

　　精确去重，明细数据必须保存，可以通过数据倾斜来处理，一个节点的压力分到多个节点上。

模糊去重，精度要求不高的情况，相关算法去重。

　　去重算法：

　　布隆过滤器。位数组算法的应用不保存实际的明细数据，只保存明细数据对应的哈希表的标记位。适用于：统计维度值较多的情况，如全网各种业务的UV数据统计。可以在各个维度之间共享。基础估计。Hash 还用于根据数据分散程度估计现有数据集的边界，从而获得近似的总去重值。适用于：统计维度值很厚的情况，比如整个市场的UV数据。它不能在各个维度之间共享。

　　2. 数据倾斜：

　　当单个节点的数据量比较大时，就会遇到性能瓶颈。数据需要分桶。

　　重复数据删除指标分为桶。通过对bucket中的去重值进行hash，将相同的值放到同一个bucket中进行去重，然后将每个bucket中的值相加。利用 CPU 和内存资源按非重复数据删除指标划分桶。随机分配到每个bucket，每个bucket汇总，使用每个bucket的CPU容量

　　3. 交易处理：

　　实时计算中的分布式处理，系统不稳定，如何实现精确的数据处理

　　5.2.3 数据存储

　　数据实时处理（聚合、清洗）并写入在线存储系统。写操作为增量操作，源源不断

　　存储的三种类型的数据：

　　实时任务使用的数据库特点：

　　表名设计：汇总层标识+数据字段+主维度+时间维度（主维度相同的所有数据在一张物理表中）

　　rowkey设计：MD5+主维度+维度标识+子维度1+时间维度+子维度2（MD5对数据进行hash，平衡服务器负载）

　　5.2.4 数据服务

　　设置统一的数据服务层获取结果

　　优势：

　　5.3 流式数据模型5.3.1 数据分层

　　ODS层

　　属于运营数据层，业务系统直接返回的最原创数据采集，粒度最细。实时和离线在源头统一（好处：同一条数据处理的指标口径基本一致，便于比较）。如：原创订单变更记录数据，订单强度变化过程，一个订单有多条记录。

　　DWD层

　　根据业务流程中建模的实时事实细节，将没有上下文的记录返回离线系统，最大程度保证ODS和DWD层实时离线的一致性。如：订单的付款时间表，用户访问日志时间表。订单强度支付记录，一个订单只有一条记录。

　　DWS层

　　计算各个维度的汇总指标。如果维度对所有垂直业务线通用，则将其放置在实时通用汇总层中。比如一个电商数据（卖家实力）几个维度的汇总表。卖家的实时交易金额，每个卖家一个记录。

　　ADS层

　　对于不同的统计维度值数据，我们的销售人员会关注它。外卖区实时交易金额

　　DIM层

　　基本来源于离线维度表层（ODS离线处理），提取到实时应用。如产品维度表、卖家维度表等。 订单项目类别与行业对应表。

　　5.3.2 多码流关联

　　在流计算中，需要将两个实时流与主键关联起来，才能得到对应的表。

　　关键点：需要互相等待，双方到达后才能成功关联。

　　难点：数据到达是一个增量过程，数据到达时间不确定、无序，需要涉及中间状态的保存和恢复。

　　当A表和B表实时关联ID时，无法知道表的到达顺序。因此，当两个数据流中的每个新数据到达时，都必须在另一个表中进行搜索。如果匹配，则拼接成一条记录输出到下游；如果无法匹配，则需要将其存储在内存或外部存储器中，直到表 B 中的记录也到达。每次都在对方表的当前全量数据中查找。可以根据关联的主键在bucket中进行处理

　　5.3.3维表使用@

　　实时计算时，相关维表会使用当前实时数据（T）关联T-2的维表数据

　　你为什么这样做？

　　数据无法及时准备。在零点，实时数据必须与维表相关联，T-1的维表数据不能在零点立即准备好，无法准确获取最新的全量数据。所有最新数据=T-1数据+当天变化。当天实时数据无序，时间不确定。数据的混乱。比如10点的业务数据与维表关联成功，获取维表的字段信息（只能说是获取到10点的最新状态数据，而不知道会不会变）

　　有两种类型的维度表

　　满载。数据量小，每天上万条记录，分类维表增量加载。无法全部加载，增量搜索和LRU过期形式，热点数据存储在内存中5.4大推广挑战5.4.1大推广特性毫秒延迟峰值明显（高吞吐量）保证（需要多链路冗余、快速切换、对业务方透明）公关特性（主键过滤、精确去重、统一口径一） 5.4.2大促保证@

　　实时任务优化

　　独占资源和共享资源的策略（一台机器长时间需要从共享资源池中抓取资源，考虑分配更多的独占资源）合理选择缓存机制，减少库的读写次数，合并计算单元，并降级拓扑级别。（每个节点的数据传输都必须进行序列化和反序列化，在级别深度上性能较差） 内存对象共享，避免字符串复制 高吞吐量和低延迟平均

　　数据链路保证

　　多链路建设、多机房容灾、异地容灾、链路切换推送

　　压力测试

　　数据压力测量：将实时操作的订阅数据点调整到几小时或几天前，以模拟蓄洪压力测量。

　　产品压测：自压测试优化服务器性能（所有手机读取操作的URL，QPS：500次/秒压测）；前端页面稳定性测试（8-24小时，提高前端页面稳定性）