乐趣区

关于数据库设计:万亿数据秒级响应Apache-Doris-在360-数科实时数仓中的应用

jiezi

作者： 360 数科中间件团队

编辑整理： SelectDB

作为以人工智能驱动的金融科技平台，360 数科携手金融合作伙伴，为尚未享受到普惠金融服务的优质用户提供个性化的互联网生产金融产品，致力于成为连贯用户与金融合作伙伴的科技平台。360 数科旗下产品次要有 360 借条、360 小微贷、360 分期等，截止目前，已累计帮忙 141 家金融机构为 4300 万用户提供授信服务、为 2630 万用户提供借款服务、单季促成交易金额 1106.75 亿元。同时作为国内当先的信贷科技服务品牌，360 数科在三季度累计注册用户数首次冲破 2 亿。

业务需要

随着金融科技业务的一直倒退，对数据的安全性、准确性、实时性提出了更严格的要求，晚期 Clickhouse 集群用于剖析、标签业务场景，然而存在稳定性较低、运维简单和表关联查问较慢等问题，除此之外，咱们业务中有局部报表数据扩散存储在各类 DB 中，这也导致保护治理复杂度较高，亟需做出优化和重构。

零碎选型及比照

基于以上需要及痛点，咱们对实时数仓的选型指标提出了明确的需要，咱们心愿新的 MPP 数据库具备以下几个特点：

  • 数据写入性能高，查问秒级
  • 兼容规范的 SQL 协定
  • 表关联查问性能优良
  • 丰盛的数据模型
  • 运维复杂度低
  • 社区沉闷
  • 对商业敌对，无法律危险

2022 年 3 月开始，咱们对合乎以上特点的数据库 Apache Doris 开展了为期两个月的调研测试。以下是 Apache Doris 1.1.2 在各个方面的满足状况。

基于上述情况，咱们决定采纳 Apache Doris，除了能够满足上文提到的几个特点，咱们还思考以下几个方面：

  1. Clickhouse 因为 Join 查问限度、函数局限性、数据模型局限性（只插入，不更新）、以及可维护性较差等起因，更适宜日志存储以及保留以后存量业务，不满足咱们以后的业务需要。
  2. 目前 Apache Doris 社区沉闷、技术交换更多，SelectDB 针对社区有专职的技术支持团队，在应用过程中遇到问题均能疾速失去响应解决。
  3. Apache Doris 危险更小，对商业敌对，无法律危险。大数据畛域 Apache 基金会我的项目形成了事实标准，在 360 数科外部已有广泛应用，且 Apache 开源协定对商业敌对、无法律危险，不会有协定上的顾虑。

平台架构

360 数科大数据平台（毓数）提供一站式大数据管理、开发、剖析服务，笼罩大数据资产治理、数据开发及任务调度、自助剖析及可视化、对立指标治理等多个数据生命周期流程。在整个 OLAP 中，目前 Apache Doris 次要使用离线数仓剖析减速、自助 BI 报表等业务场景。

在引入 Doris 后，思考已有数据分析业务以及数据规模，Doris 集群将先同步局部业务上优先级更高的数据。通过上述架构图能够看到，依靠 Doris 弱小的查问性能，咱们将把 Doris 架设在 Hive 数仓的下层，为特定场景进行查问减速，这样的架构建设起来老本很低，只须要实现数据从 Hive 数仓到 Doris 集群的导入适配，因为 Doris 集群并没有产生任何新表，能够间接复用曾经建设好的数据血缘关系。

数据导入计划，咱们在调研了 Stream Load 和 Broker Load 之后，从导入性能、开发成本上进行了评估，在导入性能上，Broker Load 要比 Stream Load 稍逊一筹，而在开发成本上两种形式并没有显著的差别。而且对于大表的同步，Broker Load 的导入形式能够做到单表一次导入一个事务，而 Stream Load 在单表数据量超 10G 时则须要拆分后进行数据导入。因而数据导入抉择应用 Broker Load 来进行。

数仓即席查问计划，咱们自行开发的查问引擎反对多查问引擎动静切换的机制，通过辨认查问数据的元信息对本次查问做主动的查问引擎（Doris/Presto/Spark/Hive）路由和故障切换。

Doris 反对原生 MySql 协定，对规范 SQL 反对良好，使得 Doris 能够和一些 BI 工具（帆软、观远等）无缝联合，因而独自搭建了一个 Doris 报表剖析集群作为 BI 工具数据源。

利用实际

Doris 对 Hive 数仓的查问减速计划

在即席查问场景中，传统的查问引擎（Hive/Spark/Presto）越来越满足不了数据开发者、数据分析师对查问响应性能提出的高要求，动辄几十秒甚者分钟级的查问耗时极大的限度了相干场景的开发效率。

为进步查问性能，咱们通过架设的 Doris 数仓减速层来缩短查问耗时，目前咱们在不开启 Doris 缓存、不开启用物化视图等优化策略的状况下，命中 Doris 即席查问均匀耗时即可从几分钟缩短至 5 秒内。

