《OLAP 在火山 EMR 的实践.pdf》由会员分享,可在线阅读,更多相关《OLAP 在火山 EMR 的实践.pdf(25页珍藏版)》请在三个皮匠报告上搜索。
1、DataFunSummit2023OLAP火山EMR的最佳实践演讲人:琚克俭-火山引擎-研发工程师EMREMR产品概述产品概述 EMR OLAP云原生 EMR OLAP客户案例分析 EMR OLAP未来规划DataFunSummit2023!#$%&()*+,-!#$%&%()使用EMR产品,延续开源架构技术栈,并协同开源大数据生态与火山生态%*+,-./0,12.1345678&9:;Flink-DorisDataFunSummit2023客户案例:某新广告客户(实时场景)客户背景n使用开源的Greenplum,存放近3个月的数据,用于在线报表查询。n在线和离线数据存储在不同地方,读取离线数
2、据需要先读取到在线存储中。核心痛点n保障查询性能,牺牲实时性,每15分钟批量写入最新数据到在线数据存储n实时更新能力n在线报表业务的联合多维分析性能不佳。产品方案nEMR Doris统一对外提供查询nEMR OpenSearch保证数据高QPS的实时更新能力n通过Datasail实时同步MySQL CDC和Kafka数据到Doris和OpenSearch中,保证数据实时性。高频更新高性能查询全域数据集成 DataSail业务库媒体平台数据存储和查询计算DataSail:全量增量一体数据同步Doris:向量化查询应对多表Join、聚合分析ES:高频更新与索引查询DataFunSummit2023
3、ES连接器优化-catalog建表优化无需建表n Catalog方式只需要定义源端资源,即可实现对源表使用Doris on ES能够综合OLAP的分析优势和ES的更新能力及全文索引能力,提供更加完善的分析解决方案强强联合n ES实时高QPS更新能力n 实现ES多索引关联查询n Doris、StarRocks与ES外表实现更复杂的全文索引过滤ES IndexES Index1ES Index1ES Index1EsExternal Table3EsExternal Table2EsExternal Table1ESCatalog方式二Catalog推荐方式一:外表方式,事先创建外表DataFun
4、Summit2023ES连接器优化-下推优化ElasticSearchDorisAgg PushdownOuter join-Inner JoinRunTimeFilterPushdownProject PruneFilter PushdownProject Prunen 减少输出列Filter Pushdownn 利用ES本身aggregationRuntimeFilter join优化n Join的条件在where表达式中同时满足条件列is not null,outer join可转换成inner joinn Runtime filter 下推的场景更丰富Agg Pushdownn 利用E
5、S本身aggregationDataFunSummit2023资源隔离(读写分离)BEgroupAreplica1BEBEgroupBreplica3replica2Load dataUser AUser BUser C生成三副本落到两个资源组中User A 只能使用 groupAUser B 只能使用 groupBUser C 只能使用 groupB,且限制query使用的内存和CPU个数采用内存和CPU资源进行资源限制,超过阈值时,查询直接终止n 单query级别细粒度资源限制相同标签的BE属于同一个资源组件限制各类查询任务对计算资源的消耗,降低任务间资源降低影响n 按照资源组实现物理隔离
6、用户需求:轻量ETL+OLAP查询能够在统一在一个系统(主要是读写分离),但资源隔离(尤其是MEM的使用)是个比较大的问题针对用户设置内存使用n 支持租户级别的Query资源限制QueryDataFunSummit2023数据迁移:MySQL Load 本地文件导入特性说明n MySQL Load是标准的MySQL语法,通过SQL方式导入文件n LOAD语法常用各个引擎之间的数据同步:1、TP系统例如MySQL或者PG,将表中数据导出为文本格式2、再通过LOAD语法导入其他引擎之中n 支持MySQL Load语法,实现无缝对接从TP到AP的数据传输MySQLPostgreSQLSQLServe
7、rMySQLLOAD语法示例:#client_local.csv导入到testdb.t1表中LOAD DATA LOCALINFILE client_local.csvINTO TABLE testdb.t1COLUMNS TERMINATED BY tLINES TERMINATED BY nIGNORE 1 LINESCSV FileDoris用户需求:大量历史周期性的mysql jbdc sql导入任务+临时性的人群信息导入其他最佳实践示例序号优化手段优化提升方法实践沉淀1增加advertiser_id条件业务优化:查询过滤条件中增加advertiser_id条件,进一步减少查询数据量,
8、提高QPS引擎优化:开发in predicate优化,对in表达式中包含多个值,根据tablet裁剪后再下发至BE,减少BE计算量。业务优化实践开发规范产品特性增强2按日分区对数据进行按日分区。单日数据维持在较小的规模。开发规范3分布键设置根据查询模式定义相应的分布键。广告平台80%以上是小广告主,小广告主查询时需要一个分片查出对应数据,我们按照advertiser_id来进行数据分片,按advertiser_id查询时可以一个分片查出所有数据,减少IO交互。开发规范4Colocation JoinColocation Join 功能,是将一组拥有相同 CGS 的 Table 组成一个 CG。
9、并保证这些Table 对应的数据分片会落在同一个 BE 节点上。使得当 CG 内的表进行分桶列上的Join 操作时,可以通过直接进行本地数据 Join,减少数据在节点间的传输耗时。因广告业务中,advertiser_id-campaign_id-ad_id-creative_id 存在级联一对多关系,即 我们按 advertiser_id 做CG,提高join时的性能。开发规范产品特性增强5数据排序建表时增加data_sort.col_num,该参数为数据排序使用的列数,取最前面几列,不能超过总的key 列数。对关键查询列在数据存储时进行排序,减少数据扫描时IO次数。开发规范6物化视图可以对原
10、始数据构造月物化视图、周物化视图、天物化视图的综合使用,提高查询性能开发规范产品特性增强DataFunSummit2023实际上线效果6.86.75.28.77.68.21.00.651.01.51.10.760广告面板-汇总广告面板-数据总条数广告面板-列表广告报表-汇总广告报表-数据总条数广告报表-列表广告业务查询场景192core,768G96core,384G生产环境资源DataFunSummit2023客户案例 某互联网旅游行业用户(离线场景)客户背景n大数据系统支撑报表系统和经营平台,用于旅游客户的运营活动分析。n历史架构是Hadoop+Presto+Kyli
11、n的大数据体系当前挑战n数据规模增速高于业务增速,急迫的降本压力nPresto与Hadoop混布,稳定性差nPresto本身的性能问题和JVM GC内存使用n多套大数据系统,维护成本高新架构n利用HDFS+TOS,实现数据冷热分层存储nStarRocks支撑实时报表统计nSpark MlLib,提升用户画像的执行效率Hadoop集群HBase集群StarRocks集群数据源日志数据埋点SDKRDSEMR Flink集群HDFSSpark、HiveTOSHDFSStarRocksHBaseDataFunSummit2023Kylin场景痛点nKylin预计算的资源使用量和延迟比较大n一份CUBE
12、数据存储放大n需要维护多个系统(包含计算,HBase,调度等)StarRocks优势nMysql协议兼容,与BI工具的适配性好n性能好:无物化视图的情况已经比kylin的场景要好,在创建物化视图之后性能更优n存储成本低:默认存储压缩,存储成本减少近10 xn与Hive数据兼容:In Place数据查询Kylin升级StarRocks架构DataFunSummit2023湖仓架构升级 Starrocks LakeHousezn Dynamic Load Catalog:Trino需要重启服务,添加Hive/ES/JDBC/n 数据湖联邦分析:异构数据源查询n 支持的数据湖格式:Iceberg/H
13、udin 支持格式:Parquet/ORC/Textn 存储介质:HDFS/TOS/CFSn 查询加速:并发读取/RuntimeFilter/列裁剪/分区裁剪/谓词下推/数据预取n 性能提升:相比Trino提升 3x+(意味着可以节省2/3的计算资源)DataFunSummit2023成本控制-Task节点关键特性n Stateless:提供无状态的CN(Compute Node)节点n 伸缩策略:基于负载和时间的弹性策略n 智能识别:根据Profile,智能识别负载,动态调整CN实例个数n 极致弹性:提供CN支持秒级别快速伸缩n 资源利用:满足业务需求时提高资源利用率主要场景:n 无存储资源
14、依赖,数据湖联邦查询n Hive数据原地加速CNBEFEFEFEBECNBEFEFEFEBECN负载/时间策略自动扩缩 EMR产品概述 EMR OLAP云原生 EMR OLAP客户案例分析EMREMR OLAPOLAP未来规划未来规划DataFunSummit2023OLAP后续规划目前StarRocks+Doris 都是面向读优化的设计,在高频TPS的写入场景上由于version+compact的影响,性能会有所损耗,主要会投入:行列混存 WAL+MemTable的写入n 实时引擎存算一体的架构限制了极致弹性的能力,也限制了云上成本的控制自由度。CN节点的优化,目前只支持外表数据利用CN节点,未来希望能够支持读写BE存储节点 存算分离使用n 云原生升级 湖仓一体(实现一套存储,一套元数据,两套计算引擎,轻量化ETL)n 离线引擎DataFunSummit2023感谢观看