{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/user-case-moka",
"result": {"pageContext":{"blog":{"id":"Blogs_479","title":"TiDB in SaaS丨TiDB 在 Moka BI 场景下的应用","tags":["TiDB","SaaS"],"category":{"name":"案例实践"},"summary":"在综合考虑兼容性、稳定性、简介性、高可用、易用性等因素后，Moka BI 选择了 TiDB 作为支撑新架构的数据库，解决了数据壁垒，降低业务复杂度，实现了全面的性能提升。","body":"> 本文作者为 Moka 数据架构师张晓辉\n\n## 导读\n\nMoka 是一家 HR SaaS 服务提供商，致力于通过一流技术和服务赋能企业的人才战略。Moka 的 BI 系统通过数据统计和实时报表等方式，实现了企业招聘和人力资源管理系统的智能化。文章重点介绍了 Moka BI 对其数据库架构的革新，分享了其系统现状及对选型的思考。在综合考虑兼容性、稳定性、简洁性、易用性、高可用等因素后，Moka BI 选择了 TiDB 作为支撑新架构的数据库，解决了数据壁垒，降低业务复杂度，实现了全面的性能提升。\n\n## Moka BI 介绍\n\nMoka 是一家致力于为全员带来更好体验的 HR SaaS 服务商，从 2015 年成立到现在已累计获得数十亿元的融资，先后服务小米、万科、太平洋保险等各领域的头部企业，累计服务超 2000 家客户，核心产品智能化招聘管理系统和人力资源管理系统，为中大型企业提供从招聘、入职、薪酬、假勤、绩效等人力资源全模块管理，为企业提供极致体验、数据驱动的 HR SaaS 产品，致力于通过一流技术和服务赋能企业的人才战略。 \n\nMoka BI 则通过全方位的数据统计和可灵活配置的实时报表，赋能智能化招聘管理系统和人力资源管理系统，通过 PC 端和移动端的多样报表展示，从而改善招聘业务、提供数据支持、提升招聘竞争力，从而助力科学决策。 \n\n\nMoka BI\n\nMoka BI 的架构主要是类似于 Lambda 架构，实时处理和离线处理并存，实时数据主要来源为结构化的数据，Canal 采集 MySQL 或者 DBLE（基于 MySQL 的分布式中间件） 的 binlog，输出是 Kafka，未建模的数据按照公司进行分片，存储在业务的 DBLE 中，通过 Flink 进行实时建模，将计算后的数据写入 BI DBLE。Doris 定时同步 BI DBLE 的数据，支持数据大屏和实时报表统计，离线部分则涵盖了实时部分的数据，其结构化的数据来源于建模后的 BI DBLE 数据，明细数据存储在 HBase 中，并进行实时更新，映射成 Hive 表，非结构化的数据通过 ETL 流程存储至 Hive 中，并通过 Spark 进行计算、建模，离线数仓 ADS 层的数据，最终输出至 MySQL Redis 中，支撑离线报表统计，明细数据又支持招聘预测和搜索等外部应用。\n\n\nBI 系统架构\n\n基于 BI 整体架构，接下来看实时数据的走向和现状。首先实时数仓都是基于模型配置在 BI DBLE 中进行实时建模，BI DBLE 中的数据也是按照公司 ID 进行分库，建模后的数据通过 Canal 再次写入 Kafka，此时会有两个 Flink 程序消费该 Kafka 的数据，考虑到 Doris 的实时写入性能，Flink 会进行窗口数据合并，然后 VP 将数据写入到 Doris 中，同时另一个 Flink 程序也会将数据合并，微批写入到 HBase 中。\n\n## 现状与问题\n\n当前架构的问题也很明显，首先就是在实时建模的过程中，因为单一公司都在一个 shard 上，在大流量下会触发单点瓶颈，从而导致消费延迟。其次在 DBLE、Doris、Hive 数据是大量冗余存储的，造成了数据壁垒。此外，整个数据链路很长，要保证 DBLE、Doris、Hive 的数据都是一致的，数据治理难度非常大，针对上述问题，我们进行了数据库的调研选型。\n\n\n\n## 调研目标 \n\n我们制定了五个方向的调研目标，一期需要满足一到三项。第一个目标是兼容性，数据库要兼容 MySQL 的协议和生态，其次要兼容 Canal 格式的数据变更，还要兼容不同的云环境。第二是离散性，数据库要尽可能避免单点性能瓶颈。第三是服务的稳定性，首先是集群稳定性要高，并且支持多种容灾级别，在发生灾难时，故障响应时间要小于 30 秒，且在故障恢复后不能有数据延迟或者数据丢失。第四是易用性，我们希望数据库集群的维护成本低，并且便于扩缩容。最后的目标是简洁性，首先要简化数据存储，更进一步是最好能简化整个数据架构。\n\n\n\n## 选型对比\n\n针对上述目标我们进行了一系列的调研选型，首先想到的就是 Phoenix on HBase，它的优势很明确，不需要引入额外的存储引擎，所以不涉及到数据的导入导出。它的劣势是在实时领域下，复杂的查询要基于大量的二级索引，索引维护成本比较大，且数据变更要基于协处理器，成本很高。接着，我们又调研了比较流行的 Hudi，它的优势就是整体的架构不需要大的变化，并且实时的数据能够实时入仓入湖，但是在实时存查的情况下会存在写延迟或者读延迟，且数据变更没有办法捕获到下游。 \n\n紧接着我们又调研了 PolarDB，它的优势就是对 MySQL 的兼容性比较好，完美兼容 MySQL 的生态和协议，且迁移成本很低，支持一体化的 HTAP，且没有单点性能，看似很满足我们的调研需求，实际上它有一个很大的劣势就是没办法满足不同的云环境运行，因此也不符合本次的调研目标。 \n\n\n\n## 为什么选择 TiDB\n\n我们最终把目光瞄准了 TiDB，并进行了深度测试，为什么选择 TiDB ？TiDB 完美兼容 MySQL 协议和生态，并且 TiCDC 支持 Canal、Maxwell 等协议，无缝衔接了数据下游，并且支持在多云环境部署。其次，TiDB 带来了性能的提升，TiDB 是 Shared Nothing 架构设计，避免了数据热点，不会形成单点瓶颈，理论上性能会随着节点的无限扩展而没有上限。第三，TiDB 满足金融级高可用，多副本存储和 Multi-Raft 协议同步事务日志，支持多种容灾级别。第四，TiDB 的维护简单，基于 TiUP 一键扩缩容，且扩缩容的过程业务无感知，并且支持实时在线的 DDL。最后，TiDB 具备实时 HTAP 的能力，TiKV 行存支持 OLTP 场景的负载，TiFlash 列存与行存强一致，使用 TiFlash 和 TiSpark 可以满足大部分的 OLAP 场景需求。\n\n\n\n## 系统可行性测试\n\n在理论上都满足之后我们进行了系统的可行性测试，安装部署了 5.4.0 版本的 TiDB 集群，集群安装部署完毕之后进行了数据导入。为了真实模拟线上的业务场景，我们同步了一个业务线的全部数据，大概有 200 多张表，有 50 张表数据超过一亿，单表最大数据量为 30 亿行。实时数据则根据 Flink 同步 binlog 实时读写 TiDB 进行建模。我们的测试主要分为三个用例，第一个用例是单 SQL 串行看平均的响应 RT。同样是用 100 万的 SQL，左边绿色的是 DBLE 的响应时间，右边蓝色的是 TiDB 的响应时间，在简单查询的用例下，DBLE 的平均响应时间为 1.2 毫秒，而 TiDB 为 2.4 毫秒，复杂查询场景下 DBLE 的平均响应时间为 8.7 毫秒，TiDB 为 5.2 毫秒。关联查询下 DBLE 的平均响应时间为 20 毫秒，而 TiDB 为 8.7 毫秒。 \n\n\n\n第二个用例是并发查询，我们用了 200 个并行度，同样是 100 万的 SQL，简单查询下 DBLE 的平均响应时间为 2.5 毫秒，TiDB 为 3.2 毫秒。复杂查询下 DBLE 的平均响应时间为 12.7 毫秒，TiDB 为 7.8 毫秒，关联查询下 DBLE 的平均响应时间为 30 毫秒，TiDB 则在 13.6 毫秒。可以看到单 SQL 串行和并发查询两个用例，在复杂查询和关联查询场景下 TiDB 的平均相应时间明显优于 DBLE。 \n\n第三个用例就是在 200 个并行度下看 QPS 的峰值，首先是单公司场景下，DBLE 的 QPS 峰值在 4K 左右，而 TiDB 达到了 24K，是 DBLE 的六倍之多。多公司场景下，DBLE 峰值为 20K，TiDB 为 80K，是 DBLE 的四倍之多。并且在以上两个场景中，TiDB 的负载未出现过高的现象，理论上未达到 QPS 峰值。在以上测试验证中，TiDB 的表现是完全符合预期的，因此我们决定使用 TiDB 替换 DBLE。 \n\n## 实践调优\n\n我们在迁移过程中也进行了一些适配性的调优，首先是主键表，我们把主键表改为公司 ID+ID 联合主键，并增加了 SHARD ROW ID BITS 和 PRE SPLIT REGIONS 配置，避免了数据写热点的问题。其次 Flink 实时程序会增加雪花 ID 算法，兼容历史数据。为了和 TiCDC 适配，我们也升级了不同云环境下的 Kafka 版本。循环读写的场景在未关闭异步提交配置时，会频繁出现锁冲突的问题，在关闭后虽然会有 7% 的性能损失，但是能有效避免锁冲突的问题，所以我们把异步提交的配置关闭了。此外，TiDB 对大小写敏感，该配置只支持在集群初始化时配置，大家留意一下。 \n\n在适配以外，我们针对 TiDB 还做了一些优化工作，我们把 TiDB 的版本从 5.4.0 升级到 5.4.2，解决了 CDC 捕获特殊符号频繁重启的问题。我们把新增表的 ID 都改为 AUTO RANDOM，这样避免产生热点 ID。TiCDC 我们增加了对应 Kafka 的相关配置，保证了更新顺序及数据可靠性。在索引优化方面，所有的索引都添加了联合的索引，就是公司 ID 加原来的主键 ID。\n\n## 实践成果\n\n\n\n在做了上述适配性调优后，目前 TiDB 的性能得到一定的提升，真实日均 QPS 5K+，高峰稳定在 3w，读写比接近 1:1，性能的提升保证了无延迟的进行实时建模，并且强一致性的多副本提供了服务的稳定性。在 TiDB 线上运行期间有一个节点出现了特殊问题导致宕机，TiDB 在 10 秒内会自动进行恢复，没有影响到线上业务。TiDB 的升级运维也是业务无感知的，我们在迁移人力资源管理系统时，扩容了三个 TiKV 存储节点，在扩容期间对线上业务没有任何影响的。其次，TiDB 还解决了数据壁垒问题，之前两个系统存储的数据是独立的，没办法做一体化的数据访问，目前我们基于 TiDB 的统一存储形成了初级数据湖的使用模式。 \n\n## 总结与展望\n\n\n\n最后谈谈我们对 TiDB 的总结和展望，从 2022 年 7 月开始进行开发和测试，目前 TiDB 的 OLTP 部分已经完成了 Moka BI 全业务线的投产，在多云环境下替换了 DBLE，目前服务稳定可靠，未出现性能瓶颈，圆满达成了 2022 年下半年的目标。 \n\n随着对 TiDB 的使用深入，我们越发地认识到 TiDB 和我们的业务场景是高度匹配的，面向后续 TiDB 的使用我们制定了以下的计划：首先在 2023 年要做到两个统一，第一个统一就是统一数据存储，使用 TiSpark+TiKV 替换现有的 Hive、HBase 和离线数仓；其次我们要深度调研 TiFlash，争取使用 TiDB HTAP 能力支撑 OLTP+OLAP 的统一查询场景，减少数据架构的复杂性，从而降低数据治理的困难性。在两个统一的基础上，我们要建立公司级统一的查询平台，支撑业务部门进行复杂查询，持续提供数据输出能力。","date":"2023-03-21","author":"张晓辉","fillInMethod":"writeDirectly","customUrl":"user-case-moka","file":null,"relatedBlogs":[{"relatedBlog":{"body":"> CRM 并不是简单的销售和客户服务的效率工具。本质上，CRM 是以平台化思维实现业务管理和数据的打通，为 360 度客户旅程提供数字化支撑。\n\nIDC 发布的《IDC 中国企业级应用管理 SaaS 市场，2021H2 》报告显示：2021 年中国企业级应用管理 SaaS 市场规模达 67.8 亿美金，其中 CRM 市场份额为 32%，未来五年将以 23.1% 的 CAGR 快速增长。 \n\n虽然受到疫情影响，但随着企业数字化转型的不断深化，更多的企业需要用数字化手段、标准化流程来提高效率和节约成本。从中国企业级应用管理 SaaS 市场来看，平台化、数据化、生态化成为重要的发展趋势。CRM 作为云计算时代典型的数据密集型应用，提升海量数据的处理能力和时效性成为 CRM 服务商提升客户体验、构建核心竞争力的关键所在。\n\n## CRM 的数据架构面临重重挑战\n\n某中国企业级 CRM 头部服务商，其 CRM 产品支持从营销、销售到服务的全流程自动化业务场景，帮助企业转型为真正“以客户为中心”的数字化运营组织，实现业绩的可持续增长。随着产品能力的迭代加速和业务的规模化增长，该服务商实现了从中小企业到大中型企业的覆盖，为了应对不同行业用户的个性化需求推出了 PaaS 平台，基于平台的定制能力服务垂直行业的特定需求；同时，该服务商发力 C 端市场，陆续推出 SCRM 等产品连接海量 C 端用户，打造客户旅程的一体化闭环。 \n\n同时服务几万家不同规模的企业，打通每家企业各个业务系统的数据，为 360 度客户旅程提供数字化支撑，这些都对 CRM 服务商底层的数据平台提出了非常严苛的要求。该 CRM 服务商的数据平台架构采用多形态混合式数据存储模式来满足多租户架构下可定制的业务需求。下图所示的多租户共享数据库，考虑到大表性能、租户数据量，采用了元数据、租户分库、租户分表的整体方案，共享库按照租户和实体做水平扩展的分库分表设计。 \n\n\n多租户共享数据库的分库分表设计\n\n与此同时，为了满足多租户定制化需求，实体主数据表需要预留大量的扩展列，呈现出数据库表多，列多，索引多等特点，也给 CRM 的数据架构带来了重重挑战：\n\n### 大数据量下的分库分表无以为继\n\n随着业务高速增长，CRM 用户数接近 20 万，租户的增长一方面带来海量数据高并发访问的挑战，另一方面使得单租户单实体库数据量快速增长，单表已经超过千万级别。单体 MySQL 数据库无法水平弹性扩展，配置也已经到极限，出现性能下降的问题。此外，MySQL 的分库分表方案，业务拆分难度大，需要进行代码侧的改动进行适配，维护工作也变得非常繁琐。\n\n### 2B 和 2C 客户的体验大打折扣\n\nCRM 业务具有灵活、多变的的特征，经常遇上索引缺失/索引选取错误或者复杂模糊查询等情况，MySQL 性能完全不可接受，慢查询增多导致客户体验差。在批量操作场景，单个任务可能将系统卡死，大量慢查询堆积，严重的时候甚至会造成 OOM，查询被拉黑名单。\n\n### 业务创新的灵活度受到制约\n\n中国的企业级客户由于行业特点和业务环境的变化，通常对 CRM 有定制化和多样化需求，导致数据库需要预留很多的扩展列，经常需要在数据表中增加字段或者增加索引。MySQL 行宽只有 64K，也不支持 Online DDL，使得业务创新的灵活度受到极大制约。\n\n## CRM 真实场景下 MySQL 和 TiDB 的比拼\n\n通过与 CRM 服务商技术部门的探讨，由于 SaaS 业务的稳定性、性能都对最终客户至关重要，组织了一次全面的 PoC 验证工作，覆盖了产品的性能，兼顾数据迁移、稳定性、安全性、运维监控等能力。 \n\n从业务场景的实测结果可以看到：TiDB 并发处理和查询性能提升明显，千万级以上性能提升 70% 左右，单条、跑批都得到了大幅的性能提升（80% 在毫秒级），原先过长时间查询无返回结果的任务，在 TiDB 中得到好转；各类痛点查询，如权限查询、模糊查询、分页查询、无索引查询、聚合查询、联表查询等性能提升几倍至几百倍不等；TiDB 在添加字段，修改字段，增加索引等 DDL 上优势明显。此外，TiDB 提供高效的同步工具 DM，从 RDS-MySQL 同步到 TiDB 延迟控制在毫秒级别。\n\n## 两套数据架构的对比\n\n某 CRM 服务商原有的数据架构中，OLTP 业务通过 Mycat 连接多套 MySQL 数据库处理和存储应用的数据，所有 MySQL 通过 DataPipline 同步到 Greenplum 数仓，由 Greenplum 提供 OLAP 查询服务。引入 TiDB 分布式数据库替换原有架构之后，所有的 OLTP 业务和 OLAP 查询访问一套 TiDB 集群即可，根据业务的实际需求，灵活增加 TiKV 和 TiFlash 节点即可。 \n\n\n某 CRM 服务商数据平台架构\n\n基于 TiDB 的新架构在高可用、性能、定制化需求、客户体验、开发和运维等多个维度体现出优势：\n\n\n## “两升一降”助力 SaaS 服务商构建核心竞争力\n\n### 提升海量数据的处理能力和时效性\n\nTiDB 分布式数据库按需弹性扩展能力使得 CRM 服务商可以轻松应对租户、2B 与 2C 业务海量数据的增长。对于 CRM 类 SaaS 服务商来说，TiDB 分布式架构对库、表无数量限制，一键实现节点扩缩容，使得使得数据架构可以动态、平滑地适配业务的增长。TiDB 原生分布式特点在高并发查询、缺失索引、模糊查询等方面性能表现优异，无需担心租户增加带来高并发问题以及租户单实体数据量大等问题；TiDB HTAP 能力使得海量数据场景下的各类查询秒级得到反馈，极大提升了 CRM 的用户使用体验。\n\n### 提升 SaaS 服务商的业务灵活性\n\n在 SaaS 的基础上集成 PaaS 能力已经成为中国企业级 CRM 市场发展的重要趋势，为了满足企业用户的高度定制化和多样化需求，PaaS 平台要求数据平台具备高度灵活的可定制能力，例如增加字段完成功能迭代等。TiDB 支持 Online DDL，可实现在线添加字段，修改字段对业务无影响，加快了业务创新的速度，进一步增强了 CRM 等 SaaS 服务商在同行业中的竞争力。\n\n### 多管齐下，降低成本\n\nTiDB 一个数据栈支持混合负载，并提供实时的数据洞察，精简了 CRM 服务商数据平台的架构。从单体数据库集群、ETL 工具、数据仓库的多套系统组合到一个 TiDB 集群，大幅节省了数据在各个技术栈之间同步的时间成本以及多个数据副本的存储成本。TiDB 无需分库分表，提高了产品研发的敏捷度，减轻了各类应用的适配难度，研发人员可以把更多精力放在功能迭代和业务创新上。此外，TiDB 还提供了整套的数据同步及数据库管理、监控工具，进一步降低了后期的运维管理成本。 \n\n采用一个简单、强大、一栈式的数据服务平台成为越来越多 SaaS 企业的选择，这个平台既可以支撑海量在线交易，又可以提供实时分析能力，以极少的 DBA 和资源投入，就可以从容应对不确定的环境、多变的业务挑战。 \n\n\n","author":"PingCAP","category":4,"customUrl":"htap-database-practice-in-a-chinese-saas-provider","fillInMethod":"writeDirectly","id":435,"summary":"CRM 并不是简单的销售和客户服务的效率工具。本质上，CRM 是以平台化思维实现业务管理和数据的打通，为 360 度客户旅程提供数字化支撑。","tags":["HTAP"],"title":"MySQL or TiDB？HTAP 数据库在中国 SaaS 行业头部服务商的应用实践"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}