乐趣区

关于数据库:从-Clickhouse-到-Apache-Doris有赞业务场景下性能测试与迁移验证

jiezi

本文导读：

以后，电商经营的次要痛点不仅来自多变的市场和客户需要，也受困于碎片化用户触达等带来的竞争与挑战。为了深度开掘用户价值、造就用户忠诚度、实现业绩增长，有赞为商家搭建了全方位 OLAP 剖析零碎，提供实时与离线剖析报表、智能营销与人群圈选等 SaaS 服务。本文将具体介绍有赞从 Clickhouse 至 Apache Doris 的迁徙布局和性能比照测试实际，分享如何基于 Apache Doris 对立 OLAP 技术栈，并满足宏大数据体量下的实时剖析与极速查问，最终有赞在多个场景下实现查问均匀提速 200%。

作者：李闯 有赞 根底平台数据研发工程师

有赞是国内当先的电商 SaaS 服务商，目前领有社交电商、新批发、美业、教育及有赞国际化五大业务体系，通过旗下的社交电商、门店治理、解决方案以及其余新批发 SaaS 软件产品，全面帮忙商家解决在挪动互联网时代遇到的推广获客、成交转化、客户留存、复购增长、分享裂变等问题，帮忙每一位器重产品和服务的商家实现顾客资产私有化、互联网客群拓展、经营效率晋升，最终助力商家胜利。

在面对商家与开发者的定制化服务需要的同时，为了可能更好地反对商家无效解决引流获客、分销体系等难题，有赞为商家搭建了 OLAP 剖析零碎，提供以下 SaaS 服务场景：

  • 商家离线后盾报表： 面向 B 端为商家提供 T+1 报表查问，对计算精度、查问性能及稳定性要求较高，同时会面临简单查问场景。
  • 人群圈选与智能营销： 从私域触点、线下触点获取用户数据，联合罕用社交平台中接入的用户数据，依据业务需要在客户数据平台（Customer Data Platform – 以下简称 CDP）、数据管理平台（Data Management Platform - 以下简称 DMP）、客户关系管理系统（Customer Relationship Management- 以下简称 CRM）进行不同消费者的全方位画像剖析。该场景会面临大量高频的数据实时更新，同时查问体量较大、QPS 较高，时常呈现简单 SQL 查问场景。
  • 商家实时剖析报表： 面向 B 端为商家提供相干实时报表剖析查问，该场景特点是 QPS 比拟高，商家能够抉择不同的维度组合进行查问，对实时性和稳定性要求高。
  • 天网日志剖析零碎： 为所有业务零碎提供日志采集、生产、剖析、存储、索引和查问的一站式日志服务。该场景写入吞吐高，须要达到每秒百万级别的数据写入；且查问频率低，波及天网 TopN 日志查问，因而零碎要求具备实时聚合以及含糊搜寻能力。

随着业务数据体量逐步宏大，业务对于时效性、联邦查问剖析的需要也更加迫切，现有组件在应用过程中对业务人员开发、运维人员保护都存在肯定痛点，因而决定降级数据架构并基于 Apache Doris 来对立 OLAP 技术栈。本文将具体介绍晚期架构的组成、OLAP 零碎运行流程、以及理论利用痛点，分享零碎架构在迁徙过程中的技术与调优教训。

晚期架构痛点

晚期架构如图所示，数据次要来源于业务数据库 Binlog 与用户日志等原始数据，通过实时与离线两条链路别离对数据进行解决。其中原始数据首先导入至 Apache Kafka 与 NSQ 消息中间件，一部分会通过 Apache Flink 进行流解决计算并与存储在 HBase 中的维度明细表进行关联，另一部分数据会存储于 Apache Hive 与 HDFS 中作为离线数据，通过 Apache Spark 计算写入至 OLAP 引擎中。

