处理时延降低 24 倍，联通云粒数据引擎优化实践

作者：郑扬勇，云粒星河数据中台产品负责人

云粒智慧科技有限公司成立于 2018 年 6 月，是中国联通集团混改以来成立的首家合资公司，是中国智慧城市数智化建设者。一直以来，云粒智慧以数字化、智能化、集约化产品为核心，全面融合“5G+大数据+AI+CIM”等最新技术，致力于构建未来城市数字化基础设施平台，打造“绿色、互联、智能”的现代化智慧城市，为政企提供符合政策导向及智慧城市发展趋势的“三中台+智能化应用”解决方案，实现城市智脑与生态环境可持续发展。

这里说到的“三中台”，其最重要的中台即云粒星河数据中台，是一套集“数据建设与运营方法论、软件+行业资产包和数据技术服务”的中台体系，提供数据采集、融合、治理、计算、分析、服务、可视化的全链路一站式管理与服务。经过四年 4 个大版本的迭代，目前已累计完成 80+ 客户项目的落地交付，实现产品销售总额超过 1.2 亿元的好成绩。

Hive 存在四大痛点交付成本显著增加

云粒星河数据中台作为大数据处理系统，数据引擎是其最重要的核心中间件。云粒星河数据中台的数据引擎一直选用开源的 Apache Hive，自诞生，到 3.x 系列最后一个版本。总体上 Apache Hive 是一个非常优秀、久经考验的 OLAP 引擎，但在项目落地实施的过程中，我们也遇到了诸多痛点，导致最终交付成本偏高，拉低了项目的毛利率。

痛点 1：组件众多，运维困难，云原生化不友好

Hive 依赖 Hadoop，我们使用 HDFS 存储数据，YARN 作为资源管理框架，Tez 优化 Hive DAG 任务；由于需要高可用，每个节点都需要启动好几个相关进程，这些进程的配置、监控、伸缩、保活等都极大地增加了运维工作量。由于 Hive 和 Hadoop 使用的是已经老旧的按节点方式扩缩容的架构设计，因此云原生非常不友好，社区至今也没有提供容器化部署方案；自行尝试通过 Statefulset 方式运行在 Kubernetes 中并进行性能测试，发现性能竟然有 30% 以上的下降，因此我们仍然使用物理机或 VM 方式部署。

痛点 2：资源利用率低, 任务调优繁琐复杂

由于 YARN 是双层悲观并发资源管理（调度）框架，经过 Tez 优化后的 Hive DAG 任务向 YARN 申请资源仍然是按固定配额（vCore 和 Mem）的方式进行，为了能够最大化利用资源提高并发，需要在项目中根据任务处理数据量情况 Case By Case 做配置调优，并且随着数据中台数据处理量的不断变化（通常情况是逐步增加），配置调优的工作需要持续进行，无法一劳永逸。

痛点 3：数据处理时延大，用户体验差

由于诸多原因，我们没有使用 Hive 的 LLAP 特性，这会导致 Hive 即使处理极小的数据量如数百条记录，由于需要冷启动最低两个 YARN Container（含一个 App Master），至少需要数秒才能返回，无法做到亚秒级交互式查询，难以支持数据大屏等实时性要求较高的下游应用，为了解决这个问题，我们追加部署了基于 MPP 架构的 Presto 引擎解决了这个问题，但这也带来新的问题，即对内存资源的需求也大大增加了，这种成本的增加最终还是会转变为交付成本，降低项目利润。

痛点 4：不支持行级更新，灵活性较低

Hive 是一个为数仓而生经典的 OLAP 引擎，数据更新仅支持全表/分区级覆盖，极低的情况下如果需要对远景冷区部分数据进行更新，处理较为麻烦；另外分区设置策略也颇为费脑——粒度太大更新效率较低，粒度太小又容易发生分区和小文件数据量爆炸，表现为还是效率低下……

正是由于以上一些挑战，自云粒星河数据中台 3.0 大版本发布支持多引擎并行能力开始，公司内部一直在寻找一款稳定可靠、AP 和 TP 兼备、能够在集约资源环境下有较高效率表现的数据引擎。

选型 OceanBase，并发性能提升 10 倍+

但数据引擎作为基础软件百花齐放，我们如何在一堆“好”软件中最好的只有更挑选更适合自己的以及怎么判断适合？云粒总结了如下五点：

• 开源软件，友好的商业 License；

• 支持云原生；

• 支持集群模式；

• 支持私有化部署；

• 有较高成熟度（社区、生态等）。

经过较长时间的调研和比较，初步满足条件的数据引擎仅剩以下  CockroachDB、YugabyteDB、PingCap TiDB、OceanBase 四款。其中，CockroachDB 社区版限制较多，例如，较为基础的索引功能都需要获取商业版 License 解锁；YugabyteDB 在内部性能测试对比过程中表现较差，因此两者排除较早；而对于后两款，OceanBase 相比 TiDB，更适合我们的点在于以下三个方面：

第一，OceanBase 的架构较为简洁，只有 OBServer 和 OBProxy。而 TiDB 由 PD、TiDB、TiKV、TiFlash 四个组件构成。如果只是部署一套集群用于内部服务，那么二者的区别不大，但我们需要部署和运维几十甚至上百套集群，配置、部署、运维等方面用 OceanBase 较为便利。

