数据仓库-业务数据采集（基于物流数仓）
0、物流数仓架构
这里的数据采集的架构就是：在业务数据进入MySQL之后，部分表通过DataX全量同步到HDFS，部分表通过Flink-CDC的增量同步方式同步到Kafka，再通过Flume将数据从Kafka同步到HDFS；这两部分在HDFS的数据用于后续的数仓搭建。
数据采集用到的组件：MySQL+DataX+Hadoop+Flink+Kafka+Zookeeper+Flume
1、业务数据同步概述
1.1、数据同步策略概述
业务数据是数据仓库的重要数据来源，我们需要每日定时从业务数据库中抽取数据，传输到数据仓库中，之后再对数据进行分析统计。
为保证统计结果的正确性，需要保证数据仓库中的数据与业务数据库是同步的，离线数仓的计算周期通常为天，所以数据同步周期也通常为天，即每天同步一次即可。
数据的同步策略有全量同步和增量同步。
全量同步，就是每天都将业务数据库中的全部数据同步一份到数据仓库，这是保证两侧数据同步的最简单的方式。
业务数据库中不同日期的数据库中的数据
| 日期：2020-01-10 |
日期：2020-01-11 |
日期：2020-01-12 |
|||||
| Id |
Name |
Id |
Name |
Id |
Name |
||
| 1 |
张三 |
1 |
张三 |
1 |
张三 |
||
| 2 |
李四 |
2 |
李小四 |
2 |
李小四 |
||
| 3 |
王五 |
3 |
王五 |
||||
| 4 |
赵六 |
||||||
| 5 |
田七 |
||||||
数据仓库增量同步到的数据
| 2020-01-10 |
2020-01-11 |
2020-01-12 |
|||||
| Id |
Name |
Id |
Name |
Id |
Name |
||
| 1 |
张三 |
2 |
李小四 |
4 |
赵六 |
||
| 2 |
李四 |
3 |
王五 |
5 |
田七 |
||
1.2、数据同步策略选择
两种策略都能保证数据仓库和业务数据库的数据同步，那应该如何选择呢？下面对两种策略进行简要对比。
| 同步策略 |
优点 |
缺点 |
| 全量同步 |
逻辑简单 |
在某些情况下效率较低。例如某张表数据量较大，但是每天数据的变化比例很低，若对其采用每日全量同步，则会重复同步和存储大量相同的数据。 |
| 增量同步 |
效率高，无需同步和存储重复数据 |
逻辑复杂，需要将每日的新增及变化数据同原来的数据进行整合，才能使用 |
根据上述对比，可以得出以下结论：
若业务表数据量比较大，且每天数据变化的比例比较低，这时应采用增量同步，否则可采用全量同步。
下图为各表同步策略：这里可以看出左边的是维度表，基本不会有什么变化而且数据量小，右边的是事实表，数据量都比较大。
1.3、数据同步工具概述
数据同步工具种类繁多，大致可分为两类，一类是以DataX、Sqoop为代表的基于Select查询的离线、批量同步工具，另一类是以Maxwell、Canal、Flink-CDC为代表的基于数据库数据变更日志（例如MySQL的binlog，其会实时记录所有的insert、update以及delete操作）的实时流式同步工具。
全量同步通常使用DataX、Sqoop等基于查询的离线同步工具。而增量同步既可以使用DataX、Sqoop等工具，也可使用Maxwell、Canal、Flink-CDC等工具，下面对增量同步不同方案进行简要对比。
| 增量同步方案 |
DataX/Sqoop |
Maxwell/Canal/Flink-CDC |
| 对数据库的要求 |
原理是基于查询，故若想通过select查询获取新增及变化数据，就要求数据表中存在create_time、update_time等字段，然后根据这些字段获取变更数据。 |
要求数据库记录变更操作，例如MySQL需开启binlog。 |
| 数据的中间状态 |
由于是离线批量同步，故若一条数据在一天中变化多次，该方案只能获取最后一个状态，中间状态无法获取。 |
由于是实时获取所有的数据变更操作，所以可以获取变更数据的所有中间状态。 |
本项目中，全量同步采用DataX，增量同步采用Flink-CDC。
1.4、数据同步工具部署
1.4.1、DataX
DataX 是阿里巴巴开源的一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。
源码地址：GitHub - alibaba/DataX: DataX是阿里云DataWorks数据集成的开源版本。
Reader和Writer的具体参数可参考官方文档，地址如下：
https://github.com/alibaba/DataX/blob/master/README.md
DataX部署：略。
1.4.2、Flink-CDC
1、什么是CDC
CDC是Change Data Capture(变更数据获取)的简称。核心思想是，监测并捕获数据库的变动（包括数据或数据表的插入、更新以及删除等），将这些变更按发生的顺序完整记录下来，写入到消息中间件中以供其他服务进行订阅及消费。
2、CDC的种类
CDC主要分为基于查询和基于Binlog两种方式，我们主要了解一下这两种之间的区别：
| 基于查询的CDC |
基于Binlog的CDC |
|
| 开源产品 |
Sqoop、Kafka JDBC Source |
Canal、Maxwell、Debezium |
| 执行模式 |
Batch |
Streaming |
| 是否可以捕获所有数据变化 |
否 |
是 |
| 延迟性 |
高延迟 |
低延迟 |
| 是否增加数据库压力 |
是 |
否 |
3、Flink-CDC
Flink社区开发了 flink-cdc-connectors 组件，这是一个可以直接从 MySQL、PostgreSQL 等数据库直接读取全量数据和增量变更数据的 source 组件。目前也已开源。
Flink-CDC相关的介绍：基于 Flink SQL CDC的实时数据同步方案
开源地址：https://github.com/ververica/flink-cdc-connectors
4、部署
就是写Flink代码，其中引入了CDC的依赖，然后打成jar包提交到服务器的Flink上运行。
com.ververica
flink-connector-mysql-cdc
${flink-cdc.version}
2、全量表数据同步
2.1、数据通道
全量表数据由DataX从MySQL业务数据库直接同步到HDFS，具体数据流向如下图所示。
注:目标路径中表名须包含后缀full，表示该表为全量同步目标路径中包含一层日期，用以对不同天的数据进行区分
2.2、DataX配置文件
我们需要为每张全量表编写一个DataX的json配置文件，此处以 base_organ为例，配置文件内容如下：
{
"job": {
"content": [
{
"reader": {
"name": "mysqlreader",
"parameter": {
"column": [
"id",
"name",
"region_id",
"area_code",
"iso_code",
"iso_3166_2"
],
"connection": [
{
"jdbcUrl": [
"jdbc:mysql://hadoop102:3306/tms?useUnicode=true&allowPublicKeyRetrieval=true&characterEncoding=utf-8"
],
"table": [
"base_organ"
]
}
],
"password": "000000",
"splitPk": "",
"username": "root"
}
},
"writer": {
"name": "hdfswriter",
"parameter": {
"column": [
{
"name": "id",
"type": "bigint"
},
{
"name": "org_name",
"type": "string"
},
{
"name": "org_level",
"type": "bigint"
},
{
"name": "region_id",
"type": "bigint"
},
{
"name": "org_parent_id",
"type": "bigint"
},
{
"name": "points",
"type": "string"
},
{
"name": "create_time",
"type": "string"
},
{
"name": "update_time",
"type": "string"
},
{
"name": "is_deleted",
"type": "string"
}
],
"compress": "gzip",
"defaultFS": "hdfs://mycluster",
"hadoopConfig":{
"dfs.nameservices":"mycluster",
"dfs.namenode.rpc-address.mycluster.nn2":"hadoop103:8020",
"dfs.namenode.rpc-address.mycluster.nn1":"hadoop102:8020",
"dfs.client.failover.proxy.provider.mycluster":"org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider",
"dfs.ha.namenodes.mycluster":"nn1,nn2"
}
"fieldDelimiter": "\t",
"fileName": "base_organ",
"fileType": "text",
"path": "${targetdir}",
"writeMode": "truncate"
}
}
}
],
"setting": {
"speed": {
"channel": 1
}
}
}
}注：由于目标路径包含一层日期，用于对不同天的数据加以区分，故path参数并未写死，需在提交任务时通过参数动态传入，参数名称为targetdir。
2.3、DataX配置文件生成
当MySQL中有多张业务数据表时，不可能花时间对每一张表都写一个对应的DataX的JSON配置文件，而且容易有个别配置文件出错，不易排查，直接用代码批量生成 DataX 的JSON配置文件最好。
就是写java代码，从MySQL数据库中读取对应的表名字段等信息，然后拼接成上方的DataX的JSON配置文件。将程序打成jar包，然后就可以通过jar包批量生成DataX配置文件。
代码：略
2.4、测试生成的DataX配置文件
以base_organ表为例，测试用脚本生成的配置文件是否可用。
1）创建目标路径
由于DataX同步任务要求目标路径提前存在，故需手动创建路径，当前base_organ表的目标路径应为/origin_data/tms/base_organ_full/2023-01-01。
[admin@hadoop102 bin]$ hadoop fs -mkdir -p /origin_data/tms/base_organ_full/2023-01-012）执行DataX同步命令
[admin@hadoop102 bin]$ python /opt/module/datax/bin/datax.py -p"-Dtargetdir=/origin_data/tms/base_organ_full/2023-01-01" /opt/module/datax/job/import/tms.base_organ.json3）观察同步结果
观察HFDS目标路径是否出现数据。
2.5、全量表数据同步脚本
为方便使用以及后续的任务调度，此处编写一个全量表数据同步脚本。
1）在~/bin目录创建mysql_to_hdfs_full.sh
[admin@hadoop102 bin]$ vim ~/bin/mysql_to_hdfs_full.sh脚本内容如下
#!/bin/bash
DATAX_HOME=/opt/module/datax
DATAX_DATA=/opt/module/datax/job
#清理脏数据
handle_targetdir() {
hadoop fs -rm -r $1 >/dev/null 2>&1
hadoop fs -mkdir -p $1
}
#数据同步
import_data() {
local datax_config=$1
local target_dir=$2
handle_targetdir "$target_dir"
echo "正在处理$1"
python $DATAX_HOME/bin/datax.py -p"-Dtargetdir=$target_dir" $datax_config >/tmp/datax_run.log 2>&1
if [ $? -ne 0 ]
then
echo "处理失败, 日志如下:"
cat /tmp/datax_run.log
fi
}
#接收表名变量
tab=$1
# 如果传入日期则do_date等于传入的日期，否则等于前一天日期
if [ -n "$2" ] ;then
do_date=$2
else
do_date=$(date -d "-1 day" +%F)
fi
case ${tab} in
base_complex | base_dic | base_region_info | base_organ | express_courier | express_courier_complex | employee_info | line_base_shift | line_base_info | truck_driver | truck_info | truck_model | truck_team)
import_data $DATAX_DATA/import/tms01.${tab}.json /origin_data/tms/${tab}_full/$do_date
;;
"all")
for tmp in base_complex base_dic base_region_info base_organ express_courier express_courier_complex employee_info line_base_shift line_base_info truck_driver truck_info truck_model truck_team
do
import_data $DATAX_DATA/import/tms01.${tmp}.json /origin_data/tms/${tmp}_full/$do_date
done
;;
esac2）为mysql_to_hdfs_full.sh增加执行权限
[admin@hadoop102 bin]$ chmod +x ~/bin/mysql_to_hdfs_full.sh 3）测试同步脚本
[admin@hadoop102 bin]$ mysql_to_hdfs_full.sh all 2023-01-014）检查同步结果
查看HDFS目表路径是否出现全量表数据，全量表共12张。
2.6、全量表同步总结
全量表同步逻辑比较简单，只需每日执行全量表数据同步脚本mysql_to_hdfs_full.sh即可。
3、增量表数据同步
3.1、数据通道
3.2、Flink-CDC配置
通常，企业在搭建离线数仓后会搭建配套的实时数仓，本项目后续也会有配套的实时数仓。我们采用的是lambda架构，该架构下离线实时共用一套采集系统，采集程序作为ODS层App存在，因此，此处的项目结构与物流实时数仓一致。
Lambda架构总共由三层系统组成： 批处理层（Batch Layer）， 速度处理层（Speed Layer），以及用于响应查询的 服务层（Serving Layer）。
Flink-CDC介绍和配置（查看其中的 2、Flink-CDC配置）：
Flink-CDC增量数据同步-CSDN博客
3.3、Flume配置
1）Flume配置概述
Flume需要将Kafka中各topic的数据传输到HDFS，因此选用KafkaSource以及HDFSSink。对于安全性要求高的数据（不允许丢失）选用FileChannel，允许部分丢失的数据如日志可以选用MemoryChannel以追求更高的效率。此处采集的是业务数据，不允许丢失，选用FileChannel，生产环境根据实际情况选择合适的组件。
KafkaSource订阅Kafka的 tms_ods主题的数据，HDFSSink将不同的数据写入不同路径，路径中应包含表名及日期，前者用于区分来源于不同业务表的数据，后者按天对数据进行划分。关键配置如下：
就是通过Flume的拦截器将body数据中的ts和tablename字段提取出来放到 head 中，用于后面将数据放到不同的HDFS路径。
具体数据示例如下：
2）Flume配置实操
（1）创建Flume配置文件
在hadoop104节点的Flume家目录下创建job目录，在job下创建tms_kafka_to_hdfs.conf。
[admin@hadoop104 flume]$ mkdir job
[admin@hadoop104 flume]$ cd job/
[admin@hadoop104 job]$ vim tms_kafka_to_hdfs.conf （2）配置文件内容如下
a1.sources = r1
a1.channels = c1
a1.sinks = k1
a1.sources.r1.type = org.apache.flume.source.kafka.KafkaSource
a1.sources.r1.batchSize = 5000
a1.sources.r1.batchDurationMillis = 2000
a1.sources.r1.kafka.bootstrap.servers = hadoop102:9092,hadoop103:9092,hadoop104:9092
a1.sources.r1.kafka.topics = tms_ods
a1.sources.r1.kafka.consumer.group.id = tms-flume
# 拦截器
a1.sources.r1.interceptors = i1
a1.sources.r1.interceptors.i1.type = com.admin.tms.flume.interceptors.TimestampAndTableNameInterceptor$Builder
a1.channels.c1.type = file
a1.channels.c1.checkpointDir = /opt/module/flume/checkpoint/tms
a1.channels.c1.dataDirs = /opt/module/flume/data/tms
a1.channels.c1.maxFileSize = 2146435071
a1.channels.c1.capacity = 1000000
a1.channels.c1.keep-alive = 6
## sink1
a1.sinks.k1.type = hdfs
a1.sinks.k1.hdfs.path = /origin_data/tms/%{tableName}_inc/%Y-%m-%d
a1.sinks.k1.hdfs.filePrefix = db
a1.sinks.k1.hdfs.round = false
a1.sinks.k1.hdfs.rollInterval = 10
a1.sinks.k1.hdfs.rollSize = 134217728
a1.sinks.k1.hdfs.rollCount = 0
a1.sinks.k1.hdfs.fileType = CompressedStream
a1.sinks.k1.hdfs.codeC = gzip
## 拼装
a1.sources.r1.channels = c1
a1.sinks.k1.channel= c1（3）编写Flume拦截器
① 创建名为tms-flume-interceptor的项目
② 在pom文件中添加如下内容。
org.apache.flume
flume-ng-core
1.10.1
provided
com.alibaba
fastjson
1.2.68
org.apache.maven.plugins
maven-assembly-plugin
3.0.0
jar-with-dependencies
make-assembly
package
single
③ 在com.admin.tms.flume.interceptors包下创建TimestampAndTableNameInterceptor类
package com.admin.tms.flume.interceptors;
import com.alibaba.fastjson.JSONObject;
import org.apache.flume.Context;
import org.apache.flume.Event;
import org.apache.flume.interceptor.Interceptor;
import java.nio.charset.StandardCharsets;
import java.util.List;
import java.util.Map;
public class TimestampAndTableNameInterceptor implements Interceptor {
@Override
public void initialize() {
}
@Override
public Event intercept(Event event) {
Map headers = event.getHeaders();
String log = new String(event.getBody(), StandardCharsets.UTF_8);
JSONObject jsonObject = JSONObject.parseObject(log);
Long ts = jsonObject.getLong("ts");
String tableName = jsonObject.
getJSONObject("source").getString("table");
headers.put("timestamp", ts + "");
headers.put("tableName", tableName);
return event;
}
@Override
public List intercept(List events) {
for (Event event : events) {
intercept(event);
}
return events;
}
@Override
public void close() {
}
public static class Builder implements Interceptor.Builder {
@Override
public Interceptor build() {
return new TimestampAndTableNameInterceptor();
}
@Override
public void configure(Context context) {
}
}
} ④ 打包
⑤ 将打好的包放入到hadoop104的/opt/module/flume/lib文件夹下
[admin@hadoop104 lib]$ ls | grep tms-flume-interceptor
tms-flume-interceptor-1.0-SNAPSHOT-jar-with-dependencies.jar3）通道测试
（1）启动Zookeeper、Kafka集群
（2）启动hadoop104的Flume
[admin@hadoop104 flume]$ bin/flume-ng agent -n a1 -c conf/ -f job/tms_kafka_to_hdfs.conf -Dflume.root.logger=INFO,console（3）执行模拟数据jar包，生成数据
按照上文说明修改application.yml中的配置项后执行jar包。
[admin@hadoop102 bin]$ java -jar tms-mock-2023-01-06.jar（4）观察HDFS上的目标路径，如下。
增量表目录已生成。
（5）观察数据日期
与Flink-CDC Job启动时指定的日期相同。
4）编写Flume启停脚本
为方便使用，此处编写一个Flume的启停脚本
（1）在hadoop102节点的/home/admin/bin目录下创建脚本tms-f1.sh
[admin@hadoop102 bin]$ vim tms-f1.sh在脚本中填写如下内容
#!/bin/bash
case $1 in
"start")
echo " --------启动 hadoop104 业务数据flume-------"
ssh hadoop104 "nohup /opt/module/flume/bin/flume-ng agent -n a1 -c /opt/module/flume/conf -f /opt/module/flume/job/tms_kafka_to_hdfs.conf > /opt/module/flume/tms-f1.log 2>&1 &"
;;
"stop")
echo " --------停止 hadoop104 业务数据flume-------"
ssh hadoop104 "ps -ef | grep tms_kafka_to_hdfs | grep -v grep |awk '{print \$2}' | xargs -n1 kill"
;;
esac（2）增加脚本执行权限
[admin@hadoop102 bin]$ chmod +x tms-f1.sh3.4、增量表同步总结
Flink-CDC Job在启动后会先执行一次全表扫描，然后从binlog的最新位置读取。生产环境下全表扫描的数据会依据扫描时间进入对应日期的目录，从binlog同步到的数据会依据binlog中记录的数据变更时间进入对应目录，因此在数仓上线首日启动增量采集通道即可，如果没有特殊情况后续无须重启，且不需要通过mock_date指定数据日期。
本地环境下，即自己用程序模拟业务数据时，首次启动时，生成数据的时间mock_date应为假定的数仓上线首日，模拟每日数据前需要重启Job，并将日期更换为模拟数据的日期，修改application.yml中的日期，待通道重启完毕后再生成模拟数据。
4、总结
这个物流数仓的数据采集模块是尚硅谷的教学视频。
在B站的视频：01_项目概述_哔哩哔哩_bilibili
这里介绍了物流数仓的数据采集的流程和实现的详细方式，中间的组件部署的流程就自行查找吧，不然太冗长了。
数据采集也是数仓的一大知识点，也是必须掌握的能力。
有帮助的话请点个赞吧！