调度器选择
一、需求分析
1、支持多租户的权限控制
我们在日常工作中不止研发会进行任务的调度，其他的业务部门和厂商都可能会在DS上跑一些任务，如果没有多租户的权限控制的话，那整个集群使用起来都会非常的混乱。
2、上手简单，支持可视化任务管理
上手简单，因为我们团队内部在很多时候，开发会给到数仓/业务团队去使用，如果任务调度上手非常困难，如果需要进行大量的配置或者编写代码，相对成本就要高很多，相信在很多大数据团队都会存在这个需求，并且有些项目需要快速迭代，所以对于选型的工具必然是上手简单的。
3、支持对任务及节点状态进行监控
我们对任务调度原生监控主要有两点需求，第一是服务器的监控，可以直接通过任务调度web页面去看，第二是任务调度的监控，针对任务是否成功、执行时间等相关数据和状态能够一目了然。
4、支持较为方便的重跑、补数
我们数据有实时、周期和离线三部分的，数据特性产生了这个需求，比如对于每15分钟或者每小时的数据任务，如果不能很好的支持重跑和补数的话，对我们影响还是比较大的。
5、支持高可用HA、弹性扩容、故障容错
集群运维和故障管理方面也是需要支持的。
6、支持时间参数
有时候需要基于时间参数进行数据的ETL周期操作。
二、任务调度对比
Crontab
在Unix和类Unix系统中周期性地执行指令或脚本，用来在Linux上直接执行脚本，但只能用来运行脚本。
不支持多租户权限管理、平台管理、分发执行等功能，在我们公司中的应用是在一些特点服务器跑一些临时的脚本。
并且原生Crontab只支持分钟级别的调度，不支持重跑。
Rundeck
Rundeck是一个基于Java和Grails的开源的运维自动化工具，提供了Web管理界面进行操作，同时提供命令行工具和WebAPI的访问控制方式。
像Ansible之类的工具一样，Rundeck能够帮助开发和运维人员更好地管理各个节点。
分为企业版和免费版，免费版对于我们来说功能还是有点欠缺的。
Quartz
Quartz 是一款开源且丰富特性的任务调度库，是基于Java实现的任务调度框架，能够集成与任何的java应用。
需要使用Java编程语言编写任务调度，这对于非研发团队而言，是无法去推广使用的。
xxl-job
是一款国产开发的轻量级分布式调度工具，但功能比海豚调度少。
其不依赖于大数据组件，而是依赖于MySQL，和海豚调度的依赖项是一样的。
Elastic-Job
是基于Quartz 二次开发的弹性分布式任务调度系统，初衷是面向高并发且复杂的任务。
设计理念是无中心化的，通过ZooKeeper的选举机制选举出主服务器，如果主服务器挂了，会重新选举新的主服务器。
因此elasticjob具有良好的扩展性和可用性，但是使用和运维有一定的复杂度。
Azkaban
Azkaban也是一个轻量级的任务调度框架，但其缺点是可视化支持不好，任务必须通过打一个zip包来进行实现，不是很方便。
AirFlow
AirFlow是用Python写的一款任务调度系统，界面很高大上，但不符合中国人的使用习惯。
需要使用Python进行DAG图的绘制，无法做到低代码任务调度。
Oozie
是集成在Hadoop中的大数据任务调度框架，其对任务的编写是需要通过xml语言进行的。
三、选择DolphinScheduler的理由
1、部署简单，Master、Worker各司其职，可线性扩展，不依赖于大数据集群
2、对任务及节点有直观的监控，失败还是成功能够一目了然
3、任务类型支持多，DAG图决定了可视化配置及可视化任务血缘
4、甘特图和版本控制，对于大量任务来说，非常好用
5、能够很好满足工作需求
数据集成选择
一、 数据需求
数据量：每天上千万条
字段数：上百个字段，String类型居多
数据流程：从关系型数据库和kafka中同步集成到doris，基于doris直接分析结果依然存储在doris中，应用直接查询doris的数据
存储周期：3年~8年
查询响应：对于部分字段需要秒级响应
二、数据同步选型
Sqoop
Sqoop是一款开源的工具，主要用于在Hadoop(Hive)与传统的数据库(mysql、postgresql…)间进行数据的传递，在DolphinScheduler上也集成了Sqoop的任务调度，但是对于从Hive到ClickHouse的需求，Sqoop是无法支持的。
Flink
通过DS调度Flink任务进行或者直接构建一套以Flink为主的实时流计算框架，对于这个需求，不仅要搭建一套计算框架，还要加上Kafka做消息队列，除此之外有增加额外的资源开销。
其次需要编写程序，这对于后面的运维团队是不方便的。
最后我们主要的场景是离线，单比较吞吐量的话，不如考虑使用Spark。
Spark&SparkSQL
在不考虑环境及资源的情况下，Spark确实是最优选择，因为我们的数据加工也是用的SparkSQL，那现在的情况就是对于数据同步来说有两种方式去做。
第一种是加工出来的数据不持久化存储，直接通过网络IO往ClickHouse里面去写，这一种方式对于服务器资源的开销是最小的，但是其风险也是最大的，因为加工出来的数据不落盘，在数据同步或者是ClickHouse存储中发现异常，就必须要进行重新加工，但是下面dws、dwd的数据是14天清理一次，所以不落盘这种方式就需要再进行考虑。
第二种方式是加工出来的数据放到Hive中，再使用SparkSQL进行同步，只是这种的话，需要耗费更多的Yarn资源量，所以在一期工程中，因为资源量的限制，我们并没有使用SparkSQL来作为数据同步方案，但是在二期工程中，得到了扩容的集群是完全足够的，我们就将数据加工和数据同步全部更换为了SparkSQL。
DataX
单机、易受比如网络闪断、数据源不稳定等因素影响
SeaTunnel
在最新的SeaTunnel中不在依赖于spark或者flink，可以直接运行在zata引擎上，支持的数据源种类丰富，社区活跃度高，支持基于DolphinScheduler的调度，除了离线还支持实时和cdc、一个框架就可以解决离线实时、cdc多种类型任务，完善的任务监控机制。
未来的规划
1、实现集成、开发、质量的统一调度，一套框架解决数据治理的60%的功能
2、统一任务的日志管理
3、集成flink或者spark任务
