随着天眼查近年来对产品的持续深耕和迭代，用户数量也在不断攀升，业务的突破更加依赖于数据赋能，精细化的用户/客户运营也成为提升体验、促进消费的重要动力。在这样的背景下正式引入 Apache Doris 对数仓架构进行升级改造，实现了数据门户的统一，大大缩短了数据处理链路，数据导入速率提升 75 %，500 万及以下人群圈选可以实现毫秒级响应，收获了公司内部数据部门、业务方的一致好评。
作者 | 天眼查实时计算负责人 王涛
天眼查是中国领先的商业查询平台，以公开数据为切入点、以关系为核心的产品，帮助传统企业或个人降低成本，为防范化解金融风险方面提供了产品化的解决方案。目前已收录全国 3 亿多家社会实体信息，300 多种维度信息及时更新，致力于构建商业安全，从而实现“公平看清世界”。
业务背景
天眼查的数据仓库主要服务于三个业务场景，每个场景都有其特点和需求，具体如下：
- 亿级用户人群圈选：人群圈选场景中目前有 100+ 人群包，我们需要根据 SQL 条件圈选人群包，来支持人群包的交并差、人群包实时圈选和人群包更新通知下游等需求。例如：圈选出下单未支付超过 5 分钟的用户，我们通过用户标签可以直观掌握用户支付状态，为运营 & 营销团队提供更精细化的人群管理服务，从而提高转化率。
- 多元活动支撑的精准营销：该场景目前支持了 1000 多个指标，可支持即席查询，根据活动效果及时调整运营策略。例如在“开工季”活动中，需要为数据分析 & 运营团队提供数据支持，从而生成可视化的活动驾驶舱。
- 高并发的 C 端分析数据：该场景承载了 3 亿 + 实体（多种维度）的数据体量，同时要求实时更新，以供用户进行数据分析。
原有架构及痛点
为满足各业务场景提出的需求，我们开始搭建第一代数据仓库，即原有数仓：
在原有数仓架构中， Hive 作为数据计算层，MySQL、ES、PG 作为数据存储 层，我们简单介绍一下架构的运行原理：
- 数据源层和数据接入层：MySQL 通过 Canal 将 BinLog 接入 Kafka、埋点日志通过 Flume 接入 Kafka，最后由 DataX 把 Kafka 中的数据接入数据计算层 Hive 中；
- 数据计算层：该层使用 Hive 中的传统的数仓模型，并利用海豚调度使数据通过 ODS -> DWD -> DWS 分层，最后通过 DataX 将 T+1 把数据导入到数据存储层的 MySQL 和 ES 中。
- 数据存储层：MySQL 主要为 DataBank、Tableau、C 端提供分析数据，ES 用于存储用户画像数据，PG 用于人群包的存储（PG 安装的插件具有 Bitmap 交并差功能），ES、PG 两者均服务于 DMP 人群圈选系统。
问题与挑战：
依托于原有架构的投入使用，初步解决了业务方的需求，但随着天眼查近年来对产品的持续深耕和迭代，用户数量也在不断攀升，业务的突破更加依赖于数据赋能。精细化的用户/客户运营也成为提升体验、促进消费的重要动力。在这样的背景下，原有架构的缺点逐渐暴露：
- 开发流程冗长：体现在数据处理链路上，比如当面对一个简单的开发需求，需要先拉取数据，再经过 Hive 计算，然后通过 T+1 更新导入数据等，数据处理链路较长且复杂，非常影响开发效率。
- 不支持即席查询：体现在报表服务和人群圈选场景中，所用的指标无法根据条件直接查询，必须提前进行定义和开发。
- T+1 更新延迟高：T+1 数据时效性已经无法提供精确的线索，主要体现在报表和人群圈选场景上。
- 运维难度高：原有架构具有多条数据处理链路、多组件耦合的特点，运维和管理难度都很高。
理想架构
基于以上问题，我们决定对架构进行升级改进，在正式升级之前，我们希望未来的架构可以做到以下几点：
- 原架构涉及 MySQL 、PG、ES 等多个组件，并为不同应用提供服务；我们希望未来的架构可以兼容 MySQL 协议，实现低成本替换、无缝衔接以上组件。
- 支持即席查询且性能优异，即席查询能够给业务方提供更灵活的表达方式，业务方可以从多个角度、多个维度对数据进行查询和分析，更好地发现数据的规律和趋势，帮助业务方更精准备地做出决策。
- 支持实时聚合，以减轻开发负担并保证计算结果的准确性。
- 统一数据出口，原架构中数据出口不唯一，我们希望未来的架构能更统一数据出口，缩短链路维护成本，提升数据的可复用性。
- 支持高并发， C 端的实时分析数据需要较高的并发能力，我们希望未来的架构可以高并发性能优异。
技术选型
考虑到和需求的匹配度，我们重点对 OLAP 引擎进行了调研，并快速定位到 ClickHouse 和 Apache Doris 这两款产品，在深入调研中发现 Doris 在以下几个方面优势明显，更符合我们的诉求：
- 标准 SQL：ClickHouse 对标准 SQL 支持有限，使用中需要对多表 Join 语法进行改写；而 Doris 兼容 MySQL 协议，支持标准 SQL ，可以直接运行，同时 Doris 的 Join 性能远优于 ClickHouse。
- 降本增效：Doris 部署简单，只有 FE 和 BE 两个组件，不依赖其他系统；生态内导数功能较为完备，可根据数据源/数据格式选择导入方式；还可以直接使用命令行操作弹性伸缩，无需额外投入人力；运维简单，问题排查难度低。相比之下，ClickHouse 需要投入较多的开发人力来实现类似的功能，使用难度高；同时 ClickHouse 运维难度很高，需要研发一个运维系统来支持处理大部分的日常运维工作。
- 并发能力：ClickHouse 的并发能力较弱是一个潜在风险，而 Doris 并发能力更占优势，并且刚刚发布的 2.0 版本支持了 。
- 导入事务：ClickHouse 的数据导入没有事务支持，无法实现 Exactly Once 语义，如导数失败需要删除重导，流程比较复杂；而 Doris 导入数据支持事务，可以保证一批次内的数据原子生效，不会出现部分数据写入的情况，降低了判断的成本。
- 丰富的使用场景：ClickHouse 支持场景单一，Doris 支持场景更加丰富，用户基于 Doris 可以构建用户行为分析、AB 实验平台、日志检索分析、用户画像分析、订单分析等应用。
- 丰富的数据模型：Doris 提供了 Unique、Duplicate、Aggregate 三种数据模型，可以针对不同场景灵活应用不同的数据模型。
- 社区响应速度快：Doris 社区的响应速度是其独有特色，SelectDB 为社区组建了一直完备的社区支持团队，社区的快速响应让我们少走了很多歪路，帮助我们解决了许多问题。
新数仓架构
经过对 Doris 进行综合评估，我们最终决定采用 Doris 对原有架构进行升级优化，并在架构层级进行了压缩。新的架构图如下所示：
在新架构中，数据源层和数据接入层与原有架构保持一致，主要变化是将 Doris 作为新架构的数据服务层，统一了原有架构中的数据计算层和存储层，这样实现了数据门户的统一，大大缩短了数据处理链路，解决了开发流程冗长的问题 。同时，基于 Doris 的高性能，实现了即席查询能力，提高了数据查询效率。另外，Flink 与 Doris 的结合实现了实时数据快速写入，解决了 T+1 数据更新延迟较高的问题。除此之外，借助于 Doris 精简的架构，大幅降低了架构维护的难度。
数据流图
缩短数据处理链路直接或间接地带来了许多收益。接下来，我们将具体介绍引入 Doris 后的数据流图。
总体而言，数据源由 MySQL 和日志文件组成，数据在 Kafka 中进行分层操作（ODS、DWD、DWS），Apache Doris 作为数据终点统一进行存储和计算。应用层包含 C 端、Tableau 和 DMP 系统，通过网关服务从 Doris 中获取相应的数据。
具体来看，MySQL 通过 Canal 把 Binlog 接入 Kafka，日志文件通过 Flume 接入 Kafka 作为 ODS 层。然后经过 Flink SQL 进行清洗、关联维表，形成 DWD 层的宽表，并生成聚合表。为了节省空间，我们将 ODS 层存储在 Kafka 中，DWD 层和 DWS 层主要与 Doris 进行交互。DWD 层的数据一般通过 Flink SQL 写入 Doris。针对不同的场景，我们应用了不同的数据模型进行数据导入。MySQL 数据使用 Unique 模型，日志数据使用 Duplicate 模型，DWS 层采用 Aggregate 模型，可进行实时聚合，从而减少开发成本。
应用场景优化
在应用新的架构之后，我们必须对业务场景的数据处理流程进行优化以匹配新架构，从而达到最佳应用效果。接下来我们以人群圈选、C 端分析数据及精准营销线索为主要场景，分享相关场景流程优化的实践与经验。
一、 人群圈选
原流程（左）中 ，业务人员在画像平台页面上利用表的元数据创建人群圈选任务，任务创建后进行人群 ID 分配，写入到 PG 画像表和 MySQL 任务表中。接着根据任务条件定时在 ES 中查询结果，获取结果后更新任务表的状态，并把 Bitmap 人群包写入 PG。利用 PG 插件提供的 Bitmap 交并差能力操作人群包，最后下游运营介质从 PG 取相应人群包。
然而，该流程处理方式非常复杂，ES 和 PG 中的表无法复用，造成成本高、效益低。同时，原流程中的数据为 T+1 更新，标签必须提前进行定义及计算，这非常影响查询效率。
现流程（右）中 ，业务人员在画像平台创建人群圈选任务，后台分配人群 ID，并将其
