唯品会大数据实践 sacc pub
TRANSCRIPT
About VipShop
• #3 b2c电子商务公司
• #5 互联网公司市值排名
• ~1300+ 技术人员, fast expanding…
• 业务线：网站，移动，物流，财务，仓储，供应商
• ~200+ offline /~100 online 计算集群
• 10点高峰一小时(2x 晚高峰流量)
• 电商大促(核心系统15x-30x 平时10点高峰)
• 移动 booming
19:50:05 2
Agenda
• 数据平台实践– 离线计算分析平台演化
– 实时计算平台演化
– 一些技术选型和经验
• 数据应用实践– 系统开发和运营
– 数据魔方，选品
– 恶意用户识别/风控系统
– 商品品牌推荐
– 个性化排序
19:50:05 3
数据平台的建设• 离线计算分析平台选建设
– 混合平台：Hadoop+Greenplum– 迁移策略和计划– hive vs pig– hbase vs MySQL– daily job, hourly job, min job
• 实时计算平台的建设– Binlog2Kafka – MySQL2Kafka – Spark vs Storm – Redis Challenge
• 外部数据• 碰到的问题
19:50:05 4
离线平台的演化• 2012 年底：CDC调度+GP10节点系统稳定
• 2013 Q1：CDC调度+ETL Gp + Query Gp, Tuning
• 2013 Q2：
– 自有调度平台开发 + 自有抽取系统+
– Hadoop 流量开始迁移 +
– GP交易数据 + Query GP
• 2013 Q3：
– 自有调度平台+抽取迁移
– Hadoop流量迁移结束（70）, 交易数据迁移开始
– GP交易数据+Query GP
– 核心数据小时级ETL
• 2013 Q4
– 元数据管理系统，数据质量工具
– ETL Gp完整迁移开始
– Query GP扩容40节点
• 2014 Q1– 全部ETL@Hadoop
– ~200 nodes cluster + 40 Ad-Hoc EDW
– Hybrid node configuration
19:50:05 5
离线混合平台• Referene:
– Netflex, LinkedIn, eBay
• GreenPlum + Hadoop– 保护现有投资– Hadoop 海量数据分析– ETL复杂计算– 权限打通
• Greenplum：– GP擅长adhoc query速度快，– 分析师适应– 不足够scalable– 长期成本
• Hadoop– Massive scalable，但是单个查询慢– 海量ETL计算– Web查询
19:50:05 6
Hive vs Spark/shark
• Impala/shark:– 不成熟，无法和GP相比；
– Impala很多功能不支持；
– Shark很多跑不出来；80%的query 成功率；
– Shark 被SparkSQL替换掉
• Hive还是太慢；– 在快速改进，速度，功能，权限
– 和当前基本都兼容
– Keep an eye on SparkSQL
19:50:05 7
Hive vs Pig
• There were debate whether pig or hive
• Why Hive– 开发人员适应性
– ETL和分析师统一方案
– 国内主流公司解决方案
– 持续升级
– 社区
• Hive升级– 0.10 0.110.13
19:50:05 8
Hbase vs MySQL
• 背景：– 离线应用分析出来的结果，需要被在线应用用到– 数据量非常大，以后会更大– 应用场景复杂– 参考JD，TB，Hbase 更加多采用– 大批量数据访问，低QPS
• 看上去Hbase更加合适，– 但是我们选择了MySQL ，Why？– MySQL 开发管理有丰富经验，Hbase当时无– 产品需要很快出来，需要对外服务– 开发速度更快，更加稳定– 128G RAM+Flash卡– 现在在部分往Hbase迁移
19:50:05 9
Hbase vs Redis
• 背景：– 个性化user profile, high QPS, very time sensitive– 用户信用体系user profile ,low QPS, non-critical– 用户实时浏览，订单历史，high tps, high qps– 都是海量数据– 看上去Hbase更加合适， 但是不放心
• 选择：– Critical 的Redis– Non-critical 的Hbase– 积累经验，逐渐往Hbase dual write– 其实Hbase也不便宜，就是scale不动系统– Redis某种程度上也可以实现
19:50:05 10
Other tips
• Agent 模式 vs 直接抽取模式
– 跨机房网络问题
• Online 规范
– DB: dictionary, ddl, delete
– Log: location, format ，URL规范
• 调度系统，一个很大的话题
• Yarn
– 究竟现阶段是不是需要？
19:50:05 11
Solr/ES
• 场景：
– 离线和在线的根据tag检索
– 实时和daily更新
– 海量更新
• 问题
– 迁移hive的job到storm 逻辑过于复杂
– Peak 更新ES跟不上(200k msg/s@peak)
– 投入不足
19:50:05 12
Experimental Platform
• Good vision– 统一AB测试框架和报表– 灵活的多维度支持，各种分流方法– 大公司都是这么干的
• Problem:– Too complex design– Not necessary requirement at this moment– Too Heavy– 每个模块都想自己控制跑的更快
• Result– 只是根据Cookie/MID 随机分流– 各个AB场景自己做AB测试
19:50:05 13
Pain Points
• 开发环境和生产环境的隔离
• 数据安全/开发者权限
• 数据质量
19:50:05 14
实时计算平台的建设
• 架构和组件
– Flume/Binlog
– Kafka
– storm/spark/Impala
– Redis
– Hbase
19:50:05 15
Yarn ?
• 真正价值？
• 离线计算 vs RealTime 计算共享集群？
19:50:05 16
RealTime
• How realtime is realtime?
• Storm vs Impala vs Spark
– Min data, impala to replace storm
– Min data, spark to replace storm(complexity/cost)
*storm mini-batch 未使用
19:50:05 17
Redis
• Storm计算用redis保存中间和结果数据– 流量一直增加– 大促流量狂涨– 计算复杂度一直增加– 不停拆分。。。– 每次改代码
• 怎么办？– 逐个模块拆分– 一开始就按模块写不同instance– 一开始就Shard– Twemproxy– 优化数据结构– 不求100%准确hll log
19:50:05 18
Binlog
• Value:– 除了日志数据之外的重要数据来源, Source of truth
• Approach:– Binlog2kafka– Mysql2kafka
• Consumers– FDS– User Profile Builder – Cache update– Search index/Stock API update
• Management Console/Dictionary(WIP)*Reference databus@linkedin
19:50:05 19
应用实践
• 业务应用– 运营分析
– 帮助公司买
– 帮助公司卖
• 技术开发和运营– Telescope 业务监控
– Logview 服务监控
– Application logging
– CDN日志分析
– Site speed分析
– 安全审计分析
19:50:05 20
19:50:05 21
应用于唯品会
全面客户关系管理
大数据对于技术运营
19:50:05 22
实时业务监控
7
现有平台
访问地址：xxxx.vipshop.com
商品展示登录注册订单信息代金券信息支付模块
商品展示购物车登录注册订单信息代金券信息支付模块
FDS探索号CDNNginx域
B2C 移动端
用户增加数移动端下单数整体下单数订单总金额购物车增加数购物车内货品数量
业务集合域流量集合
登录热力地图注册热力地图订单热力地图购物车访问热力地图
日志数据 WTW HeatMap 大屏幕
19:50:05 23
实时页面加载时间监控
19:50:05 24
实时PV分布监控
19:50:05 25
全网Pool健康度(logview)
19:50:05 26
• 进去可以看到每个pool，每个服务器，每个url的请求次数，响应时间，错误率，在过去两周的各个维度的统计数据和曲线；
• 可以看到pool之间的互相调用关系；
• 全无入侵，应用上线即插即用；（比如图片的服务质量）
现在在开发下一版本的logview ,发现应用之间的调用关系和调用连，以及和db/Cache 之间的调用数据；
短期改版
19:50:05 27
商业CDN质量分析
19:50:05 28
大数据在网站个性化
19:50:05 29
总体个性化成果
19:50:05 30
PC端– 推荐：
• 10%~12% PC销售占比
– 首页个性化排序• ~4%销售金额提升
移动端– 首页个性化排序
• ~4%销售金额提升
– 列表页排序优化• ~8%销售金额提升
Infrastructure
19:50:05 31
• Platform :– Hadoop platform
– 实时计算平台
– Experiment platform
– 运营后台（Debug平台）
– ML platform
– Large Redis Cluster
– DashBoard
• Data & API – User profile
– Item Profile
– Brand Profile
PC用户 移动用户
Adapter Adapter
算法模型1
算法模型2
算法模型3
算法模型4
stockd bmsd
Flume->kafka
Binlog->kafka
Storm/C++
Profile redis
Item redis
Training Data
Business Rule
EP
Debug Platform
hadoop
19:50:05 32
系统架构
底层数据
19:50:05 33
品牌– 历史和实时销售数据– 价格，品类，颜色尺码风格，季节– 品牌相似性
商品– 商品profile的长期开发– 历史和实时商品信息（库存，销售，转化）
用户– 用户点击浏览，购物车，购买，收藏行为– 按品类，风格，价位，性别，尺码– 用户实时行为路径
我们走过的路
19:50:05 34
• 2013Q4-2014Q1:基于人群分组和人工排序的个性化运营尝试– 人群划分– 首页人工排序– 列表页人工规则自动排序– 无效果。。。
• 2014Q2:开始有机会在小流量新版首页尝试技术主导– 机器学习+业务规则– 首页动态生成个性化推荐模块– 首页动态生成个性化排序页面
– 提高了首页到列表页转化率，降低了跳出率，提高了销售
我们走过的路
19:50:05 35
• 2014 Q3-Now: 首页和列表页的个性化排序– 机器学习train model– Hadoop 生成 user profile/brand profile– Storm 计算实时转化销售数据，用户实时行为和意图
– 实时排序首页和列表页
• 下一步– 更多引入个性化因子(feature)– 细化user/brand profile ,更多数据– 引入更多其他算法，做到算法可以灵活替代– 不但个性化排序和推荐，还可以有更多
一些想法
19:50:05 36
产品方向决定项目成败
– 方向都错了，还怎么成功？
– 所以技术都希望可以把控产品
– 责权结合，不能有责无权
– 快速迭代，小流量测试
– 在小流程小流量出来一些不错的数据之后，才有机会在主流程上面尝试
技术要和产品和业务在一起紧密协作：
– 业务有什么痛点，技术有什么手段可以解决这些痛点
– 和业务的沟通不够，产品部门自己也没概念，应该怎么做推荐和个性化
– 模块丢给你，就是你的事情了，那就是技术自己玩了
BI/DW不分家
– 总会提出无穷多的需要，
– 容易互相complain和竞争
基础要扎实，但是要短时间出成就
– DW层，到现在还没有全部统一到同样底层数据
– 离线Dataplatform，5年不用做大的重构
– 实时计算一直会快速演进
一些小结
19:50:05 37
• 技术选型：– 业界标准best practice
– 成熟技术: 技术本身的成熟度，和我们队这个技术的把控力
– reference customer/implementation
– 用最合适的技术，而不是最先进的技术
• Don’t reinvent the wheel 框架
算法
• 基础架构/数据很重要– 模块化
– 通用化
• Things Change半年前不用，可能现在用；
Spark，Hbase
Q&A