数据开发对部分报表的同步时效提出了很高的要求

数据开发对部分报表的同步时效提出了很高的要求，我们在针对性的优化表同步时效时，发现一些表导入耗时较长，但通过集群监控体系发现相关表同步期间，BE、FE 节点的 CPU、内存、磁盘 IO 、网卡 IO 并没有达到瓶颈，集群的 Compaction Score 在此期间也一直稳定在低位，且整个同步过程同步任务均未出现 - 235、-238 等相关的错误，我们推测瓶颈可能还是在导入任务的并发程度上。

因为有些表在 Hive 数仓是非分区的表，所以第 1 种通过划分分区范围拆分多个导入 Job 的方式就行不通了，理论上仍然可以通过划分不同的 HDFS 文件来拆分 Job，但是这种方式在毓数大数据平台还需要进一步去适配，所以我们还是优先考虑通过调整集群配置的方式彻底解决此问题：

首先可以通过适当调高 FE 的 max_broker_concurrency 去提高 Scan HDFS 文件阶段的并发度（最高调高至 BE 节点数），而对于 Table Sink 阶段，可通过调高 FE 的 default_load_parallelism（设置 fe.conf，可调整到 BE 节点数）和 send_batch_parallelism 参数（ SQL Session 执行 set global send_batch_parallelism=5 或在提交 Broker Load 中的 PROPERTIES 中指定，最高调整到 5，如果超过此值，需要同步调整 be.conf 的 max_send_batch_parallelism_per_job 参数），提高该阶段并发度。通过提高 Broker Load Job 各阶段导入的并发度，相关报表的同步时效显著提升，这里我们选取 5 张典型表为例，优化前后的同步时效表现如下：

双机房容灾建设

为了保障 Doris 集群的可用性，我们需要为 Doris 集群提供双机房容灾能力。Doris 目前虽然可以通过不同的 Tag 将 BE 分组部署在多个机房，但是无法解决机房出现问题时的 FE 可用性问题。经过方案调研分析，我们决定通过自行开发 Replicator 主从同步插件去实施双机房容灾建设，具体的架构如下：

通过在主集群安装 Replicator 插件，Replicator 插件会拦截并解析主集群执行的全量 SQL，然后经过过滤操作，筛选涉及库、表结构变更和数据增、删、改相关的 SQL，并将相关 SQL（部分 SQL 需要改写）发送到备集群进行重放。除此之外，我们在 Doris 控制台开发了 Validator 数据校验程序，定期校验主备集群间的数据结构差异和数据差异并上报，在主集群因各种问题导致不可用时，直接通过切换 DNS 解析地址到备集群 LVS 地址完成主备集群的切换。

总结规划

效果总结

从 2022 年 3 月份开始进行对实时数仓沟通进行调研，7 月份正式上线生产，集群数据规模快速增长。目前，生产环境共有 2 个集群，数百张表，几十 TB 数据，每日有数百个同步工作流在运行，几十亿规模的数据新增 / 更新。在此规模下，Doris 对业务支持良好，稳定运行。

• Doris 集群架构清晰简单，不依赖其他组件，数据模型简单，数据导入方式多样化且适配成本很低，使得我们可以快速完成前期的调研测试并在短时间内上线实施。

• Doris 集群作为目前公司 BI 工具的重要数据源，承载了相当一部分的报表分析业务，极大加速了报表分析的时效性。Doris 上线 3 + 月的时间，已经承载了小部分即席查询场景，大大缩短了相关查询的耗时。

• Doris 具有完善的监控机制和审计机制，极大的降低了我们的运维工作

• Doris 社区十分活跃，在我们使用 Doris 过程中遇到的一些疑难问题，官方也可以及时进行响应、处理。

未来规划