有赞数据架构次要应用了以下三种 OLAP 引擎，各个组件依据业务场景的特点与需要为上游利用提供不同场景的查问与剖析：

  • Apache Kylin： 基于 Apache Kylin 搭建商家离线报表后盾，为商家提供 T+1 报表查问。目前后盾曾经具备超 500 万家的商家数量，对于局部体量较大的商家，其单点会员数可能达到千万级别、商品 SKU 达到数十万、平台构建 Cube 数量达 400+。
  • Clickhouse： 基于 Clickhouse 进行人群圈选与 TopN 日志查问业务，其中人群圈选次要通过实时的明细查问来辅助用户行为数据分析。
  • Apache Druid： 针对 B 端商家实时剖析报表场景，基于 Druid 构建维度查问零碎，为商家提供实时指标查问服务。

然而因为该架构组件过多、架构冗余等问题导致维养、开发、业务利用等方面带来了一系列的挑战，具体如下：

01 Clickhouse：查问性能有余

针对部份 SaaS 场景的高并发高 QPS 查问场景，Clickhouse 的查问能力体现不够现实。因为 Clickhouse 组件自身设计的问题，无奈反对多表或大表 Join 的查问场景，这就导致一旦呈现关联查问场景，业务方须要从新寻找解决方案，使整体查问效率低下。

02 Apache Druid：数据修复解决难度大

  • 数据修复难度大： 当呈现 Apache Flink 本身容错导致数据反复的状况，Druid 齐全依赖写入侧进行幂等操作，因为本身不反对数据更新或删除，只能对数据进行全量替换，导致数据准确性低、修复难度大。
  • 数据一致性问题： 对于 Druid 而言，导入数据后须要构建完 Segment 能力响应查问后果。一旦上游 Flink 写入 Kafka 的过程中呈现数据提早，则无奈依照预期工夫写入 Druid 中，指标数据就会呈现较大稳定，数据一致性无奈失去保障。
  • 数据修复链路过长、老本过高：为了解决部份长期数据修复问题，咱们首先须要破费小时级工夫将 Apache Kafka 数据备份至 HDFS 上，在备份实现后还须要将数据从新导入 Druid 之后进行修复，整体修复的链路过长，投入的工夫与研发老本会随之升高。

03 Apache Kylin : T+1 时效性低

Apache Kylin 在数据处理过程中采纳了预计算的形式，通过在多维 Cube 构建过程中实现聚合计算，并生成 T+1 数据报表。对局部在夜间经营的商家而言，他们须要期待一天工夫能力查看前一天的报表数据，这无奈满足用户对于时效性的需要。

04 整体架构：运维老本高、研发效力低、架构灵便度差

  • 研发老本高： 业务方须要学习每种组件（Clickhouse、Druid、Apache Kylin)的应用形式、并且查问 SQL 规范各异，这会使学习老本加大，并且在前期进行研发、监控、运维、周边生态工具等开发工作过程中，须要投入大量的人力与开发接入老本，升高开发效率。
  • 运维瓶颈： 在扩缩容期间业务方须要停写进行集群调整，且单次扩容须要将所有的库表都进行迁徙，不仅无奈保障运维工夫老本，还会减少过高的人力老本。而目前有赞存在大量的扩容需要，现有架构的运维老本则成为零碎的一大痛点。
  • 架构灵便度差： Apache Kylin 仅在维度和指标提前设定、表构造固定的场景下可能失常运行，一旦减少维度和指标则须要新建 Cube 并重刷历史数据；Clickhouse 在宽表补数时会呈现须要从新全量导入数据，这些架构缺点在业务运行过程中都会引发资源应用减少、运维成本增加、研发效力较低的问题。

技术调研与收益老本评估

基于上述架构痛点，咱们对市面上的架构进行了调研与选型，心愿抉择一款可能简化以后简单架构、对立 OLAP 技术栈的引擎。咱们除了剖析 OLAP 性能自身对于业务的帮忙，还须要评估架构革新所带来的收益老本比，思考架构进行迁徙和重构之后所带来的 ROI 是否合乎预期。

对于收益而言，咱们须要评估新架构引入后的性能是否如预期晋升，将 Apache Doris 别离与 Clickhouse、Druid、Kylin 进行比照评估。

