【IT168 现场报道】2016年10月27日-29日，2016中国系统架构师大会(SACC 2016)在北京万达索菲特大饭店举行。作为中国规模最大的架构师豪门盛会，本届大会以“架构创新之路”为主题，站在创新的风口上，与大家共同打造一场通过架构创新及各种IT新技术来带动企业转型增效，助力架构师们腾飞的技术盛会。
大会云集了国内外顶尖专家，共同探讨云计算和大数据等技术背景下，如何通过架构创新及各种IT新技术来带动企业转型增效。本届大会共设置两个主场分享时段，24个技术交流专场时段;邀请来自互联网、电子商务、金融、电信、政府、行业协会等20多个领域，150多位技术专家及行业领袖来分享他们的经验;并将吸引4000多名系统运维、架构师、及各种企业的IT决策人士参会，为他们提供最具价值的交流平台。
在28日上午的【云和大数据下的架构实践及优化】主场， Hulu大数据基础架构组负责人董西城为大家带来了精彩的演讲。
▲Hulu大数据基础架构组负责人 董西城
董西城老师曾参与商用Hadoop原型研发，分布式日志系统，Hadoop调度器改造及Spark优化等项目的设计与研发。曾出版《Hadoop技术内幕：深入解析MapReduce架构设计与实现原理》和《Hadoop技术内幕：深入解析YARN架构设计与实现原理》书籍。
董西城老师从Spark简介、Spark在Hulu的应用、Spark在Hulu的优化、基于Spark的漏斗分析系统四大方面展开分享。其中重点介绍了Spark特点：
高效-绝大部分情况下，Spark比MapReduce快;
易用-提供了丰富的API，支持Java，Scala，Python和R四种语言。代码量比MapReduce少2-5倍;
与Hadoop集成-读写HDFS/Hbase。与YARN集成
接着，董西城又介绍了RDD。这是对Spark的一个抽象，为了处理数据方便，弹性式分布数据集。这是一个分布式数据抽象，操作起来非常方便。
为了统一Spark中对结构化数据的处理。在引入DataFrame之前，Spark之有上针对结构化数据的SQL查询以及Hive查询。
这些查询的处理流程基本类似：查询串先需要经过解析器生成逻辑查询计划，然后经过优化器生成物理查询计划，最终被执行器调度执行。
而不同的查询引擎有不同的优化器和执行器实现，并且使用了不同的中间数据结构，这就导致很难将不同的引擎的优化合并到一起，新增一个查询语言也是非常艰难。
为了解决这个问题，Spark对结构化数据表示进行了高层抽象，产生了DataFrameAPI。
在DataFrame上可以应用一系列的表达式，最终生成一个树形的逻辑计划。这个逻辑计划将会经历Analysis,LogicalOptimization,PhysicalPlanning以及CodeGeneration阶段最终变成可执行的RDD。
除了最开始解析 SQL/HQL 查询串不一样之外，剩下的部分都是同一套执行流程，在这套流程上 Spark 实现了对上层 Spark SQL, Hive SQL, DataFrame 以及 R 语言的支持。
随着序列化以及Hash的广泛使用，现在CPU反而成为了一个瓶颈。内存方面，使用Java原生的堆内存管理方式很容易产生OOM问题，并伴随着较大的GC负担，进一步降低了CPU的利用率。
Spark在Hulu的实践：Hulu是一家在线付费视频网站，每天都有大量的用户观看行为数据产生，这些数据会由Hulu的大数据平台进行存储以及处理。推荐团队需要从这些数据中挖掘出单个用户感兴趣的内容并推荐给对应的观众，广告团队需要根据用户的观看记录以及行为给其推荐的最合适广告，而数据团队则需要分析所有数据的各个维度并为公司的策略制定提供有效支持。
他们的所有工作都是在Hulu的大数据平台上完成的，该平台由HDFS/Yarn,HBase,Hive,Cassandera以及的Presto，Spark等组成。Spark是运行在Yarn上，由Yarn来管理资源并进行任务调度。
Spark则主要有两类应用：Streaming应用以及短时Job。
Streaming应用中各个设备前端将用户的行为日志输入到Kafka中，然后由SparkStreaming来进行处理，输出结果到Cassandera,HBase以及HDFS中。短时Job并不像Streaming应用一样一直运行，而是由用户或者定时脚本触发，一般运行时间从几分钟到十几个小时不等。
此外为了方便PM类型的用户更便捷的使用Spark，我们也搭建了ApacheZeppelin这种交互式可视化执行环境。对于非Python/Scala/Java/R用户(例如某些用户想在NodeJS中提交Spark任务)，我们也提供REST的Spark-JobServer来方便用户提交作业。
Hulu从0.9版本就开始将Spark应用于线上作业，内部经历了1.1.1,1.2.0,1.4.0等诸多版本，目前内部使用的最新版本是基于社区1.5.1进行改造的。
较多的迭代触发StackOverflow的问题在某些机器学习算法里面需要进行比较多轮的迭代，当迭代的次数超过一定次数时候应用程序就会发生StackOverflow而崩溃。这个次数限制并不会很大，几百次迭代就可能发生栈溢出。
