关于数据湖:杭银消金基于-Apache-Doris-的统一数据查询网关改造

导读： 随着业务量快速增长，数据规模的不断扩大，杭银消金晚期的大数据平台在应答实时性更强、复杂度更高的的业务需要时存在瓶颈。为了更好的应答将来的数据规模增长，杭银消金于 2022 年 10 月正式引入 Apache Doris 1.2 对现有的风控数据集市进行了降级革新，利用 Multi Catalog 性能对立了 ES、Hive、GP 等数据源进口，实现了联邦查问，为将来对立数据查问网关奠定了根底；同时，基于 Apache Doris 高性能、简略易用、部署成本低等诸多劣势，也使得各大业务场景的查问剖析响应实现了从分钟级到秒级的逾越。

作者|杭银消金大数据团队周其进，唐海定，姚锦权

杭银生产金融股份有限公司，成立于 2015 年 12 月，是杭州银行牵头组建的浙江省首家持牌生产金融公司，通过这几年的倒退，在 2022 年底资产规模冲破 400 亿，服务客户数超千万。公司秉承“数字普惠金融”初心，保持服务传统金融笼罩不充沛的、具备消费信贷需要的客户群体，以“数据、场景、风控、技术”为外围，依靠大数据、人工智能、云计算等互联网科技，为全国消费者提供业余、高效、便捷、可信赖的金融服务。

杭银消金业务模式是线上业务联合线下业务的双引擎驱动模式。为更好的服务用户，使用数据驱动实现精细化治理，基于以后业务模式衍生出了四大类的业务数据需要：

预警类：实现业务流量监控，次要是对信贷流程的用户数量与金额进行实时监控，呈现问题主动告警。
剖析类：反对查问统计与长期取数，对信贷各环节进行剖析，对审批、授信、支用等环节的用户数量与额度状况查问剖析。
看板类：打造业务实时驾驶舱与 T+1 业务看板，提供外部管理层与经营部门应用，更好辅助治理进行决策。
建模类：反对多维模型变量的建模，通过算法模型回溯用户的金融体现，晋升审批、授信、支用等环节的模型能力。

为满足以上需要，咱们采纳 Greenplum + CDH 交融的架构体系创立了大数据平台 1.0，如下图所示，大数据平台的数据源均来自于业务零碎，咱们能够从数据源的 3 个流向登程，理解大数据平台的组成及分工：

业务零碎的外围零碎数据通过 CloudCanal 实时同步进入 Greenplum 数仓进行数据实时剖析，为 BI 报表，数据大屏等利用提供服务，局部数据进入风控集市 Hive 中，提供查问剖析和建模服务。
业务零碎的实时数据推送到 Kafka 音讯队列，经 Flink 实时生产写入 ES，通过风控变量提供数据服务，而 ES 中的局部数据也能够流入 Hive 中，进行相干剖析解决。
业务零碎的风控数据会落在 MongoDB，通过离线同步进入风控集市 Hive，Hive 数仓撑持了查问平台和建模平台，提供风控剖析和建模服务。

咱们将 ES 和 Hive 独特组成了风控数据集市，从上述介绍也可知，四大类的业务需要根本都是由风控数据集市来满足的，因而咱们后续的革新降级次要基于风控数据集市来进行。在这之前，咱们先理解一下风控数据集市 1.0 是如何来运行的。

风控数据集市 1.0

风控数据集市原有架构是基于 CDH 搭建的，由实时写入和离线统计分析两局部组成，整个架构蕴含了 ES、Hive、Greenplum 等外围组件，风控数据集市的数据源次要有三种：通过 Greenplum 数仓同步的业务零碎数据、通过 MongoDB 同步的风控决策数据，以及通过 ES 写入的实时风控变量数据。

实时流数据： 采纳了 Kafka + Flink + ES 的实时流解决形式，利用 Flink 对 Kafka 的实时数据进行荡涤，实时写入 ES，并对局部后果进行汇总计算，通过接口提供给风控决策应用。