对于老本而言，咱们首先会思考在替换过程中，周边工具开发的老本，其中波及监控、告警、上下游依赖平台等一系列工具的构建与研发；其次业务的迁徙会波及大量业务革新与协调，如何催动业务方进行革新、提供更丰盛的革新工具、尽可能升高投入老本也是咱们次要思考的问题。

通过一系列评估后，咱们发现基于 Apache Doris 进行架构迭代，其不论是在业务赋能还是老本方面，都可能无效解决以后架构的痛点，极大水平地实现降本增效的指标，整体迭代的预期收益显著高于革新代价，因而咱们决定基于 Apache Doris 构建对立实时数仓，具体评估剖析如下：

  • 查问性能优异： 解决了 Clickhouse 在高 QPS 查问与大表关联查问场景下的弊病，提供了优良的并发查问能力。此外，在 Apache Doris 2.0 公布后，倒排索引性能反对任意维度疾速检索、文本分词全文检索，在日志场景下的查问性能晋升尤为显著。
  • 高效的数据更新： Apache Doris 的 Unique Key 反对大批量数据更新、小批量数据实时写入，笼罩咱们 90 % 业务场景，其 Duplicate Key 与 Aggregate Key 模型还可能反对局部列更新，整体数据模型丰盛，帮忙晋升写入与查问效率。
  • 保证数据正确性： Apache Doris 反对事务导入，Bitmap 性能反对精准去重，保证数据不丢不重；同时反对精准写入，保证数据基表与物化视图强一致性、正本数据强一致性。
  • 简略易用、开发成本低： Apache Doris 高度兼容 MySQL，使开发简略应用门槛升高，且 Doris 的迁徙与扩缩容老本较低，在横向扩容等运维操作方面特地简略。其周边组件的接入与监控的接入皆绝对简略，Doris 社区提供 Flink & Doris Connector、Spark & Doris Connector 等接入工具，并且监控模版可能间接取用，无需再开发。
  • 社区活跃度高： 在过往退出的开源社区中，Apache Doris 社区活跃度十分高，社区开发者多、迭代更新快，对于社区内的问题解答也非常踊跃，在开发过程给予了十分多的帮忙。

基于 Apache Doris 构建对立实时数仓

如上图所示，新架构将基于 Apache Doris 搭建对立实时数仓，替换原架构中的三个 OLAP 组件，解决由组件过多引起的接入老本高、资源应用减少、数据链路过长等问题，最终可能加重业务方的累赘、缩小整体框架的硬件老本、实现引擎与技术栈对立等指标。

在有赞绝大多数利用场景中，原架构都存在数据反复、数据提早须要修复的状况，引入 Apache Doris 之后，咱们将利用其 Unique Key、Duplicate Key、Aggregate Key 模型性能实现高效的数据更新，保障写入效率，并且 Doris 架构具备弹性伸缩的能力，引入后可能极大水平地升高故障产生的概率以及呈现故障时数据恢复的效率。

此外咱们还将引入 Apache Doris 以下性能：

  • 倒排索引： Apache Doris 2.0 版本的倒排索引性能优化天网日志剖析零碎，实现多维度疾速检索，减速日志场景的查问剖析性能。
  • 主键模型写 时合并（Merge-on-Write）： Apache Doris 提供丰盛的导入形式，能够将小批量数据实时导入 Doris 中，为后续上架门店业务提供实时报表查问，与原价构应用比照，Doris 可能极大水平晋升导入时效性。

从 Clickhouse 到 Apache Doris 的迁徙教训

在确定架构迁徙之后，咱们首先抉择用 Apache Doris 来替换 Clickhouse 组件，次要因为在业务增长时 Clickhouse 查问性能瓶颈较大、集群扩缩容操作过于简单等痛点使运维团队的工作量大幅减少，加之大表 Join 能力差、高 QPS 查问性能差等一系列问题无奈满足业务方诉求，且 Clickhouse 性能与 Apache Doris 类似，业务方更便于迁徙，因而咱们优先替换 Clickhouse 组件。

