Doris 提供了完善的 Profile 机制

对于慢查询和慢导入,Doris 提供了完善的 Profile 机制,在了解相关技术细节后,我们在线上集群开启了 Profile 收集,通过调度任务定时收集慢查询、慢导入的 Profile 信息并落库。

Doris 提供的 Profile 信息非常详细,例如 OLAP_SCAN_NODE 提供了原始的扫描行数,各个索引的过滤行数,每个 Instance 的 EXCHANGE_NODE 提供了接收的数据总行数和接收的数据量大小。这些信息为查询调优提供了详细的依据,我们在使用过程中针对快速定位查询性能的瓶颈进行了优化,取得了良好的效果。

建表规范

在我们的使用场景中,有下列类型的表:

  • pda 表:每日全量更新,即每日分区存储全量快照数据

  • pdi 表: 每日增量更新,即每日分区存储增量数据

  • a 表:全量不分区表

  • s 表:静态非每日更新数据

由于当前 Doris 集群中所有的表都是基于 Hive 数仓中各层级的表同步而来,因此目前仅使用了 Duplcate 模型和 Unique 模型,对于 pda、pdi 和 a 表,为了降低 Doris 表的分区数,减轻 FE 元数据管理压力,我们在建 Doris 表时均启用了根据日期划分的动态分区特性,较久远的历史数据我们按年、月的维度分区归档,近期的数据按日、小时分区,未来我们计划通过程序自动识别完成历史分区的归档合并。

对于 pda 表使用场景,pda 表需要每日同步全量数据,我们采用了 Duplicate 模型,不考虑使用 Unique 模型数据去重的原因是 Doris 的导入模型本身就提供了基于任务 Label 的数据一致性保证,同步时一次调度周期的 pda 表的一个分区的导入任务能产生唯一且不变的 Label,因此我们可以保证即使错误执行了多次,该分区的数据仍然不会重复。另外,因为 Duplicate 模型相比于 Unique 模型,在导入和查询阶段均不会做预聚合去重,所以可以一定程度上加速导入和查询的性能。

对于 pdi 表使用场景,因在实际使用中 pdi 表存在少数对历史数据的部分更新场景(绝大部分是数据更新场景,基本没有数据删除场景),考虑到 Doris 数据表的分区可用性,我们采用了 Unique 模型,这样在更新历史分区的数据时不必做重建分区操作。

对于 a 表使用场景,因业务上可以接受短时间数据不可用情况,我们启用了动态分区,在做数据导入时,每次导入都会先删除历史分区,然后将全量数据导入今天的分区内,这样做的考虑是杜绝重建表操作,且实施成本相对比较低,因此我们没有采取动态更新视图绑定当日分区的方案。

在 Doris 之前的版本中,尚未实现 Hive 元数据变更同步和管理功能,为了提高效率开发了 Doris 建表工具,我们通过选择和配置数仓集群、Hive 表名、数据模型、Bucket 数量等参数,自动关联 Hive 表,解析表字段并生成对应的建表语句。经过与社区沟通得知,最近即将发布的 1.2 新版本中已经实现 Multi Catalog,支持 Hive 元数据的对接和 Schema 的自动同步,可以极大程度上减少这一部分的工作。

监控体系

当前 Doris 集群监控体系分为主机指标监控告警、日志告警和集群指标监控告警,总体监控体系如下。

你可能感兴趣的:(大数据,数据库,数据挖掘)