网站开发 常德,网站的流量是怎么回事,平顶山哪里有做网站的公司,有创意的产品设计作品介绍基于Blink为新商业调控打造实时大数据交互查询服务 案例与解决方案汇总页#xff1a;阿里云实时计算产品案例解决方案汇总从IT到DT、从电商到新商业#xff0c;阿里巴巴的每个细胞都存在大数据的DNA#xff0c;如何挖掘大数据的价值成为抢占未来先机的金钥匙#xff0… 基于Blink为新商业调控打造实时大数据交互查询服务 案例与解决方案汇总页阿里云实时计算产品案例解决方案汇总 从IT到DT、从电商到新商业阿里巴巴的每个细胞都存在大数据的DNA如何挖掘大数据的价值成为抢占未来先机的金钥匙传统的大数据开发主要基于离线计算平台MaxComputeODPS进行天级别、小时级别的批量数据分析但近些年随着618、99、双11、双12等大促活动的常态化传统的离线数据分析已经无法满足大促当天的需求以双11实时交易数据为例试想如果我们只能看到前一小时或者前一天的成交数据对于公司高层的决策制定、对于行业/运营/商家/商品的行动指导、对于算法的预测调控将大大折扣可以说大数据实时化已经成为通向新商业体系必须拥有的诺亚船票。 从2017年8月开始一群有激情有干劲的小伙伴历经三个月打造出一套实时大数据交互查询服务完美的支撑了珠峰、闪电、通天塔、优惠券、凑单等业务的实时需求并经过了双11、双12等大促活动的实战考验 一、背景介绍 珠峰调控的典型应用场景如下图所示 采集用户在淘宝的每一次浏览/点击/加购/成交等行为都被记录在日志中并实时传送到TimeTunnel该部分工作由业务团队或数据团队完成加工基于集团的明星产品Blink对所需业务渠道的日志进行加工处理产出业务所需要的各种维度/各种指标 装载将加工好的格式化数据装载到lightning交互式查询引擎方便后续快速查询分析通过定制化报表可以实时动态展示行业/类目/商家/宝贝/分桶等多维实时指标方便小二分析决策更多业务报表详见珠峰、闪电 干预在搜索/推荐等产品中算法自动获取指标、并根据实时分析的结果更改线上参数影响线上效果干预后的结果又进入下一个数据轮回直到业务目标完成二、解决方案 2.1 确立目标 改造后的实时数据既要满足功能还要可兼容、可扩展 数据的正确性和稳定性是一切的前提实时数据统计口径必须和离线一致资源有限必须打造统一的解决方案满足已有需求以及未来可能的需求建立标准化拉更多人一起参与数据共建数据的生产和消费都要统一管理消灭一切不合理2.2 梳理需求 将各平台的业务需求进行挨个梳理针对数据自身特点进行抽象确定数据分层 全网数据独立的数据表如全网加购、全网成交等渠道数据根据业务独立性划分为手淘搜索、推荐、营销平台等渠道各渠道包括数据指标曝光宝贝曝光/搜索曝光、点击、引导加购、引导成交等各数据指标是独立的数据表子业务场景含在渠道数据表中存储在固定字段并用关键字区分例如手淘搜索全部分页/天猫分页、推荐的猜你喜欢/购后等数据维度含在渠道数据表中存储在固定字段如时间、宝贝、卖家、类目、行业等和多值字段如分桶、BC类型等梳理各业务方关注的数据场景梳理出双11的数据需求和查询需求 数据要求 宝贝量从去年的20w到5kw增长250倍卖家量从去年的1500到16w增长100倍单表最大数据量 600亿 实时性 单表写入最大QPS 200w/s数据延迟时间日志落地到查询可见 5s 查询需求 查询频率3s、1min、5min、1h查询范围当天、当前小时、前5min、前10min查询响应时间 3s单表查询QPS 100/s2.3 架构选型 目前可以满足上诉性能要求并且相对成熟的实时大数据架构方案有两种 blink kv存储在blink层进行数据预聚合并将聚合后的计算值写入kv存储用户按照事先约定好的key进行查询即可拿到实时结果常用的kv存储比如hbase、redis、tair等。该方案的优势是查询毫秒级响应并支持查询高并发但不足之处是可扩展性较差增加维度或改变查询条件需要改动整条链路。比如双11媒体交易大屏提供00:00到当前时刻的交易总额但如果想查看10:00-10:20的交易总额改造成本就会很高甚至无法进行blink olap/oltp在blink层进行数据明细加工并补充数据标签加工后的数据装载到olap/oltp用户带着自定义条件进行查询。该方案最大的优势就是交互式查询用户可以根据自己需要进行各种维度的查询组合但不足之处就是无法支持高并发高QPS查询而且查询之间会互相干扰偶尔一个大的聚合查询会导致其它查询失败两套方案各有优劣各有适应的业务场景考虑到我们打造的实时数据支持的业务场景较多而且需求各不相同综合比较之后我们选择了第二套方案至于不支持高QPS的问题我们通过优化查询Query解决。实践证明我们的选择是很明智的用户对实时数据的查询需求随着大促逐渐临近呈爆发性的增长甚至双11当天决策层还对我们提出若干新的数据需求不过我们都轻松应对合理的架构让一切不可能成为了可能 2.4 最终架构 2.5 规范标准 统一接口定义 全网数据接口定义渠道搜索数据接口定义渠道宝贝数据接口定义规范实时处理逻辑的分析方法 找日志生产者掌握字段含义并结合业务需求进行初步设计以BI使用的ODPS表为基础梳理离线处理逻辑订阅实时日志使用离线处理逻辑进行日志详细分析实现实时任务代码实时离线对比验证分别从全部、卖家、宝贝三个维度验证要求数据差异均小于3%制定Blink代码开发规范 主流程使用Table APIScala开发日志处理以及字段处理使用UDFJava开发UDF设计尽量只专注一件事如多值字段中n个字段最好提供n个UDF分别处理过滤逻辑和处理逻辑要求代码层面隔离不能耦合严格遵守集团开发规约 让合适的人做合适的事 搜索数据属于我们擅长的我们负责开发维护其它数据推动相应业务方按照标准开发我们提供技术支持和资源支持2.6 重构 实时任务 实时任务重构过程中做了很多细节优化 ID值存储实时数据均存储各维度ID值将冗余字段Name剔除大大减少查询引擎的存储查询压力辅表为主当数据在辅表和日志都存在时优先透出辅表数据数据打标提供全网用户/全网卖家/全网宝贝的数据打标方便业务方按照数据标一次查询获得结果数据分区产出到TT中的实时数据按照宝贝ID进行Partition可以减少查询引擎的单次消耗异步读写写TT以及读写HBase均采用异步操作既提高读写QPS又保证实时任务受集群环境影响最小化离线备份所有的实时数据表每15min同步到相应的云存储ODPS表以防不时之需……封装查询接口 为了约束规范业务方使用实时数据我们封装了统一的数据查询接口 采用租户分配QPS配额的方式控制访问频率对常用查询方法进行封装减少用户学习成本每次查询都进行实时监控并记录追踪日志方便出现问题时快速排查 另外我们对业务方每条Query进行了分析推动业务方优化不合理的Query对于查询Query较大较慢的业务搭建独立的查询引擎通过以上措施减少了业务间互相干扰大大的提高了系统稳定性业务效率也得到了极大提升 数据校验 邀请BI作为裁判对重构的实时数据进行了一致性校验__校验结果90%以上的场景数据差异在1%以内__实时数据准确性得到了大家的一致认可 线上运维 使用烽火台监控延迟报警、无数据报警在KMonitor建立各级监控全景监控、单任务监控、全链路大盘 通过多轮压测保证任务资源占用既不浪费又能满足大促需要三、成果总结 3.1 实战效果 2017年双11活动期间实时大数据共运行Blink任务40产生实时数据表40占用资源约近5000vcore、近20T mem 双11当天处理日志量数百T数据峰值TPS约7000w产出纯净业务数据数十T总条数1500亿其中单表全天近700亿数据处理峰值200w支持了全网数据的辅表信息透出实时数据延迟在秒级别查询服务全天请求近200wQPS峰值约700次平均响应时间1.5s 3.2 建立生态 随着实时大数据取得的成功越来越多平台希望引入实时数据截止到18年1月底实时大数据服务情况如下图所示目前业务平台、数据渠道、数据指标仍在不断扩充中实时大数据生态已经初具规模这对参与实时数据建设的所有小伙伴们来说是莫大的认可 四、作者简介 花名言柏来自搜索事业部-工程效率技术质量-算法工程平台-实时大数据平台14年加入阿里主要从事电商体系实时数据研发以及实时交互式查询赋能于新商业