接下来，咱们将分享 Doris 替换 Clickhouse 的迁徙计划，架构迭代的整体节奏分为 SQL 语句改写实现主动导入（蕴含建表语句与查问语句的改写）、查问性能测试、稳定性测试、导入性能测试与优化，在完结一系列测试后最终进行整体业务数据的迁徙。

01 SQL 建表语句与查问语句改写

目前，咱们针对 Unique Key 模型与 Duplicate Key 模型制作了 SQL 建表语句改写工具，如上图所示，反对通过配置参数主动将 Clickhouse 建表语句转为 Doris 建表语句，该工具的次要性能具体如下：

  • 字段类型映射： 因为 Doris 与 Clickhouse 字段不统一，存在一些特殊要求的转换，例如 Key 值类型 String 须要转为 Varchar 以及设置对应长度、分区字段 String 须要转为 Date V2 等；
  • 动静分区表的历史分区数确定： 因为部份表存在历史分区，须要在建表时指定分区数量，否则插入数据会呈现 No Partition 异样；
  • Buckets 数量确定： 尽管历史分区表能够进行对立配置，然而往往历史分区数据量不完全一致，因而咱们依据历史分区的理论数据量推算出历史分区的分桶数，同时对于非分区表能够依据历史数据量设置 Properties 进行主动分桶配置；
  • TTL 周期确定： 能够设定动静分区表的转换周期，设定保留工夫后再转换；
  • Unique 模型的 Sequence 设置： 在导入时能够指定 Sequence 列导入程序，解决了导入程序无奈确定的问题，无效保证数据导入过程中的有序性。

与建表语句改写工具相似，SQL 查问语句改写可能主动将 Clickhouse 查问语句转成 Doris 查问语句，次要为了双跑进行数据准确性和稳定性验证。在改写过程中，咱们梳理了以下注意事项：

  • 查问表名转换： 在 Clickhouse 与 Doris 建表过程中存在肯定的映射规定，在进行双跑测试的过程中，咱们能够间接依据映射规定间接进行转换。
  • 函数转换： 因为 Clickhouse 与 Doris 应用函数差别较大，须要依据 Doris 和 Clickhouse 的函数映射关系进行函数映射转换。其中咱们遇到一些比拟非凡的函数转换须要进行特地解决，例如 Clickhouse 中的 COUNTIF() 须要转换为 SUM（CASE WHEN _ THEN 1 ELSE 0) 以达到雷同的成果，ORDER BY 与 GROUP BY 须要利用 Doris 开窗函数进行转化，此外 Clickhouse 利用 Array Join 进行列传行，对应 Doris 则须要利用 Explode、Lateral View 来开展；
  • 语法层面的不兼容： 因为 Clickhouse 不兼容 MySQL 协定而 Doris 高度兼容，因而在子查问中须要进行别名设置。特地是在人群圈选的业务场景中存在多个子查问，因而在售后转换的时候须要把对应子查问利用 sqlparse 进行递归，查看出所有的子查问进行设置。

02 Apache Doris 与 Clickhouse 性能压测

查问性能测试次要通过 Apache Doris 与原架构 Clickhouse 组件在三个外围业务场景（CDP、DMP、CRM）下的比照体现。咱们选用了线上等比的集群规模，通过 查问 SQL 性能比照、大表 Join 性能两方面 进行比照压测，同时检测 Doris 在查问期间的 CPU 以及 内存损耗。接下来咱们将具体介绍压测过程与具体性能数据比照。测试集群规模 3 FE + 16 BE，BE 单节点配置为（32C 128 G 7T SSD）。

外围场景下查问 SQL 性能比照

在进行查问 SQL 性能测试中，咱们次要基于以后理论利用场景最多的三大零碎进行查问，别离是 CDP、DMP、CRM 场景的比照。最终无效查问 SQL 16 条，线上场景下查问 SQL 的具体特点如下：

