2022 年 3 月开始，我们对符合以上特点的数据库 Apache Doris 展开了为期两个月的调研测试。以下是 Apache Doris 1.1.2 在各个方面的满足情况。

基于上述情况，我们决定采用 Apache Doris，除了可以满足上文提到的几个特点，我们还考虑以下几个方面：

1. Clickhouse 由于 Join 查询限制、函数局限性、数据模型局限性（只插入，不更新）、以及可维护性较差等原因，更适合日志存储以及保留当前存量业务，不满足我们当前的业务需求。

2. 目前 Apache Doris 社区活跃、技术交流更多，SelectDB 针对社区有专职的技术支持团队，在使用过程中遇到问题均能快速得到响应解决。

3. Apache Doris 风险更小，对商业友好，无法律风险。大数据领域 Apache 基金会项目构成了事实标准，在 360 数科内部已有广泛应用，且 Apache 开源协议对商业友好、无法律风险，不会有协议上的顾虑。

平台架构

360 数科大数据平台（毓数）提供一站式大数据管理、开发、分析服务，覆盖大数据资产管理、数据开发及任务调度、自助分析及可视化、统一指标管理等多个数据生命周期流程。在整个 OLAP 中，目前 Apache Doris 主要运用离线数仓分析加速、自助 BI 报表等业务场景。

在引入 Doris 后，考虑已有数据分析业务以及数据规模，Doris 集群将先同步部分业务上优先级更高的数据。通过上述架构图可以看到，依托 Doris 强大的查询性能，我们将把 Doris 架设在 Hive 数仓的上层，为特定场景进行查询加速，这样的架构建设起来成本很低，只需要完成数据从 Hive 数仓到 Doris 集群的导入适配，因为 Doris 集群并没有产生任何新表，可以直接复用已经建设好的数据血缘关系。

数据导入方案，我们在调研了 Stream Load 和 Broker Load 之后，从导入性能、开发成本上进行了评估，在导入性能上，Broker Load 要比 Stream Load 略胜一筹，而在开发成本上两种方式并没有明显的差异。而且对于大表的同步，Broker Load 的导入方式可以做到单表一次导入一个事务，而 Stream Load 在单表数据量超 10G 时则需要拆分后进行数据导入。因此数据导入选择使用 Broker Load 来进行。

数仓即席查询方案，我们自行开发的查询引擎支持多查询引擎动态切换的机制，通过识别查询数据的元信息对本次查询做自动的查询引擎（Doris/Presto/Spark/Hive）路由和故障切换。

Doris 支持原生 MySql 协议，对标准 SQL 支持良好，使得 Doris 可以和一些 BI 工具（帆软、观远等）无缝结合，因此单独搭建了一个 Doris 报表分析集群作为 BI 工具数据源。

应用实践

Doris 对 Hive 数仓的查询加速方案

在即席查询场景中，传统的查询引擎（Hive/Spark/Presto）越来越满足不了数据开发者、数据分析师对查询响应性能提出的高要求，动辄几十秒甚者分钟级的查询耗时极大的限制了相关场景的开发效率。

为提高查询性能，我们通过架设的 Doris 数仓加速层来缩短查询耗时，目前我们在不开启 Doris 缓存、不开启用物化视图等优化策略的情况下，命中 Doris 即席查询平均耗时即可从几分钟缩短至 5 秒内。

未来我们将通过分析相关查询的特征，通过开启缓存、创建相关物化视图等策略来进一步优化 Doris 的查询性能。