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

导言

抱歉，作为从 S2 开始的骨灰级玩家看到 EDG·UZI 官宣首发上线，兴奋之余忘了写文档 - -||，还望各位看官老爷见谅，这次错了，下次还敢 ^_^

这是继上次的 30 问上篇的中篇，也是 10 个问题，有些还是比较难回答的，欢迎大家在评论区或者私聊我来进行 battle~

Q&A

1. 时区 zone，因现在国家在发展东数西算，一些行业存在跨时区跨机房的情况，即使在国内北京和云南也存在比较大的时差，从业务角度如果要求时间偏差率控制在10秒级别，如何解决，是否会增加数据处理或者业务处理复杂度？

时差和时延问题在跨地域应用场景中是一个难以避免的问题，从软硬件一套系统的角度来看，这个更多的应当是硬件方面要解决的问题，比如光纤光缆的传输效率的提升以及多级级联的数据交换中心的配套和落地，所以这个问题我觉得应该从两个角度看：

1. 从硬件角度而言，网络传输的延迟是很难避免的，这个想要有更高效的传输效率，可能更多应该是从物理设备的介质角度、中继转发传输配套设施等角度来解决。
2. 软件角度而言：

1. 要在 Doris 里统一的进行多时区时间戳的管理，比如之前有一个用户是跨国企业，部署的 Doris 集群在全球范围内有很多个，每个集群要根据当地时间来统计业务指标，而同时在中国的总部也必须同时去将所有地区的多时区进行并行转换，比如一个表内以 shanghai_time 为主时区维度字段，并同时有纽约、北爱尔兰、新加坡、曼谷等地区的时区维度字段，然后在计算的时候进行不同时区的数据汇总，剩下的需要贴合业务来进行进一步的设计。
2. 其实从数据延迟这个角度而言，有没有一种类比可能更贴合我们大多数的同学在日常处理中的认知——Flink 流式数据处理时数据的迟到问题，在面试中经常被问到的零点漂移等问题其实就是类似这样的同质问题的实际例子，那么零点漂移问题的答案其实发散性的去思考思考，和当前这个光缆传输延迟的问题的答案无异都是很相似的，要么等待，等待要等待多久，要么就是业务角度进行取舍：能不能容忍数据计算时的延迟，或者能不能容忍数据可见性的时延较高？
3. 在国内区域的业务的话，其实这种延迟个人觉得可以视同为 Flink 无界流数据迟到来处理，不需要考虑跨时区问题，因为一般结算都是按照北京时间来结算的，哪怕比如新疆时间和北京时间会差三个小时左右，但是做结算一般都是按北京时间的。故而综合下来，我觉得这个问题一方面要在数据落档的时候要进行多维度的存储，同时要注意精度要求，一方面要和业务方进行协商，博得一个双方都可以接受的方案。

2. 时区 zone 其实存在2类问题，1类问题是跨时区的集群节点，2类问题是不跨时区的集群节点，单存在跨时区的数据

这两种在上一个问题中都做了相应的解答，如果是不跨时区的集群节点，可以按照 Flink 无界流数据迟到的问题来处理，如果是跨时区的集群节点，做多时区时间维度同步和入库时间处理。

3. 对于目前业务开发普遍使用 spring boot/spring cloud，数据库连接池，数据事务控制的等方面的建议和应该避免和规避的使用 Doris 的方式有哪些建议

首先无论是用 SpringBoot 还是 SpringCloud，只要使用 JDBC 来连接 Doris 做 CRUD，那么就应当使用数据库连接池来管理和控制数据库的 session，其原因和建议使用姿势如下：

1. Doris 作为一个数据库，本身的连接资源是比较珍惜的，Doris 的连接是长连接，不会随着会话的客户终端终止而立即释放，所以如果拿着长连接当短连接来用，那么就会很快把连接数用光，具体的表现就是新的 Session 无法连上集群，在 FE 的 WARNING 日志里报 Exception happened in one session 这样的日志。

