摘要 ：本文整理自云粒智慧高级技术专家付大伟在 4 月 20 日的 2024 OceanBase 开发者大会上的分享，讲述了其数据中台在传统数仓技术框架下做的一系列努力后，跨进 FlinkCDC 结合 OceanBase 的实时数仓演进过程。
内容主要分为以下几个部分:
- 业务背景及挑战
- 实时数仓的架构演进
- 未来规划
4月20日，云粒智慧高级技术专家付大伟在2024 OceanBase开发者大会上分享了云粒智慧实时数仓的建设过程，讲述了其数据中台在传统数仓技术框架下做的一系列努力后，跨进 FlinkCDC 结合 OceanBase 的实时数仓演进过程。
业务背景及挑战
云粒智慧成立于2018年6月，它是中国联通和阿里巴巴共同出资成立的一家科技公司，主要面向政府和中小规模的企业，提供智慧城市和生态环保方面的智能化应用。联通云粒拥有三中台：数据中台、智能中台和应用中台，以及智能化应用产品，与政府合作为各地提供智慧城市建设服务，包括政务数据一体化、公共数据开放、一网统管、一网通办等业务。另外，我们在一些应急领域如水利和环保，也拥有智能化预警等方面的业务。
其中，数据中台主要提供数据采集、融合、治理、分析、计算的服务，是公司比较重要的产品。自公司成立初开始产品发育，到如今历经 5 个大版本迭代，现已在全国范围内落地上百个客户项目。下图是数据中台架构，可以看到其整体运行在 K8S 集群上，为了更好地动态扩缩容，计算和存储都使用 OceanBase，同时使用 Minio 做非结构化文件的存储工作，使用Flink流计算引擎。在引擎上层，我们构建了一个引擎操作系统，用来适配在客户交付过程中面临的不同的大数据底座。
由于为各类政企交付项目，因此我们在交付过程中积累了三方面的业务特性。
-
多业务线，形态各异 ：政务领域业务跨度较大，多种数据源、不同频率的数据汇集，带来很多业务复杂性问题。
-
计算资源匮乏 ：各项目3-5台计算资源，难以运行大规模计算；服务器资源匮乏，大量数据计算往往耗时较长。
-
业务协同需求强 ：数据实时性较强，各单位追求业务协同效率，比如防汛减灾、水质污染等实时告警场景。
上述业务特点为技术实现带来了很大的挑战。技术中台作为大数据处理系统，引擎是它最核心的内容，在中台 1.X 到 3.X 版本迭代过程中，其实选用 Hive 和 HDFS 作为计算存储的引擎，但遇到诸多痛点，主要表现为以下四点。
-
资源利用率低：受限于 YARN 的调度策略，需要在项目中依据任务和资源情况逐个调优，任务量增加后仍需持续投入，难以一劳永逸。
-
数据时延：实时数据入仓带来了诸多小文件问题，虽然项目组在 Flink 的框架下做了诸多优化，仍然无法满足大屏监控、预警、数据消费等应急场景需求。
-
不够灵活：数据更新方式仅支持全表/分区级覆盖，应对已经入仓的历史数据中部分数据更新时，处理逻辑复杂且低效。
-
运维复杂：组件众多，配置、监控、伸缩、保活等都极大地增加了运维工作量。高可用场景下每个节点均需要多个进程，容器部署性能下降。
因此，在数据中台 4.X 版本时，我们希望引进新的引擎来解决上述问题。
实时数仓的架构演进
数据引擎作为一款基础软件，目前市面上百花齐放。我们在选型过程中主要关注五个方面：
-
它的开源协议是否足够宽松。
-
是否能够支持云原生的方式部署。
-
它需要支持集群。
-
它能够以私有化的方式部署到客户的现场。
-
这个产品以及它的生态是否有足够高的成熟度。
我们经过了较长时间的调研，认为 OceanBase 在三方面表现优异。第一，它的架构设计比较简洁，主要是由 OBServer 和 OBProxy 组成，即便运维多套客户环境，也会节省很大的成本，增加一些便利；第二，数据中台作为一个原生支持多租户的系统，我们使用 OceanBase 的多租户，整体方案上都会更加契合。第三，OceanBase作为开源数据库(https://github.com/oceanbase/oceanbase)，其社区和生态开放、成熟，尤其是针对我们常用的数据集成软件 DataX 和 Flink ，都有官方的一些插件。OceanBase 非常契合我们的技术实现路线。
因此，我们也对 OceanBase 做了一些性能测试，包括我们部署 3 台 8 核 32G 的服务器集群，每次处理的数据量都达到 1G 以上来观测它的性能。我们观测到，OceanBase 的性能指标最高可以达到 Hive 的 24 倍，在整个选型和应用过程中，我们发现 OceanBase 的学习成本也比较低的，熟悉MySQL就能上手，而且官方文档比较齐全。此外，当我们确定产品选型后，在后续的迁移工作中，我们花了一个多月的时间就完成了适配和迁移，比预期快很多。同时据运维人员反馈，利用OceanBase的日志能够解决大部分运维的问题。
至于数据同步工具的选型，Flink CDC 的选型比较水到渠成，首先是契合度的问题，数据中台在最初版本中，我们已经使用 Flink 作为流计算的引擎，所以 Flink CDC 比较贴合我们的路线。其次，Flink CDC 支持的方式非常多，包括全量、增量，以及先全量再增量的方式，这有利于提升交付效率。以往我们利用离线的开发，比如 Hive 的数仓来做增量同步时，需要开发人员设计一个比较大的图，去数仓捞出最新的时间戳，并且把它作为一个参数注入 DataX 的一些导入节点上，之后还需要数据去重、关联等治理操作才能够完成。
此外，Flink CDC 运行在 Flink 分布式引擎上，在 K8 s上，我们根据客户实时数据量的大小可以自动扩缩容 Flink。
自从选用 OceanBase+Flink CDC 架构后，架构变得非常简洁，我们用OceanBase代替了以前以Hive为主的MPP引擎、HiveServer2、YARN 和 HDFS。使用 Flink CDC 来完成关联数据库日志的同步，使用 FlinkSQL 做相应的实时加工处理。数据写入流程也更加便捷。
总而言之，优化后的平台架构，在以下方面呈现出较大优势，使我们能够依托 FlinkCDC 和 OceanBase，建设完全云原生的智能化数据中台。
第一， 云原生化。微服务、调度任务、大数据引擎全部基于 K8S 云原生技术，支持容器化部署和资源调度，实现弹性伸缩和快速升级。
第二， 数据开发。不同业务形态下简易配置，离线与实时数据开发均提供 SQL 化（离线标准 SQL、实时 FlinkSQL）、配置化；拖拉拽式作业编排，百万级任务调度、开发效率提升。
第三， 运维管理。以往，大数据底座问题往往需要运维+开发花费1-2天时间进行排查和优化，OceanBase 清晰的日志信息给运维带来极大便利，常见问题1小时内解决。
第四， 资源利用。流计算和 OceanBase 的广泛应用，使得单个项目服务器资源由原来的 11 台 缩减到 6 台，在业务量和资源投入上可以更好的平衡。
第五， 学习成本。OceanBase 对大数据新入行人员非常友好，学习成本极低。
下面我们以具体项目来说明 OceanBase + FlinkCDC 架构的优势。
这是我们在贵州某项目上的应用，从客户的数据量、接入量可以看出，体量较大。客户需要接入物联网设备产生的数据，并且做实时预测、实时告警。它的数据表超过 1900 个，涉及的数据量有 675 亿条，而且每天接入的数据量都达到 1.9 亿左右。
在改造前，我们使用 Hive 引擎需要 11 台服务器，并且实时数据接入是采用离线批量的方式让它入仓，基本上会有5分钟左右的延迟，不能满足客户实时告警的需求。另外，更新逻辑比较复杂，我们需要额外运行很多任务以保证入仓数据是最新、最完整、和业务匹配的。
改造后，我们发现只需要 8 台服务器就能够支撑客户所有的业务，而且可以将延时控制在 5 秒左右，极大提升了数据告警效率。由于更新支持变得容易，大家的任务量也被极大缩减了。整体而言，服务器资源节省 27% ；实时效率提升 100 倍；业务复杂度降低 10% 。
未来规划
我们今年正在发力数据中台 5.X 版本的建设，进一步支持云原生化，包括结合 OceanBase 4.3 版本在云原生环境下做项目交付；通过FlinkCDC 支持更多数据源、Flink ML 探索应用，增强流计算；基于计算引擎的资源监控升级调度策略；让数据平台能够在有限的资源下运行更多的调度任务。