离线风控数据： 采纳基于 CDH 的计划实现，通过 Sqoop 离线同步外围数仓 GP 上的数据，联合实时数据与落在 MongoDB 上的三方数据，经数据荡涤后对立汇总到 Hive 数仓进行日常的跑批与查问剖析。

需要满足状况：

在大数据平台 1.0 的的反对下，咱们的业务需要失去了初步的实现：

预警类：基于 ES + Hive 的表面查问，实现了实时业务流量监控；
剖析类：基于 Hive 实现数据查问剖析和长期取数；
看板类：基于 Tableau +Hive 搭建了业务管理驾驶舱以及 T +1 业务看板；
建模类：基于 Spark+Hive 实现了多维模型变量的建模剖析；

受限于 Hive 的执行效率，以上需要均在分钟级别返回后果，仅能够满足咱们最根本的诉求，而面对秒级甚至毫秒级的剖析场景，Hive 则稍显吃力。

存在的问题：

单表宽度过大，影响查问性能。风控数据集市的上游业务次要以规定引擎与实时风控服务为主，因规定引擎的特殊性，公司在数据变量衍生方面资源投入较多，某些维度上的衍生变量会达到几千甚至上万的规模，这将导致 Hive 中存储的数据表字段十分多，局部常常应用的大宽表字段数量甚至超过上千，过宽的大宽表十分影响理论应用中查问性能。
数据规模宏大，保护老本高。 目前 Hive 上的风控数据集市曾经有存量数据在百 T 以上，面对如此宏大的数据规模，应用表面的形式进行保护老本十分高，数据的接入也成为一大难题。
接口服务不稳固。 由风控数据集市离线跑批产生的变量指标还兼顾为其余业务利用提供数据服务的职责，目前 Hive 离线跑批后的后果会定时推送到 ES 集群（每天更新的数据集比拟宏大，接口调用具备时效性），推送时会因为 IO 过高触发 ES 集群的 GC 抖动，导致接口服务不稳固。

除此之外，风控分析师与建模人员个别通过 Hive & Spark 形式进行数据分析建模，这导致随着业务规模的进一步增大，T+1 跑批与日常剖析的效率越来越低，风控数据集市革新降级的需要越发强烈。

基于业务对架构提出的更高要求，咱们冀望引入一款强劲的 OLAP 引擎来改善架构，因而咱们于 2022 年 9 月份对 ClickHouse 和 Apache Doris 进行了调研，调研中发现 Apache Doris 具备高性能、简略易用、实现成本低等诸多劣势，而且 Apache Doris 1.2 版本十分合乎咱们的诉求，起因如下：

宽表查问性能优异：从官网颁布的测试后果来看，1.2 Preview 版本在 SSB-Flat 宽表场景上绝对 1.1.3 版本整体性能晋升了近 4 倍、绝对于 0.15.0 版本性能晋升了近 10 倍，在 TPC-H 多表关联场景上较 1.1.3 版本上有近 3 倍的晋升、较 0.15.0 版本性能晋升了 11 倍以上，多个场景性能失去飞跃性晋升。

便捷的数据接入框架以及联邦数据分析能力： Apache Doris 1.2 版本推出的 Multi Catalog 性能能够构建欠缺可扩大的数据源连贯框架，便于疾速接入多类数据源，提供基于各种异构数据源的联邦查问和写入能力。 目前 Multi-Catalog 曾经反对了 Hive、Iceberg、Hudi 等数据湖以及 MySQL、Elasticsearch、Greenplum 等数据库，全面笼罩了咱们现有的组件栈，基于此能力有心愿通过 Apache Doris 来打造对立数据查问网关。

生态丰盛： 反对 Spark Doris Connector、Flink Doris Connector，不便离线与实时数据的解决，缩短了数据处理链路消耗的工夫。

社区沉闷： Apache Doris 社区十分沉闷，响应迅速，并且 SelectDB 为社区提供了一支专职的工程师团队，为用户提供技术支持服务。

