1.1、Kepler生产实践
1.1.1、Kepler生产实践
调度系统Kepler自从开发使用以来。调度的任务数量从最开始的几百个到后来的一万五左右，在投入使用的几年里，调度本身还算稳定，基本没有出过较大的事故。调度系统从比较粗糙到日趋完善也经历了很多次完善。
开始时，调度系统被调度起来的任务信息都会暂存到Zookeeper集群中，但随着传输平台在公司的推广、业务大规模的扩张。Zookeeper集群已经暂存不下同时调度起来的任务数据，这些数据会慢慢拖垮Zookeeper集群[22]。于是改成了从数据库读取，并对数据库进行读写分离，准备了只用于读的备库。大大提高了数据库的访问效率，并且调度系统的稳定性也随之提高[23]。
但调度系统还存在很多问题，一是资源管理的问题，主要是如果同时发起Hive连接或者Mysql连接的任务过多会导致有些任务连接数据库超时而导致任务失败，现在每晚2点左右是调度高峰期，同时起来几千个任务会导致很多共享资源出现并发问题。二是大任务抢夺集群资源，中小任务因为资源不足运行超时的问题经常发生，但其实对各部门来说，大小任务本身是同样重要的，集群应该采取一视同仁的策略，进行资源隔离是有必要的。
考虑到上述第一个问题，该企业对调度系统增加了一个资源管理器，统计对公共资源的并发数。当并发数超过一定数量时，就暂时不为状态为Init的任务分配资源，让其等待。以保证整体任务运行的稳定性。针对上述第二个问题，我们对每个任务运行都启用一个Docker容器，由于容器的资源量都是一定的，因此就保证大小任务的运行的公平性。
当然，该企业的调度系统依然存在不足，比如调度机器的单点故障，如何搭建HA（High Availablity）机制[24]提高调度系统的安全性和可靠性仍然是以后需要主要考虑的问题。
1.1.2、Kepler性能测试
调度和执行机测试环境是32核64G内存、硬盘从240GB到2TB不等。调度机一台，执行机八台。目前Kepler调度系统总共管理了5000多个传输任务，1万多个计算任务。我们可以用这些任务来测试调度系统性能。调度机每十分钟从数据库中读取到触发时间的实例，没有出现问题。调度队列正常值在600个任务左右，此时系统运行良好，但当调度队列超过峰值1200个任务时，调度系统出现响应缓慢的情况，任务的执行状态会出现长时间凝滞的情况。
任务正常运行情况统计如下,任务成功率高达99%，任务失败的主要原因来自高峰时段Mysql数据库连接的失效或者Hadoop集群的抗压问题。另外一个主要原因是任务超时（超过3个小时），一般是因为数据量太大，无效数据较多的原因。计算任务的平均运行时间是1小时，传输任务的运行时间是1.5小时。
表 6.1 Kepler调度系统测试数据
1.2、Wormhole生产实践
1.2.1、Wormhole生产实践
Wormhole开发测试完毕后，我们先整个数据中心推广，然后就是作业的按计划的迁移使用新工具。Wormhole的成功推广大大提高了ETL过程的全局可控性和管理性，同时传输效率大大提高、传输可靠性得以保证。比如，我们能够更有效的面对Mysql集群的变化对ETL任务的影响，也可以对所有的数据传输任务进行监控和日志采集。现在我们能通过Wormhole统计整个平台的数据传输规模，以及传输效率。这在以前分散传输的情况下是不可能的。
目前Wormhole已经在整个企业数据中心普遍使用，在整个数据传输平台中，我们大概每天运行有5000多道数据传输任务运行于每天的不同时段，每个传输任务量级都在600多万条记录。每天为该企业传输的数据量接近1T，占整个企业线上到线下传输数据量的60%（剩下的是Kafka拉取的日志和Storm实时分析产生的数据）。可以说是Wormhole为整个该企业数据传输作出了巨大的贡献。
Wormhole整体架构比较优秀，在生产实践中，我们后续只做了一些Mysql，Hive等数据库读写splitter（分片）类的二次开发，让数据库的读写的并发数能够更有效合理的，有效改善了以前读取时一个分片的单线程状况，大大提高一些瓶颈任务的传输时间。双端缓冲队列的并发性能得到了生产的检验。
表6.2 Wormhole传输效率分析
1.2.2、Wormhole性能测试
Wormhole测试机器参数与Kepler相同，都是32核64G内存、硬盘从240GB到2TB不等。经过测试wormhole可适用多种数据库，其中包括Mysql，Hive，Hbase，Greenplum等。测试的多个任务的传输成功率达99%，失败原因与上文相同。传输性能根据源、目的数据库的种类分别在2到6万行/每秒。持续运行的稳定性在三天以上，实际上大部分任务运行不超过三个小时。最佳传输数据量在100TB以内。
表 6.3 Wormhole测试数据
1.3、Galaxy生产实践
1.3.1、Galaxy生产实践
在没有任务开发前台前，许多任务都是手工配置插入数据库，很多任务配置不规范，产生很多遗留问题。而且手工配任务的方式也阻碍了数据传输平台本身的推广和其他团队的认可。
为了能够自动化配置任务，我们开发了任务配置、任务管理、任务监控、任务状态分析和数据质量等一系列一条龙服务。用户可以在我们的平台上配置、管理和监控自己的任务。大大节省了用户的开发时间。
目前Galaxy前台大概有500多名活跃的开发者，总共管理了5000多个传输任务，1万多个计算任务。而且每天还在以几十个任务左右的数量递增。日均PV，UV都在千级。而且后来还接入Storm的实时计算平台，Flume+Kafka日志抓取平台等，可以说Galaxy前台已经是该企业数据平台最有影响力的管理工具。大部分的数据传输，加载和转换工作都通过此平台进行。
表 6.4 Galaxy平台规模的扩张
1.3.2、Galaxy性能测试
Galaxy和Galaxy-Halley的测试环境都是32核64G内存，硬盘1TB。机器各位两台。Galaxy能支持的日均PV数峰值为10万左右，日均UV峰值为5万左右，每秒请求数峰值是1千次。Galaxy-Halley能支持的RPC请求峰值为每秒1300次。Ngix负载均衡服务器运行良好，承载量在日均10万PV以上。
表 6.5 Galaxy平台性能测试
1.4、本章小结
本章主要是描述了某企业ETL数据传输平台在生产实践中的状况，以及各模块的测试情况。从另一个角度看该企业数据传输平台的整体情况。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
