Apache Doris在天翼云的最佳实践

李康大数据总监 整体介绍01案例速览02经典案例03展望未来04 目录 01整体介绍 整体规模 总节点数 应用场景 即席多维分析案例 案例简述： 主要是通过Doris作为数据分析和即席查询工具提升各省数据平台的查询效率，促进数字化转型。 案例成果： 替代经分系统原Impala+Redis架构，解决Impala稳定性差和Redis缓存量有限的问题，提升了报表周期、优化数字化业务经营的手段和效果。替代数据集市Oracle数据库，通过能开平台直连Doris，满足一线0.4s~0.7s数据调用及查询的要求，实现数据集市去O的改革目标。替代地市公司BI系统使用的PG库，在数据分析过程中的计数、聚合、单条快速检索运算等情况秒级可见。 湖仓一体案例 案例简述 主要是使用FlinkCDC+SeaTunnel集成工具Doris+Spark计算引擎，以及Iceberg结合Hdfs/对象存储等实现湖仓一体的统一架构。 通过自研TaskFlow集成工具把FlinkCDC(实时)和SeaTunnel(离线)融合在一起发挥各自的优势公共组成流批一体的数据集成体系。利用Doris和Spark计算引擎的分析和加工能力，实现数据建模、数据分析、数据查询等。通过Iceberg把Hdfs和对象存储融合在一起作为数据统一的存储层。 案例成果： 自研了TaskFlow提供流批一体的数据集成能力，利用Iceberg提供了统一的存储能力。利用Doris的多维分析和日志检索能力，提升了在线应用和BI报表、日志系统的查询效率。通过Amoro对Iceberg小文件进行5分钟粒度的合并，数据可见和性能较Hive两倍提升。 国产化案例 案例简述： 在国产化基础设施（CPU、OS）上，围绕采集、存储、调度、计算等四层核心业务构建国产化大数据平台，而Doris在其中主要承担大数据MPP计算的重要角色。因此需要使Doris在鲲鹏芯片上落地并对Doris做了权限扩展和安全加固，为国产化大数据平台舔砖加瓦。 案例成果： 利用毕昇编译器提升了Doris编译效率30%。通过优化Bitshuffle提升运行效率25%。通过安全加固提升了数据的安全性。 日志检索案例 案例简述： 通过Doris替换传统ELK的日志架构，提升日志系统的查询效率。满足省市在安全网关、系统运维等场景对日志检索，存储，以及智能分析的业务需求。 案例成果： 写入吞吐提升了5倍。存储成本降低了80%。百亿级日志检索秒级，查询效率提升3倍。 高并发即席查询 背景： 基于天翼云3AZ多活的云资源池，应用云原生技术完成了电信内部某子公司的大数据平台(AIoT)架构升级。而Doris在这个项目中角色主要是为了给业务应该提供大规模应用系统的数据查询，替换掉原有的Orical数据库，助力公司内各行业应用规模发展。 业务特性： 高并发1W+。单表数据规模庞大（总表百亿，单日几个亿）。结果集小（大多数只有单行结果）。表数据需要进行实时update操作。 如何实现海量数据的高并发查询 测试方案 思考 使用jmeter发起300W的请求，每秒并发1W，持续压5分钟。owner_id使用离散数据压测，样本数为5000 通过业务特性可知业务单表数据量很大，但是有一个特点就是大多数的查询都是单行结果，是典型的点查场景。这相当于在大海中捞一根针但是庆幸的是Doris的数据分片粒度足够小（先分区在分桶）、索引丰富（内建智能、布隆、倒排等）因此我们需要好好利用这两个特性来尽量压缩数据的扫描范围。 分区分桶 我们先把数据按天分区，然后按owner_id字段进行分桶。理论来说是分桶数越大数据分片越小查询效率越高，但是Meta越大会随Tablet数的增加而增加，影响了数据管理同步和写入性能，因此我们需要通过压测选取合适的分桶数，经过多组实验和权衡100个分桶是比较合适当前场景的。 索引 智能索引（前缀索引和ZoneMap）是Doris的内建的在创建表时默认给每个字段都建立相应的索引，并当前只有是点查场景只需要建立布隆过滤器即可。 高并发查询措施&效果 解决措施 效果 经过分区分桶+库表统计信息把上百亿大表在执行计划阶段确定目标的tablet，把数据缩小到百万级别。 在利用智能索引和布隆过滤器索引进一步过滤扫描的segment。 容量评估 思考 测试方案&数据 数据存储和写入资源评估相对比较固定按需分配即可，但是计算资源评估是比较难的一个问题，往往和查询的业务复杂度、请求频率、数据规模与分布、任务的执行效率等因素有关。任务的执行耗时取决于计算引擎性能，其它因素主要取决于业务并且是动态变化的，这给资源评估带来了极大的困难。通过分析我们明显可知业务的场景(点查)和数据量是相对固定的，加上分区和分桶策略我们基本固化了数据分布，目前只需要明确执行引擎在现在场景中的执行耗时我们就能通请求频率计算出，因此我们需要对Doris的在点查场景进行一次压测。 使用jmeter发起180W的请求，持续压5分钟，每秒请求6000。 QPS压测现象&结论 Fe和Be节点的负载(CPU/IO)都比较低，并没有随任务数的增加的加大。 出现这个现象是因为业务场景是点查场景结果集小，并通过分区分桶+索引策略数据过滤率很高，因此IO和CPU都不是一很高。QPS到达5000千多之后调整各级线程数和队列大小、执行并发度等参数QPS都升不上去，并线程和队列资源使用率并不高。执行并发度无效是因为当前查询命中的基本上是一个tablet，任务基本只有一个instance来执行，并行度基本起不到作用。线程和队列资源的使用率不高但是QPS上不去可能是系统各级锁竞争引起。任务耗时在任务5000以下任务95分位的任务执行耗时都很低ms级，在5000+95分位的任务执行耗时会逐步增加。 实验结论： 综上所述点查场景下单节点的QPS可以达到5000，因此当前fe节点数据就是所需QPS/5000,而BE是可以横向扩展的，因此可以是可以按照QPS/(5000/3/节点使用率)。 如何实现数据快速导入01 思考 测试方案&现象 在数据导入上首先要考虑的是如何把数据从Oracle导入到doris中，因为我们大数据产线FlinkCDC的集成产品也已经比较成熟了，所以FlinkCDC的集成方案就成为我们的首选。于是我们对该方案做了压测，在压测中发现如下问题： 使用Flink全量的导入Oracle的10个Instance的数据，数据量300G+。 FlinkCDC的挂掉、频繁重启。Doris的经常抛出Lable已存在的问题。数据导入性能比较低，只能写入几百条每秒。集群的BE资源IO占用过高。 解决Doris抛出Lable已存在的问题 思考 经过对Doris的Lable标签设计原理和flink-doris-connector的分析，最后发现是因为flink-doris-connector使用steamload把数据写入。而steamload是通过http协议把数据写入到Doris中的，在http的类库中默认是开启了重试策略的。如果网络异常或延迟都是触发客户端的重试，而Http的重试是不保证数据ExactlyOnce语义的。因此我们关掉了http的重试，并在connetor层做重试，每次重试的时候会改变Label，进而解决了再不丢数的情况下避免因Label重复导致的flink任务挂掉的问题。 如何解决Doris写入慢的问题01 思考 我们对flinkCDC写入Doris流程做了比较深入的分析，flinkCDD当前主要是通过streamload的方式进行写入，streamload提供了一种可以直连BE进行数据传输的方式，Doris-flink-connector也是采用这种方式进行数据导入，在这种情况下影响写入性能主要是由tablet数量,数据模式（Unique、Duplicate、Aggregate）,表存储方式（MoW、MoR),streamload的数据块大小，硬件资源（网络、IO）5个方面的因素影响的。 Tablet数量： 该因素主要是影响到写入数据块在Doris侧的数据分发，进而影响到磁盘的IOPS和网络。因为tablet数多大数据比较分散，一次steamLoad的数据就被分得比较散写入磁盘的次数比较多，不仅消耗磁盘的IOPS同时增加了随机写磁盘的次数，因此tablet应该比较小。但是过小的tablet数又影响查询效率，因此我们需要在写入性能和查询性能上做一个权衡。 数据模式： 这个主要是和业务场景相关，不同数据模型下数据block的写入性能不一样，通常来说Unique性能是最好的，单tablet写入性能可以达到磁盘上限，Aggregate这个性能是和业务统计关联性比较大性能不固定。 如何解决Doris写入慢的问题02 表存储方式： 和数据模型类似，主要是影响单block的写入性能，包括LTM和compaction的速度。 streamload的数据块大小： 这个因素主要是和connector的参数相关，也就是可以调整connector的单个bactch的buffer大小和赞批的时间来调整数据块大小。 硬件（网络、IO）： 硬性这个就是可以通过提升硬件来加速的。 综合上面的因素考虑，当前场景下Tablet数量是100，数据模式因存在更新需要Unique，表存储方式选择MoR这个三者都是已经确定只需按需调整即可。当前剩余streamload的参数和硬件影响未明确，因此我们对这两个方面做了相关实验。 StreamLoad的Batch实验 测试环境 使用FlinkCDC导入Oracle的10个Instance的数据，数据量300G+。 测试环境 在客户端，通过streamload在不同批次大小的方式下进行压测。使用每批2w的数据量，分别从两个全量和增量维度，做不同tablet规模下的压测。 测试结论： sl每批条数调大后，单次sl的耗时其实是基本一致的，但flinkcdc的同步性能得到巨大提升。 降低tablet数可以较大提升写性能，但是会影响查询效率。 HDD磁盘的实验 测试数据: 测试环境 机器配置：CPU96内存：128G 磁盘：1块8T的sata盘 测试方案 通过相同的数据量不同数据块的大小测试磁盘在不同数据块情况下的性能差异。通过fio对磁盘进行随机写和顺序写来测试两种情况下的磁盘的性能差异。 测试结论: HDD磁盘随机写IPOS是有限的仅仅是几百，数据块大小对影响影响很大。 HDD磁盘顺序写IPOS是可以达到万级的，块大小对吞吐的上限影响不大。HDD磁盘的吞吐上限大概在250M左右。 SSD磁盘的实验 测试数据: 测试环境 机器配置：CPU96内存：128G磁盘：1块普通SSD，1块MVME磁盘 测试方案 通过fio对普通磁盘和MVME两种磁盘进行测试，评估普通SSD和MVME磁盘的性能差异。通过相同的数据量不同数据块的大小测试磁盘在不同数据块情况下的性能差异。通过fio对磁盘进行随机写和顺序写来测试两种情况下的磁盘的性能差异。 测试结论: 普通SSD随机写和顺序写性能差不多500MB。普通的SSD在数据块很小<4k,性能衰减比较严重（250M左右）。MVME貌似没有想象的那么强，极限吞吐在4G，IOPS在极限在25W。 快速写入的解决措施&效果 解决措施 效果： 从上面多个实验可以得出Doris写入的结论如下： 6并行度，每个并行度2core:4G,1小时导入500G左右 目前Doris的BE集群所使用的磁盘是HDD，不适合写小批数据（因为HDD在随机写场景下IOPS低)。通过攒大批方式可以有效提高StreamLoad的当次写入的数据块大小进而提升写入性能。通过降低Tablet的数