2. Doris 在业务程序中使用的时候，还是要遵循 Doris 是一个 AP 库的原则，不能做频繁的（毫秒级的频繁入库和事务性的修改等）CRUD 中的 CUD，但是可以做 R（Read），所以如果在用代码进行数据入库的时候，我们建议使用 StreamLoad 的方式调用 Http API 来完成数据攒批写入，这个攒批写入的批次值最好在 5000-20000 条一批次，同时尽可能的保证数据入库的导入频次可以保证最小在 1s 以上（建议5-10s）。

3. 使用数据库连接池来管控连接，无论是创建还是复用以及销毁，对数据库本身的压力会减低很多，对业务方的使用体感会提升很多。

4. Doris 默认一个账号的最大并发度是 100，由 max_user_connectors参数来控制，这不代表 Doris 只能抗这么多并发，这只是为了防止一个用户用大量的链接把所有的资源都吃光（当然也有可能用少量的大查询就已经把集群资源吃光了，但这毕竟是少数情况），一个 FE 的默认最大链接是 1024，这两个数值都可以调整。

4. 并发查询量大的场景如何解决？

并发查询应当要分场景来讨论，在实际的业务场景里，一般会有两类场景：

1. 面向客户的查询场景，这类场景常见于广告主的报表查询、运营商的用户查询明细、电商店铺查询后台情况、保险员查询自己管理的保单信息等，整体的查询并发度会非常大，要求的延迟要在毫秒级或者亚秒级，但是一般不涉及关联查询，都是基于一个表的过滤、聚合、排序、分组等查询方式，这种场景，在 Doris 2.0 里有了专项的解决特性——单表高并发查询能力，底层实现是用行列混存的方式来加速点查效率，我们测试的结果非常喜人，在标准测试集群下（16C64G * 3），单 FE 的并发度可以达到上万 QPS。

2. 面向企业内部的查询场景，这类查询通常以固定报表、AdHoc 这两类为主，那么像这类查询，并发度要根据企业的 QPS、查询数据量、查询复杂度等综合考虑，包括需要的目标查询时延等，需要具体情况具体分析了。

5. 对于 replace 关键字，因官方文档所在同一批次无法保障有序性，可以 udf 介入吗，这个有什么好的建议吗

在 Unique Key 模型中，其实有专门来保障这个同一批次有序性的特性：Sequence 列。

这个 Sequence 列就是为了在同一导入批次中将数据根据 Sequence 列进行排序然后有序导入，无需 UDF 接入，一方面 UDF 介入只能在导入后进行重新排序，另一方面 UDF 本身的性能是要比 Local Native 要低的，所以还是建议使用专门来处理这个问题的 Sequence 列来解决这个问题。

6. FE 的 SQL 函数与 hive 和 presto 等的覆盖面和兼容性

当前 Doris 的函数已经在逐步丰富了，如果你有更多需要，可以在 github issue 区或者 Doris 论坛里发帖求助，我们会不定期的进行补充，同时也欢迎大家来贡献，一起共建社区。那么剩下的我觉得从三个方面来解答：

1. 常用的、主流的 Hive 函数，我们都做了大量的兼容和适配。

2. 我们当前的 JAVA_UDF 框架，是可以百分百兼容原 Hive UDF Jar 的，也就是改造零成本。

3. 关于 Presto 的联邦查询能力，这个在 Doris 1.2 开始已经做的很出色了，以 Catalog 为基准的联邦查询层的改造，让 Doris 有了很丰富的查询网关层统一的能力，而且性能在大部分场景下是优于 Presto 的，所以如果以平替 Presto 的角度来看这个覆盖面的话，Doris 是可以胜任的。

而且现在 Doris 已经支持了 Hudi、Paimon、Iceberg 等数据湖新势力，对 ES、MySQL、SQLServer、Hive、Oracle 等等，甚至对 Hana 这类数据库都已经有了支持，下一步会对更多的数据源进行兼容扩充，比如国内的一些 TP 库等，敬请期待。

7. flink- Doris -connnector 是否支持 source 和 sink，是否支持 just-once

Flink-Doris-Connector 当前是支持上游数据源 Sink 到 Doris 来的，但是从 Doris 通过 Binlog 这类机制做 Source 当前是无法支持的，不过已经在支持的路上了。