风控数据集市 2.0

基于对 Apache Doris 的初步的理解与验证，22 年 10 月在社区的反对下咱们正式引入 Apache Doris 1.2.0 Preview 版本作为风控数据集市的外围组件，Apache Doris 的 Multi Catalog 性能助力大数据平台对立了 ES、Hive、Greenplum 等数据源进口，通过 Hive Catalog 和 ES Catalog 实现了对 Hive & ES 等多数据源的联邦查问，并且反对 Spark-Doris-Connector，能够实现数据 Hive 与 Doris 的双向流动，与现有建模剖析体系完满集成，在短期内实现了性能的疾速晋升。

大数据平台 2.0

风控数据集市调整优化之后，大数据平台架构也相应的产生了变动，如下图所示，仅通过 Doris 一个组件即可为数据服务、剖析平台、建模平台提供数据服务。

在最后进行联调适配的时候，Doris 社区和 SelectDB 反对团队针对咱们提出的问题和纳闷始终放弃高效的反馈效率，给于踊跃的帮忙和反对，疾速帮忙咱们解决在生产上遇到的问题。

需要实现状况：

在大数据平台 2.0 的加持下，业务需要实现的形式也产生了变更，次要变动如下所示

预警类：基于 ES Catalog+ Doris 实现了对实时数据的查问剖析。在架构 1.0 中，实时数据落在 ES 集群上，通过 Hive 表面进行查问剖析，查问后果以分钟级别返回；而在 Doris 1.2 集成之后，应用 ES Catalog 拜访 ES，能够实现对 ES 数据秒级统计分析。
剖析类：基于 Hive Catalog + Doris 实现了对现有风控数据集市的疾速查问。目前 Hive 数据集市存量表在两万张左右，如果通过间接创立 Hive 内部表的形式，表构造映射关系的保护难度与数据同步老本使这一形式简直不可能实现。而 Doris 1.2 的 Multi Catalog 性能则完满解决了这个问题，只须要创立一个 Hive Catalog，就能对现有风控数据集市进行查问剖析，既能晋升查问性能，还缩小了日常查问剖析对跑批工作的资源影响。
看板类：基于 Tableau + Doris 聚合展现业务实时驾驶舱和 T+1 业务看板，最后应用 Hive 时，报表查问须要几分钟能力返回后果，而 Apache Doris 则是秒级甚至是毫秒级的响应速度。
建模类：基于 Spark+Doris 进行聚合建模。利用 Doris1.2 的 Spark-Doris-Connector 功能，实现了 Hive 与 Doris 数据双向同步，满足了 Spark 建模平台的性能复用。同时减少了 Doris 数据源，根底数据查问剖析的效率失去了显著晋升，建模剖析能力的也失去了加强。

在 Apache Doris 引入之后，以上四个业务场景的查问耗时根本都实现了从分钟级到秒级响应的逾越，性能晋升非常微小。

生产环境集群监控

为了疾速验证新版本的成果，咱们在生产环境上搭建了两个集群，目前生产集群的配置是 4 个 FE + 8 个 BE，单个节点是配置为 64 核 + 256G+4T，备用集群为 4 个 FE + 4 个 BE 的配置，单个节点配置保持一致。

集群监控如下图所示：

能够看出，Apache Doris 1.2 的查问效率十分高，原打算至多要上 10 个节点，而在理论应用下来，咱们发现以后次要应用的场景均是以 Catalog 的形式查问，因而集群规模能够绝对较小就能够疾速上线，也不会毁坏以后的零碎架构，兼容性十分好。

前段时间，Apache Doris 1.2.2 版本曾经公布，为了更好的撑持应用服务，咱们应用 Apache Doris 1.2.2 与 DolphinScheduler 3.1.4 调度器、SeaTunnel 2.1.3 数据同步平台等开源软件实现了集成，以便于数据定时从 Hive 抽取到 Doris 中。整体的数据集成计划如下：

