原文阅读：【巨人肩膀社区·博客·分享】 Doris 夺命 30 连问！(上)

导言

在前段时间和 Apache Doris 一个数据体量比较大的测试用户沟通过程中，对方的多达十几人的大数据架构师团队就关于 Apache Doris 的各种特性和自身业务场景提出了众多问题，个人感觉非常有探讨的价值，一起来看看，如果有异议或者意见，可以评论留言，也可以私聊~

Q&A

1. 怎么看待存算分离，优缺点，适合的业务场景，Doris 的 roadmap 是否包含？

存算分离本身对数据库本身而言，是对大数据量场景下的一个比较亮眼的发展点，主要的思路是将计算节点和存储节点解耦合，可以避免数据的 reblance 以及实现计算资源的弹性扩缩容，主要的缺点有几个：

1. 如果做不到更好的资源利用率，那么存算分离的性价比将会极大降低
2. 如果做不好存算链接的功能设计的话，那么性能将会极大降低
3. 如果本身硬件的性能不达标，尤其网络硬件，那么可能存在网络瓶颈
4. 整体部署复杂度会上升

这种特性形态，有计算和存储两方面的亮点：

1. 网络状态不错的情况下，有明显流量峰谷期的场景，比如保险行业的业务系统，可能每天早晨 9 点到 11 点是全国业务员大规模查询订单状态的业务时间段，可能需要的计算量是平时的 4-5 倍，而剩下的其他时间，可能都维持在 20% 左右的集群负载，那么如果是在云上有这样特性的产品话，那么可能每天只需要平时包年包月当前集群 20% 的机器资源，9-11 点 2 小时弹性扩容 80% 的机器资源，这样就会贴合着业务流量线扩缩容集群算力线，极大的降低用户的计算成本。

2. 在存储方面更是降本的大头，在云上的本地盘和对象存储做单位存储对比的话，对象存储的单位成本只有本地盘的1/8，那么尤其是业务增长较快的公司，可能很快后期的数据存储成本会远超于计算成本，如果是百 TB 级的用户，那么每年省的存储费用大概都是好几十万。

那么适用场景的话，有以下几个场景比较适用：

1. 日志系列的存储和分析场景

2. 对近期的数据查询速度有比较高的要求，对往期数据（如一个月前、三个月前这样的数据有归纳查询诉求【月度查询、季度查询、年度查询】）查询时延和频次不高

3. 对业务有明显峰谷期的场景

4. 整体业务发展速度快，不确定后期需要多大计算量和存储量的业务场景

而 Apache Doris 在这一方面，也做出了自己的特色：

1. 2.0 版本会推出冷热分层的特性，该特性将在下一个问题里详细答疑

2. 2.0 版本会推出 ComputerNode ，利用该类节点进行联邦查询的计算资源弹性扩缩容

2. 对于数据存在冷热的业务区分，数据资产的生命周期又比较长，如何在控制成本的情况下，解决这个述求？

Apache Doris 其实在早先就有了冷热存储的雏形，大家可以在配置 BE 的数据存储目录时看到 SSD 和 HDD 的 medium 选择，这里就是冷热存储的特性，但是这个特性只是在一个集群下，将热数据写到指定为 SSD 的目录路径下，在 cooldown 到期以后，自动的将 SSD 目录的数据迁移到 HDD，从计算效率角度而言，是有利的，但是整体成本下降效果比较微弱。

在 2.0 版本，社区重新设计和制作了基于 S3 对象存储为冷备存储介质的冷热分层特性，即将集群本地盘间的冷热存储进化为集群本地盘和 S3 对象存储，成本上的降低在上个问题也做了比较明确的数字对比，还有一部分是在业务层面，按时间比如天分区，通过冷热分离将使用频率低的数据存储到 s3 上降低成本，比如 30 天以内的在本地盘、30天以外的的在 s3。

