乐趣区

关于数据库:应用实践-Apache-Doris-在网易互娱的应用实践

jiezi

编者荐语：
网易互娱于 2021 年 4 月引入了 Apache Doris 产品，目前曾经倒退为多个集群，服务数十个业务，在查问速度及易用性方面也失去了业务的认可，未来会有更多的业务正在往 Doris 集群上迁徙。以下是网易互娱的实际分享。

作者介绍：Pencil，网易游戏数据与平台的离线平台组高级开发工程师，目前负责 Trino(Presto)/Doris 等组件的开发和业务反对工作。离线平台小组目前为广州互娱的大数据离线计算提供了靠近 EB 级别的大数据存储集群服务，以及 Hive/Spark/Presto/Doris/ClickHouse 等计算框架的开发与业务反对。

一、背景

随着公司游戏业务的高速倒退，越来越多的剖析需要涌现，例如：各类游戏用户行为剖析、商业智能剖析、数仓报表等。这些场景的数据体量都较大，对数据分析平台提出了很高的要求。为了解决实时剖析的时效性，同时又能保证数据疾速写入和查问，须要一个适合的数据查问引擎来补充咱们原有的架构体系。

通过大量调研，Apache Doris 比拟符合网易互娱游戏数据中心的整体要求，Apache Doris 具备以下优良个性：

  • MPP 架构 + 高效列式存储引擎
  • 高性能、高可用、高弹性
  • 规范 ANSI SQL 反对
    • 反对多表 Join
    • 反对 MySQL 协定
  • 反对预聚合
    • 反对物化视图
    • 反对预聚合后果自动更新
  • 反对数据高效的批量导入、实时导入
  • 反对数据的实时更新
  • 反对高并发查问
  • 周边生态欠缺

网易互娱于 2021 年 4 月引入了 Apache Doris 产品，目前曾经倒退为多个集群，服务数十个业务，如游戏舆情剖析，实时日活看板、用户事件剖析、留存剖析、漏斗剖析、散布剖析等。以后 OLAP 平台与数仓体系交融的架构如下图所示：

图 1. OLAP 平台与数仓体系交融架构

二、Apache Doris 简介

Apache Doris 是百度开源的 MPP 剖析型数据库产品，不仅可能在亚秒级响应工夫即可取得查问后果，无效的反对实时数据分析，而且反对 PB 级别的超大数据集。相较于其余业界比拟火的 OLAP 数据库系统，Doris 的分布式架构十分简洁，只有 FE、BE 两个服务，整体运行不依赖任何第三方零碎，反对弹性伸缩，对于业务线部署运维到应用都十分敌对。目前国内社区炽热，也有腾讯、字节跳动、美团、小米等大厂在应用。

图 2. Apache Doris 架构

2.1 FE

FE 的次要作用将 SQL 语句转换成 BE 可能意识的 Fragment，如果把 BE 集群当成一个分布式的线程池的话，那么 Fragment 就是线程池中的 Task。从 SQL 文本到分布式物理执行打算，FE 的次要工作须要通过以下几个步骤:

  • SQL Parse：将 SQL 文本转换成一个 AST(形象语法树)
  • SQL Analyze：基于 AST 进行语法和语义剖析
  • SQL Logical Plan：将 AST 转换成逻辑打算
  • SQL Optimize：基于关系代数，统计信息，Cost 模型对逻辑打算进行重写，转换，基于 Cost 选出老本最低的物理执行打算
  • 生成 Plan Fragment：将 Optimizer 抉择的物理执行打算转换为 BE 能够间接执行的 Plan Fragment
  • 执行打算的调度

图 3. FE 执行 SQL 流程

2.2 BE

BE 是 Doris 的后端节点，负责数据存储以及 SQL 计算执行等工作。

