副标题#e#
【本文系互联网技术联盟（ITA1024）原创首发，转载或节选内容前需获授权（授权后一周以后可以转载），且必须在正文前注明：本文转自互联网技术联盟（ITA1024）技术分享实录,微信公众号：ita1024k】
本篇文章整理自申贤强4月23日在『1024大数据技术峰会』上的分享实录：大数据处理和统一任务调度系统优化。
正文如下
我是来自搜狗基础平台部申贤强，今天给大家分享的话题是大数据处理和统一任务调度系统优化。
???
我们基于Hadoop系统建设搜狗海量数据存储和计算平台。提供一站式数据处理服务，每天数十亿的数据增量，推动开源数据的发展。
???
重要的事情先跟大家讲一下，开源的项目，一个是Kafka实时入Hive的sink工具，一个是任务管理系统核心组件。也欢迎大家借鉴和使用。
Github地址：
https://github.com/sogou/flume-hive-batch-sink
https://github.com/sogou/docker-on-yarn.git
今天分享主要内容分为两个方面：
???
第一，数据分析。
第二，大规模统一调度系统。
#p#副标题#e##p#分页标题#e#
先讲讲搜狗数据分析的架构，数据分析流程以及现在数据分析师在做数据分析的时候所面临的问题，以及对任务管理和定时运行的各种需求，引出第二个系统，统一调度系统，对于统一调度系统我们讲他的前世今生，以及现在的框架图。
???
搜狗数据分析平台架构图。
原始日志及数据传输、存储、数据工具分析还有任务管理层和前端页面展示层。传输层有实时和离线两个部分，对于离线数据传输我们走的DTE，这种数据直接存储于HDFS，在线层，实时直接入数据仓库。
对于数据仓库层，我们对于原始仓库通过数据筛选清洗，相当于ETL流程，生成精简的custom数据仓库，数据就位之后，数据工具层，常规工具在搜狗，Hive，pig，有HbaseNoSql，类Sql Phoenix和Spark Sql，搜狗也支持即席查询，即分布式SQL，有presto和impala。
当数据分析测试上线之后我们需要的是什么？定时任务管理系统，支持依赖支持定时，将数据结果展现给搜狗网页的产品，实时流量系统、报表以及Search Tool和奥特曼业务。
???
数据分析的流程。
基本上分为这几个部分，采集，数据仓库、计算、数据库、入库，前端页面。将上面的过程进行细化，业务方产生数据，数据要存入存储平台，数据分析书写数据，将结果反馈。
???
数据分析师面临的问题，与前端以及与产品的各种沟通。与测试经理沟通排期，数据分析师要做的事情有可能关心这个数据是不是已经就位，数据仓库的制作是不是已经完成，数据是不是有重复，结果是不是会造成结果不正确，仍然需要关心是什么？
这个任务需要部署提交环境，产品最终上线数据分析师面临的一个问题：
第一，这个数据不准确；
第二，性能有问题，查询缓慢；
第三，没有出来结果，原因提交机挂了，有可能数据分析师面临的问题，所以数据分析师本身比较苦闷的。
???
所以整体说，数据分析整体设计的流程和过程是比较复杂的，无法要求数据分析师一个人全部覆盖所有的事情，需要平台提供一些工具或系统将数据分析师的工作简化，让数据分析师专心写流程，下面我们要介绍如何去提供一些工具，和我们的任务管理系统。
???
我们做工具和系统的目标简化流程，降低人力开发与运维成本，提高开发效率提高资源利用率。
???
如果做到这一点，首先看，数据分析师在写SQL查询之前需要做的准备工作有哪些？原始日志导入，Hive生成default数据仓库需要做数据清洗，即ETL流程。首先看原始日志的导入。
???
在搜狗早期的框架，大概的结构是这样，由于历史原因，存储和计算集群是分离，我们需要进行一次数据传输，这种数据传输会造成它的不好的地方，一，不是实时入Hive，这是离线传输系统。第二，数据的格式是线上服务器固定的格式，所以它的采集频率以及它的格式是固定，对我们使用会造成一定的影响。
它的缺点：
???
-
延迟比较大，它不是实时；
-
频率修改不灵活，如果固定一小时日志采集，我们要改5分钟，需要写逻辑。
-
文件存储，计算性能差，不支持流式处理。
???
#p#副标题#e##p#分页标题#e#
基于这些我们推出这样的架构，scribe将数据传送给Kafka集群，Kafka集群通过数据实时入Hive，现在这个框架有一个好处，解决了上面的问题，一是实时批量入hive，支持流式计算，计算和压缩效率比以前要提升。
优点是什么呢？
-
支持实时批量导入Hive；
-
支持Hivc的parttiton? 采用ORC存储格式；
-
支持自定义Serde进行日志解析。
???
通过简单配置和生成代码执行，将数据很轻松导入到我们的Hive仓库，到仓库之后系一不流程进行数据精简、清洗，我们要进行ETL处理。在早期是Hive/pig表达复杂逻辑一般开发2到3天的开发时间，相对比较复杂。
所以我们对这种情况引入了Spark Dataframe API，可以混用SQL，scala和Java，开发流程段所为半天。
???
底层使用Spark加ORC存储，计算效率提升明显。我们这个开发者的SDK，称为BigDatakit，因为它与搜狗业务比较紧密，没有在这里单独去讲我们的工具，大家可以拿来看一下作为平常的思路借鉴。
???
我们SDK还可以支持的功能，刚才提到ETL，我们也支持Hbase的集成，各种分析工具的集成，并且我们开发者SDK也支持Docker。
???
这是代码比较，左边是pig的脚本，右边是ETL的脚本，两者的长度对比比较明显，基本上有很大的缩减。通过优化之后，很容易就能够将我们的代码，数据已经生成，我们需要做的事情是什么？
部署一个提交环境，数据分析师可能将他的数据部署到可执行环境。所以当前面所有事情都搞定之后，数据分析师终于可以去写自己的分析逻辑，测试OK之后，终于可以上线，上线之后有一个要求，他需要去定期执行，这一块常规的做法用Crontab，依赖的业务时间不确定，你用Crontab变成不靠铺的事情，机器的部署代价和迁移代价非常高。
???
因此我们需要一个复杂的支持业务依赖以及支持环境依赖的调度系统，就是搜狗正在使用的Clotho的系统。
这定期不定期支持任务依赖，支持集成报警，支持环境隔离，我们的环境对于Hadoop环境或者各种工具环境，对于数据分析师而言是透明，我们支持优先级调度，降低运维成本。
???
这是早期的1.0版本，早期版本大家可以看到很简单，Master-Slave结构，如果我的Hadoop1.0和Hadoop2.0，1.0完全无法工作，针对这个工作安排了1.1的版本，也是Master-Slave结构，Slave1和Slave2和异构。
???
这样存在资源浪费，为了保证稳定性而引入了1.1，如果提交的频率不是特别高，造成1.1是浪费，资源利用率是不够，运维不同版本不同环境的集群，这个对于运维成本也是相对比较高。
#p#分页标题#e#
???
资源利用率不高，我们存在资源浪费，并且在优先级支持是不太足够。我们现在所使用的系统就是的2.0调度系统，引入Docker，这是我们核心的逻辑都在上面。
??
第一，引入Docker解决环境依赖，Docker不在今天会议上，最大的优势资源与环境的隔离。
???
第二，YARN，比较优秀开源框架，大家对它使用比较多，解决调度问题，优先级问题，资源利用率的武装，所以这是引入YARN的原因。
???
#p#副标题#e#
这是总体的流程图。刚才提到配置是支持Docker，大数据kit和数据传输系统提交的是Clotho，Clotho去仓库里铺到registry。如果你的Clotho集群越来越大，Docker仓库会成为性能瓶颈，解决这个问题我们引入了registry，原理很简单，两次原子操作，解决负载均衡的问题。
???
这是我们Clotho2.0框架图，与现在的YARN系统结合在一起。
???
向客户端提交一个兆，客户端通过调度把兆分配给管理者，启动是app master，启动docker，dockerContainer，主要功能，客户端与app master一致。app master检查版本，获取日志，获取周期，docker container提交Hadoop，我们与环境无关的隔离的Hadoop集群。
因此我们引入了YARN，
第一，支持HA。
第二，指定label调度。
???
总结一下我们主要的功能， Docker Daemon监控Container的状态。
???
Clotho Master。
???
检查image版本。
???
启动Docker Container。
?
??
对于2.0一些优点其实可以看到：
第一，与Dockek和YARN的开发，对于用户而言接入或使用的成本是相对比较低的。
???
第二，它有一个很重要的问题，集群的环境对用户是透明，数据分析师不需要关心他的环境部署问题，他的环境的版本更新问题，如果我的集群进行升级或者调整，对于数据分析师不需要关心这个事情。
??
第三，形成了统一的提交集群。用户不需要单独申请自己的提交机，我们只需要去统一集群上提交自己的job就可以了。
???
第四，我们支持label调度，资源利用率是非常高的，所有的集群所有机器都可以去机动任务一个Dockecontainer。
???
极大的降低运维成本，上线后故障率基本为0。
???
我们的TODO：
第一，希望做的是长服务。像MYSQL数据库希望通过方案希望长服务支持系统里面。这种情况下能够比较好做到长服务，像MySQL的环境隔离，减少部署代价。
???
第二，Registry服务器方案需要改进。不支持Docker生存状态的展示，我们希望跟开源框架结合到一起，可以更好的监控和Docker registry仓库的情况。
???
第三，OM-Killer导致重复job。后续要做的工作动态调整内内存阈值，尽最大可能减少OM-Kille发生。
???
第四，我们与Docker Container Executeor的结合。最大限度的去挖掘我们集群的价值。
???
这是我今天分享的内容，谢谢大家。
◆ ?◆ ?◆
About 互联网技术联盟 ITA1024
#p#分页标题#e#
互联网技术联盟（ITA1024）是由京东、美团点评、小米、滴滴、携程、网易、搜狐、乐视、当当、途牛、饿了么、58、猎豹等TOP100的互联网服务和七牛、青云、听云、DaoCloud、UCloud、有云等技术服务联合发起的国内最大的企业间技术交流组织，专注于互联网+技术与创新。
联盟精心组织的1024系列技术峰会，由每周一期的线上万人课堂和每月一次的技术大会组成。每月一个技术主题，由联盟成员企业推荐的国内一流技术专家联手打造，分享如何通过一线技术应用案例和最佳实践，支撑和驱动业务成长。
联盟还通过官方网站（www.ita1024.com），官方微信公众（ita1024k），ITA1024技术月刊等多种形式，将精品技术内容精准推送给细分领域专业人群。
