唯品会海量数据的实时OLAP分析.pptx

唯品会海量数据的实时OLAP分析;;? 数据量迅速膨胀，传统的RDBMS已无法满足存储需求;? OLAP查询速度变慢 ? ETL数据处理效率降低;? 新业务开发周期变缓 ? 旧业务更新周期拖延;快快快 业务部门的需求和现状的冲突急需解决;? 优点 ? 使用商业敏捷BI工具，快速满足OLAP 报表需求 GreenPlum MPP数据库作为数据仓库 的存储、计算介质 ? 数据仓库和OLAP分析混用同一个数据 库实现。 ? 缺点： ? 海量日志数据的接入使得存储和计算 资源迅速枯竭，但RDBMS数据库水平 扩展能力有限;? 优点： ? 根据服务提供的目标不同，分拆数据 仓库和OLAP分析库，Hadoop/Hive负 责数据仓库部分，GreenPlum专注负 责OLAP部分 ? 缺点： ? 数据需要在两个不同的DB之间同步， 数据冗余且可能存在不一致性 ? BI工具没有进化，但用户的需求正在 不断进化;足够灵活;唯品会大数据实时OLAP升级过程-第 2 阶段;? 优点 ? 业务人员通过拖拽指标维度确定组合 及业务含义 ? 由SQL Parser将用户对数据的描述转 化为SQL并进行查询 ? 数据模型一次建立，多次复用 ? 缺点： ? OLAP数据是通过预先定义模型设计开 发准备的，用户可自定义查询组合但 数据的范围比较有限;无预计算模型;我们需要一个新的OLAP计算引擎;Presto – Facebook贡献的开源MPP OLAP引擎;为什么是Presto;Presto性能测试;? 优点 Presto是Facebook开源的MPP计算引 擎，直接读取Hive数据无需单独存储 同时计算能力强，横向扩展能力强 ? 中位数5秒（平均15秒）内返回所有 类型的OLAP查询 ? 缺点： 每次OLAP Ad-hoc查询都需要从DW层 拉取数据查询，当用户反复发起相同 条件的查询时，资源存在浪费的情况;最快的计算方法是不计算;Redis – 成熟的缓存方案;? 优点 ? 缓存平均命中率15%，最高命中率60% 减少了不必要的Presto查询，提高了 Presto集群的服务能力 ? 命中缓存的数据返回速度从中位数5 秒提升至0.5秒内 ? 缺点： ? 查询Pattern第一次出现的时候， Presto查询的时候还是相对比较慢;空间换时间—OLAP分析的另一条途径;Kylin – eBay贡献的开源MOLAP引擎;为什么是Kylin;? 优点 ? 核心数据使用Kylin预建CUBE，提高 常用数据??次查询的响应速度，90% 的查询在5秒内，中位数响应时间1.2 秒 ? Kylin查询平均覆盖率15%，最高25%， 大幅提升了这些核心查询的性能，同 时针对流量数据的预汇总，降低了 Presto从RawData汇总的资源消耗;OLAP分析的技术进化是一个迷宫而不是金字塔;唯品会在开源计算引擎上所做的改进;? 提升查询性能 ? 新增Hint语法，可在SQL Join级别动态设置策略，通过编译时让 join在replica和distribute两者之间设置，提高Join效率 ? 监控告警Join数据倾斜，通过减少数据倾斜提高执行效率 ? 增加多集群Load Balance，可平衡不同集群间计算量 ? 经过改造，Presto的查询实时性大幅提升;? 减少计算量 新增Kylin Connector，通过CUBE探嗅自动匹配SQL子查询中可以 命中Kylin CUBE的部分，从Kylin提取数据后做进一步的计算，降 低查询计算量 经过改造，Presto升级为Hybird OLAP引擎，同时支持ROLAP和 MOLAP两种模式;? 提高实时性 重写Kafka Connector，支持热更新Kafka中Topic、Message 和表 /列的映射定义 ? 支持Kafka按offset读取数据，支持PB格式，提高Kafka数据源的 读取效率 ? 经过改造，Presto不仅是离线OLAP引擎，准实时数据处理的能力 也得到提高;? 优化维表查找 通过引入Presto解决Kylin亿级维表实时Lookup OOM的问题，通过 Presto查询替换了原有复杂的维表映射值查找机制 ? 经过改造，唯品会版的Kylin相比开源版本极大的扩展了对业务场 景的支持程度;? 提升CUBE利用率 ? 开发CUBE Advisor，通过统计分析总结合适的维度和指标组合辅 助开发选择判断新建CUBE的策略，减少冗余和经验判断上的误差 ? 提供CUBE命中率监控，形成CUBE新建、使用到总结升级的闭环 ? 经此改造，CUBE命中率大幅提高，减少了资源的浪费提升了响应 速度;Presto;谢谢观看！