如表格所示，咱们将 Doris 与 Clickhouse 16 条 SQL 查问工夫比照，其中有 10 条 SQL Doris 查问性能优于 Clickhouse。 此外咱们将 Doris 与 Clickhouse 查问工夫总和进一步比照，在对 Doris 表结构设计优化后，Doris 整体查问速度相比 Clickhouse 快 2-3 倍。

大表 Join 查问性能测试

在关联查问测试中，以 CDP 场景下的相干数据表为根底，咱们选用了不同数据量级的主表与维表数据，主表测试数据量别离为 40 亿的用户行为表、250 亿的用户额定属性表、960 亿的用户额定属性表；维表以 kdt_id + user_id 为根底，测试量级别离为 100 万、1000 万、5000 万、1 亿、5 亿、10 亿及 25 亿维表数据量。为了测试更加全面，关联查问测试分为齐全关联与过滤关联两种测试，齐全关联是将主表与维度表间接进行 Join，过滤关联是在雷同主表量级关联中，减少了 WHERE 条件对指定的两个店铺 ID 进行过滤。

具体的查问测试体现如下：

  • 全关联 40 亿： 在 40 亿主表齐全关联查问中，Doris 查问性能均优于 Clickhouse，且随着维表数据量级增大，Doris 与 Clickhouse 查问耗时差距越大，其中 Doris 最高可能达到 5 倍 性能晋升；
  • 过滤指定店铺关联 40 亿： 在过滤条件关联查问中，主表依照 WHERE 条件过滤后的数据为 4100 万，相较于 Clickhouse，Doris 在维表数据量小的状况下可能达到 2-3 倍的性能晋升，在维表数据量大的状况达到 10 倍以上的性能晋升，其中当维度数据表超过 1 亿后，Doris 仍旧能够稳固查问，而 Clickhouse 因为 OOM 状况导致查问失败。
  • 全关联 250 亿： 在 250 亿 50 字段宽表作为主表齐全关联时，Doris 查问性能仍旧优于 Clickhouse，Doris 在所有维表量级中均能跑出，而 Clickhouse 在超过 5000 万后呈现 OOM 状况；
  • 与过滤指定店铺关联 250 亿： 在条件关联查问中，主表依照店铺 ID 过滤数据为 5.7 亿，Doris 的查问响应工夫均达到了秒级，而 Clickhouse 最快响应工夫也须要分钟级耗时，在数据量大的状况下更是无奈跑出。
  • 全关联与过滤指定店铺关联 960 亿： 不论是主表关联查问还是条件关联查问，Doris 均可跑出且响应速度较快，Clickhouse 则在所有维表量级中无奈跑出。

除响应性能外，咱们还对于 Doris 的 CPU 与内存损耗进行检测，发现 Doris 在数百亿计大表关联查问的状况下集群负载仍旧稳固。综上，Apache Doris 在绝大部份场景查问响应速度快于 Clickhosue，特地是在大表 Join 场景下，Apache Doris 性能体现齐全优于 Clickhouse。

03 Clickhouse 线上流量回放稳定性测试

在查问压测实现后，咱们开始将 Doris 与 Clickhouse 线上双跑以进一步验证 Doris 的稳定性。具体步骤如下：

  1. 通过定时采集 Clickhouse 最近 1 分钟的查问状态为 QueryFinish 的无效查问信息。
  2. 将查问信息上报至 Kafka，接着通过 Flink 生产 Kafka Topic 获取 Clickhouse 查问 SQL 并统计后果。
  3. 在 Flink 中实现 UDF 将 Clickhouse 查问 SQL 转化为 Doris 查问 SQL，并由 JDBC 执行。
  4. 获取执行后果与统计后果，与 Clcikhouse 执行信息进行比照最终寄存至 RDS。
  5. 最终通过对线上 Clickhouse 查问流量回放的统计，剖析 Doris 查问性能与查问数据准确性。

04 Apache Doris 数据导入性能测试与优化