在以后的硬件配置下，数据同步采纳的是 DolphinScheduler 的 Shell 脚本模式，定时调起 SeaTunnel 的脚本，数据同步工作的配置文件如下：

 env{
  spark.app.name = "hive2doris-template"
  spark.executor.instances = 10
  spark.executor.cores = 5
  spark.executor.memory = "20g"
}
spark {spark.sql.catalogImplementation = "hive"}
source {
  hive {pre_sql = "select * from ods.demo_tbl where dt='2023-03-09'"result_table_name ="ods_demo_tbl"}
}
 
transform {
}
 
sink {
  doris {
      fenodes = "192.168.0.10:8030,192.168.0.11:8030,192.168.0.12:8030,192.168.0.13:8030"
      user = root
      password = "XXX"
      database = ods
      table = ods_demo_tbl
      batch_size = 500000
      max_retries = 1
      interval = 10000
      doris.column_separator = "\t"
    }
}

该计划胜利施行后，资源占用、计算内存占用有了显著的升高，查问性能、导入性能有了大幅晋升：

存储老本升高

应用前：Hive 原始表蕴含 500 个字段，单个分区数据量为 1.5 亿 / 天，在 HDFS 上占用约 810G 的空间。

应用后：咱们通过 SeaTunnel 调起 Spark on YARN 的形式进行数据同步，能够在 40 分钟左右 实现数据同步，同步后数据占用 270G 空间，存储资源仅占之前的 1/3。

计算内存占用升高，性能晋升显著

应用前：上述表在 Hive 上进行 Group By 时，占用 YARN 资源 720 核 1.44T 内存，须要 162 秒 才可返回后果；

应用后：

通过 Doris 调用 Hive Catalog 进行聚合查问，在设置 set exec_mem_limit=16G 状况下用时 58.531 秒，查问耗时较之前缩小了近 2/3；
在同等条件下，在 Doris 中执行雷同的的操作能够在 0.828 秒 就能返回查问后果，性能增幅微小。

具体成果如下：

（1）Hive 查问语句，用时 162 秒。

select count(*),product_no   FROM ods.demo_tbl where dt='2023-03-09'
group by product_no;

（2）Doris 上 Hive Catalog 查问语句，用时 58.531 秒。

set exec_mem_limit=16G；select count(*),product_no   FROM hive.ods.demo_tbl where dt='2023-03-09'
group by product_no;

（3）Doris 上本地表查问语句，仅用时 0.828 秒。

select count(*),product_no   FROM ods.demo_tbl where dt='2023-03-09'
group by product_no;

导入性能晋升

应用前：Hive 原始表蕴含 40 个字段，单个分区数据量 11 亿 / 天，在 HDFS 上占用约 806G 的空间

应用后：通过 SeaTunnel 调起 Spark on YARN 形式进行数据同步，能够在 11 分钟左右实现数据同步，即 1 分钟同步约一亿条数据，同步后占用 378G 空间。

能够看出，在数据导入性能的晋升的同时，资源也有了较大的节俭，次要得益于对以下几个参数进行了调整：

push_write_mbytes_per_sec：BE 磁盘写入限速，300M

push_worker_count_high_priority: 同时执行的 push 工作个数，15

push_worker_count_normal_priority: 同时执行的 push 工作个数，15

（1）对立数据源进口，查问效率显著晋升

风控数据集市采纳的是异构存储的形式来存储数据，Apache Doris 的 Multi Catalog 性能胜利对立了 ES、Hive、GP 等数据源进口，实现了联邦查问。同时，Doris 自身具备存储能力，可反对其余数据源中的数据通过表面插入内容的形式疾速进行数据同步，真正实现了数据门户。此外，Apache Doris 可反对聚合查问，在向量化引擎的加持下，查问效率失去显著晋升。

（2） Hive 工作拆分，晋升集群资源利用率

