中国数据资产管理峰会-唯品会大数据

唯品会大数据实践CONTENT目录关于唯品会01数据平台建设02大数据应用建设03一些想法04•数据平台实践–离线计算分析平台演化–实时计算平台演化–一些技术选型和经验•数据应用实践–系统开发和运营–业务和产品运营–恶意用户识别/风控系统–商品品牌推荐–个性化排序|产品|系统|算法数据仪表盘、数据魔方、比价系统、地图服务等精准推荐基础算法库选品、分仓与预调拨数据实时接入离线计算平台实时计算平台VRC资源管理平台运维监控测试|数据细分人群用户Lookalike唯品会用户画像唯品会大数据VIPBigData整体规划平台服务数据服务数坊分析师平台对外服务VRC开发者平台画像计算VRESqoop/VDP/Flume/KafkaJob调度/Yarn调度运维监控测试数据产品HIVEPrestoSPARKRHbaseDruidHDFSRedisClusterVRE实时算法预测MLLib实时训练分析统计任务GPStorm自助报表平台应用产品服务接入计算存储调度系统-大数据基础平台规划自助取数平台数据平台的建设•离线计算分析平台选建设–混合平台：Hadoop+Greenplum–迁移策略和计划–dailyjob,hourlyjob,minjob–扩容，扩容，扩容–离线和实时的混合–开放平台•实时计算平台的建设–Binlog2KafkaVDP–MySQL2Kafka–SparkvsStorm–RedisChallenge–稳定性挑战–开放平台•碰到的问题离线平台的演化-1•2012年底：CDC调度+GP10节点系统稳定•2013Q1：CDC调度+ETLGp+QueryGp,Tuning•2013Q2：–自有调度平台开发+自有抽取系统+–Hadoop流量开始迁移+–GP交易数据+QueryGP•2013Q3：–自有调度平台+抽取迁移–Hadoop流量迁移结束（70）,交易数据迁移开始–GP交易数据+QueryGP–核心数据小时级ETL•2013Q4–元数据管理系统，数据质量工具–ETLGp完整迁移开始–QueryGP扩容40节点•2014Q1–全部ETL@Hadoop–~200nodescluster+40Ad-HocEDW–Hybridnodeconfiguration离线混合平台-2•Referene:–Netflex,LinkedIn,eBay•GreenPlum+Hadoop–保护现有投资–Hadoop海量数据分析–ETL复杂计算–权限打通•Greenplum：–GP擅长adhocquery速度快，–分析师适应–不足够scalable–长期成本•Hadoop–Massivescalable，但是单个查询慢–海量ETL计算–Web查询离线开放平台-3•开放平台–自助ETL开发–自助报表开发和展现–自助取数分析–成本breakdown,changeback•性能，实时，扩展性，成本–Presto–Druid实时计算系统架构采集推荐建模打点日志binlog消息数据实时增量抽取计算模型训练效果反馈Render&RouterLayerCandidateScanLayerCalculateLayerVRC模型训练平台Flume/VDP/VMSVRE应用开发：任务配置可视化编程EsperEPL平台组件：输入组件输出组件UDFVRCPortal：任务发布日志查看监控告警RuleLayerHbasevsRedis•背景：–个性化userprofile,highQPS,verytimesensitive–用户信用体系userprofile,lowQPS,non-critical–用户实时浏览，订单历史，hightps,highqps–都是海量数据–看上去Hbase更加合适，但是不放心•选择：–Critical的Redis–Non-critical的Hbase–积累经验，逐渐往Hbasedualwrite–其实Hbase也不便宜，就是scale不动系统–Redis某种程度上也可以实现04:35:2311Redis•Storm计算用redis保存中间和结果数据–流量一直增加–大促流量狂涨–计算复杂度一直增加–不停拆分。。。–每次改代码•怎么办？–逐个模块拆分–一开始就按模块写不同instance–一开始就Shard–Twemproxy–优化数据结构–Pipeline/Batch–不求100%准确hlllog–RedisCluster04:35:2312Challange•实时计算作为平台•离线和实时的融合•离线向实时的迁移成本应用实践•业务应用–运营分析–帮助公司买–帮助公司卖•技术开发和运营–Telescope业务监控(storm)–Logview/Titan服务监控(spark)–Applicationlogging(Spark)–CDN日志分析(Hive)–Sitespeed分析(storm)–安全审计分析(impala/storm)大数据对于技术运营04:35:2315实时业务监控7现有平台访问地址：xxxx.vipshop.com商品展示登录注册订单信息代金券信息支付模块商品展示购物车登录注册订单信息代金券信息支付模块FDS探索号CDNNginx域B2C移动端用户增加数移动端下单数整体下单数订单总金额购物车增加数购物车内货品数量业务集合域流量集合登录热力地图注册热力地图订单热力地图购物车访问热力地图日志数据WTWHeatMap大屏幕04:35:2316实时页面加载时间监控实时PV分布监控商业CDN质量分析AppServiceQuality•SparkStreaming,30secmini-batch•进去可以看到每个pool，每个服务器，每个url的请求次数，响应时间，错误率，在过去两周的各个维度的统计数据和曲线；•可以看到pool之间的互相调用关系,调用量…•全无入侵，应用上线即插即用；DataServiceQuality大数据在唯品会特卖模式的业务价值大数据对于数据化运营04:35:2324应用于唯品会全面客户关系管理数据化运营-数据产品•对外：–供应商：数据魔方•对内：–高管：手机数据仪表盘，经营分析–商务：选品，比价–物流：分仓，预调拨–产品/运营：指导产品分析和决策，经营分析，效果评估，产品优化–金融：供应商贷款，–消费者：个性化推荐，唯品白条–营销：个性化EDM，个性化Push，CRM–业务安全：风控打法一：数据从按天更新向实时化转变丰富数据可视化交互方式数据仪表盘打法二：合规前提下，开放更多数据给供应商丰富数据接口格式及实时性数据魔方打法三：实时比价与价高告警比价数据与销售转化率数据关联分析比价系统数据仪表盘数据魔方比价系统产品-数据产品及服务PC用户移动用户AdapterAdapter算法模型1算法模型2算法模型3算法模型4stockdbmsdFlume-kafkaBinlog-kafkaStorm/C++ProfileredisItemredisTrainingDataBusinessRuleEPDebugPlatformhadoop04:35:2427系统架构挑战•用户–数据稀疏，有效反馈少–长尾严重–用户体验，50ms返回•ITEM–冷启动–特征难抽取，比如图片素材•场景–缺少上下文–没有明显意图，不同于“搜索”28底层数据品牌–历史和实时销售数据–价格，品类，颜色尺码风格，季节–品牌相似性商品–商品profile的长期开发–历史和实时商品信息（库存，销售，转化）用户–用户点击浏览，购物车，购买，收藏行为–按品类，风格，价位，性别，尺码–用户实时行为路径04:35:2429我们走过的路04:35:2430•2013Q4-2014Q1:基于人群分组和人工排序的个性化运营尝试–人群划分–首页人工排序–列表页人工规则自动排序–无效果。。。•2014Q2:开始有机会在小流量新版首页尝试技术主导–机器学习+业务规则–首页动态生成个性化推荐模块–首页动态生成个性化排序页面–提高了首页到列表页转化率，降低了跳出率，提高了销售我们走过的路•2014Q3-Now:首页和列表页的个性化排序–机器学习trainmodel–Hadoop生成userprofile/brandprofile–Storm计算实时转化销售数据，用户实时行为和意图–实时排序首页和列表页•下一步–更多引入个性化因子(feature)–细化user/brandprofile,更多数据–引入更多其他算法，做到算法可以灵活替代–不但个性化排序和推荐，还可以有更多04:35:2431个性化推荐下一个阶段•实时，实时，再实时–实时计算商品品牌信息，用户profile–实时推荐–实时算法迭代更新–实时Abtestverify•个性化，个性化，个性化–移动天然是个个性化的好场所–更多的个性化因子–更加全面的数据：用户画像建设，曝光数据的收集…个性化阶段性成果PC端–推荐：•10%~12%PC销售占比–首页个性化排序•~4%销售金额提升移动端(2014/12)–首页个性化排序•~4%销售金额提升–列表页排序优化•~15%销售金额提升–Overall:~17%04:35:2433推荐关键点34推荐用户场景ITEM解决之道35推荐数据算法系统一些小结•技术选型：–业界标准bestpractice–成熟技术:技术本身的成熟度，和我们队这个技术的把控力–referencecustomer/implementation–用最合适的技术，而不是最先进的技术•Don’treinventthewheel框架算法•基础架构/数据很重要–模块化–通用化•ThingsChange半年前不用，可能现在用；Spark，Hbase04:35:2436THANKYOU