本文导读：
随着河北幸福消费金融的客户数量和放贷金额持续上升，如何依托大数据、数据分析等技术来提供更好决策支持、提高工作效率和用户体验，成为了当前亟需解决的问题。基于此，公司决定搭建数据中台，从基于 TDH 的离线数仓再到基于 Apache Doris 的实时数仓，最终统一了数据出口，提升了数据质量，并实现查询速度近 400 倍的提升。本文将详细为大家分享河北幸福消费金融数据中台搭建经验和应用实践，希望为其他企业带来一些有益的参考。
作者｜河北幸福消费金融 信息科技部
河北幸福消费金融股份有限公司由张家口银行发起设立，是 2017 年 6 月正式开业的全国第 22 家、河北省首家消费金融公司，主要面向个人客户发放最高额不超过 20 万元的普惠、小额、信用消费贷款。目前公司服务区域覆盖全国 32 个省级单位，相继获评为国家科学技术部认定的全国高新技术企业、河北省科技型中小企业和石家庄市科技“小巨人”企业。
随着客户数量和放贷金额持续上升，如何依托大数据、数据分析等技术，为各业务线人员提供更好的决策支持，如何提高工作效率、为客户提供更佳的使用体验，成为了当前亟需解决的问题。具体需求如下：
- 高管看板类：搭建高管驾驶舱帮助高层快速了解公司当前的整体经营状况，驾驶舱集成全业务线数据，包括实时业务指标和离线业务指标，在该场景下我们希望查询结果可以在 毫秒内返回，便于管理层进行高效决策。
- 实时变量类：为给风控决策提供实时支撑，需在 500ms 内返回全产品线查询结果，并可基于申请、授信、关联人、逾期以及还款等基础信息，计算产品级、客户级和借据级高维度衍生变量 。
- 决策分析类：为给各业务部门提供业务分析和决策支撑，需在秒级返回年、季、月多维度的主题报表，特别是风险部门，需要从放款开始回溯全生命周期的运营情况；而计财部门，则需要通过以往经营数据表现，预测未来的盈利，数据量大且逻辑复杂。
- 风险建模类：提供全量、明细级的数据，用于风险建模的变量跑批，满足对客户评分评级，参与审批、授信等核心业务的要求，以支持业务指标的观测、投入产出分析、变量筛选以及决策制定等业务需求。
- 监管合规类：为确保业务符合相关法律法规、行业标准等规范，需要根据监管合规的要求进行合规子系统的定期上报，上报的数据分为指标汇总项数据和明细数据。
为了满足不同业务线对数据分析的需求，公司开始搭建数据中台并对进行优化。最初，公司基于商业化产品 TDH 搭建了离线数仓，以满足基本数据分析需求。然而，随着数据时效性的提高和实时分析需求增加，公司迫切需要搭建一款实时数据仓库。因此引入了 Apache Doris 并在此基础上搭建了实时数仓，最终建立了一个高效、稳定的数据中台。本文将详细为大家分享河北幸福消费金融数据中台搭建经验和应用实践，希望为其他企业带来一些有益的参考。
基于 TDH 的离线数仓
因早期主要解决的是离线分析需求，优先基于 TDH 集群建设离线数仓。通过 Sqoop、DataX 将上游数据采集到离线数仓，经过标准化数据清洗，完成数仓的日常跑批。离线数仓架构图如下所示：
随着数据积累和业务人员对数据时效的要求越来越高，基于 TDH 离线平台的一些问题逐渐显现出来：
- 数据采集同步时效慢：离线数仓抽数工具依赖于 Sqoop、DataX 等组件，而受限于调度周期，此类工具采集的数据必然有滞后性。
- 资源冲突大：离线数仓每日跑批时间跨度大，一般从凌晨到下午5点左右，这将导致跑批和即席查询之间发生资源冲突，影响业务人员的使用体验。
- 查询分析慢：在使用离线平台进行自定义统计分析和数据探索时，查询分析响应速度慢、时效性难以保障，严重影响工作效率。
- T+1 延迟高：各业务线对实时数据处理的需求在逐渐增多，T+1 的数据已经无法适应数据快速获取和产生业务价值的诉求。
- 报表定制周期长：报表定制化开发有固有的迭代周期，难以满足业务人员对数据的灵活多样的分析探索。
- 烟囱效应：定期上报数据时，数据中台需要从多个业务系统中拉取数据。当业务系统发生变更后，会波及上述相关的报送子系统，形成烟囱效应。
技术选型
为了解决上述问题，我们迫切需要一款 MPP 引擎来构建实时数仓。对于新引擎我们有几个基本的要求：首先，需要简单易上手，以便团队快速掌握和使用；其次，需要具备强大的数据导入能力，以便快速高效地导入海量数据；同时，需要兼容离线数仓相关工具，以便与现有的数据处理工具和技术体系无缝衔接；此外，搭建和切换成本也需要低，以便快速部署使用和进行扩缩容；最后，它需要具备较好的并发能力和优异的查询性能，以便支持高并发、复杂查询等业务场景的需求。
在以上选型要求驱动下，我们对目前比较流行的 ClickHouse 与 Doris 进行了系统的调研，其中 Apache Doris 更符合我们的选型的要求，具体原因如下：
- 部署成本低：Doris 采用分布式技术架构，部署只需两个进程，不依赖其他系统，在线集群扩缩容，自动副本修复，部署及使用成本较低。
- 快速上手使用：Doris 采用主流的分区分桶设计思路，索引结构与 MySQL 的思路类似，相关人员在使用 Doris 时无需学习大量的新知识。相比之下，ClickHouse 在建库建表需要分别指定类型，使用流程相对比较繁琐，上手难度也比较高。
- 工具兼容：业务人员通常使用 TDH 的客户端工具 WaterDrop 进行离线数仓查询，Doris 通过标准协议链接可完美兼容 WaterDrop，而 ClickHouse 无法兼容。
- 数据生态圈丰富：Doris 数据生态圈丰富，与 Flink、Kafka 等组件结合度较高，同时支持联邦查询，提供了丰富的数据导入和接入方式，可以满足多场景下的数据处理需求。
- 高并发能力：我们对 Doris 进行了性能压力测试，在高并发和大数据量的情况下，Doris 表现出较好的性能和稳定性，能够满足不同业务场景的需求。
- 社区活跃度高：Doris 社区非常活跃，有大量的开发者和用户参与其中，提供了丰富的技术支持和解决方案。同时 Doris 社区提供了全面的文档和资料，方便用户学习和使用 Doris。此外，SelectDB 为社区提供了一支全职专业的技术团队为社区用户提供服务与支持，任何问题均可得到快速响应。
基于 Doris 的实时数据仓库
在离线数仓的基础上，使用 Doris 结合 CDH 集群、Airflow 集群搭建了实时数仓，实时数仓的数据来源主要为离线数仓和 MySQL，使用 Flink CDC 结合 PyFlink（使用 Python 调用 Flink 的 API，简称 PyFlink）将 MySQL 中的数据实时地采集到核心计算引擎 Doris 中（后文将详细介绍），上层为 Airflow 分布式调度系统，可以将实时任务进行常规化的调度运维。我们对 Doris 引擎进行了基本数仓分层，数据经过各层处理后统一为各场景提供数据服务。
基于 Doris 提供的丰富的导入方式，我们可以快速将离线数仓中的实时数据清洗整合接入到 Doris 集群中，实现数据的快速迁移。目前我们已经将基于 TDH 的查询分析和数据探索服务全部转移到 Doris 引擎上，借助 Doris 引擎快速计算的能力和优异的查询性能，可以更高效地进行数据处理和分析，业务处理速度和效率得到显著提升。
以某 SQL 为例，该 SQL 主要应用在信贷审批场景。我们对比了原有架构和新架构从十万、千万，亿级别的三个大表中的查询返回速度。结果显示，在过去 TDH 架构中执行查询需要 11 分 30 秒才可返回结果，而在基于 Doris 的新架构中仅需要 1.7 秒即可返回结果，速度提升近 400 倍！
数据规模：
原有离线数仓：需要 11 分 30 秒才可返回结果
基于 Doris 的新数仓：优化查询后仅需要 1.7 秒即可返回结果，有时甚至可以 1 秒内返回。
应用实践
实时数据归集
公司的业务系统通常是按照产品进行库划分，各个产品表结构保持一致。而实时数仓核心功能就是依靠 Doris 丰富的导入能力，将分散的库对应的相同的逻辑表归集到 Doris 下的同一个逻辑表上，汇集后的数据也能在监管主题层面进行整体调整，避免烟囱效应的发生。汇集的实时数据进入数仓后，会主动触发衍生变量的自动计算，更新衍生变量的值。而衍生变量的汇总值在一个单独的表中，当进行查询时，可以实现毫秒级别的查询响应。
在进行实时数仓归集时，首先需要确定 FlinkCDC、Flink 、Flink on Yarn、Apache Doris 等核心组件的版本号，接着基于 PyFlink 进行产品化自动接入实时数仓的建设。具体操作如下：
- 在数据层面，将业务系统数据库按照水平和垂直进行切分，以提升读写性能并增加高可用性。
- 在数仓层面，我们对业务表的数据进行了维度汇集，以便进行更好的统一汇总分析。
- 在数据接入方面，我们需要高效地接入现有业务系统的存量数据，并持续稳定地接入增量数据。
此外，我们还提供了标准化的接入方案和接口，以满足不同业务场景的需求。
使用步骤：
数据质量监控
离线数仓存在各种数据质量问题，这些问题通常在数据跑批时才会暴露出来，导致数据修复时间窗口急剧被压缩。为了解决这个问题，我们利用 Doris 建立了数据质量监控系统，同时将离线数仓的数据质量监控模型迁移到 Doris 。基于该系统可以实时监控业务指标和数据质量，并在发现问题时及时进行人工干预或报警，提高离线数仓跑批的稳定性和效率。另外当实时数仓获取归集后的数据后，可通过数据质量监控系统的校验规则第一时间对数据质量进行实时检查，保证数据归集的准确性。
目前我们已经将 30% 的数据监控指标和 35 个业务指标迁移到 Doris 实时集群上，每月可成功规避问题 3 次以上，有效提升了离线数仓跑批的数据质量。后续我们将继续将更多的数据监控指标和业务指标迁移到 Doris 集群中，以进一步提高数据处理的效率和质量。
数据联邦查询
各业务条线的核心数据存储在不同类型的数据库中，如 MySQL、Hive、ES 等。Apache Doris 1.2 版本提供的 Multi Catalog 功能可以统一数据查询出口、实现联邦查询，为数据分析提供了极大的便利。同时，借助 Doris 的持久化能力，可以通过外表的方式快速同步其他数据源数据，方便快捷。此外，通过 Apache Doris 聚合查询、向量化引擎等技术的加持，我们真正实现了高效的数据统一门户，提高了数据分析的效率。
优化经验
负载均衡
随着 Doris 接入的业务量不断增加，FE 的负载也在不断增长。为了实现 Doris 的高可用性，我们增加了 FE 节点数，在多个 FE 节点上部署负载均衡层。我们选择基于 Nginx TCP 反向代理的方式来构建 FE 的负载均衡，有效地实现了 FE 角色之间的负载均衡。具体配置方式如下：
查询优化
当前审批系统的业务数据持久化在关系型数据库 MySQL 中，累计总进件量将近 2.8 亿。为了应对日益膨胀的的数据问题，业务系统的数据库采用了分表和数据归档的设计思路。但是在业务上，我们仍需要对全量数据进行业务查询，并且时效要求在 3 秒内返回结果。以下是查询需求的抽象分类：
- 以“申请编号”，“客户编号”，“身份证号”，“核心客户号”中的一个或多个作为查询条件进行查询
- 以“申请日期”或“更新日期”中的一个条件，结合“姓名”、“申请类型”、“进件渠道”、“白名单渠道”、“决策阶段”、”审批类型”、”审批结果”等形成复核条件做查询
- 以“申请日期”或“更新日期”中的任意一个为条件，对近一周的审批明细数据进行查询查询
为了满足以上查询场景的需求，我们将审批进件数据结合 Doris 引擎的分区分桶技术、布隆过滤器和位图索引进行合理的设计，最终整体实现了满足业务上 3 秒内的查询效率需求。
优化策略：
分区：apply_time
分桶：ID、database_name、table_name
布隆索引：id_number, bhb_customer_id, customer_name, customer_id, serial_no
位图索引：apply_source,white_channel,approval_result,approval_status,product_type,decision_stage
基于上述查询的 压测 指标效果如下：
运维管理
通过 Doris 提供的 Prometheus 和 Grafana 可以快速获取 Doris 集群的整体健康状况以及各个角色的多方面指标值。同时我们还将监控平台与公司统一告警平台进行二次融合，告警平台可以通过 API 获取 Prometheus 的基础指标值与阈值进行比较，从而触发不同级别的报警或者达到服务自动重启。此外，我们在 FE 和 BE 服务级别上实现任务的自动运维，确保在服务异常时能够自动拉起，保证核心服务的可用性。
总结收益
Doris 已经在公司内部得到了广泛的应用，目前已搭建数十台集群规模，为公司带来了以下收益：
- 数据处理时效提升：数据处理的时效从 T+1 到实时，解决了离线数据延迟的问题。
- 秒级查询响应：借助 Doris 分区分桶、物化视图、布隆索引等功能进行查询优化，即席查询的速度从原先的 20 分钟左右降低到分钟甚至秒级响应，相较之前有近 400 倍的速度提升。
- 统一查询出口：依赖于 Doris 强大的导入能力和 Multi Catalog 功能成功将各业务库的数据整合汇总到 Doris 中，由 Doris 统一提供数据查询及分析服务，极大的提升了查询分析响应效率。
- 提升数据质量：基于 Doris 建立了数据质量监控系统，目前我们已经将 30% 的数据监控指标和 35 个业务指标迁移到 Doris 实时集群上，有效提升了离线数仓跑批的数据质量。
综上所述，Doris 在公司内部的广泛应用，为我们带来了多方面的收益，助力企业提升数据分析效率、降低数据管理成本、实现统一、实时、高效的数据中台建设，为业务向好发展注入了新的动力。
未来我们将继续扩大 Doris 的使用范围，在实时、性能、时效要求更高的业务领域发力，其次我们还将尝试使用 Doris 更多的功能及新特性，一方面深化 Doris 在公司的使用，另一方面我们会将真实的使用体验反馈到社区，帮助 Doris 进一步迭代优化。