BE 节点都是齐全对等的，FE 依照肯定策略将数据调配到对应的 BE 节点。在数据导入时，数据会间接写入到 BE 节点，不会通过 FE 直达，BE 负责将导入数据写成对应的格局以及生成相干索引。在执行 SQL 计算时，一条 SQL 语句首先会依照具体的语义布局成逻辑执行单元，而后再依照数据的散布状况拆分成具体的物理执行单元。物理执行单元会在数据存储的节点上进行执行，这样能够防止数据的传输与拷贝，从而可能失去极致的查问性能。

图 4. BE 执行 SQL 流程

三、 集群治理

3.1 Compaction 调优 – Tablet 治理

在网易互娱引入 Apache Doris 初期，业务用户在测试过程中发现建表时指定 bucket 数越大，查问速度越快，导致了用户在新建表和分区时对立将 bucket 数指定为 64。随着导入的数据越来越多，问题也开始裸露了进去：业务陆续反馈 alter 分区失败、批改字段长度失败等问题。通过 SA 排查发现这些失败都是超时导致，同时发现业务操作的表数据量仅 2G，replica 数却达到了 68736：

图 5. 业务表数据量及 replica 数

更进一步地，为了将问题彻底裸露进去，对该集群进行全量统计发现 60T 的数据量达到了靠近 2000 万的 tablet 数，tablet 数过多会导致以下几个问题：

  1. 用户建分区，建表，批改字段等元数据操作耗时长，甚至会超时失败；
  2. 元数据都放在 FE 内存中，GC 压力较大，同时 FE 在进行 Checkpoint 操作时因为元数据占用内存翻倍，极易呈现 OOM 的危险；

bucket 数是查问吞吐和查问并发的一种衡量，为了集群的衰弱倒退，旧数据必须进行 tablet 治理，新的建表标准需建设起来。

3.1.1 治理指标

tablet 数量 = 分区数 正本数 bucket 数

从下面的计算公式可知，在用户的场景下，前两者都是固定不变的，决定 tablet 数大小的只有 bucket 数。

鉴于该集群目前数据量大小为 60T 左右，联合对 bucket 的更进一步了解以及以后集群理论状况，治理的指标和长期管制的指标定为：

  1. tablet 数：2000w -> 100w
  2. tablet 增长量：15000/TB

3.1.2 施行打算

（1）对于现存的表

  1. 扫描集群内所有的表，以分区粒度输入一份残缺的数据统计给业务方，并依据每张表的理论状况附上批改倡议；
  2. 制订治理打算依照由高收益到低收益，优先解决最不合理的库，将元数据管理压力降下来，再逐渐依照打算治理所有的库。

因为 Doris 目前不反对按分区级别展现整个库下的数据状况，因而独自开发一个程序进行扫描，伪代码如下所示：

con = DriverManager.getConnection()
for db in db_list:
    con.execute("use %s".format(db)))
    for table in table_list:
        con.execute("show create table %s".format(table)) #获取第一个分区的 bukcet 数
        result.append(regrex_extract_bucket(con.next()))
        con.execute("show partitions from %s".format(table))            
        result.append(regrex_extract_bucket(con.next())) #获取除第一个分区的 bukcet 数
write_result_to_excel(result)  

截取局部写入 Excel 的数据，统计格局如下：

图 6. Doris 集群分区粒度数据统计及治理冀望

联合 Excel 优良的透视表性能，即可轻松获取表粒度、以及库粒度下的治理倡议统计表，最终治理指标也是根据计算出来的总冀望分区数失去。以库粒度做统计截取局部数据如下所示：

图 7. 集群库粒度数据统计及治理冀望

依据统计表失去的信息，优先选择高收益率的库进行治理（上图中已标绿），对表的治理形式有以下两种形式：

第一种形式：数据重插

# 鉴于 Doris 对所有已存在分区的 bucket 数无奈批改的状况，应用新建表重插的形式进行，步骤为：1. create table xxx_bak 
for partition in partition_range:     
     if(partition.data != null)
          2. alter table xxx_bak add partition if not exists date bucket[动静值]; // 动静值依据每一个分区理论的数据量计算传入     
          3. insert into xxx_bak select * from xxx where dt=date 