数据导入性能测试是咱们重要关注的环节之一，Apache Doris 自身对于实时数据和离线数据的导入提供了比拟丰盛的导入形式，实时数据的导入形式次要是通过 Apache Flink 将 NSQ 和 Apache Kafka 的数据实时通过 Stream Load 形式写入 Apache Doris 中。在离线数据中，Doris 提供了多种导入形式：

  • 反对通过 Spark SQL 读取内部数据，通过 Stream Load 形式写入 Apache Doris；
  • 反对通过 Spark Load 形式，利用 Spark 集群资源将数据排序操作在 HDFS 中实现，再通过 Broker Load 将数据写入 Doris；
  • 反对 Doris Multi-Catalog 性能间接读取 内部数据源并通过 Insert Into 形式写入 Doris。

因为离线数据量较大，针对这类数据咱们将几种数据导入形式进行了性能测试比照，通过明细数据的各个数据量级比照测试导入工夫。测试集群规模 3 FE + 16 BE，BE 单节点配置为（32C 128 G 7T SSD）测试后果：

Spark Doris Connector 格局导入的并行度为 80，单批为 100 万，集群的负载状况如下：

依据上方测试后果，咱们进一步剖析各种导入形式的劣势与后续调优计划，心愿以下的调优实际可能帮忙到有相似需要的开发者们：

Doris Insert Into

Insert Into 形式可能提供疾速导数性能，在用法上也绝对简略，目前该形式的导入性能曾经足够反对咱们的业务需要。

Spark Doris Connector 反对阻塞写入

Spark Doris Connector 导入形式更具备通用性，可能解决大量数据导入的问题，导入性能绝对稳固，在导入过程咱们须要正当管制导入速率与导入并行度。思考到咱们的业务场景每天会波及千亿级别的数据量并破费 5-6 个小时进行导入，对于这类大表数据的导入如果因为 BE 写入被回绝导致失败，会造成上游数据产出提早等问题。此外，在 2.0 版本中，相似 -235，-238 谬误曾经在 Apache Doris 内核层面解决，无需用户再手动解决此类问题。

咱们次要从管制写入速度动手，整体革新原理是通过指数退却写入的形式提早阻塞，利用配置参数使大数据量呈现导入异样时能够期待重试，不让工作失败。通过最大阻塞次数、单次最大阻塞工夫、须要阻塞异样捕捉关键词这三个参数来捕捉阻塞异常情况，实现阻塞退却性能。最终在该设置下，咱们的大表导入数据成功率达 95% 以上。

[1] 相干 PR：https://github.com/apache/doris-spark-connector/pull/117

Spark Doris Connector 反对 Bitmap 数据导入

在浏览 Apache Doris 官网文档时，咱们发现 Spark Load 的形式能够对 Bitmap 数据进行导入，同时可能将 Bitmap 数据计算放在 Spark 集群中进行计算。在业务实际中，咱们应用 Spark Doris Connector 更为罕用，于是开始摸索通过 Spark Doris Connector 的形式实现 Bitmap 数据导入。

如上图所示，Bitmap 建表语句次要分为三个字段，其中最初一个字段是将 CASE_ID 进行 Bitmap 计算。在与社区成员沟通之后，提供一种设置 Doris Read Field 选项，写除 Bitmap 列外的其余列，同时在 Doris Write Field 中做映射解决。最终实现如上图所示形式通过 Spark Doris Connect 间接将 Apache Hive 明细数据导入 Apache Doris 的 Bitmap 数据中。

Spark Doris Connector CSV 格局导入优化

在咱们的导入流程中，无论是 Spark Doris Connector 还是 Flink Doris Connector，最终都是利用 Stream Load 的形式进行导入，其导入文件 CSV 与 JSON 有两种导入格局且对于不同格局的抉择，导入性能的损耗与速率也是不同的。

在优化前，咱们进行了测试，以数十亿数据规模、26 个字段的业务表进行导入性能测试，发现 CSV 格局比 JSON 的导入速度快近 40% 且其内存耗费是更低的，这也是为什么 Apache Doris 官网举荐应用 CSV 格局。