将来咱们将通过剖析相干查问的特色，通过开启缓存、创立相干物化视图等策略来进一步优化 Doris 的查问性能。

实现 Doris 减速的外围是反对查问引擎动静切换，查问引擎动静切换的工作机制如下：

查问引擎会及时收集 Hive 和 Doris 的元信息，包含库、表、表字段、表行数等信息，在用户提交即席查问申请时，首先会解析出用户查问的表，并依照如下程序判断：

  • 查问的表是否已在 Doris 同步
  • Doris 表和 Hive 表构造是否雷同
  • Doris 表和 Hive 表表行数是否统一

如果以上要求均被满足，则会将该查问路由到 Doris，否则会顺次依照 Presto、Spark、Hive 的程序进行路由查问，当查问出现异常时，也会依照该程序顺次进行故障转移。

慢查问慢导入剖析

对于慢查问和慢导入，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 集群监控体系分为主机指标监控告警、日志告警和集群指标监控告警，总体监控体系如下。

主机指标监控 是基于 Open-Falcon 开发的监控告警平台，次要采集 Doris 集群节点的 CPU、IO、内存、磁盘等相干指标并进行监控告警。

集群指标监控 参考了 Doris 官网文档提供的基于 Prometheus 和 Grafana 和集群指标监控计划。

日志告警 依然是基于咱们的监控告警平台，次要用于监控 Doris 服务日志中容易辨认但其余监控形式老本较高的监控、告警场景，是其余两种监控的补充。通过日志监控告警，咱们可能精确辨认数据导入工作的失败起因并能进行及时的推送告诉。

问题排查和审计日志

为了及时排查一些极其的集群问题，上述针对 Doris 的监控体系建设依然是不够的。为了在集群 BE 出现异常宕机时疾速定位堆栈，须要在所有的 BE 节点开启 Core Dump。除此之外，审计日志在集群的日常运维中也施展了重要作用。

对于 Doris 集群的审计日志收集个别能够通过 2 种形式：

  • 第一种形式是通过日志收集组件、收集各个 FE 节点上的fe.audit.log
  • 第二种形式是通过装置 Doris 提供的 Auditloader 插件（下载 Doris 源码，该插件在 doris/fe_plugins/auditloader，具体应用文档可参考官网文档：审计日志插件）。

思考到第二种形式操作更简略，因而采纳此形式进行日志采集。不过在应用 Auditloader 插件的过程中，陆续发现和修复了一些插件问题，并向社区提交了 PR，与此同时，咱们定制开发了外部控制台，便于查看集群的同步工作状况，数据分布状况以及进行审计日志的检索。

审计日志为集群 BE 解体时具体 SQL 定位、客户端拜访统计、查问 SQL 耗时统计、拜访 SQL 特征分析等提供了具体的信息。例如，数据开发已经反馈查问 Doris SQL 失败，检索日志呈现了大量连接数超限的异样，咱们通过审计日志，迅速定位到了问题起因是因为上游导入工作流 Bug 在短时间内创立较多的数据库连贯。另外，对于已经应用的低版本 Doris 呈现数次 BE 异样宕机问题，咱们通过 gdb 调试工具定位到解体时 SQL 的 query_id 后，配合审计日志也能疾速的定位到导致解体的具体 SQL。

优化实际

数据导入实际和调优

初期数据源次要来自 Hive 数仓，因而大部分数据导入以 Broker Load 形式为主。大数据平台自助导入工作工作流适配了 Doris Broker Load 导入形式，数据开发零代码——通过简略的勾选配置即可实现自助的 Doris 数据导入工作流创立。

而在 Broker Load 的应用过程中，咱们也陆续遇到了一些问题，这里拿出几个典型的问题和一些调优教训来分享。

在 Broker Load 导入时遇到的问题：

  1. 因表分桶数设置过少造成 Broker Load 导入失败，具体表现为导入工作失败且异样信息为：
tablet writer write failed, tablet_id=xxx, txn_id=xxx, err=-238

咱们揣测造成 -238 谬误的起因可能是分桶设置太少，接着咱们通过 BE 节点的挂载数据来查看单个 Tablet 下的文件大小，咱们发现单个 Tablet 的文件占用空间远大于官网举荐的 10GB 下限范畴，这也证实了咱们的揣测正确，因而咱们通过适当进步 Doris 表的分桶数，使得这个问题有了较大的缓解。

顺便说一下，如果呈现 -235（旧版本是 -215）异样，个别是因为 Compaction 过慢导致 Tablet 版本沉积超过限度，这个时候通过 Grafana 看到 BE Compaction Score 在导入前后有显著的稳定，而且绝对值很高。如果遇到此问题能够参阅 ApacheDoris 公众号文章：Doris 最佳实际 -Compaction 调优(3) 对 Compaction 过程进行调优。

  1. 因 Hive 表字段变更导致 Broker Load 导入失败：

