共计 4882 个字符，预计需要花费 13 分钟才能阅读完成。
导读： MOKA 次要有两大业务线 MOKA 招聘（智能化招聘管理系统）和 MOKA People（智能化人力资源管理系统），MOKA BI 通过全方位数据统计和可灵便配置的实时报表，赋能于智能化招聘管理系统和人力资源管理系统。为了提供更齐备的数据反对，助力企业晋升招聘竞争力，MOKA 引入性能强悍的 Apache Doris 对晚期架构进行降级转型，成就了 Moka BI 弱小的性能与优良的用户体验。
作者|Moka 数据架构师 张宝铭
业务需要
MOKA 次要有两大业务线 MOKA 招聘（智能化招聘管理系统）和 MOKA People（智能化人力资源管理系统）。
- MOKA 招聘零碎笼罩社招、校招、内推、猎头治理等场景，让 HR 取得更高效的招聘体验，更便捷的合作体验，让管理者取得招聘数据洞见，让招聘降本增效的同时，建立企业在候选人心目中的业余形象。
- MOKA People 笼罩企业所须要的组织人事、假期考勤、薪酬、绩效、审批等高频业务场景，买通从招聘到人力资源管理的全流程，为 HR 工作提效赋能。通过多维度数据洞见，助力管理者高效科学决策。全生态对接，更加重视全员体验，是一款工作体验更愉悦的人力资源管理系统。
而 MOKA BI 通过全方位数据统计和可灵便配置的实时报表，赋能于智能化招聘管理系统和人力资源管理系统。通过 PC 端和挪动端的多样化报表展现，为企业改善招聘业务提供数据反对，全面晋升招聘竞争力，从而助力科学决策。
MOKA BI 晚期架构
Moka BI 数仓晚期架构是类 Lambda 架构，实时处理和离线解决并存。
- 实时局部数据次要起源为结构化的数据，Canal 采集 MySQL 或 DBLE（基于 MySQL 的分布式中间件）的 Binlog 输入至 Kafka 中；未建模的数据依照公司分库，存储在业务 DBLE 中，通过 Flink 进行实时建模，将计算后的数据实时写入业务 DBLE 库，通过 DBLE 提供报表查问能力，反对数据大屏和实时报表统计。
- 离线局部涵盖了实时局部数据，其结构化数据来源于 DBLE 的 Binlog，明细数据在 Hbase 中实时更新，并映射成 Hive 表，非结构化数据通过 ETL 流程，存储至 Hive 中，通过 Spark 进行进行离线局部建模计算，离线数仓 ADS 层数据输入至 MySQL 和 Redis 反对离线报表统计，明细数据又为指标预测和搜寻等内部利用提供数据反对。
现状与问题
在晚期数仓架构中，为了实现实时建模以及实时报表查问性能，就必须要求底层数据库可能承载业务数据的频繁插入、更新及删除操作，并要求反对规范 SQL，因而过后咱们抉择 DBLE 作为数据存储、建模、查问的底层库。晚期 Moka BI 灰度期用户较少，业务数据量以及报表的使用量都比拟低，DBLE 尚能满足业务需要，但随着 Moka BI 逐步面向所有用户凋谢，DBLE 逐步无奈适应 BI 报表的查问剖析性能要求，同时实时与离线架构拆散、存储老本高且数据不易保护，亟需进行降级转型。
技术选型
为匹配业务飞速增长的要求、满足更简单的查问需要，咱们决定引入一款性能突出的 OLAP 引擎对 Moka BI 进行降级革新。同时出于多样化剖析场景的思考，咱们心愿其可能撑持更宽泛的利用场景。调研的次要方向包含 报表的实时查问能力、数据的更新能力、规范的查问 SQL 以及数据库的可维护性、扩展性、稳定性等。
确定调研方向后，咱们首先对 Greenplum 开展了调研，其特点次要是数据加载和批量 DML 解决快，但受限于主从双层架构设计、存在性能瓶颈，且并发能力很无限、性能随着并发量减少而疾速降落，同时其应用的是 PG 语法、不反对 MySQL 语法，在进行引擎切换时老本较高，因而在基本功能调研完结后便不再思考应用。
随后咱们对 ClickHouse 进行了调研，ClickHouse 在单表查问场景下性能体现十分优异的，然而在多表 Join 场景中性能体现不尽如人意，另外 ClickHouse 短少数据实时更新和删除的能力，仅实用于批量删除或批改数据，同时 ClickHouse 对 SQL 的反对也比拟无限，应用起来须要肯定的学习老本。
紧接着咱们对近几年长驱直入的 Apache Doris 进行了调研，在调研中发现，Doris 反对实时导入，同时也反对数据的实时更新与删除，能够实现 Exactly-Once 语义；其次，在实时查问方面，Doris 能够实现秒级查问，且在多表 Join 能力的反对上更加强劲；除此之外，Doris 简略易用，部署只需两个过程，不依赖其余零碎，兼容 MySQL 协定，并且应用规范 SQL，可疾速上手，部署及学习老本投入均比拟低。
Benchmark
在初步调研的根底之上，咱们进一步将 Apache Doris、Clickhouse 与当下应用的 DBLE 在查问性能上进行了多轮测试比照，查问耗时如下：
- 多表 Join：随着 SQL Join 数量的增多，Doris 和 ClickHouse 性能体现差距越来越大，Doris 的查问提早绝对比较稳定，最长耗时仅为 3.2s；而 ClickHouse 的查问提早出现指数增长，最长耗时甚至达到 17.8s，二者性能最高相差 5 倍，DBLE 的查问性能则远不如这两款产品。
- 慢查问： 在线上慢查问 SQL 的比照测试中，Doris 的性能同样十分稳固，不同的 SQL 查问根本都能在 1s 内返回查问后果，ClickHouse 与之比照查问提早稳定较大、性能体现很不稳固，二者雷同 SQL 性能差距最大超过 10 余倍。
通过以上调研比照，能够看出 Apache Doris 不论是在基本功能上、还是查问性能上体现都更胜一筹，因而咱们将指标锁定了 Doris，并决定尽快引入 Apache Doris 作为 Moka BI 新一代 数仓 架构的查问引擎。
新版架构
在引入 Doris 之后，Moka BI 数仓架构的次要变动是将 OLAP 和 OLTP 进行拆散，即应用 DBLE 反对数据的实时建模，数据来源于 Moka 零碎的业务数据，蕴含了结构化和半结构化的数据，通过 Flink 读取 DBLE Binlog，实现数据去重、合并后写入 Kafka，Doris 通过 Routine Load 读取 Kafka 实现数据写入，此时 DBLE 仅作为数据建模合成应用，由 Doris 提供报表查问能力。
基于 Doris 列存储、高并发、高性能等个性，Moka BI 报表采纳自助形式构建实现，撑持客户依据需要灵便配置行、列、筛选的场景。与传统报表按需要定制开发方式比照，这种自助式报表构建非常灵活，平台开发与需要开发齐全独立，需要实现速度失去极大的晋升。
数据导入方面，数据通过 Routine Load 定期批量导入到 Doris 数据仓库中，保障了数据的准实时同步。通过对系统数据收集与建模，及时向客户提供最新的业务数据，以帮忙客户疾速理解招聘状况，并做出无效的调整。
数据更新方面，Doris 在大数据量（单表几十亿）的场景下，体现出了突出的数据更新和删除能力，Moka BI 读取的是业务库的 Binlog 数据，其中有大量的更新以及删除操作，Doris 能够通过 Routine Load 的 Delete 配置实现实时删除，依据 Key 实现幂等性写入，配合 Flink 能够做到真正的 Exactly-Once。在架构中减少了 Routine Load 后，数仓能够实现 1 分钟级别的准实时 ， 同时联合 Routine load + Kafka 能够实现流量的削峰，保障集群稳固，并且能够通过重置 Kafka 偏移量来实现间数据重写，通过 Kafka 实现多点生产等。
数据查问方面，充分利用 Doris 的多表 Join 能力，使得零碎可能实现实时查问。咱们将不同的数据表依照关联字段进行连贯，造成一个残缺的数据集，基于数据集可进行各种数据分析和可视化操作，同时可高效应对任意条件组合的查问场景以及须要灵便定制需要的查问剖析场景，在某些报表中，须要 Join 的表可能达到几十张，Doris 弱小的 Join 性能，使 Moka BI 的报表查问能够达到秒级响应。
运维治理方面，Doris 部署运维简略不便，不依赖第三方组件，无损弹性扩缩容，主动数据平衡，集群高可用。Doris 集群仅有 FE 和 BE 两个组件，不依赖 Zookeeper 等组件即可实现高可用，部署、运维不便，相比传统的 Hadoop 组件，十分敌对，反对弹性扩容，只需简略配置即可实现无损扩容，并且能够主动负载数据到扩容的节点，大大降低了咱们引入新技术栈的难度和运维压力。
调优实际
新架构理论的落地应用中，咱们总结了一些调优的教训，在此分享给大家。
在 Moka BI 报表查问权限场景中，同样配置的报表，有权限认证 时查问速度比 没有权限认证 时慢 30% 左右，甚至呈现查问超时，而 超管权限 查问时则失常，这一景象在数据量较大的客户报表中尤为显著。
人力资源管理业务的数据权限有着极为严格和精密的管控需要，除了 SaaS 业务本身对于不同租户间的数据隔离要求外，还须要针对业务人员的身份角色、治理部门领域以及被管理人员的信息敏感水平对可见数据的范畴进行进一步细分，因而在 Moka BI 权限功能模块的设计之时就思考并实现了极为灵便的自定义配置化计划。例如 HRBP 与 PayRoll、HRIS 等角色的可见字段不同、不同职级或部门但角色统一用户的可见数据区间不同，同时针对局部敏感的人员信息还须要做数据过滤，或者出于治理受权的需要长期开明某一权限，甚至以上权限要求还会进行多重的穿插组合，以保障每一用户可查看的数据、报表、信息均被限度在权限范畴以内。
因而当用户须要对数据报表进行查问时，会先在 Moka BI 的权限治理模块进行多重验证，验证信息会通过 in 的形式拼接在查问 SQL 中并传递给 OLAP 零碎。随着客户业务体量的增大，对于权限管控的要求越精密、最终所产生的 SQL 就越简单，局部业务规模比拟大的客户报表会呈现上千甚至更多的权限限度，因而造成 OLAP 零碎的 id 过滤工夫变长，导致报表查问提早减少，给大客户造成了体验不佳。
解决方案：
为适配该业务场景，咱们通过查看官网的文档发现 Doris Bloom Filter 索引的个性能够很好的解决该问题
Doris BloomFilter 索引应用场景：
- BloomFilter 实用于非前缀过滤。
- 查问会依据该列高频过滤，而且查问条件大多是
in和=过滤。 - 不同于 Bitmap，BloomFilter 实用于高基数列，比方 UserID。因为如果创立在低基数的列上，比方“性别”列，则每个 Block 简直都会蕴含所有取值，导致 BloomFilter 索引失去意义。
通过验证，能够通过上方比照报表看到，将相干 ID 字段减少 BloomFilter 索引后 ，权限验证场景查问速度晋升约 30%，有权限验证的报表超时的问题也失去了改善。
收益与总结
目前 Moka BI Doris 有两个集群， 共 40 台服务器， 数仓 共保护了 400 多张表 ，其中 50 多张表数据量超过 1 亿，总数据量为 T B 级别。
引入 Apache Doris 革新了新的数据仓库之后，满足了日益增长的剖析需要以及对数据实时性的要求，总体收益蕴含以下几点：
- 高性能数据查问： Doris 基于列存储技术，可能疾速解决大量的数据，并反对高并发的在线查问，解决了关系型数据库无奈反对的简单查问问题，简单 SQL 查问的速度回升了一个数据量级。
- 数据仓库 的可扩展性： Doris 采纳分布式集群架构，能够通过减少节点来线性晋升存储和查问瓶颈，突破了关系型数据库数据单点限度问题，查问性能得以显著晋升。
- 更宽泛的利用： 基于 Doris 构建了对立的数据查问平台，利用不再局限于报表服务，对于离线的查问也有很好的撑持，能够说 Doris 的引入是构建数仓一体化的前奏。
- 实现自助式剖析： 基于 Doris 弱小的查问能力，咱们引入了全新的报表构建形式，通过用户自助构建报表形式，可能疾速满足用户的各种灵便需要。
在应用 Doris 的两年多工夫里，Moka BI 与 Apache Doris 独特成长、共同进步，能够说 Doris 成就了 Moka BI 弱小的性能与优良的用户体验；也正是 Moka BI 非凡的应用场景，也丰盛了 Doris 的优化方向，咱们提的很多 Issue 与倡议，通过版本更新迭代后使其更具竞争力。在将来的工夫里，Moka BI 也会紧跟社区脚步，一直优化、回馈社区，心愿 Apache Doris 和 SelectDB 倒退越来越好、越来越弱小。