【数仓】离线和实时数据开发-《大数据之路》读书笔记

  今天更新《大数据之路》第 4 章和第 5 章，离线数据开发以及实时技术。关注公众号回复 802 获取 pdf。其他章节更新中。可以点击这里查看其他章节。

  前面的文章讲述了日志文件和业务系统的数据如何采集到大数据平台中。原始数据只有被整合计算之后才能挖掘潜在信息，从而实现大数据的价值。

1.离线数据开发

1.1 统一计算平台

  数据研发岗的工作大致可以概况为：了解需求→模型设计→ETL 开发→测试→发布上线→日常运维→任务下线。阿里采用的统一计算平台是自研的 MaxCompute，体系分为四部分：

1. 客户端：提供 RESTful API，命令行，可视化
2. 接入层：提供 HTTP 服务、Cache、负载均衡，实现用户认证和访问控制
3. 逻辑层：核心，Worker 处理 RESTful 请求，Scheduler 负责 Job 的调度拆分，Executor 负责执行 Job
4. 计算层：运行在计算集群

1.2 统一开发平台

具体开发流程如下：

2.实时技术

2.1 流式技术架构

  流式技术架构包括以下四个部分：

1. 数据采集：数据实时采集到数据中间件中供下游订阅
2. 数据处理：需要流式计算引擎
3. 数据存储：处理后的数据写入在线服务的存储系统中
4. 数据服务：提供接口和 HTTP 服务

整体技术架构图如下：

2.1.1 数据采集

实时采集，都来自于业务服务器，种类主要包括两种：

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

不是新增一条就采集一次，而是按批次进行，达到下面条件任意一个就采集，降低延迟同时增加吞吐量：

• 数据大小限制：例如 512KB 就写一批
• 时间阈值限制：例如 30s 就写一批

2.1.2 数据处理

计算引擎：Storm，S4，Spark Streaming，Flink

典型问题：

1. 去重指标：
   • 布隆过滤器：适合统计精度要求不高，结果比真实值小，比如全网各个商家的 UV 数据。
   • 基数估计：利用哈希，按照分散程度估计数据的边界，结果可能偏大也可能偏小。适合统计精度不高，比如整个大盘的 UV 数据
2. 数据倾斜：分桶处理
   • 去重指标分桶：对去重值分桶 Hash，相同的值一定在同一个桶中，最后把每个桶的值加和得到总值
   • 非去重指标分桶：数据随机发到每个桶，最后把每个桶汇总。
3. 事务处理：用超时时间、事务信息、备份机制等保证数据的幂等性。

2.1.3 数据存储

实时+数据量大，因此通常用 HBase 来解决。两个重要的实践经验：

1. 表面设计：
   • 规则：汇总层表示+数据域+主维度+时间维度
   • 例如：dws_trd_slr_dtr 表示 数据汇总层+交易数据+卖家+0点截止当日
2. rowkey 设计：
   • 规则：MD5+主维度+维度标识+子维度1+时间维度+子维度2
   • 例如：卖家 ID 的 MD5 前 5 位+卖家 ID+app+一级类目 ID+ddd+二级类目 ID。以 MD5 的前四位作为 rowkey 的第一部分可以把数据散列，让服务器整体负载均衡，避免热点。卖家 ID 属于主维度，查数据时必传，每个统计维度都会生成一个维度标识，以便在 rowkey 上做区分。

2.1.4 数据服务

提供统一的数据服务获取实时数据，做到以下三点：

• 不用直连数据库，对下游透明
• 调用方只需使用接口，不关心底层逻辑
• 屏蔽存储系统间的差异，统一的调用日志输出

2.2 流式数据模型

与离线类似。但每一层没有离线做的那么宽，维度和指标也没那么多，是离线的子集。

2.2.1 数据分层

• ODS：原始数据，实时和离线源头相同
  • 举例：订单粒度的变更过程，一笔订单多条记录
• DWD：会回流到离线系统供下游使用，最大程度保证实时和离线数据在 ODS 和 DWD 一致
  • 举例：订单粒度的支付记录，一笔订单一条记录
• DWS：各个维度汇总
  • 举例：卖家的实时成交额，一个卖家一条记录，实时刷新
• ADS：个性化维度汇总，不是特别通用的统计维度数据放在这一层，这里的计算只有自身业务才会关注的维度和指标，跟其他业务没有交集，常用于垂直创新业务中。例如淘宝下的某个爱逛街、微淘等垂直业务。
  • 举例：外卖业务地区的实时成交金额，只有外卖业务使用
• DIM：实时维表层的数据基本上是从离线维表层导出的，抽取到在线系统中调用。
  • 举例：商品类目和行业的对应关系

ODS 到 DIM 在离线系统中处理，ODS 和 DWD 放在数据中间件供下游订阅，DWS 和 ADS 会落地到在线存储系统供下游调用。

2.2.2 多流关联

把两个实时流的主键进行关联，得到实时明细表。

问题：数据到达的时间是不确定的和无序的，比如 A 表和 B 表关联，无法知道两个表的到达顺序，每条新数据到来都需要到另一张表中查询，例如 A 表某条数据到达，到 B 表的全量数据中查询：

• 找到：关联上，拼接成记录，输出到下游
• 没找到：关联不上，放在内存或外部存储中等待，直到 B 表的记录到达

通过分析发现，多流关联的关键点是相互等待。因此过流关联涉及到中间状态的保存和恢复。

注意：

• 不管 A 和 B 是否关联成功，都要存到外部存储中，任务重启时可以恢复内存数据。保证不丢失。
• 另外要去重。比如订单记录可能变更多次，多次关联有重复。最终根据订单 ID 去重。

2.2.3 维表的使用

实时计算中一般用实时数据 T 关联 T-2 的维表数据，原因如下：

1. 数据无法及时准备好：T-1 的维表不能再 0 点就准备就绪。
2. 无法准确获取全量的最新数据：维表一般是全量数据，当天的最新维表需要 T-1 日的数据 + 当天的变更，这样维表也变成实时流，由于实时数据的无序性，因此会产生歧义。
3. 数据的无序性：维表作为实时流输入，获取维表数据困难，因为实时应用永远也不知道什么时候是最新的。

欢迎关注公众号。