电商平台实战经验：电商中的Hadoop生态系统应用

紫色薰衣草

导读：我们都知道Hadoop是一个能够对大量数据进行分布式处理的软件框架。具有可靠、高效、可伸缩的特点。而如何将Hadoop生态系统应用到电商中呢？以下和大家分享。

技术交流和面试其实有些共通性,比如经常会有类似问题: 如何做到高可用的? 访问峰值达到什么量级? 系统如何撑住的? 高并发下数据一致性如何保证? 如何进行性能优化? 使用了什么新技术? 等等。

实际上如果大家对高可用、高并发、高性能的系统设计有兴趣,从这方面有很多部分可以谈：从硬件到软件、从程序到SQL、 从分布式缓存到CDN,从中间件优化到JVM调优,直到最后我们发现,高可用、高并发、高性能依靠的不是某个硬件、某种技术、某种DB,而需要依靠好的架构,依靠可以落地实施的架构。

好架构有很多,从国外谷歌、亚马逊到国内的BAT,都有很多先进架构图。借用一句令人印象比较深的话: 我们从不缺架构图。架构图是形,而怎么落地就是它的神了;就如军用材料,技术大家都懂,工艺才是关键。对于搞技术的人来说,能实施落地才是关键。

我们的分享分为以下几个方面：

▪1、Hadoop生态圈

▪2、广告和联盟系统

▪3、爬虫比价系统

▪4、延保系统

▪5、金融风控系统

▪6、典型应用模式

做技术这么多年，有个感受，就是针对现实业务的抽象是道，具体结合技术的应用就是术。比如电商、生产、销售、财务、营销、物流这些业务的抽象，到一定程度上，都是不变的，对道的理解不够，大方向就有偏差。落地应用，术用的不好，系统实现的就烂。

今天的交流，还到不了道的层次，主要是术的应用。我在以前在通讯行业干过多年，因为对Hadoop有些应用，因此借以也得到了一个转行互联网的机会。下面我就对我自身在苏宁易购的Hadoop应用理解，抛砖引玉，献丑一把。

这个图很好的列举了Hadoop生态圈系统，在互联网界也是大行其道，主要是沾了个“大数据”的边，变得很：”热”。大数据忽悠不懂的老板挺好使，其实到具体上手应用也挺容易，但易懂难深。

下面从我经手的一些相关应用说说，广告系统和联盟系统，是做平台电商创收的利器。

C店商家在电商平台上通过广告系统投放，通过联盟系统吸引流量。我加入广告部门时，先接手联盟系统，系统还比较原始，就是普通的信息系统，前台页面，SSH框架，后台DB2数据库。流量一大，系统就会宕机，优化就是砍各种功能，连点击日志都不记录了，为啥？因为量大，关系型数据库撑不住。

优化重构势在必行，概括的说法，就是做了一些系统级别的垂直拆分，引入了一些技术解决痛点。

分了面向广告主的系统，面向运营的系统，面向商家的系统，任务系统，点击系统。对于联盟系统而言，虽然是CPS计费，没有详细的点击日志，就没法做深入的应用，比如反作弊啊，效果分析啊等等。于是Flume+HDFS+Hive+HBase都上阵了。

在2014年系统的日PV达到 2千万左右，大促4千万左右。系统也平稳度过双11，但这在之前是没法平稳的。

有的同学肯定会问，为啥用了HDFS/Hive，还要用HBase呢？因为Hive利于统计，而HBase利于查询，我们系统的场景都需要，而两者之间打通的成本也比较高，于是用了双写的方案。

对于极端要求性能的场景，功能又比较单一的引流点击系统，用了Nginx+Lua的架构，抛开了J2EE的那套，效果还不错。

广告系统主要引进了STORM，使实时计费下线广告变得容易，以前放REDIS，没那么实时。主要也是实时+离线结合，离线的离不开Hadoop。

现在一般使用HDFS的时候都会选择用Hive，毕竟写MR需要点功夫，除了个别需要的场合，一般使用Hive搞定，比较SQL人人都会。

