前言
大家好,我是ChinaManor,直译过来就是中国码农的意思,我希望自己能成为国家复兴道路的铺路人,大数据领域的耕耘者,平凡但不甘于平庸的人。
以上是实时技术篇的思维导图 ～
接下来几篇
manor将更新正在阅读的《阿里巴巴大数据实践》的第五章实时技术
数据模型设计是贯通数据处理过程的，流式数据处理也 样，需要 对数据流建模分层。实时建模跟离线建模非常类似，数据模型整体上分 为五层（ DS DWD DWS ADS DIM ）。 由于实时计算的局限性，每一层中并没有像离线做得那么宽，维度 和指标也没有那么多，特别是涉及回溯状态的指标，在实时数据模型 几乎没有。 整体来看，实时数据模型是离线数据模型的 个子集，在实时数据 处理过程中，很多模型设计就是参考离线数据模型实现的。 下面从
数据分层、多流关联、维表使用这 个方面来详细说明。
1 数据分层
在流式数据模型中，数据模型整体上分为五层。
1.ODS 离线系统的定义一样， ODS 层属于操作数据层，是直接从业务 系统采集过来的最原始数据，包含了所有业务的变更过程，数据粒度也 是最细的。在这一层，实时和离线在源头上是统一的 这样的好处是用 份数据加工出来的指标，口径基本是统一的，可以更方便进行实时 和离线间数据比对。例如：原始的订单变更记录数据 服务器引擎的访 问日志。 2 . DWD DWD 层是在 层基础上，根据业务过程建模出来的实时事实明 细层，对于访问日志这种数据（没有上下文关系，并且不需要等待过程 的记录），会回流到离线系统供下游使用，最大程度地保证实时和离线 数据在 层和 DWD 层是一致的。例如 订单的支付明细表、退款 明细表、用户的访问日志明细表。 3. DWS 订阅明细层的数据后，会在实时任务中计算各个维度的汇总指标。 如果维度是各个垂直业务线通用的，则会放在实时通用汇总层，作为通 用的数据模型使用。比如电商网站的卖家粒度，只要涉及交易过程，就 跟这个维度相关，所以卖家维度是各个垂直业务的通用维度，其中的 总指标也是各个业务线共用的。例如：电商数据的几大维度的汇总表 家、商品、买家）。 4. ADS 个性化维度汇总层，对于不是特别通用的统计维度数据会放在这 中，这里计算只有自身业务才会关注的维度和指标，眼其他业务线 般没有 集，常用于 些垂直创新业务中。例如：手机淘宝下面的某个 逛街、微淘等垂直业务。 5. DIM 实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线 系统中供实时应用调用。这一层对实时应用来说是静态的，所有的 ETL 处理工作会在离线系统中完成。维表在实时应用的使用中跟离线稍有区 别，后面章节中会详细说明。例如：商品维表、卖家维表、买家维表、 类目维表。 下面通过简单的例子来说明每一层存储的数据。
- ODS层：订单粒度的变更过程， 一笔订单有多条记录
- DWD层：订单粒度的支付记录，一笔订单只有一条记录。
- DWS卖家的实时成交金额，一个卖家只有一条记录，并且 指标在实时刷新。
- ADS外卖地区的实时成交金额，只有外卖业务使用。
- DIM层：订单商品类目和行业的对应关系维表。
其中， ODS层到 DIM 层的 ETL 处理是在
离线系统中进行的，处理 完成后会同步到实时计算所使用的存储系统。 ODS层和 DWD 层会放在数据中间件中，供下游订阅使用。而 DWS 层和 ADS 层会落地到在线 存储系统中，下游通过接口调用的形式使用。 在每一层中，按照重要性划分为 PO Pl P2 P3 等级， PO 属于最 高优先级保障。根据不同的优先级给实时任务分配不同的计算和存储资 源，力求重要的任务可以得到最好的保障。
另外，字段命名、表命名、指标命名是按照 OneData 规范来定义的， 以便更好地维护和管理。具体 On Data 的说明见后续章节。
5.3.2 多流关联
在流式计算中常常需要把两个实时流进行主键关联，以得到对应的
时明细表。在离线系统中两个表关联是非常简单的，因为离线计算在
任务启动时已经可以获得两张表的全量数据，只要根据关联键进行分桶
关联就可以了。但流式计算不一样，数据的到达是一个增量的过程，并
且数据到达的时间是不确定的和无序的，因 在数据处理过程中会涉及
中间状态的保存和恢复机制等细节问题。
比如 表和 表使用 ID 进行实时关联，由于无法知道两个表的到
达顺序，因此在两个数据流的每条新数据到来时，都需要到另外一张表
中进行查找。如 表的某条数据到达，到 表的全量数据中查找，如
果能查找到，说明可以关联上，拼接成一条记录直接输出到下游 但是
如果关联不上，则需要放在内存或外部存储中等待，直到 表的记录
也到达。多流关联的一个关键点就是需要相互等待，只有双方都到达了，
才能关联成功。
比如 表和 表使用 ID 进行实时关联，由于无法知道两个表的到
达顺序，因此在两个数据流的每条新数据到来时，都需要到另外一张表
中进行查找。如 表的某条数据到达，到 表的全量数据中查找，如
果能查找到，说明可以关联上，拼接成一条记录直接输出到下游 但是
如果关联不上，则需要放在内存或外部存储中等待，直到 表的记录
也到达。多流关联的一个关键点就是需要相互等待，只有双方都到达了，
才能关联成功。
下面通过例子（订单信息表和支付信息表关联）来说明
在上面的例子中，实时采集两张表的数据，每到来一条新数据时都
在内存中的对方表截至当前的全量数据中查找，如果能查找到，则说明
关联成功，直接输出 ：如果没查找到 ，则把数据放在内存中的自己表数
据集合中等待。另外，不管是否关联成功，内存中的数据都需要备份到
外部存储系统中，在任务重启时，可以从外部存储系统中恢复内存数据
这样才能保证数据不丢失。因为在重启时，任务是续跑的，不会重新跑
之前的数据。
另外，订单记录的变更有可能发生多次（比如订单的多个字段多次
更新），在这种情况下 需要根据订单 ID 去重，避免 表和 表多次关
联成功；否 输出到下游就会有多条记录，这样得到的数据是有重复的。
以上是整体的双流关联流程，在实际处理时，考虑到查找数据的性
能，实时关联这个步骤一般会把数据按照关联主键进行分桶处理，并且
在故障恢复时也根据分桶来进行，以降低查找数据量和提高吞吐量。
3 维表使用
在离线系统中，一般是根据业务分区来关联事实表和维表的，因为
在关联之前维表的数据就已经就绪了。而在实时计算中，关联维表一般
会使用当前的实时数据（ ）去关联 T-2 的维表数据，相当于在 的数
据到达之前需要把维表数据准备好，并且 般是 份静态的数据。
为什么在实时计算中这么做呢？主要基于以下几点的考虑。
1 数据无法及时准备好
当到达零点时，实时流数据必须去关联维表（因为不能等待，如果
等就失去了实时的特性），而这个时候 T- 的维表数据 般不能在零点
马上准备就绪（因为 T-1 的数据需要在 一天加工生成），因此去
联巨 维表，相当于在 -1 一天时间里加工好 T-2 的维表数据。
2. 无法准确获取全量的最新数据
维表 般是全量的数据，如果需要实时获取到当天的最新维表数据，则需要 -1 的数据＋当天变更才能获取到完整的维表数据。也就是
说，维表也作为一个实时流输入，这就需要使用多流实时关联来实现。
但是由于实时数据是无序的并且到达时间不确定，因此在维表关联上有
歧义。
3. 数据的无序性
如果维表作为实时流输入的话，获取维表数据将存在困难。比如
10:00 点的业务数据成功关联维表，得到了相关的维表字段信息，这个
时候是否就已经拿到最新的维表数据了呢？其实这只代表拿到截至
10:00 点的最新状态数据（实时应用永远也不知道什么时候才是最新状
态，因为不知道维表后面是否会发生变更）。
因此在实时计算中维表关联一般都统一使用 T-2 的数据，这样对于
业务来说，起码关联到的维表数据是确定的（虽然维表数据有一定的延
时，但是许多业务的维表在两天之间变化是很少的）。
在有些业务场景下，可以关联 T-1 的数据，但 T-1 的数据是不全的。
比如在 斗的晚上 22:00 点开始对维表进行加工处理，在零点到达之前，
有两个小时可以把数据准备好，这样就可以在 的时候关.！｛＃ T-1 的数据
了，但是会缺失两个小时的维表变更过程。
另外，由于实时任务是常驻进程的，因此维表的使用分为两种形式。 ( I ）全量加载 在维表数据较少的情况下，可以一次性加载到内存中，在内存中直 接和实时流数据进行关联，效率非常高。但缺点是内存一直占用着，并 且需要定时更新。例如：类目维表，每天只有几万条记录，在每天零点 时全量加载到内存中。 (2 ）增量加载 维表数据很多，没办法全部加载到内存中，可以使用增量查找和 LRU 过期的形式，让最热门的数据留在内存中。其优点是可以控制内 存的使用量；缺点是需要查找外部存储系统，运行效率会降低。例如 会员维表，有上亿条记录，每次实时数据到达时，去外部数据库中查询， 并且把查询结果放在内存中，然后每隔一段时间清理一次最近最少使用 的数据，以避免内存溢出。 在实际应用中，这两种形式根据维表数据量和实时性能要求综合考 虑来选择使用。
总结
以上便是阿里巴巴大数据实践｜实时技术篇流式数据模型（三） 下一篇讲阿里巴巴的大促挑战与保障~
愿你读过之后有自己的收获,如果有收获不妨一键三连，我们下篇再见👋·
