数仓采集通道的设计

写在前面

• 离线和实时数仓共用一套数据采集通道系统
• 数据采集存储到HDFS上
• 完全分布式（三台节点）

下文中一共有三个方案的讨论

方案一：

(node01)Flume（TailDir Source） + Kafka Channel + HDFS Sink + Kafka --> Kafka(node02)

架构图如下：

Kafka Channel有一个参数：parseAsFlumeAgent = true，即数据以Event的方式发送给Kafka

Event 格式 ： Header + Body

数据发送到HDFS Sink，下游可以解析出Body数据，Event数据存储在node02节点的kafka主题TopicA中，离线数仓这样设计没有问题

但是对于实时数仓那个来说，header的数据是不需要的，这样就导致多存储了一些无用的数据

如果将参数parseAsFlumeAgent设置为false，这样实时数仓就可以只读取到body的数据，看起来似乎就完美解决了这个问题，其实不然。

因为我们需要实现Flume中拦截器的功能，而拦截器的实现需要结合header来使用，故此种实时和离线共用的数据采集系统不合适，会丢失header数据。

方案二：

(node01)FLume（TailDir Source） + Kafka Channel + Kafka --> Kafka(node02)

架构图如下：

参数parseAsFlumeAgent设置为false

此方案数仓采集过程一共4个链路（数据传输环节）
如下图：

方案三：

(node01)FLume（TailDir Source） + Kafka Channel + Kafka Sink + Kafka --> Kafka(node02)

架构图如下：

参数parseAsFlumeAgent设置为false

上游：数据通过node01的Kafka Channel存储到node02的Kafka主题（只有body数据）中，再从Kafak主题中读取数据

下游：拦截器处理，利用Kafka Channel将数据从Kafak主题中读取出来，

此方案数仓采集过程一共3个链路（数据传输环节）
如下图：

与方案二相比，该方案节省一个Sink，节省一个数据传输环节，相应地提高了性能

最终方案

方案三的采集设计通道更符合本项目的需求，架构图如下：

全文结束！