4. 查看新的 xxx 数据量，分区数是否正确；// 重点！！5. ALTER TABLE xxx RENAME xxx_old; 
6. ALTER TABLE xxx_bak RENAME xxx; 
7. drop xxx_old。​
-----
计划阐明：依据优先程序对一张待治理的表进行步骤 1 和步骤 2，第 3 步应用串行的形式提交执行（缩小资源占用和出错的可能性）。执行完后依据数据验证计划对数据进行验证，确保无误后进行 5，6 操作。​
特地阐明：因为迁徙过程中依然会有数据写入旧表，因而迁徙过程中有两个内容要确保：1、在重插最新的分区过程中，业务管制确保该时间段内没有数据流入；2、一张表的 1 - 6 步骤在下一次写入数据前实现。3、如未实现则独自标记，在当天完结写入数据和下次写入数据前实现该分区的重插。依据业务反馈大部分 load 分区操作都能在 1 分钟实现，所以重插的工夫窗口是很大的。

应用该种形式对三种类型的表进行测试，后果如下：

  • 小表测试 21.5M 6806tablet 650s
  • 中表测试 19G 4191tablet 330s
  • 大表测试 188G 10624tablet 1930s

第二种形式：数据重 Load

# 对于表数据在 Hive 数据还存在的，该形式更为简略
1. drop partition
2. create partition
3. load data from Hive

（2）对于将来新增表

对于业务方，业务在导入数据时减少判断逻辑，依据 Hive 表数据状况指定 bucket 数，建分区标准如下：

  • 0-10M 的数据量：1
  • 10-50M 的数据量：2
  • 50M-2G 的数据量：4
  • 2-5G 的数据量：8
  • 5-25G 的数据量：16
  • 25-50G 的数据量：32
  • 超过 50G 的数据量：64

对于服务方，新增以下措施：

  1. 监控页面新增 tablet_per_TB_data 指标，及时检测到异样建表建分区的状况。
  2. 定期（如每月）统计哪些表还存在 tablet 优化的空间，提供给业务，并催促改良。

3.1.3 治理收益

通过一段时间的治理，tablet 数显著降落：由靠近 2000 万降落到 300 多万，业务反馈的元数据操作相干问题显著缩小：

图 8. tablet 监控

FE 的堆内存占用显著降落，执行 Checkpoint 时，元数据会在内存中复制一份，体现在监控图上是一段尖峰，治理后尖峰变得更弛缓，大大晋升了 FE 的稳定性：

图 9. FE JVM Heap Stat

3.1.4 治理阐明

因为 Hive 中数据存储格局与 Doris 数据存储格局不同，因而在数据量断定方面存在差异，会导致 SA 在扫描分区 tablet 数时失去局部治理谬误的论断，总体来说理论值会比预期值高，以某库为例：

图 10. 某库分区治理后验证后果

3.2 Compaction 调优 Stream Load 治理

3.2.1 问题形容

业务应用的某个 Doris 集群经常出现 BE 异样退出的状况，影响实时数据导入到 Doris 集群，查看监控显示 Compaction Cumulative Score 值稳定非常异样：

图 11. Compaction Cumulative Score 监控

Doris 的数据写入模型应用了 LSM-Tree 相似的数据结构。数据都是以追加（Append）的形式写入磁盘的。这种数据结构能够将随机写变为程序写。这是一种面向写优化的数据结构，他能加强零碎的写入吞吐，然而在读逻辑中，须要通过 Merge-on-Read 的形式，在读取时合并屡次写入的数据，从而解决写入时的数据变更。

Merge-on-Read 会影响读取的效率，为了升高读取时须要合并的数据量，基于 LSM-Tree 的零碎都会引入后盾数据合并的逻辑，以肯定策略定期的对数据进行合并。Doris 中这种机制被称为 Compaction。

该值能够反映以后版本沉积的状况，这个值在 100 以内算失常，如果继续迫近 100，阐明集群可能存在危险，而从图 11 中能够看到，该集群的 Compaction Score 周期性的迫近 500。

