本文将介绍OceanBase在红象云腾大数据场景下的落地实践与思考，希望帮助正在探索OceanBase的企业用户快速实现OceanBase选型与落地。
红象云腾是一家专注于ApacheHadoop生态的大数据软件厂商，主要产品是红象云腾大数据基础平台(RedoopEnterpriseV9.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里面，在业务量大的时候，hivemetadata也没有特别好的存储方案。比如客户说我们hivemetadata的MySQL也得高可用，这是客户在我们业务线现场提的需求，怎么办？我们做一个MySQL集群吗？又掉进去了是吧？如果做主备的话，又不具备高可用能力。所以说在我们整个Hadoop技术栈里面有很多场景，比如第一个替代MySQL的场景，第二个是承担多种前端业务查询请求的场景。
「新能源电力大数据上线OceanBase」
用OceanBase的长处补Hadoop的短板是红象要努力尝试去做的，把这两个生态结合起来以更好的服务客户。可以看一下红象的Hadoop和OceanBase组合的电力行业的新能源案例：这是一个大数据平台，包含了Hadoop、Hive、Druid、Spark、Flink等组件。
大家可能从市场上看到的发行版本都很大，我们红象的目标是把我们的发行版做小。我个人曾经思考过：小到极致，砍到极致，能留下什么？我们核心围绕着Hadoop，把其余的做成插件，外围的找合作伙伴来做。这是我想给创业者的一个建议：当你把一堆开源组件集合起来，还不如你做好一个组件，反倒更能凸显价值，这也是我们的一个路线。把Hadoop做好，剩下的我们与合作伙伴一起完成商业解决方案。
在能源大数据的场景里面有一条业务流。光伏传感器的数据会源源不断的录到kafka里，Flink程序去消费kafka的数据，消费完数据又会重新录到kafka里，然后ApacheDruid去消费kafka数据，再对外提供服务，这是一条工业时序数据的处理场景。
这个过程在什么地方用到OceanBase？我们的点表数据传过来的时候是CSV一样的逗号分割的流，这个流的每一个字段会变化，我们就需要一个数据库来存储这些变化。我们需要在Flink里面拿到matadate字段描述信息，然后把表结构的信息补充上去。因此从原始kafka数据到我们的DRUID要消费的这个数据中间是要有一个数据补齐的工作。对于指标的描述信息就存在OceanBase里面。
我们还有一些使用了各种数据库的业务。以前，我们会把这些数据录到Hadoop里面建个hive表，再供业务使用，整个流程非常复杂，用户使用起来也很累。现在，直接把数据直接录到OceanBase里面，再对外提供服务。架构非常简单，可以很方便解决客户问题。
以前红象做事情喜欢做加法，把一个系统搞得好复杂，现在做事情都做减法。我们在新疆有个通信管理局项目，项目数据有个Hadoop节点。首先把电信和联通的数据加载到kafak里面，再通过Spark进行计算，计算完之后录到hive里面，处理流程太长了。经过简化，我们直接把数据推到Hadoop里面就搞定了。有的时候做减法感觉更好，我们现在做事情做架构都是做减法。
这一套Hadoop集群的部署架构上面有4个管理节点，下面是数据节点，其中OceanBase由6个节点构成，每个节点是36核G，有1个2T的数据盘，一个日志盘，这个是经过OceanBase的团队check以后目前在运行的方案。
我们的集群部署结构有3个zone，每个zone有两台机器，总共6台机器的基础架构，支撑的业务由OceanBase加PGSQL，还有HDMS这些组件共同来支撑各种业务，业务场景有数据接口、系统应用、报表可视化等等这些应用场景。
「Hadoop+OceanBase点亮新能源大数据」
这个是我们现在集群情况，目前只是个小集群：3个kafka，8个Hadoop管理节点加数据节点，6个OceanBase节点，支撑10万个点位数据。每天有10万个点位需要收集，新增数据0.5个TB左右，虽然数据量还不是很大，但是我们后面有个Hadoop节点的集群，随着数据量会越来越大，OceanBase在该业务扮演的角色会越来越重要，核心功能会体现的淋漓尽致，比如弹性扩缩容，HTAP能力等。
这个项目的投资额很大，是我们国家能源部布局的光伏储能的时政平台，是一个很有意义的项目，它是代表着我们在光伏产业的新技术新产品。
四、从用户角度还能改进什么？
从红象云腾的实践中，基于用户角度，想对OceanBase提出五点建议供参考。
1.JBOD（justabunchofdisks）多盘符挂载支持。
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云平台（OceanBaseCloudPlatform，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.HiveMetadataOnOceanBase。
当前我们的Hadoopmetadata解决方案还是基于MySQL，因此存在单点、容量受限的问题。我们计划使用OceanBase替换MySQL方案并应用在通信管理的管理局项目上，目前该方案还是测试阶段。
2.OceanBaseBackUpToNFSOnHDFS。
这个问题是关于Oceanbase的Backup。OceanBase本身有备份和恢复的功能，大家也都可以使用，同时数据默认是三副本（即数据会存储三份），通过Paxos协议保证数据的强一致性，天然保证业务的高可用。不过我们想的是OceanBase在帮我们解决问题的同时能不能也用上Hadoop？这样两个产品的优势会整合起来，形成一个非常好的解决方案。
在下面这个场景里大家可以感受下：我们公司最大的客户是中国航天，在Hadoop上存储、管理的数据达到几十个PB，管理了几十颗卫星的数据，因此我们的责任很大，不能掉以轻心的。这套系统上线之后，这十几年来我们没有出现过一次因为机器故障导致大规模数据丢失的问题，有时候哪怕是丢了几个小块，我们都可以从文件系统把这个块数据找回，所以Hadoop给了我们一个很好的备份机制，大家可以放心的把数据存在上面，而不用担心数据丢失。因此，可以尝试把Hadoop当作OceanBase的备份组件使用，这是我的小建议。
写在最后
从开源中来，到开源中去，这是我给大家的一个建议。有很多同学都是用开源产品的，可能也是开源软件的创立者，我们是开源软件的受益者，所以我们也要为开源做出我们的贡献。
分享一下我对开源的理解：
第一，开源是一个建立标准的过程，一流的公司是做标准的。第二，开源是一个建立连接的过程。你的软件被大量的使用，你和各个公司建立起了连接，自然有商业机会。红象云腾使我们参与到Hadoop的开源社区里面，去普及和推广Hadoop，这是我们成长起来的关键原因。我们希望能够跟着OceanBase开源社区共同成长，为OceanBase开源贡献我们的力量。