【AICon】 如何构建高效的 RAG 系统?RAG 技术在实际应用中遇到的挑战及应对策略?>>> 了解详情
写点什么

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

  • 2015-09-07
  • 本文字数:3700 字

    阅读完需:约 12 分钟

在 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 单左右,目前准备和沃尔玛门店的共享和交换数据,后面线上线下融合的新场景、新玩法也越来越多了。

InfoQ:感谢您接受采访,期待您的演讲。

2015-09-07 03:565128
用户头像
臧秀涛 略懂技术的运营同学。

发布了 300 篇内容, 共 129.2 次阅读, 收获喜欢 34 次。

关注

评论

发布
暂无评论
发现更多内容

腾讯前端面试题合集

beifeng1996

JavaScript 前端

许世伟老师架构课笔记分享

BeyondLife

架构师 需求设计

力扣349 - 两个数组的交集【哈希表+数组+双指针】

Fire_Shield

双指针 哈希表 9月月更

Qt实现文本编辑器(一)

中国好公民st

c++ qt 9月月更

5分钟教你如何利用华为云IoT进行物联网设备上云

wljslmz

物联网 IoT 华为云 9月月更

架构师的十八般武艺:架构边界

agnostic

架构边界

【iOS逆向】某不知名App越狱检测

小陈

iOS逆向

中秋阅读计划 | 有趣不枯燥的“小薄书”

图灵社区

程序员 科普 计算机 书单 中秋

B-Tree索引

急需上岸的小谢

9月月更

京东前端一面面试题

bb_xiaxia1998

JavaScript 前端

【Nacos云原生】阅读源码第一步,本地启动Nacos

石臻臻的杂货铺

云原生 nacos 9月月更

在线编码、格式转换

人生如梦

React 在线格式化 在线编码 转码工具

开始思考吧

吴京

学习 思考 思想

数据治理(十三):Ranger 安装与启动

Lansonli

数据治理 9月月更

Java进阶(十四)实现每天定时对数据库的操作

No Silver Bullet

Java 数据库 9月月更

库调多了,都忘了最基础的概念-《死锁与范式的碰撞》

知识浅谈

死锁 范式 9月月更

Python 教程之变量(3)—— 全局变量和局部变量

海拥(haiyong.site)

Python 9月月更

如何刻意练习-中秋读书随笔

刘旭东

刻意练习

python小知识-日志处理logging

AIWeker

Python python小知识 9月月更

极速导入elasticsearch测试数据

程序员欣宸

elasticsearch 9月月更

Nvm的安装及使用(Nodejs版本管理器)

node.js NVM 9月月更

C++学习------cmath头文件的源码学习04

桑榆

c++ 源码阅读 9月月更

算法基础(一)| 快速排序和归并排序详解

timerring

算法 9月月更

力扣15 - 三数之和【奇妙的双指针】

Fire_Shield

双指针 LeetCode 9月月更

AQS 阻塞队列机制源码分享

new life

AQS

中秋阅读计划 | 有趣不枯燥的“小薄书”

图灵教育

程序员 科普 计算机 书单 中秋节

LeetCode-164. 最大间距(Java)

bug菌

9月日更 Leet Code 9月月更

关于 SAP UI5 所有控件的共同祖先 - sap.ui.base.ManagedObject

Jerry Wang

SAP Fiori SAP UI5 ui5 9月月更

Python 教程之变量(2)—— Python中整数的最大可能值是多少?

海拥(haiyong.site)

Python 9月月更

LeetCode-454. 四数相加 II(Java)

bug菌

9月日更 Leet Code 9月月更

TCP/IP参考模型

StackOverflow

编程 计算机网络 9月月更

《Storm技术内幕与大数据实践》作者陈敏敏谈大数据技术在电商领域的应用_QCon_臧秀涛_InfoQ精选文章