IT评测·应用市场-qidao123.com
标题:
用户实践：从 HBase 升级为OceanBase，仟传实现110000 TPS的千亿级KV性能优
[打印本页]
作者:
道家人
时间:
2024-7-15 21:25
标题:
用户实践：从 HBase 升级为OceanBase，仟传实现110000 TPS的千亿级KV性能优
本文作者：
仟传网络科技技能专家 刘贵宗 & 肖旺生
一、业务需求及选型背景
仟传网络科技（TargetSocial），是国内着名的内容社交平台整合营销服务商，为企业级客户提供高效的KOL（关键意见领袖）和公/私域流量管理方案。公司旗下拥有四大焦点业务，包罗企微生态、品牌私域、社媒采买以及抖音生态，这些业务分别由企微SCRM系统、会员营销管理系统、社媒KOL智能采买系统以及抖音SCRM整合运营平台等自主研发的系统支撑。致力于为广告主打造一个覆盖传播、投放、监测、评估等全链路的立体内容生态，从而创造更具价值的营销服务。
由于其业务场景丰富，涉及客户管理、用户行为分析、标签管理、粉丝管理、互动管理、素材管理、私域流量和员工管理、内容精准推送、裂变传播和传播效果监测、热点监测、品牌舆情监测、线上商城等诸多范畴，仟传对数据处置惩罚产物的支撑本领要求灵活、精细、快速。为了满足业务发展对数据处置惩罚本领的不断增长，仟传网络科技对其 KV 方案进行了升级，从 HBase 迁移至 OceanBase。
本文将分享仟传 KV 方案从 HBase 升级为基于 OceanBase 的 OBKV 实践经验
。
为了满足业务发展需求，我们在技能层面对新的数据库方案提出了以下
6 点关键需求
：
支持动态 Schema：
在我们的场景中，字段数量可能会频繁变更，传统关系型数据库接纳固定 Schema 的方式无法得当我们的需求，因此业务要求存储方案必须支持动态 Schema，能够随业务须要动态增减字段。
支持部分列更新
：一条数据可能拥有上百个字段，我们渴望能够便捷地更新此中的一部分字段，所以要求数据操作的粒度能够细化到字段级。
单表支持千亿级记录存储：
在存储本领方面，我们须要单表支持千亿级别的记录行存储。
支持数据高速摄入：
数据可快速灌入数据库，避免上游数据陡增导致数据流积压的情况。
毫秒级点查相应：
我们的 KV 应用于点查场景，要求点查一条完整的业务数据的相应时间在几十毫秒以内。我们渴望数据库做到 5 毫秒内相应点查需求，即便在集群高负载下，也能够保持快速相应，即短时间内要点查 1000 万个 ID。
单字段大小支持 1MB
：由于业务数据中可能存在超长文本，因此我们须要单字段存储支持 1MB 大小。
根据上述需求，我们对比了 Doris、HBase、OceanBase。然而，由于 Doris 在实行部分列更新时会消耗大量 CPU 资源，且重复数据多次热点写入时存在性能缺陷，与我们的场景明显不匹配，因此没有对 Doris 进行更深入的调研。以下是 HBase、OceanBase 在性能、部署、运维、架构以及数据分布方面进行对比分析。
颠末综合评估，我们最终选择了OceanBase 作为其 KV 方案的数据库，选择 OceanBase 的重要缘故原由如下。
成本更低：存储资源消耗小，基于 zone 实现 3 副本冗余，保证数据可靠性，存储资源消耗更小，相于 HBase 更具成本优势。
运维简朴：OcenBase 提供丰富的文档及界面化操作工具，部署、运维更简朴，减轻了运维负担。
部分列更新性能更优：正常的 put 操作即支持部分列更新，对性能消耗较小，满足了业务对数据操作灵活性的要求。
热点数据写入性能更佳：通过对时间戳字段的设计、数据去重、TTL 以及差别粒度的合并等操作，可避免重复数据多次写入时的性能题目，保证了数据写入的流畅性。
数据分布均匀：数据均匀分布在各分区上，分区均匀分布在各 OBServer上，保证各 OBServer 上的数据分布是均衡的，提升了系统的稳定性和性能。
很多时间各人把 OceanBase 作为一个关系型数据库来使用，中间层有 OBSQL，上层有 JDBC，从客户端做一整套从前到后的调用。然后，现实上 OceanBase 分为多个条理，如下图所示：
在这种架构下，底层的 OBKV 和 OBSQL 共享一个 OceanBase 强同等性分布式存储，同时分别通过独立的客户端及计算层进行通讯，这种独特架构赋予了 OceanBase 以下 5 个明显优势。
多模融合：通过一套数据库管理多种模型数据（OBKV & OBSQL）。
运维视图统一：共享一套完备的数据库运维工具（OCP、ODC、OMS等）。
完备的容灾方案：支持单 Zone 或跨 Zone 容灾，并提供主备库容灾本领。
资源隔离：支持原生多租户，提高资源使用率。
高级特性：包罗安全加密、接纳站、冷热数据分离、备份恢复等功能。
值得一提的是，OceanBase 的 OBKV 具有两类产物本领，原生OBKV和兼容HBase 的 OBKV。
原生 OBKV 支持直接调用 OBKV 提供的 API，直接访问存储事务层，非常的简洁易用。这种情况下，时延很低，吞吐量很高，重要适用于给开源及自研计算层提供高可靠、可扩展的强同等性存储引擎。兼容 HBase 版本的 OBKV 则更得当专注于上层业务的场景，可以将 OBKV 作为工具使用，不但兼容 HBase 协议和模型，还具备相比 HBase 更高的性能、更稳定的存储、更平滑的时延、更易用&完备的运维工具，是替代开源 HBase 的抱负选择。
二、OceanBase在测试和生产环境的性能表现
以下是我们对 OceanBase 在测试环境和生产环境的性能观测情况进行的详细分析。
在测试环境，我们使用 OceanBas 4.2.1 版本，部署了 2-2-2 集群架构，此中包含3个 Zone。每个 Zone 里放置了 2 台设置为 80 核 256GB 的呆板，日记盘为 1TB 的 NVME SSD 盘，三块盘构成 Raid 0，总存储空间是 21TB，由于整个集群只面向一个业务，因此只创建了一个 64 核 180GB 的业务租户。
下面两张图分别展示了测试阶段读性能和写性能的表现。总体而言，TPS 可以稳定在每秒 6 万左右，事务相应时间维持在 2~4 毫秒之间，大多数时间相应速度为 2 毫秒。可见，测试阶段的性能表现非常精彩。
下面两张图展示了 OceanBase 在我们现实生产场景下的性能表现。
在现实生产场景中，TPS 根本可以稳定在每秒 5 万，但并不是它的上限，而是一个稳定值。当上游数据出现积压时，TPS 会有明显爬升，甚至可以达到每秒 11 万。也就是说，在上游压力增大的时，OceanBase 的 OBKV 可以快速追平数据，解决积压情况。在这个过程中，事务相应时间根本维持在 2~3 毫秒之间。
综合测试环境及现实场景的性能表现，尤其是在运行期间，无 HBase GC 题目, 运行非常稳定。因此，OceanBase 完全可以满足我们的需求。
三、OBKV使用实践及优化
自 2023 年 10 月开始，我们成为了 OceanBase OBKV 模式的早期使用者之一。到目前为止，已颠末去了五个月，我们在使用过程中积累了一些实践经验和优化心得，渴望与更多 OceanBase 用户分享我们的经验。
如下图所示，这是我们的数据处置惩罚流程。我们将数据分为行为数据（事件数据）和维度数据两类，以用户表为例，紫色模块代表 Kafka 的流式数仓，绿色模块代表OBKV，作为缓存层与红色模块的 Flink 流式任务进行交互，红色线条代表事件数据或日记数据的流转过程。我们的用户数据（维度数据）是从事件表中抽取，但抽取的数据不完整，须要通过 API 模式补数据再回写到 OBKV。同时，在向下游发送事件数据时，我们会关联最新的用户信息，最终将数据写入下游系统。
我们的数据重要有以下三个特点：
数据量比力大，每天在Kafka里单个 topic 有 10 亿+的数据量。
数据是 JSON 格式，此中的 scheme 字段不固定，包含一些嵌套范例和引用关系。
数据有重复，这些重复的数据有可能是整个 JSON 的一部分，此中的部分字段会被更新。
受上述数据特点的影响，我们在测试 OBKV 的过程中遇到了几个题目。
题目1：TPS下降。在正常流量情况下，TPS 能够稳定在每秒 3 万，但随着时间的推移，TPS 会开始渐渐下降。颠末 5~6 小时，TPS 从 3 万降到 1 万。颠末排查，发现故障缘故原由为使用方式不妥，我们将在后续详细描述。
题目2：超时读写。随着 TPS 的下降，客户端开始出现超时读写。默认超时时间为 3 秒，这意味着 Flink 任务在 3 秒后会报错。
题目3：OCP 某监控节点的 CPU 非常。详细表现为部分节点 CPU 使用率长时间能维持在 90% 以上，导致集群团体性能。下降。例如，从下图可以看到我们有六个节点，此中一个节点是 root service 地点节点，就会造成木桶效应引发系列反应，对于我们的生产测试来说是不可行的。
颠末我们与 OceanBase 工程师的排查定位，最终发现根本缘故原由是：
数据中存在大量热点数据。
热点数据高频更新，在一个非常短的时间内(秒级别)大量更新，导致写入版本太多。
与此同时，系统在并行实行大量的区间扫描操作。
后续我们在读写方面做了一系列优化操作，重点对热点数据进行优化, 并实行数据去重操作，以下是我们的优化步骤供各人参考。
第一次设计时，优化方案没有定位到版本的题目，重要提升了 sink 算子的并行度。
第二次优化时，在 sink 算子内部使用线程池消耗往 OBServer 并行发 Put，进一步增大写 OceanBase 的并发。
第三次优化时，关闭 autoflush 并设置 writeBuffer 进行批量写入。在这个过程中遇到当前版本 OceanBase 服务端不支持的题目，缘故原由是一个事务内不允许同一个 key 的差别版本一起写入。
在后续的版本迭代中，OceanBase 发布了 HBase max version 和 TTL 的功能特性。我们创建了一张表进行了测试，并在客户端写入时间时指定了时间戳。对于我们的特殊业务，比如作品表，须要从 JSON 数据里面提取 eventTime，timestamp=eventTime 作为这条数据的一个版本。而用户表是一个维度信息，不像作品表可以直接提取时间，并且默认值是Long.MaxValue最终用的timestamp=Long.MaxValue - 1。在服务端可以明确为是一种宏或会自动转换为当前的时间戳，就会导致用户表出现版本过多的题目，假犹如一个用户写入很多次，那在 OceanBase 里面存的版本就有多种。
最终，我们的调整方案是用户表的一个 T 就是一个 Long.MaxValue - 1，最后 1 位转换成 16 进制，和最后一位是 E，以确保唯一性。
写优化：作品表
作品表是我们的一个事实表，根据字段来提取一个时间戳作为版本。在优化完版本题目后，我们还须要刷新历史数据。如下图所示，我们使用TTL功能对历史数据进行刷新。从14号10点到17号11点跑了三天，scan count大概是4.3亿。这个数量是每一个分区的数量，共997个分区上千亿数据，导致TTL连续跑了一周时间。
为了最大程度地加快数据清理速度，我们加大了 TTL 并行度，每个节点分配 64 个线程，并将租户 CPU 使用率提高到 100%。最终我们有效地优化了作品表历史数据的刷新，在最短时间内完成了数据的自动清理，性能非常可观，优化效果非常明显。
在 OceanBase 中我们存储了近一个月的数据，每天的增量数据为 10 亿，再分散到每一个字段，总计上千亿数据量。最终跑完之后再看每一个 Qualify （列名）的版本，已经刷到正常的状态。从 Flink 任务的角度来看，任务数据没有积压，任务也能稳定运行，不会出现读写超时。从 Kafka 监控的数据来看，生产速度和消耗速度都符合我们的需求。
由于我们的业务需求是点查，因此我们在 OceanBase 中做了一个监控，观测团体基线的点查耗时，延时根本在 10 毫秒以内，有部分抖动也是正常情况。
写优化：维度表
在解决作品表的优化后，我们再回到维度表。维度表跑完 TTL 之后，我们看一下数据量，并将表按照 scan_cnt 进行两次排序，分别是升序排序和降序排序。我们发现最大的分区数据量达到 2.2 亿数据，最小的分区数据量为 1.4 万万，表明分区存在热点写的情况。这可能是由于数据用户的 key 分布不均匀，也可能是因为用户表本身就存在热点写。
为了进一步相识情况，我们查询了系统表 sql_audit，发现关键参数SSstore_read_row_count 的值是 750，这个参数对应的是 SSTable 个数，代表假如查一个 key 须要扫 750 个 SSstore，说明该表有热点写。其实热点写再对应到我们的数据上来说，就是有多版本。
根据上述优化，我们设计了三种方案解决分区间总条数差异大，说明用户表有热点数据和转储 SSTable 的数量过多的题目。
方案一：
使用 Flink 的滚动窗口 TumblingWindow。该方案的不足是无论窗口时间设为多大，当窗口竣事时触发写都有流量波峰题目，不可行。
方案二：
对数据进行特征提取。按用户数做 SessionWindow，相当于一个用户作为一个合并。但由于我们的数据特点是部分用户更新频率特殊快，大概每天有 12 小时在不中断更新。假如用 SessionWindow，会话窗口的 gap 不好把握，大数据量更新会有较大延时。
方案三：
用 Process 做注册。然后在 Process 里对每一个新用户注册一个定时器。当他第一次进入时注册一个定时器，并将用户属性放在状态中。当用户第二次进入，只更新状态，直到定时器触发才把用户写到 OceanBase。这种方案也有一个题目，当我们的步伐第一次启动或数据积压时，就有一波新用户，然而周期性的写入也会有波峰题目。我们的解决方案是在定时器底子上加个随机数，即Process Timer + Random time。比如定时器基数黑白常钟，那么再加五分钟的随机值，哪怕一次来了 100 万个用户，在 10~15 分钟内也能把 100 万个用户做均匀值写入OceanBase，最终能起到消峰的作用。
从下图的优化结果看，我们优化去重的效果是减少了三分之二，比如写入 30 亿数据，输出时只有 10 亿的数据量。
从下图监控数据来看，黄线代表每秒写入 OceanBase 数据的输出数据量，绿线是每秒从 Kafka 接收到的用户量。团体来说，输出基线在 6000~8000，输入为22000~25000，约莫是三分之一的需求量。至于流量波峰，比如说 2 点到 2 点 15 分时激增流量，到输出的时间，推迟 10~15 分钟，这样的波动不是很大，这就是加随机数的效果。
读优化
针对读优化，我们对 OBKV 的定位是缓存层，点查需毫秒级相应。因为我们用的是HBase API，可以在 gap 的同时对 qualifier 进行裁剪。这样做的利益有两个，一个是减少扫描 SSTable 数量，低落扫描数据带来的超时风险，二是减少一个网络 I/O，比如对呆板、OBServer 或 Flink 任务网络 I/O 的压力。
优化后用户数据不须要实时更新。我们可以在任务中加一个状态 Flink-State 来做当地缓存，并且对状态设置 TTL。相当于只有在肯定时间内和第一次才会把这些点查的哀求打到 OceanBase，99% 都能在当地状态去做。
OBKV 作为一个缓存层，须要存储近来30天的数据，而我们之前使用的 Pika 只能存近来 7~14 天的数据。假如缓存层拿不到，才会去 Elasticsearch 地点的存储层，这样可以拦截掉 90% 的 Elasticsearch 查询哀求。而且近来 30 天是满足我们的业务需求的，就舍弃查询 Elasticsearch 的操作。
我们之前在 Elasticsearch 做查询，相应速度在 10 秒钟左右。假如集群负载较高，可能会达到 1 分钟，对业务造成很大的影响。舍弃 Elasticsearch 查询后，数据全部从 OceanBase 层和当地状态层读，TPS 可以拉到很高。后续我们对这种情况做了一个压测，TPS 能够稳定在 6 万/秒 上下，峰值是 11 万/秒。对比于其他产物比如 Redis、HBase 等，OBKV 的性能表现力压群雄。
读优化后效果如下。
团体来说，我们读写都做优化后、流量稳定后，TPS 根本上能够稳定在 30000 左右，每一个 OBServer 的 TPS 节点，也能够稳定在 50000~60000。CPU 使用率也完全符合我们的期望（见下图）。
四、OceanBase&OBKV落地收益
OceanBase 的 OBKV 在仟传业务落地的过程中，我们经历了一些挑衅，非常感谢 OceanBase 团队的鼎力大举支持，让我们得以实现性能的大幅提升。
精彩的插入&点查性能：在当前集群规模及设置下，我们实现了稳定的 60000 TPS，可同时满足业务数据高速摄入和高速点查需求；在上游数据陡增时，TPS峰值可达 110000，能够快速追平数据，避免数据积压。
简洁的架构：基于 OBServer 构建整个集群；基于 OBAgent 管理集群、收罗监控数据。
基于 OCP 的界面化操作工具：可实现对集群、主机、OBServer、租户、数据库等的界面化管理，非常方便运维操作。
快速相应的技能支持团队：OceanBase 技能支持团队快速相应客户需求，并积极资助排盘题目，根据业务特点给出有效解决方案。
此外，是我们对 OceanBase 当前版本的一些优化建议，渴望可以评估采取进入未来的产物规划。
TTL 粒度细化到表级：当前 TTL 机制会覆盖到租户下全部的表，会消耗较长时间，建议将粒度细化到表，即可对租户下指定的表实行 TTL。
读写 TPS 监控分离：当前 OCP 界面上 TPS 监控信息重要表现总 TPS，建议将读和写 TPS 分离出来，更加直观反映读写性能。
多语言客户端 API 支持：obkv-client put 目前不支持同时写入多条数据，建议支持攒批写，可减轻网络 I/O；Flink connector 建议进一步完善，集成相关操作，方便用户使用；Python API 建议连续完善，支持 Python 步伐开辟。
OCP 页面跳转：当前 OCP 页面上点击时经常发生跳转，建议不要跳转，避免多窗口导致混乱。
OceanBase OBKV 目前在仟传已经正式落地，在性能、稳定性、扩展性等方面均表现精彩，有效支撑了业务的快速发展。颠末生产系统的真实实践，并得到了仟传业务开辟、运营和管理团队的同等认可。我们相信，OceanBase 将会不断完善，为用户提供更加优质的产物和服务。我们期待与 OceanBase 继续合作，共同推动分布式数据库在关键业务负载的突破和发展。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/)
Powered by Discuz! X3.4
