转载

《Storm技术内幕与大数据实践》作者陈敏敏谈大数据技术在电商领域的应用

在10月15~17日的 QCon上海2015 上，1号店资深架构师、《Storm技术内幕与大数据实践》一书作者陈敏敏将分享《1号店通用精准化平台架构以及大数据营销实践》。在大会开始之前，InfoQ就Storm、Spark等技术在电商领域的应用等话题采访了他。以下为采访内容。

InfoQ：首先请向InfoQ的读者做一下自我介绍吧。

陈敏敏：我目前在1号店担任精准化部门的架构团队负责人。在此之前曾服务于微软和三星电子等公司，长期从事大数据、搜索和推荐平台相关工作，目前主要关注NoSQL、实时计算框架、推荐、大数据营销等相关技术。

InfoQ：您在演讲中将分享Storm、Spark等技术在电商部分领域中的实践。可以介绍一下为何会选择这类技术吗？

陈敏敏：我刚开始在1号店开发了Hadoop版用户画像系统，数据是一天更新一次，后来随着业务的发展，需要知道用户晚上到家了，推荐结果中需要加入用户白天在公司看的产品；下班路上，知道用户下午看了什么，画像系统一天更新一次慢慢需要变成一天更新两次，渐渐到2014年上半年需要一天三次。

要更新三次的时候，遇到了很大的瓶颈，整个画像的数据流比较长，又要和全量的数据关联，跑完一次都要4到5个小时，势必一天一半多的时间都在跑数据，而且各种job跑的时候，那部分时间的最新行为没法引入到画像系统中，迫使我们不得不考虑其他解决方案。

当时对比了几个实时计算框架，Storm已经流行一段时间，业内也慢慢有一些实践案例，其它当时成熟度还不够。如果业内应用场景不多，到时上线的时候，坑会比较多，后来决定用Storm开发实时画像。那个时候大家经验都不是很足，集群经常发生各种莫名其妙的问题，一个应用干扰了另一个应用、进程动不动内存溢出重启等等，大约到年中的时候才差不多开发完，后来实时集群又慢慢衍生出实时意图、实时广告投放、实时显示每个品类下各个群体的用户数等项目。

至于用Spark，做推荐的时候，开始用了Hadoop mahout版的基于内存的FPG和分布式的PFP挖掘频繁项集，遇到了一定的瓶颈，数据ETL的各个过程通过HIVE也比较慢，后来决定引入Spark，在调优上也慢慢积累了一些经验，后来基于Spark开发了促销排期等项目，这些技术的引入都是在各个时期遇到不同的瓶颈，自然而然的结果。

InfoQ：电商相关的业务有何特殊性，可以介绍一下这些技术的具体应用情况吗？

陈敏敏：国内各个电商运营的玩法越来越多，数据越来越复杂，促销活动也越来越多，大大小小的促销几乎每一两周都有，竞争一直比较火热。运营人员往往要拉历史数据，花不少时间人工去对比一张张Excel表格，决定每一个阶段选哪些品牌或主题做促销。

我们那个时候想通过大数据的方法辅助他们运营；其次，影响推荐系统的权重，算法其实可能只占10%，数据清洗的投入、业务理解各自占据着20%以上的权重，推荐技术从单纯的提升GMV也慢慢转向提升跨品类销售、提高用户粘性等，这些因素，也迫使电商做更加灵活、更加精细化的投放和营销，以更加精准的命中用户群的需求，给广告投放、推荐栏位、大数据营销等带来价值。

InfoQ：可以分享一下Spark的研究和使用经验吗？

陈敏敏：Spark的东西比较多，我们这边分头研究的，比如，有人专门看图计算、有人专门看内核等，然后定期互相分享，在实践中我们也只是用了一些常规的算法和数据处理，其它深度学习和LDA等大数据的算法，在数据量上来后，目前还不是很好在Spark上应用，它们的Model往往都非常大，如果用GPU集群，GPU对内存中的Model的修改可以一致，速度稍微快点；如果用分布式的内存，Model分散在分布式内存中，随着Model慢慢增大，对Model做修改，内存之间需要做大量Shuffle操作，速度会非常慢，而对于超大规模集群，GPU也不行，超大规模的情况目前还是基于分布式的内存，谷歌大脑就是基于分布式内存的。

InfoQ：可否介绍一下相关的技术栈？

陈敏敏：大数据技术的范畴还是比较大的，下面有索引、消息系统、NoSQL和NewSQL等分布式存储媒介。

目前一个大数据平台往往需要多种存储系统，每一个存储都有它的利弊，不同的业务场景往往需要不同的系统，我们用户维度的数据同时存在了Hive、HBase和Solr中，以满足不同的业务场景；往上，分布式计算目前比较流行有流式计算、迭代计算、MR等，Spark的MR和Hadoop的MR也是有不少差别的，Hadoop中Map-Merge-Shuffle-Merge-Combine-Sort-Reduce几个过程比较固定，事先排序好再做归并提高性能，而Spark因为是以内存作缓冲区，并且是Hash-Based，可以边Shuffle 边 Aggregate 数据，不用很在乎那部分性能，可以根据场景需要再做排序，更加灵活；前面这两块很多技术原理又是相通的，比如：Storm和Kafka都要涉及消息的可靠性和顺序性，不少系统都需要推举Master的Paxos算法等分布式技术。

