开源实践 | OceanBase 在红象云腾大数据场景下的实践与思考

本文将介绍 OceanBase 在红象云腾大数据场景下的落地实践与思考，希望帮助正在探索 OceanBase 的企业用户快速实现 OceanBase 选型与落地。

作者：童小军

红象云腾 (REDOOP) 公司董事长兼 CTO，中国首位 Cloudera CCDH 认证工程师，曾任 China Hadoop Summit 联合主席。

红象云腾是一家专注于 Apache Hadoop 生态的大数据软件厂商，主要产品是红象云腾大数据基础平台(Redoop Enterprise V9.0)，产品由 CRF 数据接入，CRH 数据存储，CRS 数据分析三大部分构成。红象的核心产品是围绕以 Hadoop 为核心，打造一系列的解决方案，服务中国客户。Hadoop 是 Apache 基金会下面没有提供商业支持和服务的软件，红象基于此提供面向用户的商业解决方案。Hadoop 分布式是红象的起点，也是我们的事业，一直以来我们都在做大数据 Hadoop 推广和普及工作。在这方面，Hadoop 和 OceanBase 有很多可以互相补充的地方，我们也发现在大数据 Hadoop 生态里，缺少一个能支持分布式事务，支持跨两地多中心的解决方案。

一、为什么选择 OceanBase？

我们参与到 OceanBase 社区里面，是抱着积极参与，勇于尝试的态度，因为我们是最早吃 Hadoop 螃蟹的一批人。Hadoop 刚诞生的时候，架构非常简单，使用起来不方便。但是在 Hadoop 处于零点几的版本时，因业务及数据规模的需要，我们就开始去尝试使用。这次 OceanBase 开源之后，我觉得是惊艳四座，如果用四个字总结，就是“简洁又美”。我个人觉得技术人员是有立场的。什么叫立场？我们的时间是宝贵的，我们得把宝贵的时间用在真正优秀的作品上面。

“OceanBase 作为一个分布式数据库，在架构上却展现出了简洁美，这让我们看到了新的机会。”    —— 红象云腾 CTO 童小军

我们为什么选择 OceanBase？有以下五个原因：

第一 身份转变。OceanBase 是在今年6月1日开始走开源开放的路线，这让我们有了参与感。如果不开源，首先，我们是没有机会拿到这个版本的；其次，我们不知道怎么参与贡献；另外，我们贡献的价值也不能得到社区的认可。所以说开源开放让我们从一个旁观者，或者说是使用者，变成一个参与者，这是很重要的身份转变。另一方面我们可能确实拿不出特别充足的预算去支持商业版，但是我们也希望能用上 OceanBase 的技术，开源路线出来之后我们就大胆的去用了。

第二 技术选型。我们对于数据库是有要求的，首先，Hadoop 是原生分布式，高可用的系统，天生的设计就是多副本，但是在跨数据中心这一块比较弱。所以，我们在选择数据库时，不但要求具备分布式、高可用特点，而且还要线性可扩展，这是我们对于选型数据库的要求，OceanBase 符合我们的需求。

第三 兼容性，这是一个很关键的特性。OceanBase 对 MySQL 的兼容性很好，我们很多应用程序可以直接移植到 OceanBase 环境而不需要改太多代码。我们有一个应用程序迁移到 OceanBase 环境之后一行代码都没有修改，直接迁移使用，所以高兼容性是我们选择 OceanBase 的一个关键点。

第四 技术支持。虽然在阿里、蚂蚁内部 OceanBase 方案已经非常成熟，但是对于我们来说 OceanBase 是一个新产品，因此在选型和测试时会担心遇到业务不能正常访问或者出现异常等我们无法搞定的技术问题，对我们的客户不好交代。在我们使用 OceanBase 过程中，OceanBase 社区团队对我们的支持力度很大，遇到问题时，我们技术同学把情况反馈到用户群里，社区技术团队能够及时的响应和解答，使我们能放心使用。

选择 OceanBase 还有一个最关键的点：部署方便、简洁易用。

一开始看到 OceanBase 的时候，发现它只有一个主要组件 OBServer，当然周边组件也是有的，但是核心只有一个组件。而 Hadoop 组件实在太多了，作为一个入门用户，要掌握一套 Hadoop 系统需要花很长时间搞明白一堆组件的功能。而 OceanBase 实现了 Hadoop 里面的很多特性，也实现了很多 Hadoop 里面没有的特性，所以说简洁就是美。

二、应用在红象云腾的哪些场景？

红象主要是做分布式大数据业务场景，这个场景有两条路线，分别是批处理路线和流处理路线。Hadoop 更擅长后端处理，做大规模数据量的处理（比如 ETL 清洗），并不是很擅长面向用户端。当我们面向用户端的时候，比如说报表，当应用程序连上来的时候，Hadoop 就显得力不从心，Hadoop 更多的是面向一个大规模数据做批处理业务。