3. BE 弹性扩缩容和优化，假设 BE 的存储目录不是本地存储，是 san 或者 nfs，比如 BE 的 IP1 的机器要下线，先下线 IP1 ,然后把 IP1 的存储从 IP1 挂到 IP2,IP2 当成新的 BE 加入集群，是否可行（share nonthing），如何避免不必要的 rebalance，是否可以延迟 rebalance ？

本身在当前存算一体的架构上而言，FE 在记录元数据时不仅记录了物理盘上的具体位置信息，还记录了是具体哪个 IP + ID 的 BE 存储，从当前而言，这种直接迁移盘的行为是无法满足 ShareNothing 的诉求的。
当前 reblance 的默认线程数是 3 ，在这个线程数的情况下，对于集群的负载而言基本是无感的，在 2.0 版本里我们已经添加了一个参数 balance_slot_num_per_path 来可供大家动态的调整这个线程数，在集群负载较低的时间段内调大该参数，可快速进行数据的 reblance，也可以调小延迟 reblance。

4. 存量的 Doris 集群，在保持现有 BE 规模的情况下，在分批在 BE 节点的数据目录，增加存储空间是否可行，是否需要停集群或者下线节点？

可以的，Doris 支持通过变配 be.conf 中 storage_root_path 配置项来添加 BE 节点的存储空间。
这个操作需要重启 BE 节点，如果是多副本的数据备份下，不需要完全停集群进行变配挂载，只需要重启修改了配置的 BE 节点即可，如果是多个 BE 节点都进行了挂载，那建议使用轮询的方式进行重启加载。

在 Doris 1.2 版本开始，已经做了单节点的磁盘间均衡负载，在 1.2 版本以前，只有节点间的均衡负载。当然这个均衡负载也不是完全智能化的，比如不会根据不同节点的磁盘容量大小来决定要存在哪里，只是大体上会完成粗粒度的负载均衡，做不到完全每个盘都能根据严格的 tablet_num + Datasize 来完成均衡。

5. 多租户的隔离， Doris 的方案，隔离的级别是什么？

关于多租户，Doris 当前的策略方案是使用 Group 的形式来完成物力资源的分组隔离，简而言之就是比如有三副本，用户可以设置 1 个副本为 A Group 所有，其他 2 个副本为 B Group 所有，然后 A Group 执行的是 ELT/ETL 任务，B Group 执行的是 Ad-Hoc 场景任务，这样就可以做到互不干扰。

但是当前的资源隔离做的还是不够好，粒度有点粗，有时候无法彻底发挥出多副本的优势，故而社区再进一步的设计做新版本的资源隔离了，敬请期待。

6. Doris 集群扩容能保证数据均衡分布吗？

Doris 本身的集群就具有易运维的特性，那么易运维其中一点就是体现在数据的自动 reblance，如果有新的节点加入，可以参照问题 3。同时还需要注意的一点是，Doris 新的节点加入以后，如果有新的数据流入，那么新流入的数据也可能因为负载均衡和随机选取两个方面选择到新的节点上，这时候新写入的数据是可以直接提供服务的，无需等待 reblance。

7. Doris 本身的存储负载均衡是怎样做的，能做到什么粒度？

Doris 本身的存储负载均衡有两个粒度，一个是 BE 节点间的，一个是 BE 内磁盘间的。

其中 BE 节点间的又有两种策略，一种是负载均衡，一种是分区均衡。

负载均衡更多的是看每个 BE 本身的磁盘使用率和副本数量，在磁盘负载系数达到高水位时，会自动的进行迁移副本到低水位的 BE 节点上去，迁移的流程是先在低水位节点搞一个副本，然后删除高水位节点的副本，但是这里不做强均衡，也就是比如有 1000 个 tablet，有 5 个节点，不会一定保证每个节点都有 200 个 tablet。

