【PPT+实录】搜狗资深工程师申贤强：大数据处理和统一任务调度系
|
基于这些我们推出这样的架构，scribe将数据传送给Kafka集群，Kafka集群通过数据实时入Hive，现在这个框架有一个好处，解决了上面的问题，一是实时批量入hive，支持流式计算，计算和压缩效率比以前要提升。 优点是什么呢？
??? 通过简单配置和生成代码执行，将数据很轻松导入到我们的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是浪费，资源利用率是不够，运维不同版本不同环境的集群，这个对于运维成本也是相对比较高。 （编辑：大连站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
