2.东软跨境电商数仓项目技术选型

东软跨境电商数仓项目技术选型、框架版本选型、服务器选型、集群规划

本次在进行项目技术选型时，主要要考虑到的因素有：数据量的大小、业务需求、行业内的经验、技术成熟度以及开发维护成本。

接下来，依次从数据采集传输、数据存储、数据计算、数据查询、数据可视化、任务调度以及元数据管理七个方面来进行本次项目的技术选型。

1.数据采集传输技术选型

对于数据传输的技术来说，当前较为主流的数据传输工具有Flume、Sqoop、DataX、Maxwell、Canal等。由于我们的业务需求中数据的来源有电商平台的业务数据（存储在Mysql数据库当中）以及用户的行为日志数据，因此，我们就这两种不同类型数据的采集来进行技术选型的分析。

首先是对于存在mysql数据库当中的业务数据。业务数据是数据仓库的重要数据来源，我们需要每日定时从业务数据库中抽取数据，传输到数据仓库中，之后再对数据进行分析统计。由于我们构建的是离线数仓，因此我们不需要实时根据业务数据库的变化来同步到数仓当中，我们只需要每天进行一次同步即可，选择在凌晨同步较为合适。而我们对于业务数据库中数据同步的策略有两种----全量同步和增量同步。

1.1 DataX和Sqoop比较

对于全量同步来说，就是每天都将我们业务数据库当中的数据都同步一分到数据仓库当中，该同步方式较为简单，但是缺点在于数仓当中会存在大量冗余数据，消耗磁盘空间。对于全量同步来说，可选的同步工具有DataX和Sqoop。

Sqoop依赖于Hadoop生态，充分利用了map-reduce计算框架，在Hadoop的框架中运行，对HDFS、Hive支持友善，在处理数仓大表的速度相对较快，但不具备统计和校验能力。

DataX无法分布式部署，需要依赖调度系统实现多客户端，可以在传输过程中进行过滤，并且可以统计传输数据的信息，因此在业务场景复杂(表结构变更)更适用，同时对于不同的数据源支持更好，同时不支持自动创建表和分区。支持流量控制，支持运行信息收集，及时跟踪数据同步情况。

Sqoop只可以在关系型数据库和Hadoop组件之间进行数据迁移，而DataX能够分别实现关系型数据库Hadoop组件之间、关系型数据库之间、Hadoop组件之间的数据迁移。

除比较大的表之外，DataX的速度明显比sqoop快，并且Data的速度可以在配置文件中进行配置，我们可以根据我们的实际情况来配置DataX的速度。

因此，考虑到后续我们的数据可能不止向HDFS上进行传输，并且考虑到两者数据传输速率的不同，我们小组最终选用DataX作为全量同步的工具。

1.2 Maxwell和Canal的比较

对于maxwell来说，实现原理其实就是会在数据源端的库默认maxwell生成对应的position信息，通过记录binlog的position位点来实现断点还原。当然我们也可以手动更新数据库position位置。maxwell库中还会有table,schema，bootstrap表，其中bootstrap可以进行表引导操作。
对于canal来说，canal则是单纯的依靠binlog的position位点记录，解析binlog数据发送到kafka或其他组件。

对于两者的区别来说：

1. canal1.1.*版本之前不支持数据到kafka.只能通过手动开发完成。
2. maxwell只支持json格式，而canal的格式比较自由。
3. maxwell部署非常方便，服务端客户端一体化。canal则有adapter,serer需要分开部署。canal相对更丰满一些
4. canal支持HA，maxwell支持断点还原。
5. maxwell支持bootstrap，对于数据初始化来说，canal还不支持。
6. maxwell支持全量增量同步到kafka.canal全量暂时只能通过接口形式调用.
7. canal依靠binlog的位点记录位置，maxwell自己记录了position。

对比来看，双方各有优点，虽然maxwell的数据传输定位较为单一，仅能将数据从mysql传输到kafka当中，但是考虑到maxwell部署较为方便，较为适合短时间内项目快速迭代的场景，因此我们小组最终选择使用maxwell来进行数据的增量同步。

1.3 使用flume作为非结构化日志数据采集工具

之后是对用户的行为日志数据采集工具的选型，在这里，我们小组选择使用flume这个主流的非结构化日志数据采集工具。

Flume是由Cloudera软件公司提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，现在是Apache的顶级项目之一。

apache Flume 是一个从可以收集例如日志，事件等数据资源，并将这些数量庞大的数据从各项数据资源中集中起来存储的工具/服务。flume具有高可用，分布式，配置工具，其设计的原理也是基于将数据流，如日志数据从各种网站服务器上汇集起来存储到HDFS，HBase等集中存储器中。

同时，我们也使用了Kafka，来搭配flume一同使用，为什么要使用kafka呢？

