Spark Meetup in Shanghai 暨出差报告

5月16日和舒伯特一起参加了上海的Spark Meetup 第四次活动,之后整理输出了活动内容,汇报如下:

Opening Keynote

首先是小沃科技的副总沈洲做的开场演讲。介绍了小沃的发展: 一开始从手机应用商店入手,经历了艰难的探索后发现了手游的巨大市场并大力投入,获得了巨大利润。后来又进入电视,把游戏盈利延伸到客厅。

目前小沃的每日活跃用户700-800万,计费请求和处理上千万,需要有对大量数据的处理能力,也确实获得了大量的用户信息,对用户信息的利用也做了很多的尝试,比如付费信用机制,游戏,应用的推广等。目前有大概3亿用户的画像信息,从应用下载,游戏支付等行为进行搜集,包括通信消费,增值业务服务,行为分析。

小沃基于业务的数据处理如图所示:

我的感想是:

  • 移动互联网到处都是机会。垄断地位的运营商同时控制移动互联网的入口,又拥有大量的数据,做大更容易;
  • 很多小沃(或者说联通)这样的企业,已经积累了大量的数据,正尝试从数据中发现更多价值。

GraphX在阿里妈妈广告系统中的应用

来自阿里妈妈的吴炜同学给人的感觉是典型的工程师,所分享的内容更偏技术向。

在计算机中,图算是比较复杂的一种数据结构。在一些涉及到交互关系的算法中,图很有用。比如著名的Google的 Page Rank算法,需要根据页面彼此的链接关系计算页面的价值,那么页面就是图的顶点,链接就是图的边。计算过程就是对页面、链接构成的图状结构数据的迭代。

在社交网络及商品推荐场景中,对象和数据往往以图的形式展现出来。GraphX就是构建于Spark系统上的图计算框架。

GraphX基本原理

图计算框架做的事情,就是封装分布式存储和并行计算的细节,让算法实现者专注于图模型的设计和使用。

图计算的发展:

  • Pregel(Google): 边分割。这是更自然的思路
  • GraphLab(GMU): 点分割。2013年才提出。目前认为点分割是更利于分布式计算的。

从边分割过渡到点分割,我理解还是强调计算的本地性。

GAS模型: 邻居更新模型,有Gather, Apply和Scatter三步骤。我理解是单条边为粒度进行计算,设计的出发点就是可以充分利用并行。

图的分区算法:

  • 随机顶点切分法
  • 贪心法
  • 2D 分区算法

淘宝目前应该是采用的2D分区算法。

广告投放的原理

广告投放是很有趣的话题。

相关知识可以看一下这个网页: http://www.williamlong.info/archives/3125.html

RTB(RealTime Bidding)实时竞价,是一种利用第三方技术在数以百万计的网站或移动端针对每一个用户展示行为进行评估以及出价的竞价技术。与大量购买投放频次不同,实时竞价规避了无效的受众到达,针对有意义的用户进行购买。

RTB的相关技术,让针对用户消费行为和引导的精准定向变得可能。

吴炜同学分享的投放流程我凭记忆记录如下。关键就是第4步(计算投放)和第8步(记录投放):

  1. 用户发送页面请求;
  2. 返回请求页面(广告投放代码);
  3. 发送广告请求;
  4. 计算,匹配 判定。这其中可能会有公司之间的PK;
  5. 返回广告;
  6. 请求元素;
  7. 返回元素;
  8. 记录(投放了一次某某广告)。

阿里妈妈的广告,是有消费者点击了,广告主才需要付费。

广告点击作弊的现象和对策

一切涉及到利益的地方都有人想钻空子。针对广告点击,有一些作弊行为。基本有两类:

  • 广告主自己买点击量。大量制造点击,花点广告费,获得一些类似于评价、推荐系统的倾斜;
  • 竞争对手互点。这种行为充分体现了人性之恶: 虚假点击不带来任何好处,纯粹为了浪费对方的广告费(前面说 了,广告是点击收费)

阿里妈妈面对的不是少量的点击机器人,而是大量团队作战的机器联盟(吴炜同学吐槽说没法拿到腾讯的数据,不然可以通过作弊者的QQ群找到更多人)。再考虑到淘宝的用户量,这种情况下如果靠人为分析用户行为以甄别作弊行为就太困难了。

使用基于GraphX的图算法: 自动分析用户和行为(购买记录,收藏记录等),用户做顶点,共同操作、相似行为作边。

利用k-core 迭代算法逐步排除低度的顶点,最后得到作弊嫌疑最大的用户。

这种分析人类行为的反作弊手段,让作弊者很难应对。