再往上就是具体搜索、广告、推荐、图像/语音识别等产品了，这些技术有交集，但是差别也是不小，常用算法和关注点等都不一样，搜索的常用算法有PageRank、NLP等，广告的逻辑回归等，推荐的协同过滤、关联规则等，有些关注ROI、有些关注GMV、交叉销售提升等，基础是机器学习、数据挖掘、自然语言处理等算法。

最后是BI、大数据营销等产品，目前基于大数据的可视化以及相关OLAP的工具发展还不够成熟，上次Cloudera的人介绍了一个看起来不错的可视化产品，要收费不开源，交互式查询的Impala、Kylin、Pestro、Spark SQL这一块发展比较快，但是数据量上来，查询分析速度还是没有传统的BI工具用的舒服，需要预先通过编写UDF等计算好，而不是通过工具操作就可以预先生成一些纬度数据，降低分析人员的门槛。当然Hive本身也在优化，除了把存储文件转成ORC File、引入Tez引擎，本身的MR引擎也在优化，相信未来Hortonworks能把常规的查询等优化到1秒。

InfoQ：Twitter又开发了Heron，这方面对您有什么启发吗，可否分享一下您的认识？

陈敏敏：Heron还没开源，看论文里的描述应该算Storm的2.0, 我觉得至少比Hadoop 1.0和2.0之间的差异要小的，等它开源了，试用一段时间，再看看吧。个人觉得可能会和阿里的JStorm那样成为Storm的另外一个分支，会处于一个长期竞争关系，最终哪一个更好，看团队、公司投入等，现在还不好说。

一般新东西出来后，等业内使用过一些不同场景，更新了几个版本，再使用比较好，用的最早的那批坑也比较多，业务上线的那段时间会比较痛苦。

InfoQ：可以谈谈您编写《Storm技术内幕与大数据实践》一书的缘起吗？给我们分享一下写书的感受吧。

陈敏敏：当时做Storm项目，资料比较少，看到市面上的两本Storm的书，要么大部分内容来自英文官方文档，要么就是差不多的例子写了很多页。

回想起项亮的《推荐系统实践》、吴军的《数学之美》等书，都是比较精致，看起来比较舒服，在圈子里口碑也不错，遂想也搞一本不浪费大家时间的书。现在看京东上96%好评，只有两个中评，基本完成了当初的目标，不过里面实践部分不足，当时主要担心公司项目万一涉密，引起不必要的麻烦，后来最后找我们的CTO写序的时候发现没那么严格，现在正好把缺失的一些实践部分，在QCon上分享下。

对于写书，我觉得有一个宗旨，不能为了写书而写书，否则浪费读者时间；而应该尽可能给读者带来一些有用的东西，不用贴很多代码，或者把大家都能看到的东西都东拼西凑作为内容，如果一个人精力有限，可以找合伙人一起，做技术的大家都很忙，看一个书如果像看电影一样，有些看完了，才知道浪费时间了，显然不大好。对于写书比较痛苦的是初稿后的五个月的修改阶段，从前到后得看好多遍，审美疲劳，但是对读者要负责，尽量减少低级错误。

InfoQ：你们架构团队主要做什么？对架构师都有什么样的要求？可否介绍一下你们目前的数据量？

陈敏敏：每个公司对架构师的定义不一样，我们部门主要有推荐系统、精准化触达、大数据营销、PIS(智能比价系统)等产品，对于架构团队首先要保障大数据集群的优化、源码级Bug的解决、以及技术方案选型，目前HBase、Hadoop、Storm、Spark、Solr等都会使用到；其次，大数据的常见算法要知道，否则算法工程师倾向设计严谨的模型，系统不一定能承受得了，了解算法在有些实时场景是否需要简化？用Storm还是Spark？离线和实时怎么融合？最后，SOA、设计模式、微服务等等应用架构也要了解，没有好的模块化，推荐算法可能每个人从数据到栏位单独写一套代码，维护成本越来越高，架构如果设计出好的框架那是比较好的；最后，架构这边承担了新技术预研，大数据技术日新月异，需要能跟得上外界的发展，了解各种新技术的业务价值和成熟度，负责给部门引入新技术，目前部门还缺架构师，如果你感兴趣其中的任何一块，可以联系我们。

目前我们用户维度有1亿多注册用户数据，每个用户有91个属性，并且还在迅速增加中，我们挖掘出来的小区、公司、学校等数据也在不断补充进去；商品维度有1千多万SKU，上百个属性，通过用户评论、标题中挖掘出的标签也在不断的补充进去；另外，我们的订单平日峰值一分钟1000多单，大促时候一分钟8000单左右，目前准备和沃尔玛门店的共享和交换数据，后面线上线下融合的新场景、新玩法也越来越多了。