以前总结过一些使用要点，各位随意看看。另外就是注意数据倾斜的问题，相同的目睹，不同的Hive SQL写出来，效率差别大了。比如善用子查询，cluster by一些小技巧，这里就不展开了。

爬虫比价系统，是苏宁情报部门的拳头产品，代号“棱镜”，在2015年双11大出风头。为啥？SN跟JD拼价格，你敢低价，我马上比你更低价，iphone贴钱卖。

这个及时获取对方的商品价格的工作,就是爬虫比价系统干的事。在电商里面,除了淘宝天猫的前端技术比较牛逼,比较难爬外,其它电商基本是一爬一个准。

这个比价项目团队做了一年多,没出啥成绩,因为难点很多,都要时间攻关。我就去帮忙参谋解决了存储问题,也就是使用HBase。

大家知道,爬虫的数据量很大,以前系统用MySql，装的下也性能低。但他们这个场景挺适合用KV存储，结合数据库和搜索引擎技术，能解决不少问题。

1、相同对象不同维度的属性同属一张表,方便数据统计，单表Scan即可满足统计输入的需求

2、海量数据表，进行预分区，Rowkey在Region上均匀分布

3、小量数据表，Rowkey按数据使用维度进行组织，方便查询

4、多列簇会导致HBase性能下降，故列簇数量不超过3个

5、封装HBase操作，将HBase原生接口封装为简单的对于Java实体Bean的操作接口

6、通过实体Bean上的注解，定义OHM关系,支持HBase 表管理操作，封装HBase 读写接口（put、delete、get、scan），基于对象进行表操作，能自适应选择get/scan

7、封装常用Filter，基于对象的属性名、属性值设置查询条件,支持自动生成Rowkey及自定义Rowkey

封装了一套基于HBase的ORM组件，方便开发。HBase使用挺简单，大家都知道，主要是设计好ROWKEY就行，另外对于二级索引的引入，那时也没有找到很好的办法，华为开源的二级索引跟公司的版本兼容也不行，通过双份数据另外解决。

延保系统是我调到金融中心搞过的一个系统，延保就是电商售卖商品时，搭着卖的保险产品，因为是展示在商品详情页，因此流量大。另外存储的数据量大，因为要对某个会员，知道他购买的订单商品里，哪些购买过保险，哪些没买保险，进行推销啥的。

分析业务，系统切分，图里表现的很清楚了。大电商平台里，只要涉及到主要流程的功能，牵扯面都很广，需要跟各个中心碰头沟通，最后确认功能实现在什么系统里。

一般高大上的架构师做到这步就OK了，研发出身的架构还顺带把技术方案设计了一把，但是会有难点，量大，性能要求高。

这个系统群里，对于“延保业务增值系统”，需要检索至少一年内的电器订单，且订单是按会员维度查询，量大且检索条件不复杂，综合考虑HBase和Solr的方案，选择HBase。

说白了，就是结合具体业务场景，给出合理方案，而且可行。能保持2-3年的远见就不错了，领导早换了几拨了，总得给后面人留点事做。再说过度设计也比较难实施，现在不都讲敏捷么。

金融的风控系统，是我走前带的最后的业务了。风控难做，坑太大。不仅仅是系统开发好，还得用好。好比是PPT，微软做的工具吧，但每个人写出来的差别大了。要用好，数据挖掘分析少不了，这块SN种种原因没弄好，我就不多说了。

工具吧，也就系统，原来是基于ESPER做的内存计算，有不少问题，内存都加到几十G了，还是个单点系统。

改呗，大数据少不了，至少得STORM啊，实时计算。

ESPER+STORM都平台产品化了,EPL是个好东西。

这平台产品也不是我们业务方开发的，大数据部门提供的，挺好用。我们接入后，把各种规则表达式改造进去就可以了，这个平台产品SN叫libra。

最后总结了一个普适模式，没开过荤的可以借用下，有了解应用的随便看看了。

个性小丑

感谢楼主分享

小鬼的世界