Hive 表在应用过程中会有一些 DDL 的执行，从而导致表字段新增，咱们数仓的 Hive 表均应用 ORC 格局存储，那么就会导致 Hive 表中局部历史分区的 ORC 文件中字段信息缺失（缺失新增字段），而新分区的 ORC 文件中字段是失常的，这个时候如果对历史数据从新导入，就会有上面的异样信息：

detailMessage: ParseError : Invalid column selected xxx

在浏览了 Broker Load 相干代码后确认了问题起因：在一次 Broker Load 导入过程中，导入工作的字段解析器会读取一个 ORC 文件头解析字段信息，但解析器只会解析一次，如果一次导入过程中同时有新、历史分区的 ORC 文件，那么就可能导致工作失败。

修复的办法也很简略，只需针对每个 ORC 文件从新解析一次文件头的字段信息即可。在理解问题起因及剖析解决思路后，咱们也和社区的同学一起修复了这个问题并提交了相干 PR。

  1. 遇到空 ORC 文件时 Broker Load 导入失败：

这个问题的谬误体现和问题 2 比拟相似，具体起因是 Broker Load 导入过程没有对 ORC 文件做判空，遇到空 ORC 文件仍会尝试解析 ORC 文件字段信息导致报错，咱们把这个问题反馈给社区后，社区的同学很快修复了该问题。

  1. Broker Load 导入工作呈现 Broker list path exception. path=hdfs:xxx

创立 Broker Load 工作，应用 Kerberos 认证拜访 HDFS 的 Hive 文件导入数据，Hive 文件门路中分区和下一级目录应用通配符 *，拜访所有分区所有文件，工作提交后隔 40 多秒呈现如下的谬误：

type:ETL_RUN_FAIL; msg:errCode = 2, detailMessage = Broker list path exception. path=hdfs:xxx

在浏览了 Broker Load 的拜访 HDFS 相干代码后确认了问题起因，Broker Load 调用 HDFS 的 LS、DU 办法时会获取文件目录信息，因为门路下的文件过多导致耗时会超过 45 秒，而 Thrift 设置的 Socket 申请超时默认小于 40 秒，所以呈现了上述的 RPC 异样，问题反馈社区后，对 FE 减少了配置参数broker_timeout_ms，设置为 90 秒后解决问题。

对于 Broker Load 的导入性能调优策略

咱们针对 Broker Load 导入调优的次要方向在确保 Doris 集群不承压的状况下尽可能进步导入并发度，上面依据 2 个典型的案例来阐明：

  1. 局部 pdi/pda 表因为数据规模太大导致全量导入耗时过长 （导入数据源是 Hive 分区表）

局部 pdi/pda 表数据规模在 T 级别，在进行全量导入时，如果只提交一个 Broker Load Job，将因为导入工作的并发不够，导致导入耗时达到 5-6 小时。针对此问题，咱们能够对导入工作进行 Job 拆分，在大数据平台也适配这种场景，反对工作的主动拆分和重试机制，具体的拆分形式如下图：

不过要留神的是，拆分后可能会对集群有较高的写入压力，要及时监控导入工作和集群的状态，特地针对 -235 的状况可能须要进行 Compaction 调优。

  1. 局部 ads 表因为数据规模太大导致全量导入耗时过长（导入数据源是 Hive 非分区表）

数据开发对局部报表的同步时效提出了很高的要求，咱们在针对性的优化表同步时效时，发现一些表导入耗时较长，但通过集群监控体系发现相干表同步期间，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 过程中遇到的一些疑难问题，官网也能够及时进行响应、解决。

将来布局

在近期的布局中，咱们心愿 Doris 能撑持更多的业务场景、施展更大价值，例如基于 Doris 建设实时数仓、基于 Doris 重构用户行为画像、Doris HIVE 表面个性等。同时咱们打算通过剖析用户的查问 SQL 特色，联合 Doris 的查问缓存和物化视图个性，进一步晋升查问效率。通过开发集群探查工具，实时探测集群数据表的数据分布状况，比方 Tablet 有没有过大，Tablet 数据分布是否平均等，综合探查集群的运行状况并主动给出优化倡议。

目前咱们应用了 Doris 有大半年工夫，在这半年期间始终放弃和社区同学进行交换（提交 Issues 和 PRs），非常感谢 SelectDB 团队始终以来对咱们的技术支持。最初祝 Apache Doris 越来越好，为根底软件建设添砖加瓦。

— End —

最初，欢送更多的开源技术爱好者退出 Apache Doris 社区，携手成长，共建社区生态。Apache Doris 社区以后已包容了上万名开发者和使用者，承载了 30+ 交换社群，如果你也是 Apache Doris 的爱好者，扫码退出 Apache Doris 社区用户交换群，在这里你能够取得：

  • 业余全职团队技术支持
  • 间接和社区专家交换，获取收费且业余回复
  • 意识不同行业的开发者，播种常识以及单干机会
  • Apache Doris 最新版本优先体验权
  • 获取一手干货和资讯以及流动优先参与权
退出移动版