作者： 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 在360数科实时数仓中的应用

根据上述状况，咱们决议采用 Apache Doris，除了能够满意上文提到的几个特色，咱们还考虑以下几个方面：

  1. Clickhouse 因为 Join 查询约束、函数局限性、数据模型局限性（只插入，不更新）、以及可维护性较差等原因，更适合日志存储以及保留当时存量事务，不满意咱们当时的事务需求。
  2. 现在Apache Doris 社区活跃、技术沟通更多，SelectDB 针对社区有专职的技术支撑团队，在运用过程中遇到问题均能快速得到呼应处理。
  3. Apache Doris 危险更小，对商业友爱，无法律危险。大数据领域 Apache 基金会项目构成了事实标准，在 360数科内部已有广泛运用，且Apache 开源协议对商业友爱、无法律危险，不会有协议上的顾虑。

渠道架构

360数科大数据渠道（毓数）供给一站式大数据办理、开发、剖析服务，掩盖大数据资产办理、数据开发及使命调度、自助剖析及可视化、共同目标办理等多个数据生命周期流程。在整个 OLAP 中，现在 Apache Doris 首要运用离线数仓剖析加快、自助 BI 报表等事务场景。

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

在引进 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 的查询功能。

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

完结 Doris 加快的核心是支撑查询引擎动态切换，查询引擎动态切换的作业机制如下：

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

查询引擎会及时搜集 Hive 和 Doris 的元信息，包括库、表、表字段、表行数等信息，在用户提交即席查询恳求时，首要会解分出用户查询的表，并按照如下次序判断：

  • 查询的表是否已在 Doris 同步
  • Doris 表和 Hive 表结构是否相同
  • Doris 表和 Hive 表表行数是否共同

假如以上要求均被满意，则会将该查询路由到 Doris，否则会顺次按照 Presto、Spark、Hive 的次序进行路由查询，当查询呈现反常时，也会按照该次序顺次进行故障转移。

慢查询慢导入剖析

关于慢查询和慢导入，Doris 供给了完善的 Profile 机制，在了解相关技术细节后，咱们在线上集群敞开了 Profile 搜集，经过调度使命定时搜集慢查询、慢导入的 Profile 信息并落库。

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

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 集群监控系统分为主机目标监控告警、日志告警和集群目标监控告警，整体监控系统如下。

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

主机目标监控是根据 Open-Falcon 开发的监控告警渠道，首要采集 Doris 集群节点的 CPU、IO、内存、磁盘等相关目标并进行监控告警。

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

集群目标监控参考了 Doris 官方文档供给的根据 Prometheus 和 Grafana 和集群目标监控方案。

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

日志告警依然是根据咱们的监控告警渠道，首要用于监控 Doris 服务日志中简略辨认但其他监控办法本钱较高的监控、告警场景，是其他两种监控的补充。经过日志监控告警，咱们能够精确辨认数据导入使命的失利原因并能进行及时的推送告诉。

问题排查和审计日志

为了及时排查一些极端的集群问题，上述针对 Doris 的监控系统建造依然是不行的。为了在集群 BE 呈现反常宕机时快速定位仓库，需求在一切的 BE 节点敞开 Core Dump。除此之外，审计日志在集群的日常运维中也发挥了重要作用。

关于 Doris 集群的审计日志搜集一般能够经过 2 种办法：

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

考虑到第二种办法操作更简略，因而采用此办法进行日志采集。不过在运用 Auditloader 插件的过程中，连续发现和修正了一些插件问题，并向社区提交了 PR，与此一同，咱们定制开发了内部控制台，便于查看集群的同步使命状况，数据散布状况以及进行审计日志的检索。

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

审计日志为集群 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 拆分，在大数据渠道也适配这种场景，支撑使命的主动拆分和重试机制，具体的拆分办法如下图：

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

不过要注意的是，拆分后或许会对集群有较高的写入压力，要及时监控导入使命和集群的状态，特别针对 -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 张典型表为例，优化前后的同步时效体现如下：

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

双机房容灾建造

为了保证 Doris 集群的可用性，咱们需求为 Doris 集群供给双机房容灾能力。Doris 现在虽然能够经过不同的 Tag 将 BE 分组布置在多个机房，可是无法处理机房呈现问题时的 FE 可用性问题。经过方案调研剖析，咱们决议经过自行开发 Replicator 主从同步插件去施行双机房容灾建造，具体的架构如下：

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

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

总结规划

作用总结

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

万亿数据秒级响应，Apache Doris 在360数科实时数仓中的应用

  • Doris 集群架构清晰简略，不依赖其他组件，数据模型简略，数据导入办法多样化且适配本钱很低，使得咱们能够快速完结前期的调研测验并在短时间内上线施行。

  • Doris 集群作为现在公司 BI 东西的重要数据源，承载了相当一部分的报表剖析事务，极大加快了报表剖析的时效性。Doris 上线 3+月的时间，现已承载了小部分即席查询场景，大大缩短了相关查询的耗时。

  • Doris 具有完善的监控机制和审计机制，极大的下降了咱们的运维作业

  • Doris 社区非常活跃，在咱们运用 Doris 过程中遇到的一些疑难问题，官方也能够及时进行呼应、处理。

未来规划

在近期的规划中，咱们期望 Doris 能支撑更多的事务场景、发挥更大价值，例如根据 Doris 建立实时数仓、根据 Doris 重构用户行为画像、Doris HIVE 外表特性等。一同咱们方案经过剖析用户的查询 SQL 特征，结合 Doris 的查询缓存和物化视图特性，进一步提高查询功率。经过开发集群探查东西，实时勘探集群数据表的数据散布状况，比如 Tablet 有没有过大，Tablet 数据散布是否均匀等，归纳探查集群的运转状况并主动给出优化主张。

现在咱们运用了 Doris 有大半年时间，在这半年期间一向坚持和社区同学进行沟通（提交 Issues 和 PRs），非常感谢 SelectDB 团队一向以来对咱们的技术支撑。最终祝 Apache Doris 越来越好，为基础软件建造添砖加瓦。