至于 just-once ，我认为这个的含义应该更多的是数据的一致性要求，在 Doris 的导入阶段，有两方面的保证，一个是两阶段提交保证一致性，二是由于单批次插入是事务性的，那么不会出现一部分数据写入可查了，另一部分数据没有写进来导致查询失败。

这里需要关注的点有两个：

1. 一个是 Doris 的写入时候默认是关闭严格模式的，而 Flink-Doris-Connector 底层用的是 StreamLoad，如果出现数据导入失败但是没有找到报错信息，可以先在 JOB 任务中打开严格模式然后再二次导入，查看具体 ErrorURL 中的报错信息来针对性解决。

2. 一个是在使用 FlinkCDC 做传输的时候，要注意设置 Checkpoint 值，除非有硬性的数据可见性要求，那最低建议设置到 1s，否则建议设置到 5-10s，避免背压以及 Doris Compaction 压力大等情况。

8. 系统监控项的要点：慢查询、资源消耗性查询、水位监控达到什么情况下需要考虑扩容

首先慢查询的查询时延，要业务方觉得OK，那才算OK，有些业务场景需要几十毫秒的延迟，那么在 QPS 增高 99th 时延无法满足用户诉求的情况下，就需要扩容了，而在比如 ETL/ELT 场景中，更多要看在并发调度执行的任务中，集群的整体运行负载在什么程度了，比如在整个集群资源峰值达 45% 的日常调度处理中，如果不改变当前的任务数量和任务脚本的话，那么其实还能再增个 150-200% 的数据来跑，这个情况下集群会把资源吃满，机器满负荷跑，但基本不会出现宕机情况，但是如果要保证整个集群的低故障率，那么就得扩容了。

9. Doris 是否支持 Flink、Spark、MR 等计算引擎直接使用数据分片分布式计算？

首先回答问题：不支持。

不支持的原因在于两点：

1. Doris 是一个完备的数据库，有自己的计算引擎和存储引擎，所以本身就不需要其他计算引擎来做分布式的计算，而且只有 Doris 的计算引擎和存储引擎，才更贴合 Doris 的数据存储格式和数据查询方式，这样整个查询速度才会更快，而且本身 Doris 就是 MPP 架构，现在 1.2 开始还全面实现了向量化，在查询性能上是不差于任何一个计算引擎的。

2. Doris 在 ETL 处理场景中，等规模的集群资源下，等规模的处理数据中，Doris 的处理速度是 Hive On MR 的 8-10 倍，是 Hive On Spark 的 2-3 倍，所以更无必要使用外部计算引擎了~

10. Doris 最常用的可视化数据迁移工具是什么？支持从 Doris 读入后 Sink 到几种数据源？或从几种数据源读入后写入 Doris ？

先回答个偏离题意的答案：不久的将来，最常用的可视化数据迁移工具是 X2Doris。

为什么回答要加一个不久的将来呢，因为这个工具我们内部还在进行打磨和开发，研发进度很快，同时已经有一大批协助我们测试和使用的用户反馈说，这玩意真好用，距离大家能来用，相信应该是不远的时间。至于数据流向，这个工具提供的是其他数据源流入 Doris，是可视化的，使用非常简单。

那么回到问题本身，当前呢？

当前如果是要做写入 Doris 的，那么 Flink-Doris-Connector 和 Spark-Doris-Connector 都可以，Datax 和 Airbyte 也都没问题，甚至一些商业化的迁移工具都已支持了 Doris，上游支持什么数据库，得看 FlinkCDC 或 Spark 能支持哪些，他们能支持的，Doris 就可以。

如果是要做 Doris 写出，那么现在最好的方案是使用 Spark-Doris-Connector，这种方式适合批量的做数据迁移，不适合增量的去做，再或者就是使用 JDBC 进行查询然后做下游数据库的存储，这种方式有比较大的不确定性，所以不建议。

小结

这次的问题还是比较难的，很多问题都要结合实际的业务场景定制化的来看，那么如果你有想量身定制的场景问题，可以加我微信来一起探讨，不过我可能会比较忙，如果有回答不及时的还望海涵~

老规矩，我的微信：fl_manyi