3.2.2 Compaction 参数调节

通过监控图找到一个版本数量最高的 BE 节点。而后执行以下命令剖析日志：

grep "succeed to do cumulative compaction" logs/be.INFO |tail -n 100

以上命令能够查看最近 100 个执行实现的 compaction 工作：

I0401 12:59:18.284560 237214 compaction.cpp:141] succeed to do cumulative compaction. tablet=2566873.1945397493.0d4a2195f6f6424d-65b75eda8ddfb0b7, output_version=[2-35622], current_max_version=35646, disk=/disk3/doris-storage, segments=5. elapsed time=0.028255s. cumulative_compaction_policy=SIZE_BASED.
​
I0401 12:59:18.368721 237212 compaction.cpp:141] succeed to do cumulative compaction. tablet=2566783.1058891652.1640cd0ad79af581-ed2dab3265ffc484, output_version=[2-158658], current_max_version=158682, disk=/disk4/doris-storage, segments=1. elapsed time=0.112345s. cumulative_compaction_policy=SIZE_BASED.

通过日志工夫能够判断 Compaction 是否在继续正确的执行，通过 elapsed time 能够察看每个工作的执行工夫。

还能够执行以下命令展现最近 100 个 compaction 工作的配额（permits）：

grep "permits" logs/doris/be.INFO |tail -n 100

配额和版本数量成正比。

场景一：基线数据量大，Base Compaction 工作执行工夫长。

BC 工作执行工夫长，意味着一个工作会长工夫占用 Compaction 工作线程，从而导致其余 tablet 的 compaction 工作工夫被挤占。如果是因为 0 号版本的基线数据量较大导致，则能够思考尽量推延增量 rowset 降职到 BC 任务区的工夫。以下两个参数将影响这个逻辑：

cumulative_size_based_promotion_ratio：默认 0.05，基线数据量乘以这个系数，即降职阈值。能够调大这个系数来进步降职阈值。

cumulative_size_based_promotion_size_mbytes：默认 1024MB。如果增量 rowset 的数据量大于这个值，则会疏忽第一个参数的阈值间接降职。因而须要同时调整这个参数来晋升降职阈值。

场景二：增量数据版本数量增长较快，Cumulative Compaction 解决过多版本，耗时较长。

max_cumulative_compaction_num_singleton_deltas 参数管制一个 CC 工作最多合并多少个数据版本，默认值为 1000。思考这样一种场景：针对某一个 tablet，其数据版本的增长速度为 1 个 / 秒。而其 CC 工作的执行工夫 + 调度工夫是 1000 秒（即单个 CC 工作的执行工夫加上 Compaction 再一次调度到这个 tablet 的工夫总和）。那么可能会看到这个 tablet 的版本数量在 1-1000 之间浮动。因为在下一次 CC 工作执行前的 1000 秒内，又会累积 1000 个版本。

这种状况可能导致这个 tablet 的读取效率很不稳固。这时能够尝试调小

max_cumulative_compaction_num_singleton_deltas 这个参数，这样一个 CC 所要合并的版本数更少，执行工夫更短，执行频率会更高。还是方才这个场景，假如参数调整到 500，而对应的 CC 工作的执行工夫 + 调度工夫也升高到 500，则实践上这个 tablet 的版本数量将会在 1-500 之间浮动，相比于之前，版本数量更稳固。

3.2.3 解决方案

（1）长期解决方案

将 max_tablet_version_num 由默认的 500 设置为 1000。

参数形容：限度单个 tablet 最大 version 的数量。用于避免导入过于频繁，或 compaction 不及时导致的大量 version 沉积问题。当超过限度后，导入工作将被回绝。

这也解释了为什么有 be 宕机后业务的 load 作业也会进行的起因。

（2）最终解决方案

