《5-5 货拉拉基于 Doris 的 OLAP 体系演进及建设方法.pdf》由会员分享,可在线阅读,更多相关《5-5 货拉拉基于 Doris 的 OLAP 体系演进及建设方法.pdf(38页珍藏版)》请在三个皮匠报告上搜索。
1、货拉拉基于DORIS的OLAP体系演进及建设方法杨秋吉 大数据引擎负责人张斌 大数据工程师|0101背景介绍背景介绍0303OLAP体系演进(下)体系演进(下)0202OLAP体系演进(上)体系演进(上)0404总结思考与后续规划总结思考与后续规划目录目录 CONTENT|背景介绍01|货拉拉介绍货拉拉介绍|352352国内城市5858万万月活司机760760万万月活用户3+3+IDC1000+1000+机器数2 20PB+0PB+存储量20K+20K+日均任务数8+8+业务线货拉拉货拉拉-大数据大数据|大数据大数据基础平台基础平台基础基础层层离线计算实时计算资源管理大数据存储OLAP计算基础
2、元数据(Hivemeta)实时数据接入埋点数据接入数据对账数据链路监控离线数据接入数据数据接入接入平台平台接入接入层层数据门户数据门户权限权限中心中心个人个人中心中心内容内容管理管理知识库知识库建议建议反馈反馈数据门户数据门户权限中心个人中心内容管理知识库建议反馈门户上海品茶平台平台层层&数数仓仓数据研发平台数据研发平台飞流实时开发BQ数据查询IDP数据集成开发数据仓库数据仓库DWDWB B基础整合层基础整合层DWDWT T明细数据层明细数据层数据湖接入(数据湖接入(T+1T+1、近实时、实时)、近实时、实时)DWSDWS公共汇总服务层公共汇总服务层用户集市用户集市司机集市司机集市主数据库主数据库
3、数据治理平台数据治理平台大数据安全管理元数据管理数据建表管理数据质量管理数据工具箱数据工具箱自助分析自助分析可视化大屏可视化大屏数据服务工具数据服务工具快捷分析快速报表数据智能支撑工具数据智能支撑工具服务服务层层预警/告警监控多维分析固定报表AB Test特征平台大数据分析平台大数据分析平台数据应用支撑服务工具数据应用支撑服务工具数据工具箱自助分析可视化指标库管理数据上报固定报表用户画像数据云服务大数据分析平台辅助决策类应用辅助决策类应用赋能业务类应用赋能业务类应用应用应用层层智能营销智能广告投放实时报表鹰眼监控经营分析用户分析数据仓库数据仓库ODS贴源数据层DWS公共汇总服务层DIMDIMD
4、WD明细数据层DWB明细数据整合层用户集市用户集市司机集市司机集市集市1集市2指标库AI平台基础层基础层接入层接入层平台层平台层&数仓数仓服务层服务层应用层应用层辅助决策类应用辅助决策类应用赋能业务类应用赋能业务类应用货拉拉货拉拉-大数据大数据|OLAP体系演进(上)02|OLAP OLAP 演进简介演进简介|2021 H22021 H2支撑业务支撑业务:罗盘(实时智能决策系统,支持实时分析、诊断和策略以及复盘)需求特点需求特点:数据实时导入、自由组合维度、实时聚合分析引入引擎引入引擎:Druid,提供单表预聚合查询能力OLAP 1.0OLAP 1.0:孕育期:孕育期2021 H12021 H
5、1OLAP 2.0OLAP 2.0:完善期:完善期20222022OLAP 3.0OLAP 3.0:成熟期:成熟期支撑业务支撑业务:智能定位工具(基于埋点数据提供司机和订单的汇总和明细数据查询功能)需求特点需求特点:单表明细查询和聚合分析、海量埋点数据实时导入引入引擎引入引擎:ClickHouse,提供单表明细查询且有数据高压缩率支撑业务支撑业务:AB Test和实时数仓需求特点需求特点:多数据源(试验埋点数据、订单数据、用户数据、司机数据)关联分析引入引擎引入引擎:Doris,提供多张大表关联分析能力OLAP 1.0-OLAP 1.0-业务场景业务场景|存在问题存在问题1.Mysql存储瓶颈
6、2.开发成本高、效率低3.部分聚合需求不支持 (如长时间窗口聚合分析)OLAP 1.0-OLAP 1.0-需求分析需求分析|决定选择使用OLAP引擎OLAP 1.0-OLAP 1.0-解决思路解决思路|上生产稳定性保障POC技术调研1.业务需求理解2.结合业界实践对比 OLAP引擎1.语法功能验证2.查询性能验证3.数据质量验证1.服务稳定性保障2.数据链路稳定性保障1.构建实时/离线导数链路2.业务双跑验证OLAP 1.0-OLAP 1.0-技术调研技术调研|OLAP引擎数据导入延迟实时数据导入语义数据查询延迟支持多维分析SQL支持程度 支持明细查询JOIN支持度支持复杂数据类型集群成本可控
7、性扩展性可运维性Druid支持实时Exactly-Once低(亚秒 秒级)支持较完善可支持(关闭rollup)很低不支持中(角色较多,依赖HDFS)高高(JAVAJAVA开发,社开发,社区活跃,应用多)区活跃,应用多)高高ClickHouse支持实时At-least-once低(亚秒 秒级)支持较完善支持一般(内存JOIN)支持(MAP/JSON/Array等)低(数据压缩率高)中(C+开发,社区一般活跃,应用较多)高中Kylin分钟级/天级N/A非常低(亚秒级)支持非常完善不擅长不支持不支持高高(JAVA开发,社区活跃)高高Presto小时级/天级N/A一般(秒 分钟级)支持非常完善不擅长支
8、持支持低(无存储)高(JAVA开发)高高Doris支持实时Exactly-Once低(亚秒 秒级)支持非常完善支持支持不支持(2022 Roadmap已有规划)中中(JAVA/C+开发,社区较活跃,应用较多)高高 业务需求业务需求1.可横向扩容,无存储瓶颈;2.可自由组合维度分析;3.可支持任意时间跨度的分析OLAP 1.0-POCOLAP 1.0-POC验证验证|01 语 法 功 能 验 证语 法 功 能 验 证1.收集业务SQL,提取SQL Pattern2.Druid建表和SQL改写:UDF、rollup语义、count distinct语义02性 能 验 证性 能 验 证1.采用业务真
9、实数据和SQL测试2.关闭Cache,统计P75、P90、P99的查询时间3.结合Arthas火焰图分析性能4.性能调优:优化建表导数和索引逻辑、参数调整、物化视图03 数 据 准 确 性 验 证数 据 准 确 性 验 证1.选择基准值:hive表2.hive和druid双跑验证(发现StringLast函数在特定场景下计算值不稳定)OLAP 1.0-OLAP 1.0-稳定性保障稳定性保障|事前【故障预防】事前【故障预防】事后【故障整改】事后【故障整改】事中【故障处理】事中【故障处理】1.容量规划:压测(导数和查询)、容量评估2.容灾演练:扩容、缩容、停服务、HA验证3.恢复预案:前期业务双跑
10、,链路随时可切换1.发现能力:全链路监控告警(机器、服务、任务)2.定位能力:研究引擎原理,关注业务分享,定位大盘3.恢复和规避能力:业务双跑1.故障复盘2.整改落地OLAP 1.0-OLAP 1.0-上生产上生产|3.O L A P 稳 定 运 行稳 定 运 行1.MySQL链路下线1.业务数据接入Druid2.线上查询走MySQL库3.验证Druid数据质量和稳定性1.O L A P 测 试 阶 段测 试 阶 段2.O L A P 上 线 观 察上 线 观 察1.业务查询走Druid2.业务随时能切回MySQLOLAP 1.0-OLAP 1.0-问题总结问题总结|实时数据乱序实时数据乱序影
11、响:会产生大量的小文件(Segment),影响查询效率,增大元数据压力解决办法:在上游Flink里过滤异常数据StringLastStringLast函数结果值不稳定函数结果值不稳定影响:多次查询的结果值不一致解决办法:新增StringLastMax和StringLastMin函数无高效的精准去重函数无高效的精准去重函数影响:离线场景业务需要精准去重能力解决办法:1.引入社区里快手提供的patch,合入 0.20版本 2.另外新增SQL API,并支持导入hive 的bitmap二进制字符串类型020103OLAP 2.0-OLAP 2.0-业务需求分析业务需求分析|实时写入吞吐高能 支 持
12、单 天 近能 支 持 单 天 近 1 0 亿 实亿 实时 数 据 写 入时 数 据 写 入需支持Map和Json格式数据的高效写入和查询能 支 持 复 杂 数 据 结 构能 支 持 复 杂 数 据 结 构支持明细查询能 查 询 司 机 详 情 信 息能 查 询 司 机 详 情 信 息能 统 计 分 析 趋 势 指 标能 统 计 分 析 趋 势 指 标业 务 需业 务 需求 分 析求 分 析支持多维聚合分析OLAP 2.0-OLAP 2.0-业务需求分析业务需求分析|OLAP 2.0-OLAP 2.0-解决思路(解决思路(复用复用1.01.0的的解决思路解决思路)|上生产稳定性保障POC技术调研
13、1.业务需求理解2.结合业界实践对比 OLAP引擎1.语法功能验证2.查询性能验证3.数据质量验证1.服务稳定性保障2.数据链路稳定性保障1.构建实时/离线导数链路2.业务双跑验证OLAP 2.0-OLAP 2.0-技术调研技术调研|OLAP引擎数据导入延迟实时数据导入语义数据查询延迟支持多维分析SQL支持程度 支持明细查询JOIN支持度支持复杂数据类型集群成本可控性扩展性可运维性Druid支持实时Exactly-Once低(亚秒 秒级)支持较完善可支持(关闭rollup)很低不支持中(角色较多,依赖HDFS)高(JAVA开发,社区活跃,应用多)高高ClickHouse支持实时At-least
14、-once低(亚秒 秒级)支持较完善支持支持一般(内存JOIN)支持支持(MAP/JSON/ArrayMAP/JSON/Array等)等)低(数据压缩率高)中(C+开发,社区一般活跃,应用较多)高中Kylin分钟级/天级N/A非常低(亚秒级)支持非常完善不擅长不支持不支持高高(JAVA开发,社区活跃)高高Presto小时级/天级N/A一般(秒 分钟级)支持非常完善不擅长支持支持低(无存储)高(JAVA开发)高高Doris支持实时Exactly-Once低(亚秒 秒级)支持非常完善支持支持不支持(2022 Roadmap已有规划)中中(JAVA/C+开发,社区较活跃,应用较多)高高 业务需求业务
15、需求1.能同时支持明细查询和聚合分析;2.实时数据写入吞吐高;3.支持Map和Json格式数据的高效写入和查询OLAP体系演进(下)03|AB-TestAB-Test:大数据量的多表关联场景(各类埋点数据)进一步做业务分析多表关联场景需求强烈多表关联场景需求强烈随着公司业务的发展,多个产品线对于多数据源关联场景下在线多维分析需求越来越迫切。OLAP 3.0-OLAP 3.0-需求分析需求分析实时数仓:实时数仓:多表关联场景支持,任意时间跨度聚合分析|OLAP 3.0-OLAP 3.0-需求分析需求分析AB-TestAB-Test:业务持续增长更多靠产研驱动、离不开科学的AB实验;AB平台提供科
16、学分流、智能统计能力,助力业务决策、实现业务增长;通过AB数据与用户埋点数据关联关联,可以更直接有力的证明AB策略的优劣。OLAP 3.0-OLAP 3.0-解决思路解决思路(复用复用1.01.0的解决思路的解决思路)|上生产稳定性保障POC技术调研1.业务需求理解2.结合业界实践对比 OLAP引擎1.语法功能验证2.查询性能验证3.数据质量验证1.服务稳定性保障2.数据链路稳定性保障1.构建实时/离线导数链路2.业务双跑验证|OLAP 3.0-OLAP 3.0-技术调研技术调研C lic k h o u s e基于内存做MapJoin支持少量数据下的JOIN;采用内存字典(KV格式)方式只能
17、支持简单维表JOIN;D r u id现有OLAP引擎支持大表JOIN能力较弱,druid/clickhouse均不支持千万级甚至亿级数据量下的大表JOIN。OLAP 3.0-OLAP 3.0-技术调研技术调研|OLAP引擎数据导入延迟实时数据导入语义数据查询延迟支持多维分析SQL支持程度 支持明细查询JOIN支持度支持复杂数据类型集群成本可控性扩展性可运维性Druid支持实时Exactly-Once低(亚秒 秒级)支持较完善可支持(关闭rollup)很低不支持中(角色较多,依赖HDFS)高(JAVA开发,社区活跃,应用多)高高ClickHouse支持实时At-least-once低(亚秒 秒
18、级)支持较完善支持一般(内存JOIN)支持(MAP/JSON/Array等)低(数据压缩率高)中(C+开发,社区一般活跃,应用较多)高中Kylin分钟级/天级N/A非常低(亚秒级)支持非常完善不擅长不支持不支持高高(JAVA开发,社区活跃)高高Presto小时级/天级N/A一般(秒 分钟级)支持非常完善不擅长支持支持低(无存储)高(JAVA开发)高高Doris支持实时Exactly-Once低(亚秒 秒级)支持非常完善支持支持不支持(2022 Roadmap已有规划)中中(JAVA/C+开发,社区较活跃,应用较多)高高 业务需求业务需求1.数据导入准确性;2.支持大表join;性能验证性能验证
19、功能验证功能验证数据质量数据质量TPC-DS数据集验证,业务数据真实场景验证;功能验证功能验证多表关联场景,单天数据查询,TP75耗时9s;性能验证性能验证TPC-DS数据集、业务侧真实数据分别在hive和doris侧双跑比对;数据质量数据质量OLAP 3.0-POCOLAP 3.0-POCOLAP 3.0-OLAP 3.0-稳定性保障稳定性保障|事前【故障预防】事前【故障预防】事后【故障整改】事后【故障整改】事中【故障处理】事中【故障处理】1.容量规划确认容量指标2.压测确认容量最大水位1.发现能力:全链路监控告警2.定位能力:研究引擎原理,关注业务分享,定位大盘1.故障复盘2.整改落地OL
20、AP 3.0-OLAP 3.0-稳定性保障稳定性保障|问题问题1-1-查询性能优化:查询性能优化:需求:查询7天数据,RT 大表 join 小表 doris默认使用右表数据构建hashtable 30s-16s30s-16s2 t1 join(t2 union all t3)-(t1 join t2)union all(t1 join t3)利用RuntimeFilter特性运行时采用BloomFilter,将HashKey条件下推到大表Scan时过滤 16s-5s16s-5s|问题问题2-UnhealthyTablet2-UnhealthyTablet不下降,查询报错不下降,查询报错-230
21、-230场景:不停flink写任务,be机器交替重启,重启完后出现unhealthyTablet原因:1.coordinator be在两阶段提交执行Commit后publish前被重启了 2.max_running_txn_num_per_db参数配置过大,compaction压力大OLAP 3.0-OLAP 3.0-问题总结问题总结解决办法:1.引入社区1.10 patch(issue-9267)2.数据恢复|使用过程中的一些参数优化:OLAP 3.0-OLAP 3.0-参数优化参数优化配置项含义默认值修改值enable_profile进行查询分析FALSETRUEexec_mem_lim
22、it单个查询的内存限制2G8Gparallel_fragment_exec_instance_numBE上执行实例的个数18compaction_task_num_per_disk并发compaction数量24streaming_load_json_max_mb控制单次streamLoad数据量100150max_segment_num_per_rowset限制rowset中segment的数量200500enable_sql_cacheSQL级缓存FALSETRUEenable_partition_cache分区级缓存FALSETRUEOLAP 3.0-OLAP 3.0-数据流数据流|总结
23、思考与后续规划04|总结与思考总结与思考总结1.从业务需求出发匹配合适引擎,为业务精细化运营提供技术支持;2.摸索出一套较完善的上线流程及稳定性保障体系方案,为业务平稳运行提供能力保障;思考1.没有单种引擎能高效支持各种场景,需要针对需求特点选取合适的引擎;|OLAP平台化:平台化:自助化建模;多引擎路由、支持各类聚合、明细、关联等场景。后续规划后续规划|后续规划后续规划01支持更多业务场景,提升开发、决策效率,降本增效高 效高 效02深入内核原理,提供二次开发支持;完善监控告警体系稳 定稳 定03Doris逐步替换Druid,以Doris为主引擎、Clickhouse为辅内 核 演 进内 核 演 进非常感谢您的观看非常感谢您的观看|