导读： 随着天眼查近年来对产品的继续深耕和迭代，用户数量也在一直攀升，业务的冲破更加依赖于数据赋能，精细化的用户 / 客户经营也成为晋升体验、促成生产的重要能源。在这样的背景下正式引入 Apache Doris 对数仓架构进行降级革新，实现了数据门户的对立，大大缩短了数据处理链路，数据导入速率晋升 75 %，500 万及以下人群圈选能够实现毫秒级响应，播种了公司外部数据部门、业务方的统一好评。
作者： 王涛，天眼查实时计算负责人
业务需要
天眼查的数据仓库次要服务于三个业务场景，每个场景都有其特点和需要，具体如下：
- 亿级用户人群圈选： 人群圈选场景中目前有 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，并将其写入 MySQL 工作表中。首次圈选时，依据工作条件在 Doris 中进行即席查问，获取后果后对工作表状态进行更新，并将人群包写入 Doris。后续依据工夫进行微批轮询，利用 Doris Bitmap 函数提供的交并差性能与上一次的人群包做差集，如果有人群包更新会被动告诉上游。
引入 Doris 后，原有流程的问题失去了解决，新流程以 Doris 为外围构建了人群圈选服务，反对人群包实时更新，新标签无需提前定义，可通过条件配置自助生成，缩小了开发工夫。新流程表达方式更加灵便，为人群包 AB 试验提供了便捷的条件。流程中采纳 Doris 对立了明细数据和人群包的存储介质，实现业务聚焦，无需解决多组件数据之间的读写问题，达到了降本增效的终极目标。
C 端剖析数据及精准营销线索场景
原流程： 在原流程中，如果业务提出新需要，须要先发动需要变更，再通过评审、排期开发，而后开始对 Hive 中的数据模型进行开发并进行测试，测试实现后进行数仓上线，配置 T+1 调度工作写入 MySQL，最初 C 端和精准营销系统对 MySQL 数据进行读取。原流程链路简单，次要体现在流程长、老本高、上线周期长。
现流程： 以后明细数据曾经在 Doris 上线，当业务方发动需要变更时，只须要拉取元数据管理平台元数据信息，配置查问条件，审批实现后即可上线，上线 SQL 可间接在 Doris 中进行即席查问。相比原流程，当初的流程大幅缩短了需要变更流程，只需进行低代码配置，胜利升高了开发成本，缩短了上线周期。
优化教训
为了躲避危险，许多公司的人群包 user_id 是随机生成的，这些 user_id 相差很大且是非间断的。然而，应用非间断的 user_id 进行人群圈选时，会导致 Bitmap 生成速度较慢。因而，咱们生成了映射表，并生成了间断浓密的 user_id。当应用间断 user_id 圈选人群时， 速度较之前晋升了 70%。
用户 ID 映射表样例数据：从图可知原始用户 ID 由多位数字组合，并且 ID 很稠密（用户 ID 间相差很大），而间断用户 ID 则 从 1 开始，且 ID 很浓密。
案例展现：
- 用户 ID 映射表：
用户 ID 映射表将用户 ID 作为惟一键模型，而间断用户 ID 则通过用户 ID 来生成，个别从 1 开始，严格放弃枯燥递增。须要留神的是，因为该表应用频繁，因而将 in_memory 设置为true，间接将其缓存在内存中：
- 人群包表
人群包表是以用户标签作聚合键的模型，假如以 user_id 大于 0、小于 2000000 作为圈选条件，应用原始 user_id 进行圈选消耗的工夫远远远大于间断浓密 user_id 圈选所耗时间。
如下图所示，左侧应用 tyc_user_id圈选生成人群包响应工夫：1843ms，右侧应用使 tyc_user_id_continuous 圈选生成人群包响应工夫：543ms。耗费工夫大幅缩短
规模与收益：
引入 Doris 后，咱们曾经搭建了 2 个集群，承载的数据规模正随着迁徙的推动而继续增大。目前，咱们曾经解决的数据总量曾经达到了数十 TB，单日新增数据量曾经达到了 数亿条，而数据体量还在持续增长中。此外，咱们在 Doris 上运行的指标和人群包数量曾经超过了 500，别离涵盖了商查、搜寻、经营、用户和营收五大类指标。
Doris 的引入满足了业务上的新需要，解决了原有架构的痛点问题，具体表现为以下几点：
- 降本增效： Doris 对立了数据的门户，实现了存储和计算的对立，进步了数据 / 表的复用率，升高了资源耗费。同时，新架构优化了数据到 MySQL、ES 的流程，开发效率失去无效晋升。
- 导入速率晋升： 原有数据流程中，数据处理流程过长，数据的导入速度随着业务体量的增长和数据量的一直回升而急剧下降。引入 Doris 后，咱们依赖 Broker Load 优良的写入能力，使得 导入速率晋升了 75% 以上。
- 响应速度：Doris 的应用进步了各业务场景中的查问响应速度。例如，在人群圈选场景中，对于 500 万及以下的人群包进行圈选时，可能做到毫秒级响应。
将来布局
正如前文所讲，Apache Doris 的引入解决了许多架构及业务上的难题，初见成效，同时也播种了公司外部数据部门、业务方的统一好评，将来咱们将持续摸索，基于 Doris 开展更深度的利用，不久的未来，咱们将重点推动以下几个方面工作：
- 离线指标实时化：将更多的指标从离线转为实时，提供更及时的数据服务。
- 搭建数据血统零碎：将代码中的血缘关系从新定义为可视，全面构建数据血缘关系，为问题排查、链路报警等提供无效反对。
- 摸索批流一体路线：从使用者的角度思考设计，实现语义开发层的对立，使数据开发更便捷、更低门槛、更高效率。
在此特别感谢 SelectDB 团队，作为基于 Apache Doris 的商业化公司，为社区投入了大量的研发和用户反对力量，在应用过程中遇到任何问题都能及时响应，为咱们升高了许多试错老本。将来，咱们也会更积极参与社区奉献及流动中来，与社区共同进步和成长，欢送大家抉择和应用 Doris，置信 Doris 肯定不会让你悲观。