通过审计日志发现，版本数的变动曲线与 Doris Stream Load 导入频率变动曲线统一，所以 Cumulate Compaction Score 过高是 Stream Load 导入频次过高引起。通过和业务的沟通，确定了 Load 参数如下：

  1. sink.batch.size 设置为 10000
  2. sink.batch.interval 设置为 10s

参数批改后，问题失去了解决：

图 12. 批改后 BE Compaction Score 监控

3.3 集群扩缩容教训分享

3.2.1 背景形容

扩缩容操作简略始终是 Doris 广为人知的劣势之一。随着业务的一直迁入，网易互娱外部的 Doris 集群常常会遇到扩容的需要，也遇到了一些问题，当初对扩容教训作总结分享。

3.2.2 扩容后 be 数据不平衡

对某 Doris 集群扩容后，呈现了这样一种状况，所有旧的 be 的 tablet 全副迁徙到了新的机器中去，如下图所示：

图 13. BE ReplicaNum 散布

上图中能够看到新增的节点 tablet 数通过主动负载平衡后都达到了 29800 左右，而旧的机器 tablet 数变成了三位数。在最初一列能够看到旧机器的 Class 被打上了 HIGH 标签，而新机器的标签为 MID，从这里开始剖析，依据标签定位到以下源码：

public enum Classification {
    INIT,
    LOW, // load score is Config.balance_load_score_threshold lower than average load score of cluster
    MID, // between LOW and HIGH
    HIGH // load score is Config.balance_load_score_threshold higher than average load score of cluster
}

从正文中能够看到有一个参数 balance_load_score_threshold 能够界定该节点是负载还是低负载，这个值零碎默认是 0.1，在官网中又有如下一段解释：

Class：依据负载状况分类，LOW/MID/HIGH。平衡调度会将高负载节点上的正本迁往低负载节点

被打上 HIGH 标签的 BE 的数据就会往 MID 标签的 BE 中迁徙，导致呈现了图 13 中下方 3 个 BE tablet 数很少的状况，就是因为他们的 UsedPercent 比其余节点高，所以 score 高出了平均值 0.1。

问题：那么如果我把 balance_load_score_threshold 的数值调大，使得旧机器的标签也变成 MID，是否能够触发新的负载平衡？

论断是不行，当我将 balance_load_score_threshold 调到 0.4 之后，旧机器的标签都变成了 MID，然而新旧机器的 tablet 依然放弃着迥异的差距。这是因为迁徙策略只会从 mid -> low 或者 high -> mid，mid -> mid 不会触发负载平衡，相干源码见：BeLoadRebalancer.java 的 selectAlternativeTabletsForCluster() 办法。

以后平衡策略存在的问题：一个 BE 因为其余利用多占用了一些磁盘空间，比其余 BE 高，导致被打了 HIGH 标签后就不存储数据，而实际上他的空间利用率依然很低？

负载分数计算的源码如下：

// 计算的公式
loadScore.score = capacityProportion * loadScore.capacityCoefficient
         + replicaNumProportion * loadScore.replicaNumCoefficient;

负载因素系数和磁盘使用率系数个别都是 0.5，所以决定 load score 的是 磁盘使用率 和 正本数量。

double capacityProportion = avgClusterUsedCapacityPercent <= 0 ? 0.0
                : usedCapacityPercent / avgClusterUsedCapacityPercent;

从这一行源码中能够看到，无论你的负载多低，只有机器负载之间占比迥异，最初的 capacityProportion 值都会很大，导致该节点极有可能被打上 HIGH 标签。

3.2.3 解决办法

办法一：

调整 BE 存储数据的磁盘其余因素占用的磁盘空间（如零碎预留空间，其余应用程序占用等），使得所有 BE 磁盘除去 BE 存储数据后的磁盘使用率基本一致。

this.totalCapacityB = in.readLong();
...
long availableCapacityB = in.readLong();
this.dataUsedCapacityB = this.totalCapacityB - availableCapacityB;
this.diskAvailableCapacityB = availableCapacityB;