针对面向实时的场景，虽然也有解决方案（比如 HBase 等），但是这些解决方案还是偏重，因此我们需要一款轻量级的解决方案。以前我们用的是 MySQL，现在用 OceanBase 来替代 MySQL 集群承担业务报表。当数据运算完成后把结果存到一个结果数据库里面，OceanBase 承担面向应用端来提供服务的角色。所以在一些大数据场景下，比如数据海量存储的在线服务、ETL 清洗结果的存储、轻量级 OLAP 分析报表以及元数据库服务等都可以考虑使用 OceanBase 方案来提供服务。分布式数据库在大数据业务主要使用场景如下：

当前 Hadoop 生态依赖的一些 hive 元数据是存储在 MySQL 里面，在业务量大的时候，hive metadata 也没有特别好的存储方案。比如客户说我们 hive metadata 的 MySQL 也得高可用，这是客户在我们业务线现场提的需求，怎么办？我们做一个 MySQL 集群吗？又掉进去了是吧？如果做主备的话，又不具备高可用能力。所以说在我们整个 Hadoop 技术栈里面有很多场景，比如第一个替代 MySQL 的场景，第二个是承担多种前端业务查询请求的场景。

「新能源电力大数据上线 OceanBase 」

用 OceanBase 的长处补 Hadoop 的短板是红象要努力尝试去做的，把这两个生态结合起来以更好的服务客户。可以看一下红象的 Hadoop 和 OceanBase 组合的电力行业的新能源案例：这是一个大数据平台，包含了 Hadoop、 Hive、Druid 、Spark、Flink 等组件。

大家可能从市场上看到的发行版本都很大，我们红象的目标是把我们的发行版做小。我个人曾经思考过：小到极致，砍到极致，能留下什么？我们核心围绕着 Hadoop ，把其余的做成插件，外围的找合作伙伴来做。这是我想给创业者的一个建议：当你把一堆开源组件集合起来，还不如你做好一个组件，反倒更能凸显价值，这也是我们的一个路线。把 Hadoop 做好，剩下的我们与合作伙伴一起完成商业解决方案。

在能源大数据的场景里面有一条业务流。光伏传感器的数据会源源不断的录到 kafka 里，Flink 程序去消费 kafka 的数据，消费完数据又会重新录到 kafka 里，然后 Apache Druid 去消费 kafka 数据，再对外提供服务，这是一条工业时序数据的处理场景。

这个过程在什么地方用到 OceanBase？我们的点表数据传过来的时候是 CSV 一样的逗号分割的流，这个流的每一个字段会变化，我们就需要一个数据库来存储这些变化。我们需要在 Flink 里面拿到 matadate 字段描述信息，然后把表结构的信息补充上去。因此从原始 kafka 数据到我们的 DRUID 要消费的这个数据中间是要有一个数据补齐的工作。对于指标的描述信息就存在 OceanBase 里面。

我们还有一些使用了各种数据库的业务。以前，我们会把这些数据录到 Hadoop 里面建个 hive 表，再供业务使用，整个流程非常复杂，用户使用起来也很累。现在，直接把数据直接录到 OceanBase 里面，再对外提供服务。架构非常简单，可以很方便解决客户问题。

以前红象做事情喜欢做加法，把一个系统搞得好复杂，现在做事情都做减法。我们在新疆有个通信管理局项目，项目数据有600个Hadoop 节点。首先把电信和联通的数据加载到 kafak 里面，再通过 Spark 进行计算，计算完之后录到 hive 里面，处理流程太长了。经过简化，我们直接把数据推到 Hadoop 里面就搞定了。有的时候做减法感觉更好，我们现在做事情做架构都是做减法。

这一套 Hadoop 集群的部署架构上面有4个管理节点，下面是数据节点，其中 OceanBase 由6个节点构成，每个节点是36核128G ，有1个2T 的数据盘，一个日志盘，这个是经过 OceanBase 的团队 check 以后目前在运行的方案。

我们的集群部署结构有3个 zone，每个 zone 有两台机器，总共6台机器的基础架构，支撑的业务由 OceanBase 加 PGSQL，还有 HDMS 这些组件共同来支撑各种业务，业务场景有数据接口、系统应用、报表可视化等等这些应用场景。

「Hadoop + OceanBase 点亮新能源大数据 」

这个是我们现在集群情况，目前只是个小集群：3个 kafka，8个Hadoop 管理节点加数据节点，6个 OceanBase节点，支撑10万个点位数据。每天有10万个点位需要收集，新增数据0.5个 TB 左右，虽然数据量还不是很大，但是我们后面有 600个 Hadoop 节点的集群，随着数据量会越来越大，OceanBase 在该业务扮演的角色会越来越重要，核心功能会体现的淋漓尽致，比如弹性扩缩容，HTAP 能力等。

这个项目的投资额很大，是我们国家能源部布局的光伏储能的时政平台，是一个很有意义的项目，它是代表着我们在光伏产业的新技术新产品。

三、从用户角度还能改进什么？

从红象云腾的实践中，基于用户角度，想对 OceanBase 提出五点建议供参考。

1. JBOD （just a bunch of disks）多盘符挂载支持。

