DorisDB原理剖析 和应用实践篇_2021

2021DorisDBDorisDB原理剖析和应⽤实践篇鼎⽯·DATAROCKS数据驱动的新趋势更快、更•数据查询和分析的速度快，秒级返回结•从“T+1”到秒级实时果；数据报表建设速度快，建设简单灵活•管理者需要实时管理驾驶舱⾼效，需求快速响应。•实时数据分析场景：在线⼴告效果分析、•不依赖预计算，能够有效⽀持业务的快速更实时实时推荐、电商⼤促实时分析、⼀线任务迭代，同时⽀持聚合数据和明细数据查询⼈员实时绩效跟踪等。更统⼀•统⼀的数据分析系统有助于打破部⻔间的•不仅仅是管理层的数据分析⼯具数据孤岛，实现数据价值最⼤化。更多⼈同时•赋能⼀线业务⼈员，数据驱动业务•统⼀管理，降低管理的复杂度，提升数据使⽤•提升运营效率，促进降本增效安全性。•降低运维成本，确保系统稳定性。数据驱动的新趋势鼎⽯数据库重构企业数据基础设施新⼀代弹性MPP：极简架构✓极简架构，只有两类进程：FE和BE，便于运维✓充分利⽤多机和多核的资源✓可以执⾏多层级复杂SQL语句，⼤表的Join，⾼基数聚合，并且流⽔线执⾏✓兼容MySQLDorisDB整体架构-MPP架构整体架构-MPP架构智能CBO查询优化器1.新⼀代基于运算成本的查询优化器（Cost-BasedOptimizer）。2.超强的Ad-hoc查询能⼒。同硬件资源条件下，TPC-H测试结果可达Greenplum的7—10倍。极速向量化引擎✓向量化技术✓内存结构按照列组织引⼊Column结构，按列load数据，按列进⾏表达式计算和节点计算✓优势：✓CPU预取✓分⽀预测友好✓Cache友好✓⽅便使⽤SIMD指令集✓向量化提升效果✓向量化Filter：提升5.1倍✓向量化聚合：提升14.9倍✓向量化ShuffleJoin：提升3.7倍✓向量化BroadcastJoin：提升3.5倍⾼效的列式存储引擎1.⾼性能按列存储2.⽀持数据排序，⽀持利⽤ZoneMap等优化技术实现数据快速过滤3.⽀持Bitmap、BloomFilter索引4.⽀持延时物化技术（LateMaterialized）5.⽀持编码加速技术（Operationsonencodeddata）6.算⼦智能下推现代化物化视图加速1.物化视图：提取某些维度、指标建⽴对⽤户透明的预聚合表dateidProvPv2014.01.011北京102.⽀持多种聚合算⼦✓sum、min、max2014.01.012天津30✓Count-Distinct：HLL、Bitmap2014.01.021北京203.⾃动构建2014.01.021北京40✓⽀持实时、批量构建✓⽀持灵活增加、删除✓⽀持schemachangedatePvidPv4.透明化使⽤2014.01.0140130✓使⽤时只需指定原始表✓系统⾃动选择最优的物化视图、并保证查询结果⼀致性2014.01.0260270实时构建DWS数据2014-01-0100:11:12,1,北京,http://ww.xyz.com/index.php……2014-01-0105:13:22,1,北京,http://ww.xyz.com/view.php?id=123AggregateTable……2014-01-0109:16:20,1,北京,http://ww.xyz.com/view.php?id=137dateidProvPv……2014-01-0110:15:23,2,天津,http://ww.xyz.com/view.php?id=552014.01.01110Kafka北京2014-01-0111:16:08,1,北京,http://ww.xyz.com/view.php?id=1382014-01-0113:16:08,2,天津,http://ww.xyz.com/view.php?id=1672014.01.012天津30……2014-01-0115:45:29,1,北京,http://ww.xyz.com/view.php?id=173……1.接收Kafka流式数据，直接⾃动形成聚合结果，秒级延时。2.⽀持精确计算算⼦（Max，Min，Sum，Count），也⽀持估算算⼦（HLL）。业务⽇志3.通过Replace算⼦⽀持按组合健更新。Join优化—colocatedJoin极简运维，弹性伸缩✓数据分布弹性，在线扩容✓控制成本，按需伸缩，应对流量增⻓TableAA-1A-2A-3✓⼩规模初始集群，逐步扩容TableBB-1B-2B-3ALTERSYSTEMADDBACKEND"192.168.0.1:9050";A-1A-2B-3A-1B-1A-3A-3A-3B-3B-1B-2B-3A-2B-2A-1Case1:如何优化SSB测试SSB多表对⽐测试SSB多表测试3026.542523.2123.3520.6319.812019.5418.7117.5116.5216.1716.216.141512.511.611.7310.610.579.72109.259.066.846.351.571.381.471.381.111.121.320.830.660.610.670.610.580.690.670.820Q1.1Q1.2Q1.3Q2.1Q2.2Q2.3Q3.1Q3.2Q3.3Q3.4Q4.1Q4.2Q4.3Doris社区版Doris企业版GreenplumCase1:如何优化SSB测试—建表CREATETABLEssb_100g.lineorder_flatCREATETABLE`lineorder_flat`((`lo_orderdate`dateNOTNULLCOMMENT"",`lo_orderkey`UInt32,`lo_orderkey`int(11)NOTNULLCOMMENT"",`lo_linenumber`UInt8,`lo_linenumber`tinyint(4)NOTNULLCOMMENT"",`lo_custkey`UInt32,`lo_custkey`int(11)NOTNULLCOMMENT"",`lo_partkey`UInt32,…`lo_suppkey`UInt32,`p_color`varchar(100)NOTNULLCOMMENT"",`lo_orderdate`Date,`p_type`varchar(100)NOTNULLCOMMENT"",…`p_size`tinyint(4)NOTNULLCOMMENT"",`p_color`LowCardinality(String),`p_container`varchar(100)NOTNULLCOMMENT""`p_type`LowCardinality(String),)ENGINE=OLAP`p_size`UInt8,DUPLICATEKEY(`lo_orderdate`,`lo_orderkey`)`p_container`LowCardinality(String)COMMENT"OLAP")PARTITIONBYRANGE(`lo_orderdate`)ENGINE=Distributed('ssb_test','ssb_100g','lineorder_flat_local',lo_orderkey)(PARTITIONp1VALUES[('0000-01-01'),('1993-01-01')),PARTITIONp2VALUES[('1993-01-01'),('1994-01-01')),CREATETABLEssb_100g.lineorder_flat_localPARTITIONp3VALUES[('1994-01-01'),('1995-01-01')),(PARTITIONp4VALUES[('1995-01-01'),('1996-01-01')),`lo_orderkey`UInt32,PARTITIONp5VALUES[('1996-01-01'),('1997-01-01')),`lo_linenumber`UInt8,PARTITIONp6VALUES[('1997-01-01'),('1998-01-01')),`lo_custkey`UInt32,PARTITIONp7VALUES[('1998-01-01'),('1999-01-01')))…DISTRIBUTEDBYHASH(`lo_orderkey`)BUCKETS48)PROPERTIES(ENGINE=MergeTree"replication_num"="1",PARTITIONBYtoYear(lo_orderdate)"in_memory"="false",ORDERBY(lo_orderdate,lo_orderkey)"storage_format"="DEFAULT"SETTINGSindex_granularity=8192│);ClickHouseDoris建表建表Case1:如何优化SSB测试—建表最佳实践ClickHouse建表•LowCardinality针对低基数字符串的优化⼿段•PARTITIONBYtoYear(lo_orderdate)•ORDERBY(lo_orderdate,lo_orderkey)•ENGINE=Distributed('ssb_test','ssb_100g','lineorder_flat_local',lo_orderkey)DorisDB建表•⾃适应低基数优化不需要显示指定•PARTITIONBYRANGE(`lo_orderdate`)•DUPLICATEKEY(`lo_orderdate`,`lo_orderkey`)•DISTRIBUTEDBYHASH(`lo_orderkey`)BUCKETS48Case1:如何优化SSB测试—DorisDB的分区分桶Partition是数据导⼊和备份恢复的最⼩逻辑单位Tablet是数据复制和均衡的最⼩物理单位Case1:如何优化SSB测试—分区分桶与裁剪•针对Doris⽀持两层的数据划分•第⼀层是Partition分区，⽀持Range的划分⽅式•第⼆层是Distribution分桶，⽀持Hash的划分⽅式•Partition类似分表，是对，对⼀个表按照分区键（⼀个或者多个）进⾏切分，⼀般可以按照时间分区，根据数据量按天/⽉/年划分等等，这样可以利⽤分区裁剪减少数据访问量，也可以根据数据的冷热程度把数据划分到不同的介质上•Distribution是对数据在不同BE上的数据分布⽅式，按照分桶键hash以后均匀分布在BE上，注意尽量选择分桶键让数据均衡，不要出现bucket数据倾斜的情况•Bucket数量的需要适中，如果希望充分发挥性能可以设置为BE数量*CPUcore数量或者BE数量*CPUcore数量/2，最好tablet控制在100MB-1GB之间，tablet太少并⾏度可能不够，太多可能元数据过多，底层scan并发太多性能下降。Case1:如何优化SSB测试—排序键•排序键可以使⽤前缀索引（shortkey）和ZoneMap来进⾏⾼效的过滤，同时也能利⽤数据局部性来加速groupby等聚合操作•shortkey的列只能是排序键的前缀,列数不超过3,字节数不超过36字节,不包含FLOAT/DOUBLE类型的列,VARCHAR类型列只能出现⼀次,并且是末尾位置•索引粒度1024类似Clickhouse的index_granularity•Zonemap通过minmax来快速过滤page中的数据•针对SSB单表的13个查询，其实ClickHouse官⽅推荐的建表⽅式并不是最快的，因为没有充分发挥查询的特点和前缀索引在过滤和数据局部性的优势，按照s_region,s_nation,s_city作为前缀的⽅式会更快：DUPLICATEKEY(`s_region`,`s_nation`,`s_city`)Case1:如何优化SSB—Profile分析图形化的Profile可以看到MPP的执⾏过程，⽅便的定位性能瓶颈和数据倾斜例如：SSBQ3.2selectc_city,s_city,d_year,sum(lo_revenue)aslo_revenuefromlineorderjoindatesonlo_orderdate=d_datekeyjoincustomeronlo_custkey=c_custkeyjoinsupplieronlo_suppkey=s_suppkeywherec_nation='UNITEDSTATES'ands_nation='UNITEDSTATES'andd_year>=1992andd_year<=1997groupbyc_city,s_city,d_yearorderbyd_yearasc,lo_revenuedesc
*并⾏度设置*谓词下推*BloomFilter*MPP架构两层聚合Join优化—bloomfilter下推基于Cube的MOLAP系统和DorisDB的对⽐基于Cube的MOLAP系统DorisDB强⼤的实时计算能⼒，⽆需预计算即可达到亚秒级的查数据分析时能进⾏的查询⽅式完全依赖于预先定义和计灵活性询速度。新型预计算机制，更加灵活，令查询快上加算，不在预计算范围内的查询⽆法执⾏。快。新型预计算机制，数据源更新⾃动同步到预计算结果，数据⼀致性数据源发⽣变化时需要重新计算，⽆法⾃动同步更新。保证查询的数据⼀致性。统计维度发⽣变化时，需要重新计算历史数据，如果涉及统计维度发⽣变化时，⽆需重新计算历史数据，不影响维度变化历史数据量⼤，则重算⾮常耗时，可能会影响线上服务。线上服务。实时计算预计算模式，⽆实时计算能⼒现代化MPP计算框架，强悍的实时计算能⼒。多维度排列组合的预计算导致维度爆炸，极⼤占⽤存储空存储空间只需要按需创建物化视图，节省存储空间。间。不依赖任何外部系统，整个系统只有两种进程，⾃动故运维通常依赖Hadoop等外部系统，额外运维和维护成本⾼。障恢复，极简运维。ClickHouse和DorisDB的对⽐（1）ClickHouseDorisDB标准SQL语⾔⽀持标准的SQL语⾔，兼容MySQL协议，可以直接对不⽀持标准的SQL语⾔，⽆法直接对接主流的BI系统。的⽀持接主流的BI系统。⼏乎不⽀持分布式Join，在分析模型上仅⽀持⼤宽表模⽀持各种主流分布式Join，不仅⽀持⼤宽表模型，还⽀分布式Join式。持星型模型和雪花模型。传统MMP数据分布⽅式，⼩查询会极⼤消耗集群的资源，现代化MPP数据分布⽅式，数据按照分⽚的⽅式保存，⾼并发查询⽆法实现⾼并发查询，并且⽆法通过扩容的⽅式来提⾼并⼩查询只需要⽤到部分机器资源，能极⼤地提⾼并发查发能⼒。询量。现代化MPP架构，可以实现多层聚合，能够执⾏复杂的MPP架构Scatter-Gather模式，聚合操作依赖单点完成，操作数据SQL查询，⼤表Join，⾼基数聚合查询等。量⼤时存在明显的性能瓶颈。对⾼基数列进⾏精确去重操作（如计算APP的DAU）时，现代化MPP架构，可以实现多层聚合，能有效利⽤多机精确去重受限于单点聚合的处理⽅式，性能瓶颈明显。资源，保证查询性能。ClickHouse和DorisDB的对⽐（2）ClickHouseDorisDBExactlyonce数据导⼊⽆事务保证，⽆法保证数据写⼊的“不丢不重”，数据导⼊有事务保证，可以很容易地实现Exactlyonce语义订单类场景⽆法使⽤。语义，数据导⼊“不丢不重”。集群扩容传统MPP数据分布⽅式，数据扩容时需要进⾏数据重分现代化MPP数据分布⽅式，扩容时只需要迁移部分数据布，需要⼈⼯操作，⼯作量巨⼤，影响线上服务。分⽚⾛即可，系统⾃动完成，不影响线上服务。分布式⽅案依赖Zookeeper，在集群扩⼤时，Zookeeper不依赖任何外部系统，整个系统只有两种进程，⾃动故运维会变成性能瓶颈，额外运维和维护成本⾼。障恢复，极简运维。开源社区的核⼼研发⼈员都是中国⼈，在国内有商业化社区⽣态整个开源社区被俄罗斯公司把持，在中国没有商业化公司公司⽀持，服务更加本地化，技术⽀持⽆障碍。⽀持，使⽤上规模后技术⽀持⽆法保证。Impala+Kudu和DorisDB的对⽐Impala+KuduDorisDBDorisDB借助新的向量化引擎，性能能够达到Impala+查询性能—Kudu的5倍左右。Kudu因为在导⼊时需要完成主键查找。批量导⼊效率不导⼊不需要完成主键查找，同样的资源下，导⼊性能要导⼊性能⾼，并且需要利⽤⼤量内存。⽐Kudu好。Kudu必须要有主键。由于Kudu在⾮主键列上缺少ZoneDorisDB并不要求必须有主键，可以指定多列作为排序主键约束Map信息，对于⾮主键列的过滤条件，只能进⾏全表扫键。可以获得更好的压缩效率，更⾼的查询性能。描，性能较差。新型的聚合表机制，可以⽀持实时数据的增量聚合计⽆法对实时数据进⾏增量聚合计算，较难⽀持实时数据的实时分析算，更好地⽀持DWS和ADS层服务，更好地⽀持实时分析。数据的分析。OLAP多维查现代化物化视图机制，能做到数据⾃动更新，查询智能⽆询加速路由，令多维查询速度提升10倍以上。DorisDB除了⽀持排序键之外，还⽀持Bitmap索引，索引⽀持Kudu只⽀持主键索引，不⽀持⼆级索引等BloomFilter等索引机制加速查询。导⼊原⼦性当前Impala+Kudu没有办法做到批量数据原⼦⽣效。数据导⼊有原⼦性保证，要么都⽣效，要么都不⽣效。唯⼀值计算优⽀持HyperLogLog和Bitmap等唯⼀值近似/精确计算优⽆化化⼿段。美团集团统⼀数据分析平台✓美团的总市值已经超过2000亿美⾦，是中国⽬前第三⼤互联⽹公司。美团旗下包含外卖，美⻝，酒旅，⽕⻋票/⻜机票，⾦服等多个核⼼业务板块。业务线繁多，业务复杂度⾼，对数据分析的需求⼗分强烈。✓痛点✓数据分析场景多，需求复杂，对于不同的场景采⽤不同的系统。✓由于多系统带来了复杂的数据链路和很⾼的开发成本和维护成本。✓基于预计算的OLAP解决⽅案存在数据冗余、存储空间⼤、维度数据变化导致⼤量历史数据重新计算、学习成本⾼、开发效率低等问题。✓数据探索类查询（Adhoc查询）速度慢，响应时间得不到保证。美团集团统⼀数据分析平台✓解决⽅案：2018年开始调研对⽐市⾯上的各类数据仓库产品，经过综合考虑之后选择BIApplicationDashboard了Doris作为主⼒数据分析平台来统⼀美团的数据分析层。Doris✓摆脱对预计算的强依赖，利⽤Doris强⼤的现场计算能⼒进⾏查询，数据存储空间节省了90%，查询灵活性更强，查询速度更快（基本都在1秒以内）。HiveSparkFlink✓利⽤Doris强⼤的分布式Join能⼒，有效应对维度变化，⽆需重刷历史数据。✓统⼀数据链路，降低业务需求开发的复杂度，⼈效提升数⼗倍。Hadoop✓同时⽀持聚合数据和明细数据查询，⽀持Bitmap类型和窗⼝函数。KafkaFlumeLogDBMS✓使⽤情况✓全集团Doris平台总节点数超过1200台，总数据量数⼗PB，每⽇查询量500万次，峰值并发查询1000次/秒，将原有的Hadoop查询加速到3秒以内。✓最近⼀年，经历过数⼗次线上扩容，未发⽣影响业务的重⼤线上问题，整个平台仅需要三⼈维护。京东⼴告数据分析平台•京准通是京东集团旗下的⼴告营销推⼴平台。主要负责京准通平台的报表查询服务，为⼴告主/运营/采销等提供实时/离线的报表的查询。•痛点投放平台应⽤/⼯具•原有系统⽆法承载不断增⼤的业务数据量，查询性能⽆法达标。快⻋聚效CPD⾏业⼤盘诊断优化•原有系统⽆法⽀持⼤规模数据的精确去重操作。•⽇常业务在线变更表模式操作复杂。海投秒杀计划联合活动引流检测账户管家•原有系统扩容难度很⼤，成本很⾼。•“11”“618”⾯临双，⼤促时，系统稳定性不⾜，可⽤性隐患⼩⿊珑AFA市场部DSPDMP秒杀解冻⼤。•解决⽅案：经过对⽐分析，选择使⽤Doris作为⼴告平台的底层数据分析系统。Doris•利⽤Doris物化视图功能⽀持固定⼴告效果数据报表，利⽤Doris的现场计算能⼒为⼴告主提供更灵活的⼴告营销⼯具，可以实现99%的查询请求在100ms内返回。•Doris⽀持在线表模式变更，使得业务需求更容易得到满⾜。•使⽤情况•使⽤Bitmap和HyperLogLog技术，实现了之前⽆法⽀持的•平均每⽇千万级查询总量，百亿级数据增量，毫秒级的查询耗时。UV计算。•在所有⼤促期间⽆事故发⽣，查询峰值4500+qps，⽇查询总量8千万+，•⽇志修复操作更加⽅便。TP99毫秒级，数据⽇增量近300亿⾏，且实时导⼊数据秒级延迟。•Doris⽀持在线扩容和缩容，更好应对流量变化⼩⽶⽤户增⻓分析平台✓随着⼩⽶互联⽹业务的发展，各个产品线利⽤⽤户⾏为数据对业务进⾏增⻓分析的需求越来越迫切。需要有⼀款产品能够帮助他们屏蔽底层复杂的技术细节，让相关业务⼈员能够专注于⾃⼰的技术领域，从⽽提⾼⼯作效率。Binlog⽤户⾏为Flink/Spark实时报表KafkaDorisStreaming数据探索Log营销效果导⼊清洗分析展现✓痛点✓解决⽅案：经过对⽐分析，选择使⽤Doris作为数据分析底层技术⽅案✓原有系统⽆法⽀持灵活的维度交叉查询，查询速度慢✓查询速度快，在事件分析场景下平均降低约85%左右的查询时间，在留存和✓业务变化快，需要能⽀持在线表模式变更（如增加字漏⽃场景下平均降低约50%左右的查询时间段）✓⽀持在线表模式变更，使得业务需求更容易得到满⾜。✓数据查询分析效率较低，复杂查询需要依赖研发⼈员✓直接写SQL就能满⾜数据分析需求，⽅便业务⼈员做数据分析。✓缺乏根据⽤户⾏为⾼效的分群⼯具，⽤户运营策略粗✓使⽤Bitmap类型来进⾏精确去重，计算漏⽃转化率。放，运营效率低。✓有效使⽤UDF和UDAF来实现⽤户⾏为分析逻辑。✓使⽤情况：海内外部署了⼗多个集群，总服务器台数有数百台。最⼤单集群规模近百台服务器，7000+张表，PB级数据规模。数⼗个业务明细表近实时导⼊，每天新增百亿条数据，每天有效查询量超过1.2万。VIPKidInspire统⼀数据分析平台✓VIPKid是线上K12英语教育巨头，其发展模式已经从粗放式扩张转向精细化运营。公司内部希望搭建能有效⽀持业务发展的数据分析体系，赋能⼀线的业务⼈员和众多数据分析师。Inspire✓痛点✓查询速度慢，基于Hive的探索式分析查询⼀次⾄少⼏分钟，极其影响分析师的⼯作效率。Doris✓基于Kylin的预计算⽅式不灵活，数据处理链路复杂，⽆法⽀持业务的快速变化，⽆法⽀持明细数据查询。✓⽆法⽀持实时计算，导致多个实时场景（每⽇绩效结算，⼴告投放分析Hive等）采⽤定制系统，维护成本⾼，稳定性⽋佳，业务抱怨⽐较多。✓数据源多，数据分散，构建复杂模型⼯作量⼗分⼤。Hadoop✓解决⽅案：基于Doris搭建Inspire数据分析平台，部分业务数据直接⽤Kafka接KafkaFlume⼊Doris，完成实时计算，部分数据在Hive中处理后导⼊Doris。利⽤Doris的视图功能完成数据分析团队间的协作，利⽤UDF⾃定义转化分析。LogDBMS✓使⽤情况：✓全公司有1000+⼈员每⽇在Inspire平台查看报表。✓⽇常数据指标开发周期从1周缩短⾄半天，效率提升10倍以上！✓3⽉、9⽉学期战役，数据分析链路建设时间从20个⼈2周，缩短⾄3个⼈2天，效率提升50倍以上！✓⾼层经营分析会议不再看PPT数据，直接看Inspire系统的数据，现场深度分析并做决策。作业帮实时数仓✓作业帮实时数仓系统向各个公司重要产品线（拉新、教学、BI等）提供⾯向业务的数据信息，如到课时⻓、答题情况等。DorisonBinlog业务分析ES实时报表✓痛点Kafka✓业务线做了⼤量的重复建设，构建成本⾼。数据探索LogDoris✓不⽀持标准SQL，需求满⾜效率掉。营销效果✓只能查预聚合数据，⽆法查明细数据。✓解决⽅案：基于Doris搭建实时数仓，由Doris处理流量数据，由DorisonES处理⾮流量数据。Flink✓⾼性能，业务端延迟可控，稳定性好。✓同时利⽤Doris的Join能⼒和ES的倒排索引能⼒✓不依赖⼤宽表，业务变更⽅便。导⼊清洗分析展现✓数⼗倍⼈效的提升，数据类需求的完成时间从数⼈周缩短⾄1⼩时之内。✓使⽤情况：✓全集团近⼗个集群，50+数据表✓每天百万级调⽤次数，P99<1s2020谢谢观看THANKSFORYOURWATCHING微信公众号：DorisDB