AirJD 焦点
AirJD

没有录音文件
00:00/00:00
加收藏

唯品会大数据实践 by zhuchao

发布者 big_data
发布于 1443142494444  浏览 5971 关键词 Redis, 大数据 
分享到

第1页

唯品会大数据实践

zhuchao@gmail.com 2014-9



第2页

About VipShop

• #3 b2c电子商务公司 • #5 互联网公司市值排名 • ~1300+ 技术人员, fast expanding… • 业务线:网站,移动,物流,财务,仓储,供

应商 • ~200+ offline /~100 online 计算集群 • 10点高峰一小时(2x 晚高峰流量) • 电商大促(核心系统15x-30x 平时10点高峰) • 移动 booming



19:50:05





第3页

Agenda

• 数据平台实践

– 离线计算分析平台演化 – 实时计算平台演化 – 一些技术选型和经验

• 数据应用实践

– 系统开发和运营 – 数据魔方,选品 – 恶意用户识别/风控系统 – 商品品牌推荐 – 个性化排序

19:50:05





第4页

数据平台的建设

• 离线计算分析平台选建设

– 混合平台:Hadoop+Greenplum – 迁移策略和计划 – hive vs pig – hbase vs MySQL – daily job, hourly job, min job

• 实时计算平台的建设

– Binlog2Kafka – MySQL2Kafka – Spark vs Storm – Redis Challenge

• 外部数据 • 碰到的问题

19:50:05





第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





第6页

离线混合平台

• Referene:

– Netflex, LinkedIn, eBay

• GreenPlum + Hadoop

– 保护现有投资 – Hadoop 海量数据分析 – ETL复杂计算 – 权限打通

• Greenplum:

– GP擅长adhoc query速度快, – 分析师适应 – 不足够scalable – 长期成本

• Hadoop

– Massive scalable,但是单个查询慢 – 海量ETL计算 – Web查询

19:50:05





第7页

Hive vs Spark/shark

• Impala/shark:

– 不成熟,无法和GP相比; – Impala很多功能不支持; – Shark很多跑不出来;80%的query 成功率; – Shark 被SparkSQL替换掉

• Hive还是太慢;

– 在快速改进,速度,功能,权限 – 和当前基本都兼容 – Keep an eye on SparkSQL



19:50:05





第8页

Hive vs Pig

• There were debate whether pig or hive • Why Hive

– 开发人员适应性 – ETL和分析师统一方案 – 国内主流公司解决方案 – 持续升级 – 社区

• Hive升级

– 0.10 0.110.13

19:50:05





第9页

Hbase vs MySQL

• 背景:

– 离线应用分析出来的结果,需要被在线应用用到 – 数据量非常大,以后会更大 – 应用场景复杂 – 参考JD,TB,Hbase 更加多采用 – 大批量数据访问,低QPS

• 看上去Hbase更加合适,

– 但是我们选择了MySQL ,Why? – MySQL 开发管理有丰富经验,Hbase当时无 – 产品需要很快出来,需要对外服务 – 开发速度更快,更加稳定 – 128G RAM+Flash卡 – 现在在部分往Hbase迁移

19:50:05





第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





第11页

Other tips

• Agent 模式 vs 直接抽取模式

– 跨机房网络问题

• Online 规范

– DB: dictionary, ddl, delete – Log: location, format ,URL规范

• 调度系统,一个很大的话题 • Yarn

– 究竟现阶段是不是需要?

19:50:05





第12页

Solr/ES

• 场景:

– 离线和在线的根据tag检索 – 实时和daily更新 – 海量更新

• 问题

– 迁移hive的job到storm 逻辑过于复杂 – Peak 更新ES跟不上(200k msg/s@peak) – 投入不足



19:50:05





第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





第14页

Pain Points

• 开发环境和生产环境的隔离 • 数据安全/开发者权限 • 数据质量



19:50:05





第15页

实时计算平台的建设

• 架构和组件

– Flume/Binlog – Kafka – storm/spark/Impala – Redis – Hbase



19:50:05





第16页

Yarn ?

• 真正价值? • 离线计算 vs RealTime 计算共享集群?



19:50:05





第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





第18页

Redis

• Storm计算用redis保存中间和结果数据

– 流量一直增加 – 大促流量狂涨 – 计算复杂度一直增加 – 不停拆分。。。 – 每次改代码

• 怎么办?

– 逐个模块拆分 – 一开始就按模块写不同instance – 一开始就Shard – Twemproxy – 优化数据结构 – 不求100%准确hll log

19:50:05





第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





第20页

应用实践

• 业务应用

– 运营分析 – 帮助公司买 – 帮助公司卖

• 技术开发和运营

– Telescope 业务监控 – Logview 服务监控 – Application logging – CDN日志分析 – Site speed分析 – 安全审计分析

19:50:05





第21页

应用于唯品会



19:50:05



全面客户关系管理





第22页

大数据对于技术运营

19:50:05





第23页

实时业务监控

 现有平台

访问地址:xxxx.vipshop.com



B2C 移动端



商品展示 购物车 登录注册 订单信息 代金券信息 支付模块



商品展示 登录注册 订单信息 代金券信息 支付模块



日志数据

FDS 探索号 CDN Nginx域



WTW

用户增加数 移动端下单数 整体下单数 订单总金额 购物车增加数 购物车内货品 数量



HeatMap



大屏幕



登录热力地图 注册热力地图 订单热力地图 购物车访问热 力地图



业务集合 域流量集合



19:50:05



7 23



第24页

实时页面加载时间监控



19:50:05





第25页

实时PV分布监控



19:50:05





第26页

全网Pool健康度(logview)



• 进去可以看到每个pool,每个服务器,每个url的请求次数,响应时间,错误率,在过 去两周的各个维度的统计数据和曲线;



• 可以看到pool之间的互相调用关系;



• 全无入侵,应用上线即插即用;(比如图片的服务质量)



现在在开发下一版本的logview ,发现应用之间的调用关系和调用连,以及和db/Cache 之间



的调用数据;



19:50:05





第27页

短期改版



19:50:05





第28页

商业CDN质量分析



19:50:05





第29页

大数据在网站个性化

19:50:05





第30页

总体个性化成果

PC端

– 推荐:

• 10%~12% PC销售占比

– 首页个性化排序

• ~4%销售金额提升

移动端

– 首页个性化排序

• ~4%销售金额提升

– 列表页排序优化

• ~8%销售金额提升

19:50:05





第31页

Infrastructure

• Platform :

– Hadoop platform – 实时计算平台 – Experiment platform – 运营后台(Debug平台) – ML platform – Large Redis Cluster – DashBoard

• Data & API

– User profile – Item Profile – Brand Profile

19:50:05





第32页

系统架构



PC用户

Adapter



算法模 型1



算法模 型2



移动用户

Adapter



算法模 型3



算法模 型4



stockd



Item redis bmsd



Profile redis



Flume>kafka



Storm/C++

Binlog>kafka



hadoop



19:50:05



EP Business Rule

Debug Platform

Training Data



第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

19:50:05





第38页

Q&A



支持文件格式:*.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。