Hadoop 的机器都是 JBOD 很多盘，一台机器可能有12个盘，每个盘4个 T 的架构。但是 OceanBase 指向的是一个盘，这个时候剩下的11块盘怎么办？要是做成 raid 模式又跟我们混合部署架构不大一样。如果可以做到 JBOD 多盘符挂载支持，那么 Hadoop 的业务往 OceanBase 迁移更方便，同时机器资源复用更加友好。目前 OceanBase 团队反馈内部正在评估该需求。

2. 初始文件磁盘占用率问题。

在部署完 OceanBase 之后，我们发现磁盘占用率达到90%。这是因为 OceanBase 在部署完会创建一个大文件，先把这个空间占着方便读写，我也能理解这个事，当然运维理解不了。所以我们把 OceanBase 部署起来之后，我们运维工程师说“童老师，系统数据还没写进去，这个盘怎么满了。”后来我们通过从 OceanBase 内部提取一些指标数据告诉运维同学实际的磁盘使用情况，同时我们也希望初始文件可以增量设置。目前 OceanBase 团队反馈内部正在评估该需求。

3. 单个组件的启动、配置管理以及监控问题。

之前我们使用 OceanBase 开源第一个版本，需要用命令行方式安装部署环境，通过配置文件的方式去配置，对于单个组件的启动和关闭不是特别方便，需要对整个集群操作。在一些场景下我们需要对某一台机器的某个组件进行启动和关闭，这样可以精准的对某台机器启停，而不是去改配置文件，或者更复杂的操作，能不能针对单个机器，单个组件做配置管理，其实对于管理工具是个挑战。目前在最新的 OceanBase 社区版3.1.2版本中，OceanBase 云平台（OceanBase Cloud Platform，OCP）支持开源。OCP 是一款以 OceanBase 为核心的企业级数据库管理平台，可以轻松的解决以上提到的问题，同时 OCP 不仅提供对 OceanBase 集群和租户等组件的全生命周期管理服务，同时也对 OceanBase 相关的资源（主机、网络和软件包等）提供管理服务，能够更加高效地管理 OceanBase 集群，降低企业的 IT 运维成本，对使用者来说非常友好。

4. ODBC 驱动的支持。

我们的业务现场还有一个叫 odbc，已知 OceanBase 是支持 jdbc，不支持 odbc，但是 MySQL 可以适配 odbc，所以在实际业务场景中需要把数据写回到 MySQL 。odbc 在工业场景有很多 windows 机器或者一些原因使用 odbc 驱动，我们希望 OceanBase 不仅要支持 jdbc，odbc 也需要考虑支持。目前  OceanBase 团队反馈该需求已经在排期规划中。

5. Latin1 字符集的支持。

我们想把 hive 的 metadata 迁移上去，发现该字符集不支持，目前是通过改应用来适配，如果 OceanBase 后面能支持就更好了。目前 OceanBase 团队反馈内部正在评估该需求。

四、双方生态整合，优势互补

1. Hive Metadata On OceanBase。

当前我们的 Hadoop metadata 解决方案还是基于 MySQL，因此存在单点、容量受限的问题。我们计划使用 OceanBase 替换 MySQL 方案并应用在通信管理的管理局项目上，目前该方案还是测试阶段。

2. OceanBase BackUp To NFS On HDFS。

这个问题是关于 Oceanbase 的 Backup。OceanBase 本身有备份和恢复的功能，大家也都可以使用，同时数据默认是三副本（即数据会存储三份），通过 Paxos 协议保证数据的强一致性，天然保证业务的高可用。不过我们想的是 OceanBase 在帮我们解决问题的同时能不能也用上 Hadoop？这样两个产品的优势会整合起来，形成一个非常好的解决方案。

在下面这个场景里大家可以感受下：我们公司最大的客户是中国航天，在 Hadoop 上存储、管理的数据达到几十个 PB，管理了几十颗卫星的数据，因此我们的责任很大，不能掉以轻心的。这套系统上线之后，这十几年来我们没有出现过一次因为机器故障导致大规模数据丢失的问题，有时候哪怕是丢了几个小块，我们都可以从文件系统把这个块数据找回，所以 Hadoop 给了我们一个很好的备份机制，大家可以放心的把数据存在上面，而不用担心数据丢失。因此，可以尝试把 Hadoop 当作 OceanBase 的备份组件使用，这是我的小建议。

写在最后

从开源中来，到开源中去，这是我给大家的一个建议。有很多同学都是用开源产品的，可能也是开源软件的创立者，我们是开源软件的受益者，所以我们也要为开源做出我们的贡献。

分享一下我对开源的理解：

第一，开源是一个建立标准的过程，一流的公司是做标准的。第二，开源是一个建立连接的过程。你的软件被大量的使用，你和各个公司建立起了连接，自然有商业机会。红象云腾使我们参与到 Hadoop 的开源社区里面，去普及和推广 Hadoop，这是我们成长起来的关键原因。我们希望能够跟着 OceanBase 开源社区共同成长，为 OceanBase 开源贡献我们的力量。

更多开源实践:






戳这里看开源年度报告