导读：跟着消费信贷规划快速增长，个人信贷商场呈现场景化、体会感强的特征，精准营销、精细化危险办理以及用户运用体会的优化益发重要。作为中国杰出的由人工智能驱动的信贷科技服务渠道，奇富科技挑选将 Apache Doris 作为全体 OLAP 场景共同的剖析引擎，并运用 Apache Doris 替换了 ClickHouse 和 MySQL ，使得报表剖析场景 SLA 合格率进步至 99% 以上，平均查询耗时下降 50%。运用 Doris 替换了 Elasticsearch，离线标签场景数据导入时效从 4 小时缩短至 1 小时，为营销活动、广告投进等供给强有力的数据支撑。此外，凭仗 Doris Multi-Catalog 才能，完结湖仓查询加快，彻底处理装备表面繁琐、不支撑元信息自动同步等问题，极大进步了数据处理与剖析的速度。
作为中国杰出的人工智能驱动的信贷科技服务渠道，奇富科技（原 360 数科）致力于协助金融机构进步智能化水平。经过多年金融范畴实践，奇富科技以本身强壮安全生态为依托，完结了在人工智能、大数据、云核算等技术方面的专业积累。现在，已与银行、消费金融公司、信托公司等建立广泛合作，针对不同类型金融机构的需求供给定制化处理计划，协助客户完结数字化、智能化晋级改造。
消费信贷关于促进消费起着越来越重要的作用，是助力消费康复、激发潜在需求的重要手段之一。近年来，跟着消费信贷规划快速增长，消费信贷的产品和服务也越来越丰厚，个人信贷商场呈现的场景化、体会感强等特征。在此布景下，精准营销、精细化危险办理以及进步用户运用体会益发重要。
为更贴合场景需求、供给精准运营数据支撑，奇富科技自 22 年 3 月开端引进 Apache Doris，期望经过 Apache Doris 交融用户多维价值数据，根据海量数据进行实时精确的数据剖析，以供给个性化的营销计划及决议计划支撑。截止现在 Apache Doris 已在奇富科技被多个事务线运用，每日线上运转数百同步工作流，日均新增及更新的数据规划到达数十亿，承载了上百万次的有用查询。Apache Doris 的运用不只有用进步了数据处理与剖析的速度，还下降了运维本钱、保证了体系的安稳性，为奇富科技完结精细化运营和营销广告精准投进供给了强有力的数据支撑。
事务场景及运用现状
奇富科技大数据渠道供给一站式大数据办理、开发、剖析服务，覆盖大数据资产办理、数据开发及使命调度、自助剖析及可视化、共同目标办理等多个数据生命周期流程。其中，最典型的数据运用服务即在线报表剖析和离线标签服务，离线标签服务又包含了用户标签点查、客群画像、触发式战略生成和人群圈选四大服务。为满意不同事务数据需求，早期架构将数据分散存储在 Clickhouse、Elasticsearch、MySQL 等多个组件中，带来了数据运用和体系运维的应战：
- 部分 SLA 不合格：架构组件过多，原 OLAP 引擎的安稳性及可用性无法满意 SLA 要求。
- 运维办理复杂：需一起办理多个组件，运维复杂度和难度均较高； ClickHouse 对其他组件依靠性高，扩容难度大；MySQL 单实例容量有限，需保护多个实例且不支撑跨实例查询，添加了办理本钱。
- 数据办理难度高：全体数据关系复杂，数据办理难度较高，关于后续数据血缘和数据生命周期办理带来较高的本钱。
除此之外，还存在一些功用及安稳性问题，详细表现为：
- 查询耗时高：MySQL / ClickHouse 在面临复杂查询时功用较差，存在关联查询失利率高、查询呼应速度慢等问题，无法满意秒级查询呼应需求。
- 导入功用差：受限于 MySQL 可承载的数据规划（千万级），无法满意大规划数据导入的要求；且 ClickHouse 导入功用较差，简略呈现导入不安稳的问题。
技术选型
为处理以上问题，奇富科技计划引进一款剖析型数据库以满意大部分 OLAP 场景需求，该数据库应具有以下特性：
- 安全易办理：要求单一数据库即可满意大部分 OLAP 需求，简化数据办理流程，进步数据办理功率；要求具有完善的权限控制机制，以保证数据的安全性和隐私性。
- 精确实时：支撑数据实时导入及查询，保证数据导入不丢不重，完结 Exactly Once 语义。
- 易用低本钱：布置简略、可根据需求完结灵敏扩缩容，支撑 MySQL 语法、下降开发人员学习门槛，进步开发功率。
根据以上选型要求，奇富科技对 ClickHouse、Apache Doris 进行了调研。其中 Apache Doris 在导入、查询、运维等方面的功用符合选型要求，一起在社区规范性、活跃度、敞开程度和可继续发展方向表现出色。因而，奇富科技挑选 Apache Doris 作为全体 OLAP 场景共同的剖析引擎。
接下来将结合实在事务场景，介绍 Apache Doris 在奇富科技的深度运用和优化实践，更好了解 Apache Doris 怎么助力奇富科技完结精准营销，进步事务收益。
Apache Doris 在报表剖析场景的运用
在报表剖析场景中，数据剖析师通常会根据重要事务报告、图表、当前事务状况评价报告进行数据剖析，旨在为事务战略决议计划供给重要根据。
早期架构在应对该场景时，会呈现数据表同步时效 SLA 合格率（每日统计）波动较大的问题，经过深入剖析是由数据同步进程所触及组件繁多导致。不只如此，组件繁多还添加了数据同步的复杂性，对数据源（MySQL、ClickHouse）和同步使命（如 DataX Job、Flink Job 等）的安稳性提出了应战。
报表引擎晋级
为了处理这些问题，咱们运用 Apache Doris 替换了 ClickHouse 和 MySQL ，由 Doris 共同为报表供给服务，下降报表数据源的复杂度。从下图可知，Doris 架设于 Hive 数仓上层，可充分利用 Doris 强壮的查询功用，为报表剖析场景供给查询加快。一起 Apache Doris 支撑原生 MySQL 协议，可与帆软、观远等 BI 东西无缝结合，进步了报表剖析的灵敏性与易用性。
导入使命优先级
在原先的逻辑中，Doris 关于导入使命的处理没有优先级的概念。当有很多使命一起提交时，Doris 会依照先进先出的逻辑履行使命。因而，咱们主导规划并向社区贡献了导入使命优先级功用。该功用可以根据用户设定的优先级来处理导入使命，然后可以保证部分高优使命的时效性。详细流程如下图所示：
经过优先级设置，即便在使命高峰期，依然可以保证高优使命的时效性，极大进步了数据表同步时效 SLA 合格率。为数据的传输及运用供给了更灵敏、高效的支撑。
异地双机房高可用计划
为保障 Doris 集群的可用性及安稳性、保证在机房毛病时集群依然可读，并在毛病康复后主集群的数据可以回写，为 Doris 集群装备双机房容灾才能势在必行。经过计划调研，决定经过自行开发 Replicator 主从同步插件来完结双机房容灾建造，以下为详细的架构规划：
在主集群装置 Replicator 插件，该插件可以阻拦并解析主集群履行的全量 SQL，经过滤操作，可挑选触及库、表结构变更和数据增、删、改相关的 SQL，并将相关 SQL（部分 SQL 需改写）发送到从集群进行回放。
更进一步的，为了应对主集群或许遭遇意外状况，奇富科技规划了一套灵敏的 DNS 解析地址切换机制。当主集群不可用时，切换 DNS 解析地址到从集群，完结主从集群的切换。
除此之外，咱们还在 Doris 控制台（内部自研的 Doris 集群保护办理服务）开发了 Validator 数据校验模块，可守时对 Doris 数据表主从集群共同性状况进行校验并上报，包括元信息、行数等。
运用收益
以表同步耗时为例，利用 Doris Broker Load 方法有用下降数据导入的复杂度，进步数据导入时效性，成功将报表数据同步时效 SLA 合格率进步至 99% 以上。
以查询时效为例，下图为引进 Apache Doris 后报表剖析集群的查询时效监控，平均耗时安稳在 10s 以内、P90 查询耗时安稳在 30 秒以内 ，比较旧架构平均耗时下降了 50% 以上。跟着运用程度的加深和数据规划的增长，查询功用还得以进一步进步，取得更多内部事务线的认可。
Apache Doris 在离线标签服务场景的运用
在标签服务场景中，数据剖析师会根据用户的多重维度信息，根据一定战略进行用户标签的打标，标签首要包括行为标签和特点标签。离线标签服务则以上述标签为根底，为下方四个场景供给服务：
- 用户标签点查服务：在风控流程中，特征渠道将查询用户的标签信息，并根据标签信息构建用户特征变量。
- 客群画像服务：根据用户标签信息进行客户画像描绘，为电销、营销等部分拟定事务战略供给数据支撑。
- 触发式战略生成服务：电销部分根据用户标签信息，经过触发式战略生成人群包，并对挑选出的客户群进行外呼。
- 人群圈选服务：营销部分根据用户的标签信息，对生成的人群包进行个性化广告投进。
在原先的架构中（如上左图所示），导入的数据会逐步生成标签信息，并对标签信息进行加工、兼并为 JSON 文件（兼并操作是为了削减 Elasticsearch 的更新次数及负载），兼并后的 JSON 文件导入到 Elasticsearch 中供给数据服务。然而，这种方法带来两个问题：
- 旧标签服务过度依靠于兼并操作，假如某个标签服务的数据呈现问题，那么整个标签的兼并操作就无法完结，然后影响标签服务的正常运转。
- 数据兼并操作根据 Spark 和 MapReduce 进行，处理时效或许超过四个小时乃至更长，这样长期的处理耗时会导致场景服务错过黄金营销时刻，形成事务营收的损失。
为处理上述问题，咱们根据 Apache Doris 对架构进行了改造，如上图右图所示，在标签数据加工进程中，利用 Apache Doris 进行标签宽表的存储和处理，当上游标签准备就绪时，可运用 Aggregate Key + replace_if_not_null 完结标签兼并和部分列更新的作用。当一切标签均更新到标签宽表后，继续将其同步到 Duplicate Key 模型的标签明细宽表中，以进步查询功用。
这样的改造使得咱们能愈加及时地处理标签数据，标签数据的导入时效从 4 小时缩短至 1 小时以内。此外，凭仗 Doris 完善的 Bitmap 索引以及高并发查询功用，完结了秒级人群圈选。在点查询方面，QPS 到达 700+ ，保证了查询的快速呼应。
根据 Apache Doris 的湖仓查询加快实践
为缩短事务决议计划周期、进步数据剖析师的工作功率，关于离线湖仓查询加快的重要性日益凸显。因而自 22 年 9 月起，咱们开端将 Apache Doris 运用在离线查询加快场景中，彼时 Doris 仅支撑以 Hive 外部表的形式进行查询，因为外部表需求装备映射关系，当 Hive 元数据发生变更时需求手动更新，人工保护本钱较高，因而挑选将 Hive 中数据导入进 Doris 中以完结查询加快。
详细而言，会先根据查询频率对数据表优先级进行排序，经过 Doris Broker Load 将查询频率 Top 500 的数据表从 Hive 导入到 Doris。经过路由引擎守时调度搜集数据表在 Doris 和 Hve 中表的元信息，包括表的字段、字类型以及数据规划。当收到查询句子时，路由器检测数据的是否在 Doris 中，如存在则会路由到 Doris 引擎，然后完结查询加快。
而该计划并不完美，依靠于关于 Hive 数据的导入。当面临大规划数据导入使命时，或许形成集群资源紧张导致查询和导入功用下降的问题，乃至或许引起集群不安稳，对事务运用发生负面影响。
为处理上述问题，咱们对架构进行了进一步晋级。在 Apache Doris 1.2 版别支撑了 Multi-Catalog 多源数据目录，根据该才能简略装备即可将 Hive 集群的数据表完整同步到 Doris 中，处理了装备表面繁琐、元信息无法自动同步等问题。以下是数仓查询加快新计划：
在新计划中，首要经过以下几个步骤完结数仓查询加快计划：
- 根据 Doris Multi-Catalog 才能，将 Doris 引擎加入到查询引擎路由战略中（Internal Catalog 和 Hive Catalog）；
- 引进弹性核算节点并落地 Deploy on Yarn 计划，简化布置流程以支撑灰度期间快速晋级迭代、快速扩缩容支撑；
- 查询引擎完结自动路由，引擎挑选对用户通明。
当用户提交查询句子后，路由引擎（即查询网关）会根据搜集的数据元信息进行判断，为查询句子匹配最优查询路径。路由引擎还会剖析查询触及的分区数和表行数，来匹配最佳履行引擎（ Doris 、Presto、SparkSQL ），例如当查询句子所依靠数据表都存在于 Doris 内表中且元数据共一起，将直接路由至 Doris 内表进行查询，无法射中则将查询下压，由 Doris Hive Catalog 进行查询或许经过 Presto 进行查询。
经过这种战略，用户无需关怀查询由哪个引擎履行，也无需关注查询引擎间的语法差异。查询总能以最高效的方法履行，完结查询加快，并能保障成果的精确性。运用上述计划也遭遇了一些问题，接下来共享应对战略及优化计划。
Hive 元数据准实时同步
运用上述查询加快计划时，假如 Hive 元信息更新后无法准实时同步至 Doris ，用户查询时会呈现成果不共同问题。为防止该问题发生，可运用 Doris 元数据自动刷新特性（根据 HMS Event Listener 完结）完结元信息准实时同步。这种方法需求在 Hive 端敞开 HMS Event Listener ，并在 Doris 端敞开 HMS Event 消费开关。详细完结如下图所示：
关于 Hive 端，当敞开 Listener 后，因 Hive 本身具有内置的 Listener 完结，会对 Hive 集群中 DDL 操作以及 Insert 操作进行阻拦。在建议阻拦操作后，生成对应的 HMS Event（事情），并写入 Hive 元信息数据库中。
关于 Doris 端，当敞开消费 HMS Event 开关后，Doris 的 Master FE 节点会发动后台线程，调度式批量拉取 HMS Event，经过消费 HMS Event 获取 Hive 端的元数据改变，并将该改变同步到 Doris 内部保护的 Hive 元信息中，完结数据的准实时同步。在实施进程中也遇到了一些新的问题，在此对优化计划进行共享：
优化计划 1：Hive DDL 长期阻塞：
发动 Hive 端的 HMS Event Listener 后，Hive 处理新增表和分区时需求获取表、分区名和文件信息，生成相应的 HMS Event，而 Doris 回放 HMS Event 时并不需求文件信息。因而当 Hive 表、分区文件数过多或集群繁忙时，获取文件信息的操作会延伸 HMS Event 生成时刻，导致 Hive DDL 操作耗时添加。
根据此，咱们重写了 Hive DbNotification Listener，屏蔽对 Hive 表、表分区文件信息搜集，有用削减不必要信息的拉取与采集，缩短了 Hive 端的履行功率。
优化计划 2：消费速率与事情发生速率不匹配：
Hive 集群繁忙时，DDL 或 Insert 事情频率高，且 Doris 选用单线程串行模式消费 HMS Event，或许会呈现 Doris 消费速率与Hive 时刻发生速率不匹配的问题。
为了进步 Doris 消费速度，咱们在 Doris 端添加了预先事情兼并（HMS Event Merge）步骤，过滤掉一部分 HMS Event，大幅下降了需求消费的 HMS Even 数量。预先事情兼并的核心思想是判断批量 HMS Event 中是否存在可以抵消前面某个 HMS Event 发生的作用，假如是则越过前面的 HMS Event。经过这样的方法，HMS Event 数量可以大幅度下降，然后进步了 Doris 处理 HMS Event 的消费速度。
预先事情兼并原理如上图所示，第一个事情 DropPartitionEvent（db1.tbl1）和最终一个事情 DropTableEvent（db1.tbl1）针对同一张 Hive 表。DropPartitionEvent 发生在前，DropTableEvent 发生在后。在处理 DropPartitionEvent 时，Doris 会删除该 Hive 表的应分区缓存信息；在处理 DropTableEvent 时，Doris 会删除该 Hive 表的表缓存信息。因为后一个 HMS Event 发生的作用可以彻底抵消前一个 HMS Event 发生的作用，因而可以越过前面的 HMS Event。
咱们对集群 4 天内所处理 HMS Event 处理状况进行抽取，从上图可知，经 HMS Event Merge 操作后，Doris 消费事情数量时显著下降，较原来削减约 2-5 倍的数量。完结优化后，再未呈现消费速率低于发生速率的问题。
优化计划 3：HMS Event 类型缺失，影响 FE 安稳性
针对 CDH 或许 HDP 集群 Hive 版别发生压缩格式的 Event ，新增了 GzipJSONMessageDeserializer 反序列化器进行处理。原因是 Slave FE 节点一般经过 Journal Log 方法消费 HMS Event ，假如消费失利会导致 FE 服务直接退出，经过新增 Fallback 战略可以进步消费逻辑的健壮性，尽量防止 FE 服务退出的问题。
引进弹性核算节点，Deploy on Yarn 完结弹性扩缩容
当需求处理大规划数据或进行高功用核算时，需求更多核算资源供给支撑。若布置的 Doris BE 集群时有上百个节点，每一个节点需求多个 CPU，那么在运转进程中需求庞大的资源支撑，然后带来较大的资源本钱和布置本钱。为下降资源和布置本钱，咱们挑选引进 Doris 的弹性核算节点（Elastic Compute Node），并挑选将弹性核算节点与 Hadoop 集群的其他组件（如 DataNode 节点）混合布置，可以更好地办理和优化核算资源。
在此根底上，根据 Doris 核算节点的无状态特性，可经过 Skein 进一步简化 Doris 核算节点 Deploy on Yarn 的布置流程，完结节点弹性扩缩容。在实际运转进程中，咱们根据用户的查询习气，在夜间查询较少时缩容、在白天事务高峰时扩容，最大化利用集群资源、进步资源利用率。
如上图，在 Yaml 文件中界说 Doris 核算节点的数量和所需资源信息，并将装置包、装备文件、发动脚本共同打包至分布式文件体系。当需进行版别晋级或集群启停时，只需一行指令即可在分钟内完结整个集群上百个核算节点的启停操作。
Hive 视图查询优化
在 Hive Catalog 查询运转进程中会有偶发的查询失利问题，因而咱们对数百事务用户查询失利的原因进行了深度剖析，发现 28% 是由查询视图引起，24% 是因为用户运用了 Doris 无法匹配的函数导致。
如下图所示，当用户发送查询恳求后，在 Doris 内部将阅历词法剖析、语法剖析、逻辑履行计划和分布式履行计划四个阶段。Hive 视图辨认在第三阶段进行，即当逻辑履行计划阶段生成 Hive ScanNode 后，对其进行初始化时，Doris 会辨认该表是否为 Hive 视图。假如是 Hive 视图，将直接抛出查询异常导致查询失利。
因而咱们对 Hive 查询履行进行了优化，将 Hive 视图的辨认提早至语法剖析阶段（第二阶段）进行，假如辨认为 Hive 视图，则经过 HMS Client 客户端获取该视图界说的 DDL ，并将 DDL 带入 Doris 解析视图依靠的 Hive 实体表。在逻辑履行计划生成阶段（第三阶段），将生成与 Hive 实体表相对应的 HiveScanNode，查询将继续进行。经过简略改造，Doris 即可经过 Hive Catalog 完结对 Hive 视图的查询支撑。
运用收益
查询加快首要得益于 Apache Doris 的 Multi-Catalog 特性，相关于外部表，Multi-Catalog 无需创建表与表之间的映射关系，可以完结元数据层的对接，如上文所述只需简略的装备，完结将整个 Hive 集群的数据表完整地同步到 Doris 中，彻底处理了以往装备表面繁琐、不支撑元信息自动同步等问题。
此外，凭仗 Doris Multi-Catalog 代替了早期架构中多个数据组件，共同了数据源入口和数据查询出口，下降架构的复杂度、缩短数据处理与查询的流程，大大进步数据查询的功率。
结束语
从 22 年引进 Doris 以来，凭仗其优异的功用、较低的运维复杂度和较高安稳性，敏捷在奇富科技内部多个事务场景得到大规划的运用。截止现在，出产环境共有近十套集群、上百 BE 节点、CPU Core 超过 1000+，总数据规划到达数十 TB ，每日有数百个同步工作流在运转，日新增数据或更新的规划达近百亿，每天支撑事务方百万次的有用查询量。经过 Doris 的运用极大的下降了架构的复杂度，有用进步了数据处理与剖析的速度，下降了运维本钱，保证了体系的安稳性。
未来咱们将继续深入运用 Apache Doris 、并引进 2.0 版别，为用户带来愈加实时、共同的数据处理和剖析体会。后续咱们将要点关注存算别离架构、数据湖剖析特性以及 Doris Manager 组件的运用。
- 存算别离架构：经过存算别离架构完结集群交融，消除不同集群间 Doris 版别的差异，供给愈加灵敏的负载阻隔战略和弹性布置支撑，为用户带来愈加安稳、可靠的数据处理环境，满意不同事务需求。
- 数据湖剖析特性：继续深入运用，经过共同查询引擎简化内表面数据流经进程，下降数据处理的复杂性。
- Doris Manager 组件：为了让用户愈加轻松的进行数据库的运维和办理，飞轮科技开发了一站式数据库集群办理东西 Cluster Manager for Apache Doris（简称 Doris Manager）。该东西供给轻松布置和接收 Doris 集群的功用，支撑物理机和虚拟机环境。凭仗直观的界面，为用户供给了简略易用的可视化运维体会。一起用户还可以快捷的对节点进行扩缩容和重启，设置监控告警等操作。这将极大地进步运维功率，削减过错和中断，进步服务质量和安稳性。