从上述源码能够看到 Doris 通过底层命令拿到了 totalCapacityB 和 availableCapacityB，dataUsedCapacityB 通过两者相减计算了进去。因而要想 BE 存储的数据在各机器之间平衡，就要尽量打消其余因素导致的 BE 之间磁盘初始使用率不平衡。

本案例中是因为旧机器的磁盘 ext4 存在默认 5% 的保留空间，而新机器的保留空间为 1%，通过命令 tune2fs -m 1 /dev/sdXY 将旧机器的预留空间批改为 1% 后，所有 BE 存储的 tablet 数达到了绝对平衡的状态。

办法二：

批改 HIGH 标签的断定形式，该补丁曾经提交社区，原理是：如果 BE 的磁盘使用率小于 50%，那么无论 BE 之间磁盘使用率如许迥异，它都不会被打上 HIGH 标签，进而会失常的存储 BE 数据。补丁链接：#9496。

3.2.4 其余教训

  • 如果集群只有三台机器，三正本机制下不能 DECOMMISSION 机器；
  • DECOMMISSION 机器后会有局部 Replica 未被迁徙，能够先通过 show proc “/statistic” 查看集群是否还有 unhealthy 的分片，如果为 0，则能够间接通过 drop backend 语句删除这个 BE（三正本机制下）；
  • DECOMMISSION 机器后 tablet 未做任何迁徙，查看以后版本是否打了该补丁：#7563；

四、监控与报警

4.1 监控零碎

网易互娱外部自研的 Monitor 智能监控零碎提供多种形式上报数据，轻松实现可视化与报警。借助它的根底监控能力，只需装置 agent 即可享受笼罩硬件、操作、过程零碎层面的根底监控，笼罩物理机、虚拟机、私有云、公有公、容器等。对于裸露有 Prometheus Exporter 的组件采集，此部份零碎已提供了规范插件，只有机器在 Galaxy 上绑定了相应的服务，就会装置相应的插件，主动采集 Metrics 数据并上报 Monitor。Doris 的监控数据通过 Frontend 和 Backend 的 http 接口向外裸露，满足上述疾速接入的条件。Monitor 的可视化模块提供仪表盘（集成开源的可视化组件 grafana）、自定义视图等多种灵便配置看板，实用于多种监控场景的跨实例汇聚数据、实时 / 历史数据展现、类似指标比照展现、图表联动等灵便的个性化视图性能，让 SA 疾速轻松实现 Doris FE、BE、Broker 的监控面板建设。

图 14. Monitor 疾速实现组件监控面板建设流程

4.2 Blackhole 告警

Blackhole 是网易互娱外部宽泛应用的监控和报警零碎，提供了丰盛的报警场景：反对指标、变动、集群、聚合、端口探测、音讯、alert.py 事件报警、异样检测动静阈值、预测报警、硬件报警等。目前对 Doris 集群配置的报警规定来自两个方面：

  1. 借助 Monitor 采集的 Doris 上报的 Metrics 数据，进行要害指标的监控；
  2. 外部 Doris 的所有服务日志已通过 Loghub 采集并写入 elk 中，对 warn 级别的日志类型进行百分比阈值监控。

通过一直的迭代，目前监控的次要指标包含如下：

  • FE 端口、BE 端口异样告警
  • 查问错误率告警
  • 查问工夫 P90、P95 告警
  • BE 存储使用率告警
  • BE 内存应用告警
  • BE Cumulate Compaction Score 报警
  • Broker Load 并发数报警
  • Broker Load 异样数报警

Blackhole 的告诉策略提供了多种模式，简略告诉、反复告诉、降级告诉、触发式告诉，故障自愈告诉等，确保针对不同级别的故障能失去相应的响应速度。同时咱们为 Doris 所有的 FE、BE、Broker 均配置了 Supervisor 守护过程，能够实现服务异样退出后疾速主动拉起，联合 Doris 的 FE 高可用机制，根本保障了线上服务的稳固运行。

五、故障解决复原

