More Related Content Similar to 唯品会大数据实践 Sacc pub (20) 唯品会大数据实践 Sacc pub2. About VipShop
• #3 b2c电子商务公司
• #5 互联网公司市值排名
• ~1300+ 技术人员, fast expanding…
• 业务线:网站,移动,物流,财务,仓储,供
应商
• ~200+ offline /~100 online 计算集群
• 10点高峰一小时(2x 晚高峰流量)
• 电商大促(核心系统15x-30x 平时10点高峰)
• 移动 booming
19:50:05 2
5. 离线平台的演化
• 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
6. 离线混合平台
• Referene:
– Netflex, LinkedIn, eBay
• GreenPlum + Hadoop
– 保护现有投资
– Hadoop 海量数据分析
– ETL复杂计算
– 权限打通
• Greenplum:
– GP擅长adhoc query速度快,
– 分析师适应
– 不足够scalable
– 长期成本
• Hadoop
– Massive scalable,但是单个查询慢
– 海量ETL计算
– Web查询
19:50:05 6
7. Hive vs Spark/shark
• Impala/shark:
– 不成熟,无法和GP相比;
– Impala很多功能不支持;
– Shark很多跑不出来;80%的query 成功率;
– Shark 被SparkSQL替换掉
• Hive还是太慢;
– 在快速改进,速度,功能,权限
– 和当前基本都兼容
– Keep an eye on SparkSQL
19:50:05 7
8. Hive vs Pig
• There were debate whether pig or hive
• Why Hive
– 开发人员适应性
– ETL和分析师统一方案
– 国内主流公司解决方案
– 持续升级
– 社区
• Hive升级
– 0.10 0.110.13
19:50:05 8
9. Hbase vs MySQL
• 背景:
– 离线应用分析出来的结果,需要被在线应用用到
– 数据量非常大,以后会更大
– 应用场景复杂
– 参考JD,TB,Hbase 更加多采用
– 大批量数据访问,低QPS
• 看上去Hbase更加合适,
– 但是我们选择了MySQL ,Why?
– MySQL 开发管理有丰富经验,Hbase当时无
– 产品需要很快出来,需要对外服务
– 开发速度更快,更加稳定
– 128G RAM+Flash卡
– 现在在部分往Hbase迁移
19:50:05 9
10. 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
11. Other tips
• Agent 模式 vs 直接抽取模式
– 跨机房网络问题
• Online 规范
– DB: dictionary, ddl, delete
– Log: location, format ,URL规范
• 调度系统,一个很大的话题
• Yarn
– 究竟现阶段是不是需要?
19:50:05 11
13. 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
17. 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
19. 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
20. 应用实践
• 业务应用
– 运营分析
– 帮助公司买
– 帮助公司卖
• 技术开发和运营
– Telescope 业务监控
– Logview 服务监控
– Application logging
– CDN日志分析
– Site speed分析
– 安全审计分析
19:50:05 20
31. 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
35. 我们走过的路
19:50:05 35
• 2014 Q3-Now: 首页和列表页的个性化排序
– 机器学习train model
– Hadoop 生成 user profile/brand profile
– Storm 计算实时转化销售数据,用户实时行为和意
图
– 实时排序首页和列表页
• 下一步
– 更多引入个性化因子(feature)
– 细化user/brand profile ,更多数据
– 引入更多其他算法,做到算法可以灵活替代
– 不但个性化排序和推荐,还可以有更多
36. 一些想法
19:50:05 36
产品方向决定项目成败
– 方向都错了,还怎么成功?
– 所以技术都希望可以把控产品
– 责权结合,不能有责无权
– 快速迭代,小流量测试
– 在小流程小流量出来一些不错的数据之后,才有机会在主流程上面尝试
技术要和产品和业务在一起紧密协作:
– 业务有什么痛点,技术有什么手段可以解决这些痛点
– 和业务的沟通不够,产品部门自己也没概念,应该怎么做推荐和个性化
– 模块丢给你,就是你的事情了,那就是技术自己玩了
BI/DW不分家
– 总会提出无穷多的需要,
– 容易互相complain和竞争
基础要扎实,但是要短时间出成就
– DW层,到现在还没有全部统一到同样底层数据
– 离线Dataplatform,5年不用做大的重构
– 实时计算一直会快速演进
37. 一些小结
19:50:05 37
• 技术选型:
– 业界标准best practice
– 成熟技术: 技术本身的成熟度,和我们队这个技术的把控力
– reference customer/implementation
– 用最合适的技术,而不是最先进的技术
• Don’t reinvent the wheel
框架
算法
• 基础架构/数据很重要
– 模块化
– 通用化
• Things Change
半年前不用,可能现在用;
Spark,Hbase