中国Spark技术峰会（下）：七剑带你玩转Spark 2.0
5月13日-15日，由全球最大中文IT社区CSDN主办的“2016中国云计算技术大会”（Cloud Computing Technology Conference 2016，简称CCTC 2016）在北京新云南皇冠假日酒店隆重举行，这也是本年度中国云计算技术领域规模最大、海内外云计算技术领袖齐聚、专业价值最高的一场云计算技术顶级盛宴。本次大会以“技术与应用、趋势与实践”为主题，聚焦最纯粹的技术干货分享，和最接地气的深度行业案例实践，汇聚国内外顶尖技术专家，共论最新的云计算技术实践与发展趋势。
大会第三天，在中国Spark技术峰会下午场，来自聚效广告、 新浪微博、英特尔亚太研发有限公司、Databricks、AdMaster等企业的七位嘉宾共同为Spark技术爱好者带来了一场关于Spark 2.0的技术盛宴。
聚效广告技术经理 & DMLC成员、MXNet committer刘忆智：超越MLLib: 通过XGBoost/MXNet看Spark上的前沿（深度）机器学习
下午场正式开始，第一个登场的聚效广告技术经理 & DMLC成员、MXNet committer刘忆智给大家带来的分享是《超越MLLib: 通过XGBoost/MXNet看Spark上的前沿（深度）机器学习》。刘忆智从模型、性能等方面对图形计算框架XGBoost和深度学习计算框架MXNet进行解析。他认为，对于深度学习，Spark现有的MLlib框架的挑战包括不容易表达神经网络的结构、卷积层或全连接层的计算量、参数的量非常大导致内存受限和分布式训练处理等。XGBoost采用多线程来加速树的构建，并通过Rabit进行分布式计算；MXNet能够支持异构计算，通过参数服务器可以支持分布式训练，并通过砍掉无用步骤优化内存的开销。希望将二者与整合Spark的原因：1.Spark是大规模数据处理的事实标准，包括机器学习的操作，希望把ETL和机器学习管道整合；2.GraphX性能很好，但从整个数据处理流程来看，GraphX耗时并不少。
XGBoost和MXNet已经有Spark版本，有一些API可以使用，性能测试表现不错，Failover的工作也正在进行。
演讲最后，他总结到DMLC致力于构建高效、灵活、便携的机器学习系统，其解决方案充分利用了灵活的并行训练方法，同时在底层模块之处GPU计算，以及采用Spark进行快速的流数据处理。其JVM是一个比较通用的模块，即可用于XGBoost，又可用于MXNet，也可以用于数据处理系统。
新浪微博Feed技术专家黄波：Spark在新浪微博Feed排序的应用
新浪微博Feed技术专家黄波带来的分享是《Spark在新浪微博Feed排序的应用》。他的分享主要包括：新浪微博技术架构、Feed、Feed排序三个部分。作为中国领先的社交媒体平台，微博的技术架构分为业务、平台、数据三层。业务层主要面对用户，提供PC端、移动端、企业用户和第三方应用的产品和服务；平台层主要提供一些接口、缓存，承载微博的流量；下面是大数据层，可以分为4个层次：运用、服务、计算、存储。
紧接着，他向大家介绍了feed场景，新浪微博的用户在登录微博之后，一般会发布一些微博，粉丝会在首页看到一些微博的信息我们称之为feed，feed的基本的流程是用户发微博之后，进行物料的存储，然后无聊帅选和聚合，经过排序最后进行feed 的输出。这其中存在一些基本的问题：物料的问题和排序的问题，物料的问题方面，通过引入了关系物料和非关系物料，然后引入个性化的内容来解决物料的问题，同时引入一些用户的质量来解决物料质量的问题；在排序的方面引入了样本、模型、特征来解决排序优化的问题。
接下来，他介绍了Feed中Spark的应用，算法方面，通过使用Spark MLlib进行建立内容质量、排序防抓站模型；特征方面，通过Spark Streaming抽取实时特征。
在Feed排序一节，面对用户阅读体验难评估量化，以及用户千人千面的个性化需求等问题，他从样本、模型、特征三方面介绍了微博对应的解决方案。样本方面：分别引入Spark Streaming/Storm和Spark/Hadoop进行实时、离线的正负样本搜集。模型方面：当数据量大，采用LR、Spark MLlib进行模型训练；当显著性特征生成代价大时，采用GBDT，同时与线上系统整合，进行模型预测。特征方面：区分微博质量和用户个性化需求，同时采用Spark Streaming/Storm/Spark/Hadoop生成实时和离线特征。
分布式系统组件管理与性能监控资深专家王栋：利用ELK来进行Hadoop集群负载性能监控
分布式系统组件管理与性能监控资深专家王栋给大家带来的分享是《利用ELK来进行Hadoop集群负载性能监控》。他从Hadoop集群负载性能监控面临的问题入手展开了本次演讲，目前Hadoop集群运维中负载相关的问题尤其之多，例如文件系统异常，导致系统处理能力下降、资源抢占引起大量作业运行失败等等。接下来，他详细介绍了ELK的优势和特点，通过引入ELK，可以为Hadoop集群快速开发负载性能监控的Dashboard，为用户提供可视化的监控功能。
他重点介绍了ELK监控Hadoop集群负载性能的实现原理以及ELK和Ambari深度集成。ELK利用Logstash和logpreparer来收集Hadoop集群的负载相关日志，其数据来自YARN API、Spark作业日志等等，收集方式为：logpreparer负责准备日志文件，HDFS，REST API，logstash解析日志，存入ES；利用Elasticsearch来存储收集到的数据，通过设立文件TTL，定期清理过期数据；利用Kibana来分析数据和展示分析结果。演讲中，他建议大家利用Ambari来安装，部署和管理ELK：
- Ambari管理员可以通过Ambari Server在浏览器上实现；
- Ambari管理员可以通过Ambari Server的Service和Component管理功能对ELK的组件进行启动和停止操作；
- Ambari管理员可以通过Ambari Server动态的为Elasticsearch Component添加节点，从而扩展Elasticsearch的规模。
演讲最后他提到，ELK和Ambari的深度集成之后，可以通过修改Ambari的源代码(AMBARI-11268)，可以添加Quicklink，指向Kibana的UI界面，方便用户可以快速打开Kibana；同时也可以在Ambari Server上添加alert，可以对用户关心的负载性能指标进行监控，一旦某个指标被触发，可以通过Ambari的Alert机制进行告警。
英特尔亚太研发有限公司Spark Core团队研发经理程浩：Spinach: Spark SQL之上的快速交互式查询引擎
英特尔亚太研发有限公司Spark Core团队研发经理程浩给大家带来的分享是《Spinach: Spark SQL之上的快速交互式查询引擎》。他的演讲分为：Spinach主要特点、Spinach的使用、部署和设计原则、微基准测试数据和未来计划五个方面展开了此次演讲。
开场之初，他提到了如何利用 Spark SQL进行加速 SQL查询这个问题。除了内存管理数据、高速缓存感知计算、矢量化等操作之外，他向大家介绍了Spinach。Spinach 的项目是为了覆盖掉API和cache Layer这两层去解决问题，第一层不需要有额外的第三方的服务存在；第二点就是说我可以提供一个更细力度的缓存；第三所有的数据，数据是缓存在Off-heap Memory中，我们的Spinach是和API是跑在一个进程里面的，这些缓存是放在同一个力度上来做缓存的，这个是放在JAVA最底面一层，好处就是不会对GC带来影响，最后可以支持用户自定义的索引。
在部署和设计原则一节，他向在场的听众详细介绍了Fiber Cache Manager，其驻留在每个执行程序之中；同时管理一个off-heap内存池、数据加载以及退出策略；此外，定期通过executor heartbeat RPC与Fiber Sensor更新fiber 缓存策略。演讲最后，他提到未来计划包括将该项目开源，支持更多的索引类型和嵌套数据类型等。
大数据&机器学习资深实践者梁堰波：Build generalized linear models on massive dataset
大数据&机器学习资深实践者梁堰波带来的分享是《Build generalized linear models on massive dataset》。
massive dataset是基于spark的一个机器学习的库，但是它其实不是一个纯正的机器学习库，它有很多方面的应用，比如说关于统计，可以完成传统的统计软件做的工作。梁堰波分享的就是在它其中的一个应用，就是通用的线性模型。他所讲的东西大部分都是在上一个版本里面没有的，但是在2.0里面有的，也相当于是2.0里面最新的一个特性。
开场之初，他介绍了线性回归、逻辑回归等机器学习中的基础概念，并给出了自己的见解。他谈到线性回归和逻辑回归都是通用线性模型的特例。紧接着，他有详细解释了GLMs在SparkR和Spark MLlib中的使用差别，并并对加载训练数据、拟合模型等操作的代码进行了详细分析。
演讲中他谈到：现行所有的机器学习操作都是在一类数据上做运算，如果我们可以提供一种分布式的运算API，那么对于上层的应用的算法和利用API实现功能的人就有可能不在关心这内部是不是分布式，如果说我们可以实现这些东西，很多的工作都可以做得比较的顺畅了，所以这也是未来的发展方向，我们现在说的这个算法，如果说有一个运算，大家是不是可以一行的代码都可以搞定了？而目前，我们是手工去写了这个文件才能解决。演讲最后，他表示未来的工作重点会放在更好支持R公式、模型并行性等问题上。
Apache Spark & Apache Parquet committer，Databricks 软件工程师连城：Spark实时计算
Apache Spark & Apache Parquet committer，Databricks 软件工程师连城演讲题目是《Spark实时计算》 。他首先解释了需要流处理的原因：流处理可以使得你的决策更快、更有价值。所谓的流处理引擎是指引擎的输入输出都是数据流。他提到Spark Streaming早在三年前的Spark 0.7就已经提到，并且超过50%的使用者认为其时Spark中最为重要的组件。他提到，spark streaming是spark对流处理和批处理进行结合的尝试，提供了一些非常便利的测试，比如说内置的状态的管理和针对大规模生产集群所提出的各种各样的要求的回应，包括动态的负载均衡等等。
他认为在真正应用到生产环境当中去的时候，流处理运行或者说流处理不是孤立存在的，并用新浪微博案例加以验证其观点。
演讲中，他提到Spark本身作为一个一体化的大数据处理引擎，在一定的程度上已经比较好的支持这种多范式混合的流水线，可以在一个应用之内同时的去完成批处理、流处理、机器学习等等，但是其中还存在一些痛点：第一点，Spark Streaming是基于RDD和API来搭建的，但这是另外一套独立的API。无论是从计算的模型还是从API上两者都不是统一的，因此在用户复用代码的时只能复用函数的逻辑。第二天就是计算的函数以及RDD所存储的内容都是不透明的，很难进行针对性的优化。
紧接着，他向现场的观众介绍了Spark流处理在欺诈检测、连续应用等实例中的具体应用方式。Spark Streaming内部的处理机制是：接收实时流的数据，并根据一定的时间间隔拆分成一批批的数据，然后通过Spark Engine处理这些批数据，最终得到处理后的一批批结果数据。对于Structured Streaming，他介绍到其是一个建立在SparkSQL引擎上的一个高水平的流API，常用于同一流、交互和批处理查询。
AdMaster技术副总裁兼总架构师卢亿雷：Spark在大数据的应用实践
2016中国Spark技术峰会最后一场分享由AdMaster技术副总裁兼总架构师卢亿雷完成，其演讲主题是《Spark在大数据的应用实践》，主要分享了YARN上的各种坑、Spark与ElasticSearch的结合、Spark实践案例及流式计算几个话题。
他谈到之所以采用YARN，是因为MR、Spark、Storm计算方式众多，On YARN方便统一协调；其次由于服务器众多，方便统一管理；再者部门众多，On YARN方便资源统计和成本核算。
AdMaster采用YARN加Fair Scheduler的方式，也在持续优化调度。在Spark on YARN趟坑上，卢亿雷分享的要点有：Executor的内存没达到上限前被kill，这可以通过调 spark.yarn.executor.memoryOverhead解决，默认384，根据实际需求调；当有较多MapReducejob，scheduler调度压增的时候，Sparkjob会被kill掉，解决办法是升级hadoop集群到 2.6 以上版本；而对于Executor OOM，卢亿雷表示可以通过增加job的并 度，数据集切分成更小的数据，调整spark.storage.memoryFraction和spark.executor.memory ，设置spark.cleaner.ttl清理元数据等策略完成。
在Spark 实时监控案例分析中，他介绍到通过AdMaster通过自己开发的 flume source、flume 消息加密算法、定义的 flume to kafka 算法、并发入库算法，可支持多种数据类型的收集，并且使得数据足够均匀，安全高效地支撑13w+/s 的吞吐量，足以应对实时监控的要求。在跨屏分析案例中，谈到如何通过多个屏目识别同一个用户的问题，他表示如果公司有账户的体系，比如说阿里、腾讯和百度，可以将账户体系打通；如果没有账户体系的话，就要另谋出路，比如可以采用收集Ip/imei/idfa/其它加密唯一信息 再加上机器学习加以实现。
演讲最后，他向在场的听众分享了数据流分析案例中的亮点，一是数据采集服务中，webservice与kafka、storm配合使用；二是算法服务，基于NLP服务和机器学习实现情感分析、分词等操作。
更多精彩内容，请关注直播专题2016中国云计算技术大会（CCTC），新浪微博@CSDN云计算，订阅CSDN云计算官方微信公众号。