特征 1、通过Web构建DataX Json； 2、DataX Json保存在数据库中，方便任务的迁移，管理； 3、Web实时查看抽取日志，类似Jenkins的日志控制台输出功能； 4、DataX运行记录展示，可页面操作停止DataX作业； 5、支持DataX定时任务，支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生 效； 6、调度采用中心式设计，支持集群部署； 7、任务分布式执行，任务"执行器"支持集群部署； 8、执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行； 9、路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、 一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等； 10、阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默 认）、丢弃后续调度、覆盖之前调度； 11、任务超时控制：支持自定义任务超时时间，任务运行超时将会主动中断任务； 12、任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主 动进行重试； 13、任务失败告警；默认提供邮件方式失败告警，同时预留扩展接口，可方便的扩展短信、钉钉等 告警方式； 14、用户管理：支持在线管理系统用户，存在管理员、普通用户两种角色； 15、任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的 执行, 多个子任务用逗号分隔； 16、运行报表：支持实时查看运行数据，以及调度报表，如调度日期分布图，调度成功分布图等； 17、指定增量字段，配置定时任务自动获取每次的数据区间，任务失败重试，保证数据安全； 18、页面可配置DataX启动JVM参数； 19、数据源配置成功后添加手动测试功能； 20、可以对常用任务进行配置模板，在构建完JSON之后可选择关联模板创建任务； 21、jdbc添加hive数据源支持，可在构建JSON页面选择数据源生成column信息并简化配置； 22、优先通过环境变量获取DataX文件目录，集群部署时不用指定JSON及日志目录； 23、通过动态参数配置指定hive分区，也可以配合增量实现增量数据动态插入分区； 24、任务类型由原来DataX任务扩展到Shell任务、Python任务、PowerShell任务； 25、添加Hbase数据源支持，JSON构建可通过Hbase数据源获取hbaseConfig，column； 26、添加MongoDB数据源支持，用户仅需要选择collectionName即可完成json构建； 27、添加执行器CPU、内存、负载的监控页面； 28、添加24类插件DataX JSON配置样例 29、公共字段（创建时间，创建人，修改时间，修改者）插入或更新时自动填充 30、对swagger接口进行token验证 31、任务增加超时时间，对超时任务kill datax进程，可配合重试策略避免网络问题导致的datax卡 死。 32、添加项目管理模块，可对任务分类管理； 33、对RDBMS数据源增加批量任务创建功能，选择数据源，表即可根据模板批量生成DataX同步 任务； 34、JSON构建增加ClickHouse数据源支持； 35、执行器CPU.内存.负载的监控页面图形化； 36、RDBMS数据源增量抽取增加主键自增方式并优化页面参数配置； 37、更换MongoDB数据源连接方式,重构Hbase数据源JSON构建模块； 38、脚本类型任务增加停止功能； 39、rdbms json构建增加postSql，并支持构建多个preSql，postSql； 40、数据源信息加密算法修改及代码优化； 41、日志页面增加DataX执行结果统计数据； Azkaban Azkaban介绍 Azkaban是在linkedIn（领英）上创建的用于运行Hadoop作业的批处理工作流作业调度程序。 Azkaban通过工作依赖性解决订购问题，并提供易于使用的Web用户界面来维护和跟踪您的工作流程。 我们都知道大数据的计算、分析和处理，一般由多个任务单元组成（Hive、Sparksql、Spark、Shell 等），每个任务单元完成特定的数据处理逻辑。 多个任务单元之间往往有着强依赖关系，上游任务执行并成功，下游任务才可以执行。比如上游任务结 束后拿到 A 结果，下游任务需结合 A 结果才能产出 B 结果，因此下游任务的开始一定是在上游任务成功 运行拿到结果之后才可以开始。 而为了保证数据处理结果的准确性，就必须要求这些任务按照上下游依赖关系有序、高效的执行。一个 较为基础的处理方式是，预估出每个任务处理所需时间，根据先后顺序，计算出每个任务的执行的起止 时间，通过定时跑任务的方式，让整个系统保持稳定的运行。 一个完整的数据分析任务最少执行一次，在数据量较少，依赖关系较为简单的低频数据处理过程中，这 种调度方式完全可以满足需求。然而在企业级场景中，更多的是需要每天执行，如果任务数量较多，在 任务启动的时间计算上就将耗费大量时间，另外如果出现上游任务执行时长超出原定预计时间或者运行 异常的问题，上述的处理方式将完全无法应对，也会对人力物力造成重复损耗，因此，对于企业数据开 发过程来说，一个完整且高效的工作流调度系统将起到至关重要的作用。 工作流产生背景 工作流（Workflow），指“业务过程的部分或整体在计算机应用环境下的自动化”。是对工作流程 及其各操作步骤之间业务规则的抽象、概括描述。工作流解决的主要问题是：为了实现某个业务目 标，利用计算机软件在多个参与者之间按某种预定规则自动传递文档、信息或者任务。 一个完整的数据分析系统通常都是由多个前后依赖的模块组合构成的：数据采集、数据预处理、数 据分析、数据展示等。各个模块单元之间存在时间先后依赖关系，且存在着周期性重复**。 为了很好地组织起这样的复杂执行计划，需要一个工作流调度系统来调度执行。 工作流调度实现方式 简单的任务调度：直接使用linux的crontab来定义,但是缺点也是比较明显，无法设置依赖。 复杂的任务调度：自主开发调度平台，使用开源调度系统，比如azkaban、Apache Oozie、 Cascading、Hamake等。 其中知名度比较高的是Apache Oozie，但是其配置工作流的过程是编写大量的XML配置，而且代 码复杂度比较高，不易于二次开发。 Azkaban特征 分布式多执行器 MySQL重试 友好的用户界面 有条件的工作流程 数据触发 高安全性 支持插件扩展，从Web UI到作业执行 完整的作者管理系统 调度工具对比 Oozie Oozie：训象人（调度mapreduce）。一个基于工作流引擎的开源框架，Oozie需要部署到java servlet 中运行，主要用于定时调度，多任务之间按照执行的逻辑顺序调度。 它有如下功能特点： 统一调度hadoop系统常见的mr任务启动，hdfs操作，shell调度，hive操作等； 让复杂的依赖关系，时间触发，事件触发使用xml语言进行表达，开发效率增高； 一组任务使用一个DAG表示，使用图形表达，流程清晰； 支持多种任务调度，能完成大部分的hadoop任务； 程序定义支持EL常量和函数，表达丰富； Oozie规定在完成工作后发送电子邮件通知； Azkaban使用Web操作。Oozie支持Web，RestApi，Java API操作； Azkaban Azkaban是由linkedin开源的一个批量工作流任务调度器。用于在一个工作流内以一个特定的顺序运 行一组工作和流程。Azkaban定义了一种KV文件格式来建立任务之间的依赖关系，并提供一个易于使用 的web用户界面维护和跟踪你的工作流。 它有如下功能特点： Web用户界面 方便上传工作流 方便设置任务之间的关系 调度工作流 认证/授权(权限的工作) 能够杀死并重新启动工作流 模块化和可插拔的插件机制 项目工作区 工作流和任务的日志记录和审计 总结 Apache Oozie 是一个重量级的任务调度系统，功能全面，但是部署及配置会比较麻烦，从 crontab 到 Oozie 上手会有一定难度。 Azkaban 是介于 oozie 和 Crontab 之间的工具，但是安全性上不如 Oozie，同时如果出现失败情况， Azkaban会丢失所有的工作流，Oozie则可以继续运行。 Azkaban架构 图示 正在上传…重新上传取消
mysql服务器: 存储元数据，如项目名称、项目描述、项目权限、任务状态、SLA规则等 AzkabanWebServer: 对外提供web服务，使用户可以通过web页面管理。职责包括项目管理、权 限授权、任务调度、监控executor。 AzkabanExecutorServer:负责具体的工作流的提交、执行。 Azkaban部署模式 solo server mode(单机) 该模式中webServer和executorServer运行在同一个进程中，进程名是AzkabanSingleServer。使 用自带的H2数据库。这种模式包含Azkaban的所有特性，但一般用来学习和测试。 two-server mode(远程) 该模式使用MySQL数据库， Web Server和Executor Server运行在不同的进程中。 multiple-executor mode（集群或者分布式） 该模式使用MySQL数据库， Web Server和Executor Server运行在不同的机器中。且有多个 Executor Server。该模式适用于大规模应用。 服务器调优 hdfs调优 1. dfs.datanode.failed.volumes.tolerated: 0 允许发生磁盘错误的磁盘数量，默认为0，表示不允许 datanode发生磁盘异常。当挂载多个磁盘的时候，可以修改该值。 2. dfs.replication: 复制因子，默认3 3. dfs.namenode.handler.count: namenode节点并发线程量，默认10 4. dfs.datanode.handler.count：datanode之间的并发线程量，默认10。 5. dfs.datanode.max.transfer.threads：datanode提供的数据流操作的并发线程量，默认4096。 一般将其设置为linux系统的文件句柄数的85%~90%之间，查看文件句柄数语句ulimit -a，修改 vim /etc/security/limits.conf, 不能设置太大 文件末尾，添加 * soft nofile 65535 * hard nofile 65535 注意：句柄数不能够太大，可以设置为1000000以下的所有数值，一般不设置为-1。 异常处理：当设置句柄数较大的时候，重新登录可能出现unable load session的提示信息，这 个时候采用单用户模式进行修改操作即可。 单用户模式： 启动的时候按'a'键，进入选择界面，然后按'e'键进入kernel修改界面，然后选择第二 zip user.zip split.job nginxreload.job etl.job newuser.job activeuser.job stats_view_depth_json.job stats_view_depth.job tmp_event_log.job 行'kernel...'，按'e'键进行修改，在最后添加空格+single即可，按回车键回到修改界面，最后 按'b'键进行单用户模式启动，当启动成功后，还原文件后保存，最后退出(exit)重启系统即可。 6. io.file.buffer.size: 读取/写出数据的buffer大小，默认4096，一般不用设置，推荐设置为4096的 整数倍(物理页面的整数倍大小)。 hbase调优 1. 设置regionserver的内存大小，默认为1g，推荐设置为4g。 修改conf/hbase-env.sh中的Hbase_HEAPSIZE=4g 2. hbase.regionserver.handler.count: 修改客户端并发线程数，默认为10。设置规则为，当put和 scans操作比较的多的时候，将其设置为比较小的值；当get和delete操作比较多的时候，将其设置 为比较大的值。原因是防止频繁GC操作导致内存异常。 3. 自定义hbase的分割和紧缩操作，默认情况下hbase的分割机制是当region大小达到 hbase.hregion.max.filesize(10g)的时候进行自动分割，推荐每个regionserver的region个数在 20~500个为最佳。hbase的紧缩机制是hbase的一个非常重要的管理机制，hbase的紧缩操作是非 常消耗内存和cpu的，所以一般机器压力比较大的话，推荐将其关闭，改为手动控制。 4. hbase.balancer.period： 设置hbase的负载均衡时间，默认为300000(5分钟)，在负载比较高的 集群上，将其值可以适当的改大。 5. hfile.block.cache.size：修改hflie文件块在内存的占比，默认0.4。在读应用比较多的系统中，可 以适当的增大该值，在写应用比较多的系统中，可以适当的减少该值，不过不推荐修改为0。 6. hbase.regionserver.global.memstore.upperLimit：修改memstore的内存占用比率上限，默认 0.4，当达到该值的时候，会进行flush操作将内容写的磁盘中。 7. hbase.regionserver.global.memstore.lowerLimit: 修改memstore的内存占用比率下限，默认 0.38，进行flush操作后，memstore占用的内存比率必须不大于该值。 8. hbase.hregion.memstore.flush.size: 当memstore的值大于该值的时候，进行flush操作。默认 134217728(128M)。 9. hbase.hregion.memstore.block.multiplier: 修改memstore阻塞块大小比率值，默认为4。也就 是说在memstore的大小超过4*hbase.hregion.memstore.flush.size的时候就会触发写阻塞操 作。最终可能会导致出现oom异常。 mapreduce参数调优 1. mapreduce.task.io.sort.factor: mr程序进行合并排序的时候，打开的文件数量，默认为10个. 2. mapreduce.task.io.sort.mb: mr程序进行合并排序操作的时候或者mapper写数据的时候，内存 大小，默认100M 3. mapreduce.map.sort.spill.percent： mr程序进行flush操作的阀值，默认0.80。 4. mapreduce.reduce.shuffle.parallelcopies：mr程序reducer copy数据的线程数，默认5。 5. mapreduce.reduce.shuffle.input.buffer.percent: reduce复制map数据的时候指定的内存堆大小 百分比，默认为0.70，适当的增加该值可以减少map数据的磁盘溢出，能够提高系统性能。 6. mapreduce.reduce.shuffle.merge.percent：reduce进行shuffle的时候，用于启动合并输出和磁 盘溢写的过程的阀值，默认为0.66。如果允许，适当增大其比例能够减少磁盘溢写次数，提高系统 性能。同mapreduce.reduce.shuffle.input.buffer.percent一起使用。 7. mapreduce.task.timeout：mr程序的task执行情况汇报过期时间，默认600000(10分钟)，设置为 0表示不进行该值的判断。 Hive调优 mapside聚合">1> mapside聚合 默认情况下，Map阶段同一Key数据分发给一个reduce，当一个key数据过大时就倾斜了。 并不是所有的聚合操作都需要在Reduce端完成，很多聚合操作都可以先在Map端进行部分聚合，最后 在Reduce端得出最终结果。 1．开启Map端聚合参数设置 （1）是否在Map端进行聚合，默认为True hive.map.aggr = true （2）在Map端进行聚合操作的条目数目 hive.groupby.mapaggr.checkinterval = 100000 （3）有数据倾斜的时候进行负载均衡（默认是false） hive.groupby.skewindata = true 当选项设定为 true，生成的查询计划会有两个MR Job。分两次进行mapredue,第一次随机分获取中 间结果,第二次正常分，获取最终结果