其中值得注意的是应用 CSV 格局进行导入时，设置正当的字段分隔符和换行符对于 CSV Reader 辨认效率是至关重要的，如果 BE 的 CSV Reader 对于字段中最初一个字符和分隔符的首字符雷同时，则无奈辨认分隔符。

通过官网文档的提醒，咱们发现 Stream Load 中可能反对参数配置去除字段最外层的双引号，基于此咱们决定在 Spark Doris Connector 写入阶段增加用户设置配置，在字段外层拼接双引号，保障不必选定特殊字符仍然可能无效分隔，同时在 Stream Load 写入阶段增加去除最外层双引号的配置。通过两端配置，可能保障即便业务数据很简单的状况下，也无需为字段符号的辨认而懊恼，无效保障字段可能失常宰割。

[2] 相干 PR: https://github.com/apache/doris-spark-connector/pull/119

Spark Load

Spark Load 导入形式的特点是基于 Spark 资源进行 Shuffle、排序等工作将文件输入在 HDFS 中，之后 BE 节点可能间接读取 HDFS 上的文件并依照 Doris 格局写入。基于这种形式，在测试过程中咱们发现当数据量越大时导入速度越快、越可能节俭 Doris 的集群资源，不会带来较大性能损耗。

因为 Spark Load 在长期修复数据场景中应用频繁，咱们也基于测试进一步优化。通过官网文档与社区帮忙下咱们发现，Spark Load 阶段的导入速率次要由单次导入并发度和单次 BE 导入数据处理量两方面参数影响，且两个参数都与源文件大小、BE 节点密切相关。当管制其余变量的状况下，源文件越小，导入速度越慢，因而咱们认为在 ETL 阶段充分利用 Spark 经营资源并且正当设置 Bucket 数量可能无效减速导入速率。

将来布局与瞻望

在整体测试环节中，基于 Apache Doris 2.0 正式版本的性能测试曾经实现，咱们对于 Doris 的查问性能体现是十分满意的。此外，对于导入性能，咱们在测试时首先采纳的是 Doris 2.0-Alpha 版本，发现在导入过程中存在偶发性 CPU 瓶颈的问题，例如当通过 Spark Doris Connector 的形式，Spark 应用资源和 Doris 导入数据 CPU 存在肯定的瓶颈。同时，咱们也将问题反馈给社区，在通过社区优化与 2.0-Beta 版本公布后，稳定性失去了改善。

目前，咱们正在与 Clickhouse 线上双跑对 Doris 的稳定性进一步验证，同时咱们正在对 Spark Doris Connector 导入形式的的进行性能优化、开发导入周边工具以实现组件替换等落地工作。后续在逐渐实现 Clickhouse 的业务迁徙后，基于 Clickhouse 的迁徙教训，对未迁徙的存量业务逐渐实现 Druid、Kylin 两个组件的迁徙，最终基于 Apache Doris 构建极速剖析、实时对立的数据仓库。

在此非常感谢 SelectDB 技术团队的积极响应与业余解答，减速有赞业务的迁徙过程，也心愿通过这篇文章为筹备进行架构迁徙的企业提供相干实践经验和 OLAP 选型参考。最初，咱们也会继续参加社区活动，将相干成绩奉献回馈社区，心愿 Apache Doris 飞速发展，越来越好！

参考 GitHub PR：

[1] Spark Doris Connector 反对阻塞写入

https://github.com/apache/doris-spark-connector/pull/117

[2] Spark Doris Connector CSV 格局导入优化

https://github.com/apache/doris-spark-connector/pull/119

[3] Spark Load 创立 Hive 表面反对 Hive 版本设置

https://github.com/apache/doris/pull/20622

[4] Spark Load 零碎环境变量获取优化

https://github.com/apache/doris/pull/21837

[5] HIve 表面属性在 Spark Load 不失效优化

https://github.com/apache/doris/pull/21881

退出移动版