离线数仓的优化及重构

@

目录

• 1. 背景
• 2. 优化
• 3. 改造
  • 3.1. 重构
  • 3.2. 优化

1. 背景

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

flowchart LRFile -->|Parse|MySQL-->|Python|Hive

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

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

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

flowchart LRMySQL -->|JSON|Python-->|Table|Hive

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

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

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

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

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

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

2. 优化

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

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

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

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

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

优化后的大致结构如下：

flowchart LRPython-->|WHERE timestamp < ...|MySQLMySQL-->|JSON|PythonPython-->|Table|HivePython-->|UPDATE timestamp|RecordRecord-->| timestamp|Python

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

3. 改造

3.1. 重构

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

flowchart LRFile -->|Parse|HDFS-->|Bash|Hive-->|Python|ES

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

数仓结构大概是：

flowchart LRHDFS-->|Bash|ODSODS-->|SQL|DWDODS-->|SQL|APPAPP-->|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 TBStart --> bash_1Start --> bash_2Start --> bash_3Start --> bash_4bash_1 --> Endbash_2 --> Endbash_3 --> Endbash_4 --> End

3.2. 优化

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

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

flowchart TBStart --> bash_1bash_1 --> bash_2 bash_2 --> bash_3 bash_3 --> bash_4 bash_4 --> End

---

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

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