同时这里还有冷热存储目录的区分度，如果是配置的有两种存储数据类型路径（storage_root_path 中的 medium:SSD/HDD），那么会根据冷数据存储目录（HDD）和热数据存储目录（HDD）来进行归类，然后尽可能的在同一种介质之间进行负载均衡。

这里每 20 秒会进行一次校验，然后有高负载的会起线程进行均衡。

分区均衡的话只在乎副本个数的均衡，不考虑磁盘使用的均衡，所以可能会出现 tablet num 一致，但是磁盘空间差异很大的情况。

第二种是每个 BE 的磁盘间的负载均衡，这个均衡可以设置哪些 BE 优先做均衡动作，不考虑整体的均衡水平，默认有效时长是 24 小时。

8. Doris 的高可用有几种解释？分别是哪几种？可以保证哪些安全？

Doris 的高可用一般分为两个大类，即 FE 的高可用和 BE 的高可用。

其中 FE 的高可用分为读高可用和写高可用。

FE 当前有两种角色：Follower 和 Observer，其中 Follower 参与选举，且有读写能力，Observer 不参与选举，只有读能力，那这时候，如果要满足读写高可用，就最少得有 3 个 Follower，因为 Follower 必须要奇数个，它们要进行选举，偶数个会产生脑裂，如果只要满足读高可用，那么就只需要 1 Follower + N Observer 即可，这个 N >= 1。

BE 的高可用也分为两种，一种是数据可用的高可用，一个是数据可靠的高可用。

数据可用的高可用即为在读取时的高可用，这时候只需要保证副本数 >= 2 即可，但副本数如果小于 3 的话，那基本是抛弃了 Doris 本身很强大的自愈能力，如果副本出现问题，需要手工进行修复。

数据可靠的高可用即为在存储时，要保证多副本可靠，这时候需要 节点数 >= 存储副本数 + 1，Doris 为了数据可靠性，默认是 3 副本，那么这时候综合下来就是如下结论：

1 Follower + N(>=1) Observer 保证读高可用

3 Follower + N(>=0) Observer 保证读写高可用

在默认副本的情况下：

3+ Backends 保证数据高可用

4+ Backends 保证数据高可靠

9. Doris 是否能兼任业务生产数据库角色？即事务型 OLTP 库。

这个要看具体的场景了，在大部分 TP 场景下，Doris 是满足不了的，因为 TP 主打事务和毫秒插入频次，而对于一个 AP 库而言，是非常吃亏的，这里主要是因为 AP 库在本身设计的阶段，就是采用了数据版本做数据可见性控制，一批数据导入以后，可以根据数据批次进行打版本号，在默认的 MOR 的策略下，根据高版本号进行展示。

同时 Doris 的数据导入是事务性的，那么如果是 INSERT INTO VALUES 这样的方式的话，很容易导致数据版本堆积，大量的数据版本会导致后台自动运行的 Compaction 进程压力增大，导致整个集群负载变高，所以从这个角度而言是不能兼任 TP 库的。

但是在一些延迟非敏的场景下，比如前端的数据要求后端处理以后展示的整体时效性在秒级，那么 Doris 是可以胜任的，Doris 可以将数据插入批次最小压缩到 0.5-1s 左右，再利用 Unique 模型的 Replace 算子和 Agg 模型的 Replace_if_not_null 算子进行更新，即可完成 TP 任务。

10. 如果存在 BE 的数据存储空间差异比较大的情况下，平衡是如何处理的？

该问题其实和问题 7 基本无差异，主要是看同步策略，如果负载同步策略的话，可以再设置磁盘间的优先策略来满足存储空间的合理利用，如果是分区策略，那么的确可能会导致这种平衡问题。

小结

本来是 30 问，但是由于篇幅比较长，就决定以 3 * 10 的方式来完成这三篇问答，如果各位看官老爷在看的过程中有任何疑问或者发现错误的地方，都欢迎随时指正。

老规矩，我微信号：fl_manyi

有任何 Apache Doris 相关的问题都可以探讨。