当线上集群节点产生故障时，Supervisor 解决了大部分服务异样退出后的复原，然而仍有少部分的故障须要人为干涉。例如以下场景：用户提交的 SQL 触发了 Doris 的某个 BUG，如果不及时解决和干涉就会导致集群中一直有节点宕机、拉起，影响其余用户的失常应用。针对该场景下的问题排查，可总结为以下几个步骤：

  • 对于 BE 异样退出：
  1. 首先查看服务宕机节点的 be.out 日志文件，该日志记录了简要的 be 过程退出的堆栈，未失去问题论断则下一步；
  2. 利用 gdb 及 coredump 文件定位问题（需提前配置让 Linux 服务器产生 coredump 文件）

    1. gdb 命令关上文件：

      gdb DORIS_PATH/be/lib/palo_be coredump_file_name

    2. bt 命令开展堆栈，失去开展之后具体的堆栈信息
    3. 应用 gdb 的调试命令查看堆栈中与查问信息相干的成员变量
    4. 打印成员变量的 _query_id，并转换为 16 进制
    5. 在 fe_audit.log 中查找该 16 进制值关键字，即可定位到对应的 sql
  • 对于 FE 节点异样：
  1. 如果过程退出，组件层面通过 fe.log 和 fe.warn.log 查看是否有相干报错日志，联合 Monitor 监控面板进行问题定位；
  2. 如果过程未退出，但服务异样，采纳以下几个步骤定位问题：
    1. jps 命令参看过程 id
    2. top -Hp pid 命令参看高负载线程
    3. 将线程号转换为 16 进制
    4. jstack -l pid | grep 16 进制线程 id
    5. jmap -histo:live pid > jmap.log

整个问题排查的流程如下图所示：

图 15. 问题排查流程

网易互娱外部 Doris 的问题次要来自业务反馈和 SA 对组件巡检两个渠道。在发现问题之后，SA 会利用下面提到的排查办法来定位问题：如果是 Doris 本身存在的 BUG，SA 会踊跃将问题反馈给社区，同时回馈社区提交修复 PR；对于较为简单的问题临时无奈解决的，SA 会申请社区开发团队帮助排查问题，这里特别感谢 Doris 社区张家锋与陈明雨两位大佬，在很多问题的解决上提供了踊跃的帮忙。

六、结束语

自从 2021 年 4 月网易互娱引入 Apache Doris 以来，Apache Doris 曾经在互娱外部失去了宽泛地应用，在查问速度及易用性方面也失去了业务的认可，目前有更多的业务正在往 Doris 集群上迁徙。联合网易互娱丰盛的大数据生态系统以及 Doris 组件易运维的个性，SA 也能够疾速满足业务增长需要，交付新集群和实现旧集群扩容的工作。当然 Doris 目前也存在一些问题，比方社区对发行版本存在的高危问题没有做及时的布告、发行版本没有做分支对齐以及小版本公布内容不通明，这让 SA 同学在运维和打补丁的过程中遭逢了不少麻烦。最初，十分期待社区的向量化引擎、新版查问优化器、Lateral View 等几大新个性成熟稳固，让网易互娱的业务用户体验更上一个台阶。

以上原文来源于公众号：网易游戏运维平台，作者 Pencil

原文地址：https://mp.weixin.qq.com/s/3g…

SelectDB 是一家开源技术公司，致力于为 Apache Doris 社区提供一个由全职工程师、产品经理和反对工程师组成的团队，凋敝开源社区生态，打造实时剖析型数据库畛域的国内工业界规范。基于 Apache Doris（incubating）研发的新一代云原生实时数仓 SelectDB，运行于多家云上，为用户和客户提供开箱即用的能力。

相干链接：

SelectDB 官方网站：

https://selectdb.com (We Are Coming Soon)

Apache Doris 官方网站：

http://doris.incubator.apache…

Apache Doris Github：

https://github.com/apache/inc…

Apache Doris 开发者邮件组：

mailto:dev@doris.apache.org

退出移动版