调优和程序经验

  • Spark on ODPS 性能不行,不如原生的Apache Spark。但是阿里的好处是机器够多;
  • GC也不好做,优化空间尚有。

我的感想

  • Spark对内存的利用更好,换种说法就是对内存的依赖更大。大量数据集在内存的存在,导致垃圾回收机制对 Spark的性能影响巨大。无论在什么平台使用Spark,GC都是绕不开的问题。
  • 做社交、购物等行业,只懂技术是远远不够的,要有分析用户心理和行为的能力。

Spark在小沃科技的实践

杨明是小沃的大数据首席架构师,为我们分享了小沃在大数据方面的实践。

几个时代

杨分析小沃大数据在业务上可以划分为三个时代:

  • 处理时代
  • 管理时代
  • 运营时代

我理解这三个时代也可以说是大数据基础设施构建的时代,管理需求膨胀和运维能力成长的时代,以及数据分析和服务开发的时代。

目前小沃引入Spark技术之后的大数据架构如图:

联通小沃是从移动应用或者再具体说是手机游戏切入,大数据的输出不是一蹴而就,而是随着业务扩大的产物。其实放眼望去,大部分互联网或者互联网相关企业都是逐渐做大,在战争中学习战争的。

从杨分享的内容看,小沃还是比较忠实地利用Hadoop和Spark等开源技术,自己并没有改造。确实,找到适合自己的技术就好。联通的优势还是在于通信业内地位和海量用户。

Spark SQL

因为原生Hive 太慢,而Shark项目已停止, 现在小沃采用的是Spark SQL.

优点有:

  • In-Mem Columnar Storage
  • ByteOrder Generaton
  • Scala在代码上的优化

大数据 SQL技术对比

人人都爱SQL。对大数据而言,SQL总是热门话题。就Spark这个圈子而言,Shark已死,目前Hive Spark和SparkSQL 竞争激烈,我感觉一个是Hive with Spark(Spark只是计算框架之一),一个是Spark with Hive(Hive只是SQL引擎之一,不过事实上还是更倚重Hive Context),不知未来鹿死谁手。

Spark Streaming

推崇的是Spark Streaming的吞吐量优势。确实如此,实时性还是Storm更高。Spark Streaming以RDD为计算单元,以定制的批处理Interval为周期,粒度和时间上都较粗,却收获了稳定性和吞吐量。

Spark-R

R语言在统计分析、绘图和数据挖掘方面是无可替代的。 Spark-R 是基于Spark做R的前端,我理解是更便于大量的数据挖掘和分析人员基于Spark开展业务。

孙锐老师是Intel大数据团队的架构师,和大家分享了Spark-R的架构,功能和进展。

R语言这部分不太了解,就不再详细记述了。

交流时间

我们和Intel 的对Spark开源项目有贡献的工程师们有一些交流。

我和Intel的一位女士讨论,Spark Streaming主要胜出Storm的地方,还是Throughput,那么其实这种吞吐能力的问题,说到底还是因为Storm追求实时性而Spark是小粒度批处理有缓存概念。女士表示同意。她说,虽然Storm号称可以有小于秒级甚至是若干毫秒的响应,但是对实际应用中大部分的流计算需求,几分钟其实是可以接受的。

舒伯特最近对图计算感兴趣,可惜问到的Intel的工程师不熟悉GraphX。

我在和Intel工程师交谈中了解到他们实验环境中其实最大的集群也不过50多台机器(其实也不算少了)。国内这方面最激进的是360,宣称有突破千台的Spark集群。

由于时间原因,没有更多交流。

总结

  • 经过观看会议分享内容以及和在场工程师讨论,感到Spark 技术在国内发展还算比较快,很多企业都在实践之中;
  • Intel这样追求技术领先的公司,对于Spark推动不遗余力,更多关注底层实现和优化。与之对应小沃这样的公司, 对新技术是拿来主义。阿里妈妈则是开源技术和自身ODPS平台的结合。每家公司都要找到最适合自己的技术框架;
  • Spark布局很大,各个计算领域都有可用的框架。目前它只有资源管理和调度模块的格局还比较小,其他都是想 要替换原有系统或框架的;
  • 大数据的SQL永远是重中之重;
  • 目前看Spark的学习曲线比较陡峭,部署上易用性不是很好;
  • GC成为Spark稳定性,可靠性和性能的大问题。Spark以内存计算著称,内存利用率高。但是内存也因此而更容易 紧缺。实际应用,需要对系统底层比较熟悉,有调优能力。

我对Spark了解还比较浅,本文疏漏荒谬之处还请指出。



最后更新: 2015-05-19 13:18