咱们将原有的 Hive 跑批工作跟日常的查问统计进行了隔离，以晋升集群资源的利用效率。目前 YARN 集群上的工作数量是几千的规模，跑批工作占比约 60%，长期查问剖析占比 40%，因为资源限度导致日常跑批工作常常会因为资源期待而延误，长期剖析也因资源未及时调配而导致工作无奈实现。当部署了 Doris 1.2 之后，对资源进行了划分，齐全解脱 YARN 集群的资源限度，跑批与日常的查问统计均有了显著的改善，根本能够在秒级失去剖析后果，同时也加重了数据分析师的工作压力，晋升了用户对平台的满意度。

（3）晋升了数据接口的稳定性，数据写入性能大幅晋升

之前数据接口是基于 ES 集群的，当进行大批量离线数据推送时会导致 ES 集群的 GC 抖动，影响了接口稳定性，通过调整之后，咱们将接口服务的数据集存储在 Doris 上，Doris 节点并未呈现抖动，实现数据疾速写入，胜利晋升了接口的稳定性，同时 Doris 查问在数据写入时影响较小，数据写入性能较之前也有了十分大的晋升，千万级别的数据可在十分钟内推送胜利。

（4）Doris 生态丰盛，迁徙不便老本较低。

Spark-Doris-Connector 在过渡期为咱们加重了不少的压力，当数据在 Hive 与 Doris 共存时，局部 Doris 剖析后果通过 Spark 回写到 Hive 十分不便，当 Spark 调用 Doris 时只须要进行简略革新就能实现原有脚本的复用，迁徙不便、老本较低。

（5）反对横向热部署，集群扩容、运维简略。

Apache Doris 反对横向热部署，集群扩容不便，节点重启能够在在秒级实现，可实现无缝对接，缩小了该过程对业务的影响；在架构 1.0 中，当 Hive 集群与 GP 集群须要扩容更新时，配置批改后个别须要较长时间集群才可复原，用户感知比拟显著。而 Doris 很好的解决了这个问题，实现用户无感知扩容，也升高了集群运维的投入。

以后在架构 2.0 中的 Doris 集群在大数据平台中的角色更偏向于查问优化，大部分数据还集中保护在 Hive 集群上，将来咱们打算在降级架构 3.0 的时候，实现以下革新：

实时全量数据接入：利用 Flink 将所有的实时数据间接接入 Doris，不再通过 ES 存储；
数据集数据完整性：利用 Doris 构建实时数据集市的原始层，利用 FlinkCDC 等同步工具将业务库 MySQL 与决策过程中产生的 MongoDB 数据实时同步到 Doris，最大限度将现有数据都接入 Doris 的对立平台，保证数据集数据完整性。
离线跑批工作迁徙：将现有 Hive&Spark 中大部分跑批工作迁徙至 Doris，晋升跑批效率；
对立查问剖析进口：将所有的查问剖析对立集中到 Doris，齐全对立数据进口，实现对立数据查问网关，使数据的治理更加规范化；
强化集群稳固扩容：引入可视化运维管理工具对集群进行保护和治理，使 Doris 集群可能更加稳固撑持业务扩大。

Apache Doris1.2 是社区在版本迭代中的重大降级，借助 Multi Catalog 等优异性能能让 Doris 在 Hadoop 相干的大数据体系中疾速落地，实现联邦查问；同时能够将日常跑批与统计分析进行解耦，无效晋升大数据平台的的查问性能。

作为第一批 Apache Doris1.2 的用户，咱们深感荣幸，同时也非常感激 Doris 团队的全力配合和付出，能够让 Apache Doris 疾速落地、上线生产，并为后续的迭代优化提供了可能。

Apache Doris 1.2 值得鼎力举荐，心愿大家都能从中受害，祝福 Apache Doris 生态越来越凋敝，越来越好！

关于数据湖:杭银消金基于-Apache-Doris-的统一数据查询网关改造

业务需要

数据架构 1.0

技术选型

数据架构 2.0

数据集成计划

架构收益

将来与瞻望

总结与致谢