随着GW2查近几年对商品的稳步耕耘和插值，使用者数量也在不断飙升，销售业务的冲破更为倚赖统计数据借力，系统化的使用者 / 顾客营运也成为提高新体验、推动消费需求的重要动力系统在这样的大背景下正式引入 Apache Doris 指数函数仓构架进行升级改造，同时实现了统计数据门户的统一，缩短了统计重要信息处理信道，统计数据引入速率提高 75 %，500 万及以下群体推派能同时实现微秒级响应，收获了公司内部统计数据部门、销售业务方的一致好评。
作者 | GW2查动态排序负责人 陈浩 GW2查是中国领先的商业性查阅平台，以公开统计数据为突破口、以关系为核心的商品，帮助现代企业或个人降低成本，为防范化解金融风险方面提供更多了商品化的解决方案现阶段已收录全国 3 亿多家社会虚拟重要信息，300 多种不同层次重要信息及时处理预览，致力于构建商业性安全，进而同时实现 " 公平看清世界 "。
销售业务大背景GW2查的统计基础架构主要服务于三个销售业务情景，每个情景都有其特点和市场需求，具体如下：亿级使用者群体推派：群体推派情景中现阶段有 100+ 群体包，他们须要根据 SQL 条件推派群体包，来全力支持群体包的黏合差、群体包动态推派和群体包预览通知下游等市场需求。
比如：推派出付款未缴付超过 5 分钟的使用者，他们透过使用者标签能直观掌握使用者缴付状态，为营运 & 网络营销项目组提供更多更系统化的群体管理服务，进而提高转换率多元公益活动支撑的精准网络营销：该情景现阶段全力支持了 1000 多个指标，可全力支持Madurai查阅，根据公益活动效果及时处理调整营运策略。
比如在 " 开工季 " 公益活动中，须要为统计数据挖掘 & 营运项目组提供更多统计数据全力支持，进而生成建模的公益活动驾驶舱高并发的 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 群体推派系统。
问题与挑战：依托于旧有构架的投入使用，松讷了销售业务方的市场需求，但随着GW2查近几年对商品的稳步耕耘和插值，使用者数量也在不断飙升，销售业务的冲破更为倚赖统计数据借力系统化的使用者 / 顾客营运也成为提高新体验、推动消费需求的重要动力系统。
在这样的大背景下，旧有构架的缺点逐渐暴露：合作开发流程乏味：体现在统计重要信息处理信道上，比如当面对一个单纯的合作开发市场需求，须要先拉取统计数据，再经过 Hive 排序，然后透过 T+1 预览引入统计数据等，统计重要信息处理信道较长且复杂，非常影响合作开发效率。
不全力支持Madurai查阅：体现在报表服务和群体推派情景中，所用的指标无法根据条件直接查阅，必须提前进行定义和合作开发T+1 预览延迟高：T+1 统计数据时效性已经无法提供更多精确的线索，主要体现在报表和群体推派情景上运维难度高：旧有构架具有多条统计重要信息处理信道、多组件耦合的特点，运维和管理难度都很高。
理想构架基于以上问题，他们决定对构架进行升级改进，在正式升级之前，他们希望未来的构架能做到以下几点：原构架涉及 MySQL 、PG、ES 等多个组件，并为不同应用提供更多服务；他们希望未来的构架能兼容 MySQL 协议，同时实现低成本替换、无缝衔接以上组件。
全力支持Madurai查阅且性能优异，Madurai查阅能够给销售业务方提供更多更灵活的表达方式，销售业务方能从多个角度、多个层次对统计数据进行查阅和分析，更好地发现统计数据的规律和趋势，帮助销售业务方更精准备地做出决策全力支持动态聚合，以减轻合作开发负担并保证排序结果的准确性。
统一统计数据出口，原构架中统计数据出口不唯一，他们希望未来的构架能更统一统计数据出口，缩短信道维护成本，提高统计数据的可复用性全力支持高并发， 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 的高性能，同时实现了Madurai查阅能力，提高了统计数据查阅效率另外，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 中进行Madurai查阅，获取结果后对任务表状态进行预览，并将群体包写入 Doris。
后续根据时间进行微批轮询，利用 Doris Bitmap 函数提供更多的黏合差功能与上一次的群体包做差集，如果有群体包预览会主动通知下游引入 Doris 后，旧有流程的问题得到了解决，新流程以 Doris 为核心构建了群体推派服务，全力支持群体包动态预览，新标签无需提前定义，可透过条件配置自助生成，减少了合作开发时间。
新流程表达方式更为灵活，为群体包 AB 实验提供更多了便捷的条件流程中采用 Doris 统一了明细统计数据和群体包的储存介质，同时实现销售业务聚焦，无需处理多组件统计数据之间的读写问题，达到了降本增效的终极目标二、C 端分析统计数据及精准网络营销线索情景
原流程：在原流程中，如果销售业务提出新市场需求，须要先发起市场需求变更，再经过评审、排期合作开发，然后开始对 Hive 中的统计数据模型进行合作开发并进行测试，测试完成后进行数仓上线，配置 T+1 调度任务写入 MySQL，最后 C 端和精准网络营销系统对 MySQL 统计数据进行读取。
原流程信道复杂，主要体现在流程长、成本高、上线周期长现流程：当前明细统计数据已经在 Doris 上线，当销售业务方发起市场需求变更时，只须要拉取元统计数据管理平台元统计数据重要信息，配置查阅条件，审批完成后即可上线，上线 SQL 可直接在 Doris 中进行Madurai查阅。
相比原流程，现在的流程大幅缩短了市场需求变更流程，只需进行低代码配置，成功降低了合作开发成本，缩短了上线周期优化经验为了规避风险，许多公司的群体包 user_id 是随机生成的，这些 user_id 相差很大且是非连续的。
然而，使用非连续的 user_id 进行群体推派时，会导致 Bitmap 生成速度较慢因此，他们生成了映射表，并生成了连续稠密的 user_id当使用连续 user_id 推派群体时，速度较之前提高了 70%。
用 ID 映射表样例统计数据：从图可知原始使用者 ID 由多位数字组合，并且 ID 很稀疏（使用者 ID 间相差很大），而连续使用者 ID 则 从 1 开始，且 ID 很稠密案例展示：1、使用者 ID 映射表：使用者 ID 映射表将使用者 ID 作为唯一键模型，而连续使用者 ID 则透过使用者 ID 来生成，一般从 1 开始，严格保持单调递增。
须要注意的是，因为该表使用频繁，因此将 in_memory 设置为 true，直接将其缓存在内存中：2、群体包表群体包表是以使用者标签作聚合键的模型，假设以 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 的商业性化公司，为社区投入了大量的研发和使用者全力支持力量，在使用过程中遇到任何问题都能及时处理响应，为他们降低了许多试错成本。
还木有评论哦，快来抢沙发吧~