离线数仓的优化及重构

@TOC

1. 背景

大概就是有那么一个数仓，然后简略结构如下：

flowchart LR File -->|Parse|MySQL-->|Python|Hive

从其他封闭系统产生的日志文件，经由本系统的后端部分近线解析，将结果直接存入MySQL，而后由数仓部分使用Python脚本洗入Hive，但这实在是太慢了。

在代码当中埋了一些输出点之后，经过对行为日志的分析，我们发现最慢的部分是在数据转换的Python脚本部分

更进一步地，Python脚本的结构大概是：

flowchart LR MySQL -->|JSON|Python-->|Table|Hive

也就是说，MySQL当中存储的是JSON格式的数据，原设计是直接向Elasticsearch进行推送的，后来追加了一个存入Hive的通道

那么进一步分析Python脚本的流程，大概是：

flowchart LR MySQL -->|WHERE state=0 LIMIT ...|Python-->|Table|Hive Python-->|UPDATE state=1 WHERE ... IN|MySQL

问题就出现在，Python脚本对MySQL数据解析状态的更新上

由于采用的是UPDATE且附带WHERE条件，所以每次更新状态的时候，似乎都会把整个表锁上，详见这个^1^和这个^2^

而且由于这个表同时还有推送ES的一个通道，可能还有其他地方在同时访问，所以整张表会锁很久

2. 优化

找到了症结，接下来就是想办法了

既然问题出现在数据回流上，那么能不能想办法去掉这个步骤？

经过对MySQL表结构的分析，我们发现其中的某个字段与时间戳相关

也就是说，这张表的数据，在这个字段上是有序的

那么我们可以将这个字段作为关键字，记录此次数据处理到了哪个位置

优化后的大致结构如下：

flowchart LR Python-->|WHERE timestamp < ...|MySQL MySQL-->|JSON|Python Python-->|Table|Hive Python-->|UPDATE timestamp|Record Record-->| timestamp|Python

这样一来，数仓部分对这张表就只有读取部分，去掉写入，不再产生相关的锁，大大提升了运行效率

3. 改造

3.1. 重构

但是好景不长，过了一段时间，这部分的表现又不如人意，于是决定重构，大致的结构如：

flowchart LR File -->|Parse|HDFS-->|Bash|Hive-->|Python|ES

此次将日志文件直接解析到HDFS，再通过Bash直接建表到Hive，最后推送至ES

数仓结构大概是：

flowchart LR HDFS-->|Bash|ODS ODS-->|SQL|DWD ODS-->|SQL|APP APP-->|Python|ES

APP直接从ODS加工有两个考虑：

1. 其一是某个特殊字段仅在APP有效，所以DWD没有保存，只能从ODS 取数

2. 其二是提高并行度，使得DWD和APP可以同时加工

除此之外还有控制结构：

大概是，有四个控制脚本，有一个控制表

控制表的部分效果如下：

1. 记录远程文件名称，及其解析到的对应的HDFS文件的名称

2. 记录该文件的解析状态，例如说已落ODS

几个控制脚本的部分作用如下：

: 1.sh

1. 根据控制表当中的记录，选取还未处理的`HDFS`文件，在`Hive`当中建立对应的表

2. 处理完成之后更新这些记录的状态

: 2.sh

1. 根据控制表当中的记录，选取已经落到`ODS`的表，加工数据到`DWD`

2. 处理完成之后更新这些记录的状态

: 3.sh

1. 根据控制表当中的记录，选取已经落到`ODS`的表，加工数据到`APP`

2. 处理完成之后更新这些记录的状态

: 3_5.sh

1. 根据控制表当中的记录，选取已经落到`APP`的表，推送数据到`ES`

2. 处理完成之后更新这些记录的状态

3. 此环节暂时跳过

: 4.sh

1. 根据控制表当中的记录，选取已经落到`DWD`和`APP`的表，删除其在`ODS`的数据

2. 根据控制表当中的记录，选取已经推送到`ES`的表，且数据已过保留期限，删除其在`APP`的数据

3. 处理完成之后更新这些记录的状态

该数仓使用Azkaban进行调度，设定自动任务为每10分钟自动运行一次。每次任务运行之前都会检查运行历史，如上次任务未结束则跳过此次运行，如连续失败五次则触发企业微信机器人进行预警，其他情况正常运行

由于各部分互不依赖，则可以设置成平行结构：

flowchart TB Start --> bash_1 Start --> bash_2 Start --> bash_3 Start --> bash_4 bash_1 --> End bash_2 --> End bash_3 --> End bash_4 --> End

3.2. 优化

首先是关于bash_1的，我们发现解析到HDFS的文件体量过小，影响运行效率，故决定先进行一个HDFS文件的合并，使用hdfs dfs -cat，传入多个文件的路径，将其输出到Hive表的文件夹下，合并成为一个文件

然后是结构问题，原平行结构对环境的影响压力过大，在合并小文件后运行效率有所提升，在不触及数据更新容忍度的情况下，将Azkaban改为顺序结构，人为的加上依赖

flowchart TB Start --> bash_1 bash_1 --> bash_2 bash_2 --> bash_3 bash_3 --> bash_4 bash_4 --> End

Footnotes

1. mysql update加锁分析：是加行锁还是表锁？具体加锁加哪儿？_update表锁-CSDN博客 ↩

2. 面试官：MySQL的UPDATE语句会加哪些锁？ | 毛英东的个人博客 ↩