电商平台实战经验：电商中的Hadoop生态系统应用
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了电商平台实战经验：电商中的Hadoop生态系统应用，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5849字，纯文字阅读大概需要9分钟。
内容图文
郑应钦 中生代技术
摘要：本文来自中生代技术群的分享，分享者郑应钦是非凡网高级架构师。我们都知道Hadoop是一个能够对大量数据进行分布式处理的软件框架。具有可靠、高效、可伸缩的特点。而如何将Hadoop生态系统应用到电商中呢？请详阅本文。郑应钦，非凡网高级架构师，Teamleader
15年IT从业经验,2013年前主要在通讯行业奋战,后转向互联网,在苏宁易购工作过两年,现加入万达 飞凡网。互联网行业主要在广告,金融方面,做过研发,带过团队,常在技术管理和系统架构之间切换角色。
技术交流和面试其实有些共通性,比如经常会有类似问题:如何做到高可用的? 访问峰值达到什么量级? 系统如何撑住的? 高并发下数据一致性如何保证? 如何进行性能优化? 使用了什么新技术? 等等。
实际上如果大家对高可用、高并发、高性能的系统设计有兴趣,从这方面有很多部分可以谈：从硬件到软件、从程序到SQL、 从分布式缓存到CDN,从中间件优化到JVM调优,直到最后我们发现,高可用、高并发、高性能依靠的不是某个硬件、某种技术、某种DB,而需要依靠好的架构,依靠可以落地实施的架构。
好架构有很多,从国外谷歌、亚马逊,到国内的BAT,都有很多先进架构图。借用一句令人印象比较深的话: 我们从不缺架构图。架构图是形,而怎么落地就是它的神了;就如军用材料,技术大家都懂,工艺才是关键。对于搞技术的人来说,能实施落地才是关键。
我们的分享分为以下几个方面：
Hadoop生态圈
广告和联盟系统
爬虫比价系统
延保系统
金融风控系统
典型应用模式
做技术这么多年，有个感受，就是针对现实业务的抽象是道，具体结合技术的应用就是术。比如电商、生产、销售、财务、营销、物流这些业务的抽象，到一定程度上，都是不变的，对道的理解不够，大方向就有偏差。落地应用，术用的不好，系统实现的就烂。
今天的交流，还到不了道的层次，主要是术的应用。我在以前在通讯行业干过多年，因为对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存储，结合数据库和搜索引擎技术，能解决不少问题。
相同对象不同维度的属性同属一张表,方便数据统计，单表Scan即可满足统计输入的需求
海量数据表，进行预分区，Rowkey在Region上均匀分布
小量数据表，Rowkey按数据使用维度进行组织，方便查询
多列簇会导致HBase性能下降，故列簇数量不超过3个
封装HBase操作，将HBase原生接口封装为简单的对于Java实体Bean的操作接口
通过实体Bean上的注解，定义OHM关系,支持HBase 表管理操作，封装HBase 读写接口（put、delete、get、scan），基于对象进行表操作，能自适应选择get/scan
封装常用Filter，基于对象的属性名、属性值设置查询条件,支持自动生成Rowkey及自定义Rowkey
封装了一套基于HBase的ORM组件，方便开发。HBase使用挺简单，大家都知道，主要是设计好ROWKEY就行，另外对于二级索引的引入，那时也没有找到很好的办法，华为开源的二级索引跟公司的版本兼容也不行，通过双份数据另外解决。
延保系统是我调到金融中心搞过的一个系统，延保就是电商售卖商品时，搭着卖的保险产品，因为是展示在商品详情页，因此流量大，另外存储的数据量大，因为要对某个会员，知道他购买的订单商品里，哪些购买过保险，哪些没买保险，进行推销啥的。
分析业务，系统切分，图里表现的很清楚了。大电商平台里，只要涉及到主要流程的功能，牵扯面都很广，需要跟各个中心碰头沟通，最后确认功能实现在什么系统里。
一般高大上的架构师做到这步就OK了，研发出身的架构还顺带把技术方案设计了一把，但是会有难点，量大，性能要求高。
这个系统群里，对于“延保业务增值系统”，需要检索至少一年内的电器订单，且订单是按会员维度查询，量大且检索条件不复杂，综合考虑HBase和Solr的方案，选择HBase。
说白了，就是结合具体业务场景，给出合理方案，而且可行。能保持2-3年的远见就不错了，领导早换了几拨了，总得给后面人留点事做。再说过度设计也比较难实施，现在不都讲敏捷么。
金融的风控系统，是我走前带的最后的业务了。风控难做，坑太大。不仅仅是系统开发好，还得用好。好比是PPT，微软做的工具吧，但每个人写出来的差别大了。要用好，数据挖掘分析少不了，这块SN种种原因没弄好，我就不多说了。
工具吧，也就系统，原来是基于ESPER做的内存计算，有不少问题，内存都加到几十G了，还是个单点系统。
改呗，大数据少不了，至少得STORM啊，实时计算。
ESPER+STORM，都平台产品化了,EPL是个好东西。
这平台产品也不是我们业务方开发的，大数据部门提供的，挺好用。我们接入后，把各种规则表达式改造进去就可以了，这个平台产品SN叫libra。
最后总结了一个普适模式，没开过荤的可以借用下，有了解应用的随便看看了。
内容总结
以上是互联网集市为您收集整理的电商平台实战经验：电商中的Hadoop生态系统应用全部内容，希望文章能够帮你解决电商平台实战经验：电商中的Hadoop生态系统应用所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。