1. 生产环境中，往往是读取日志进行分析，而这往往是多数据源的，如果Kafka构建多个生产者使用文件流的方式向主题写入数据再供消费者消费的话，无疑非常的不方便。
2. 如果Flume直接对接实时计算框架，当数据采集速度大于数据处理速度，很容易发生数据堆积或者数据丢失，而kafka可以当做一个消息缓存队列，从广义上理解，把它当做一个数据库，可以存放一段时间的数据。
3. Kafka属于中间件，一个明显的优势就是使各层解耦，使得出错时不会干扰其他组件。
4. 并且数据从数据源到flume再到Kafka时，数据一方面可以同步到HDFS做离线计算，另一方面可以做实时计算，可实现数据多分发。

2.数据存储技术选型

对于数据存储层的来说，我们小组本次将数据存储到了Hadoop文件系统HDFS当中。

3.数据计算技术选型

对于数据计算技术的选型，有Hive，Tez，Spark，Flink以及Storm。我们本次的需求是离线数仓，因此我们选择hive，hive可以切换多种引擎，考虑到MR引擎的运行速度较慢，因此我们小组最终选择了Spark引擎来替代MR。

4.数据查询技术选型

Kylin和Clickhouse

5.数据可视化技术选型

初期应该会使用Superset进行可视化展示（由于经费原因），后期如果学校补贴，可以体验一把DataV或者Sugar。

6.任务调度技术选型

对于任务调度框架来说，主流的框架有Azkaban，Oozie以及DolphinScheduler

三者的对比如下图所示：

	DolphinScheduler	Azkaban	Oozie
定位	解决数据处理流程中错综复杂的依赖关系	为了解决Hadoop的任务依赖关系问题	管理Hdoop作业（job）的工作流程调度管理系统
任务类型支持	支持传统的shell任务，同时支持大数据平台任务调度：MR、Spark、SQL(mysql、postgresql、hive/sparksql)、python、procedure、sub_process	command、HadoopShell、Java、HadoopJava、Pig、Hive等，支持插件式扩展	统一调度hadoop系统中常见的mr任务启动、Java MR、Streaming MR、Pig、Hive、Sqoop、Spark、Shell等
可视化流程定义	所有流、定时操作都是可视化的，通过拖拽来绘制DAG,配置数据源及资源，同时对于第三方系统，提供api方式的操作。	通过自定义DSL绘制DAG并打包上传	配置相关的调度任务复杂，依赖关系、时间触发、事件触发使用xml语言进行表达
任务监控支持	任务状态、任务类型、重试次数、任务运行机器、可视化变量，以及任务流执行日志	只能看到任务状态	任务状态、任务类型、任务运行机器、创建时间、启动时间、完成时间等。
暂停/恢复/补数	支持暂停、恢复 补数操作	只能先将工作流杀死在重新运行	支持启动/停止/暂停/恢复/重新运行：支持启动/停止/暂停/恢复/重新运行
高可用支持	支持HA，去中心化的多Master和多Worker	通过DB支持HA，-但Web Server存在单点故障风险	通过DB支持HA
多租户支持	dolphinscheduler上的用户可以通过租户和hadoop用户实现多对一或一对一的映射关系。无法做到细节的权限管控。

对比图转自老姜的数据江湖

最终我们小组选择DolphinScheduler来完成任务的调度，因为dolphinscheduler对比azkaban有一些新特性，比如 **可视化较好，支持多租户，支持任务队列等等，**并且DolphinScheduler的操作流程更为简单方便。

7.元数据管理技术选型

使用Atlas来进行元数据管理

8.最终选型情况

数据采集：Flume，DataX，Maxwell，Kafka

数据存储：MySql，HDFS

数据计算：Hive，Spark

数据查询：Presto，Kylin

数据可视化：Superset

任务调度：DolphinScheduler

集群监控：Zabbix

元数据管理：Atlas

9.框架版本选型

本次项目中我们使用开源免费的Apache版本下的各个框架，具体的版本型号如下图所示：

框架	版本
Spark	3.0.0
Hadoop	3.1.3
Hive	3.1.2
Flume	1.9.0
Kafka	2.4.1
DolphinScheduler	1.3.9
Zookeeper	3.5.7
DataX	3.0
Maxwell	1.29.2
Kylin	2.5.1
Atlas	0.8.4

10.东软跨境电商数仓项目服务器选择和集群规划

由于本次项目的经费原因，服务器的选择上使用了阿里云上的三台服务器，搭建了一个小型的测试环境来进行项目的开发，三台服务器的配置均为四核十六G内存，如下图所示：

测试集群服务器规划如下列表所示：

服务名称	子服务	hadoop102	hadoop103	hadoop104
HDFS	NameNode	√
	DataNode	√	√	√
	SecondaryNameNode			√
Yarn	NodeManager	√	√	√
	Resourcemanager		√
Zookeeper	Zookeeper Server	√	√	√
Flume(采集日志)	Flume	√	√
Kafka	Kafka	√	√	√
Flume（消费Kafka）	Flume			√
Hive	Hive	√
MySQL	MySQL	√
DataX	DataX	√
Maxwell	Maxwell	√
Presto	Coordinator	√
	Worker	√	√	√
DolphinScheduler	MasterServer			√
	WorkerServer	√	√	√
Kylin		√
Superset			√
Atlas		√