第二，OceanBase 原生支持多租户，资源隔离和控制模型也比较清晰。而 TiDB 对于多租户支持很晚（生产可用应该是在 V7.0+），至今仍处于完善阶段。云粒数据中台作为一个原生多租户系统，使用 OceanBase 的多租户体验更舒服。

第三，OceanBase 的生态策略感觉更开放。例如，数据集成方面专门为 DataX 开发了插件，更贴合我们现有技术路线。TiDB 虽然提供了更丰富的数据集成组件包含 TiCDC、TiDB Data Migration、TiDB Lightning，但我们整合进产品会比较重，工作量会比较大。

基于上述因素，自 2021 年 OceanBase 宣布开源开始，其进入我们的候选名单，2022 年，OceanBase 发布 4.0 版本，其迭代速度和性能改进更是让我们惊叹，正是那时，我们果断确定产品选型并启动适配工作。

因为项目体量较大及产品功能较多，且大多数都与数据引擎相关，整个适配过程大概持续了两个多月完美收工。数据引擎更换为 OceanBase 后的云粒星河数据中台得到了如下优化，极大缓解甚至消除了之前的痛点。

优化 1：更简介的架构，更好的云原生

左-更换前（Hive+Presto）；右-更换后（单一 OceanBase）

从上图可以看出，相比 Hive 引擎，OceanBase 只需要在每个节点上启动 OBProxy 和 OBServer 两个进程即可，通过 Prometheus 导出 Metrics，监控运维便捷省力。得益于架构的简洁，OceanBase 很容易实现云原生化，官方已提供在 Kubernetes 中部署运行的详细方案，这对云粒星河数据中台本身实现彻底云原生化至关重要。

优化 2：让每一核 CPU 发挥最大价值

私有化环境交付，客户能够提供的资源不足已经是“家常便饭“，这就要求云粒星河数据中台必须具备“螺蛳壳里做道场”的能力，即在较低资源配置下也能有良好的处理能力表现。例如，我们甚至遇到个别客户仅提供三台 8C32GB 规格的服务器部署数据引擎。以往采用 Hive 结合 Presto 作为数据引擎。部署完各类组件，每个节点能够提供给 YARN 调度的内存往往就只剩下 10GB 左右，每个作业（Job）还需要启动一个独立的用于协调的 AppMaster（通常占用 1GB 内存），使得在小数据量高并发场景下的性能表现雪上加霜。

前文也提到需要对于 YARN 资源分配的参数反复调校，费时费力。采用 OceanBase 作为数据引擎后，单租户模式下，为 OBProxy 分配 2GB 内存，系统租户和租户 META 租户各分配 3GB 内存，剩余内存全部用于租户本身，通过试验，小数据量场景（单次处理数据量低于 1GB）并发能力相比 Hive 有十数倍提升，在较大的数据量（单次处理数据量超过 10GB）场景下也能做好处理，轻松榨干 CPU 每一核。

优化 3：数据治理从分钟级到准实时

准实时数据治理单次需要处理的数据量往往都较小，得益于高效的分布式计算调度和数据存储结构，即使是逻辑较为复杂的数据治理 SQL，OceanBase 也能游刃有余地快速完成，以下是测试数据治理工作流执行时间对比，它由一个数据接入节点和两个数据更新写入节点构成，每次处理的数据量接近 1GB，资源配置同为三台 8C32GB 服务器集群。

可以看出，OceanBase 在小数据量场景下各方面的时延都远低于 Hive。而相比定位为单一 OLAP 引擎的 Hive，定位为 HTAP 引擎的 OceanBase 在 TP 方面的诸多优势不再赘述，对于冷数据行级更新更不在话下。

从 Hive 到 OceanBase，我们的几点建议

当然，对于团队中习惯使用 Hive 做数据交付的同学，在使用 OceanBase 的过程中，也有少量感觉不太方便的地方，主要有两点：

第一，OceanBase 不支持 Insert Overwrite，还好可以使用 Truncate/Delete + Insert 曲线支持，问题不大；

第二，OceanBase 不支持使用 List 分区策略时动态分区，因此每次插入数据时，都需要检查对应的分区是否存在，如果不存在，则需要先 ALTER TABLE· ADD PARTITION，很不方便，希望未来能尽快支持。

另外，不可否认，当单次需要处理的数据量上升到一定级别如 100GB 以上，凭借 ORC 或 Parquet 列存格式优势，Hive 执行数据分析的性能表现是优于 OceanBase 的，不过可喜的是，列存计划已列入产品 roadmap，希望在不久后可以看到更强的 AP 性能能力。

写在最后

目前，更换为 OceanBase 作为数据引擎的云粒星河数据中台 4.0 已经在项目上实施落地。总的来说，OceanBase 更简洁的架构、更轻便的运维，帮助我们加速了数据中台云原生的进程，提升资源利用率的同时，并发性能提升 10+ 倍，数据处理时延降低 1.5-24 倍。这带来的直观效益是机器成本与运维人力的节约，进而带来了 20% 的毛利率提升。