携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第24天，点击查看活动详情
-
动态分区小时支持: github.com/apache/incu…
-
DOE解决查询路由异常: github.com/apache/incu…
-
multi fields在多text类型情况下空指针异常:github.com/apache/incu…
Tips
-
routine load参数问题，主要关注desired_concurrent_number并发数，max_batch_interval，max_batch_rows，max_batch_size，目的是增大单次导入的数据量，提高导入性能
-
compact参数问题，主要调整cumulative_compaction_num_threads_per_disk、base_compaction_num_threads_per_disk、min_compaction_failure_interval_sec并且在代码中对因为没拿到锁的异常进行过滤，目的是提高compact频率，加快compact速度，减少小文件的产生
-
高并发下的所有fe hang死问题，主要调整fragment_pool_thread_num_max， fragment_pool_thread_num_min，fragment_pool_queue_size，过小的fragment_pool_thread会导致fragment死锁
-
提高高并发查询性能，高并发下需要降低每个查询的资源使用，主要降低doris_scanner_queue_size、doris_scanner_thread_pool_thread_num，避免创建过多scanner线程
线上表现
查询响应时间
事实表查询表现对比
99分位耗时Druid大概为270ms，Doris为150ms，延时下降45%
Join场景下cube表查询表现对比
99分位耗时Druid大概为660ms，Doris为440ms，延时下降33%
收益总结
-
整体p99耗时下降35%左右
-
资源节省50%左右
-
去除报表引擎内部Mem Join的复杂逻辑，下沉至Doris通过DOE实现，在大查询场景下(维表结果超过10W，性能提升超过10倍，10s->1s)
-
更丰富的查询语义(原本Mem Join实现比较简单，不支持复杂的查询)
总结与未来规划
从测试和线上的表现来看，Doris引擎的表现还是非常优秀的。
多维分析聚合查询场景对比Druid引擎有很大的性能优势，再加上Doris on ES的加持和上层业务的抽象，可以即拥有ES引擎强大的分词检索能力，又不失Olap场景海量数据的聚合分析性能。两者的结合可以为这类需求提供全新的解决方案与思路。
在快手商业化业务场景里面，维度数据与事实数据Join查询是非常普遍的，有了比较不错的实践成果，后续会在Doris on ES解决方案上继续投入。
