三、国产大数据库技术

（一）阿里巴巴OceanBase

  OceanBase主要是为了解决淘宝网的大规模数据而产生的，是一个支持海量数据的高性能分布式数据库系统，达到管理数千亿条记录的规模，支持在数百TB数据上跨行跨表事务并支持SQL操作。

1. 系统架构

  （1）客户端。基于MySQL数据库开发的应用程序、工具能够直接迁移到OceanBase。
  （2）RootServer。配置服务器，一般是单台服务器。记录commit log并通常采用双机热备。
  （3）UpdateServer。存储OceanBase系统的增量更新数据。
  （4）ChunkServer。保存基准数据的服务器，通常是多台，同一份基准数据通常保存3份并存储在不同的ChunkServer上。
  （5）MergeServer。接收并解析用户的SQL请求经过词法分析、语法分析、查询优化等一系列操作后转发给相应的ChunkServer或者UpdateServer。

2. 数据查询流程

  如图所示，用户可以通过兼容MySQL协议的客户端，JDBC/ODBC等方式将SQL请求发送给某台MergeServer，MergeServer的MySQL协议模块将解析出其中的SQL语句，并交给MS-SQL模块进行词法分析（采用GNU Flex实现）、语法分析（采用GNU Bison实现）、预处理，并生成逻辑执行计划和物理执行计划。
  如果是只读事务，MergeServer需要首先定位请求的数据所在的ChunkServer，接着往相应的ChunkServer发送SQL子请求，每个ChunkServer将调用CS-SQL模块计算SQL子请求的结果，并将计算结果返回给MergeServer。最后，MergeServer需要整合这些子请求的返回结果，执行结果合并、联表、子查询等操作，得到最终结果并返回给客户端。
  如果是读/写事务，MergeServer需要首先从ChunkServer中读取需要的基线数据， 接着将物理执行计划以及基线数据一起发送给UpdateServer，UpdateServer将调用PS-SQL模块完成最终的写事务。
  CS-SQL：实现针对单个table的SQL查询，包括表格扫描（table scan）、投影（projection）、过滤（filter）、排序（order by）、分组（group by）、分页（limit），支持表达式计算、聚集函数（count/sum/max/min等）。执行表格扫描时，需要从UPS读取修改增量，与本地的基准数据合并。
  UPS-SQL：实现写事务，支持的功能包括多版本并发控制、操作日志多线程并发回放等。
  MS-SQL：SQL语句解析，包括词法分析、语法分析、预处理、生成执行计划，按照tablet范围合并多个ChunkServer返回的部分结果，实现针对多个表格的物理操作符，包括联表（Join）、子查询（Subquery）等。

3. 系统特点及优势

特点：

• 主体数据在一段时间内保持相对稳定
• 以内存保存增删改记录极大地提高了系统写事务的性能
• 扩充UpdateServer内存即增加了内存中容纳的修改量
• 动态数据服务器UpdateServer写commit log并采取双机（甚至多机）热备
• OceanBase按主键的范围查询对应着连续的磁盘读

优势：

• UpdateServer。类似于DBMS中的DB角色，提供跨行跨表事务和很短的查询修改的响应时间以及良好的一致性。
• ChunkServer。具有数据多副本、中等规模数据粒度、自动负载平衡、宕机恢复、机器plug and play等特点，系统容量及性能随时扩展。
• MergeServer。结合ChunkServer和UpdateServer，获得最新数据，实现数据一致性。
• RootServer。类似于云计算中的主控机（如GFS master），进行机器故障检测、负载平衡计算、负载迁移调度等。

4. 可靠性与可用性

• OceanBase在ChunkServer中保存了基准数据的多个副本。
• OceanBase在UpdateServer中保存了增量数据的多个副本。
• ChunkServer的多个副本可以同时提供服务。
• UpdateServer主备之间为热备，同一时刻只有一台机器为主UpdateServer提供写服务。
• OceanBase存储多个副本并没有带来太多的成本。
• 在OceanBase系统中，用户的读/写请求，即读/写事务，都发给MergeServer。

  在OceanBase系统中，用户的读/写请求，即读/写事务，都发给MergeServer。MergeServer解析这些读/写事务的内容，例如词法和语法分析、schema检查等。对于只读事务，由MergeServer发给相应的ChunkServer分别执行后再合并每个ChunkServer的执行结果；对于读/写事务，由MergeServer进行预处理后，发送给UpdateServer执行。只读事务执行流程如下。
  （1）MergeServer解析SQL语句，词法分析、语法分析、预处理，最后生成逻辑执行计划和物理执行计划。
  （2）MergeServer将请求拆分后同时发给多台ChunkServer并发执行，每台ChunkServer将读取的部分结果返回MergeServer。
  （3）如果SQL请求涉及多张表格，MergeServer还需要执行联表、嵌套查询等操作。
  （4）MergeServer将最终结果返回给客户端。

（二）云创存储数据立方（DataCube）

  针对目前各类大数据库无法实时处理极其海量数据（万亿条记录以上规模）的不足，云创大数据推出了全新的云计算数据库——数据立方。该系统采用分布式块存储、 动态B+树森林、并行执行架构以及读取本地磁盘的执行方式，使入库和处理达到了实时完成、简单易用、高度可靠的效能，使EB级的数据能够秒级处理，极大地提高了海量数据的处理效能，还可支持数据仓库存储、数据深度挖掘和商业智能分析等业务。目前平台已经在中国移动、国家地震局等得到非常成功的应用。在中国移动某省公司已经稳定生产运行3年，单库由40多个机架构成，且仍在不断扩展中，处理了高达1亿个同时在线终端形成的实时数据流15000Mbps,每天新增100亿条记录。

1. 数据立方体系架构

  数据立方（DataCube）的结构分为用户接口、索引、SQL解析器、作业生成器、元数据管理、并行计算架构、分布式文件系统等部分，如图所示。

  用户接口主要有两个：JDBC和Shell。JDBC主要执行数据的定义操作，即建立数据库、建表、建分区，对数据库、表和分区的删改等，同时可执行数据查询的SQL语句，暂不支持单条记录的增删改。数据立方提供友好的Shell交互界面，Shell支持数据库、表的增删改以及数据查询的SQL语句。
  数据在入库的同时与数据对应的索引也在同时建立，索引由若干颗B+树构成的B+树森林，数据插入内存的同时，索引B+树森林也在生成和融和，当达到内存数据块上限时，数据和索引会刷新到分布式文件系统上成为文件。数据立方的元数据存储在数据库中。其中包括数据库的名字和属性、数据库中的表、表的名字、表的列和分区及其属性、表的属性、表的数据所在目录等。
  SQL解析器接收从JDBC和SHELL传来的SQL查询语句，同时对SQL进行词法分析、语法分析、编译、优化。作业生成器根据SQL语法树生成查询作业，分析所要处理的数据表对应的索引文件所在的存储子节点位置，并将作业发送给并行计算架构。并行计算架构接收到作业生成器生成的作业，根据索引文件的位置切分查询作业形成子任务，然后将子任务发送给数据所在的存储子节点，每个节点执行这些子任务查询索引得到结果记录所在的数据文件名与偏移量，并以广播的方式发送查询子任务到数据文件所在的节点，在执行完毕后将结果返回。
  数据立方可以使用HDFS和cStor作为底层存储系统，cStor是一个主从结构的分布式文件系统，不仅具有HDFS的高吞吐率、高读/写性能等特性，还支持HDFS所不具备的对文件修改等功能，并且支持POXIS接口。

2. 分布式并行计算架构（DPCA）

  数据立方的分布式并行架构（DPCA）是典型的主从结构，主Master与从Master分别部署在HDFS的主从NameNode物理节点上，而Slave部署在DataNode物理节点上，主从Master使用Zookeeper同步，并共享系统日志，Master与Slave之间用心跳信息保持信息交换。如图所示。

  相对于MapReduce架构，DPCA具有实时性、计算的数据本地性以及数据平衡性。MapReduce架构的Job提交过程较为复杂，客户端将Job提交到JobTracker有较长的延迟，JobTracker将Job处理为MapReduce Task后，通过TaskTracker的心跳信息将Task任务返回给TaskTracker，此过程中也存在延迟。MapReduce架构虽然也遵循数据本地性，但仍会有很大比例的数据处理不是本地的。相对于MapReduce架构，DPCA的Job提交是实时性的，在提交Job之前所需程序Jar包已经分发到所有计算节点，在Job提交之后，Master在初始化处理之后即将Task直接分发到所有slave节点上，如图所示。在Job提交后，Master根据数据文件所在位置分配Task，这样在每个计算节点上要处理的HDFS上的数据块就在本地，这样避免了数据的移动，极大地减少了网络I/O负载，缩短了计算时间。每个计算节点会根据Task中SQL解析器生成的执行计划对Task执行的结果进行分发。分发的方式有3种：分发所有中间数据到所有计算节点，分发所有中间数据到部分节点，根据数据所在位置分发，如图所示。并行计算架构能够周期性地对HDFS上的数据表进行维护，保持数据表在所有的DataNode节点上所存储的数据量的平衡，减少因数据负载的不平衡而导致的计算负载的不平衡。
  举一个典型的小表与大表Join连接的实例，如图所示，Master解析Job中的执行计划，判断小表的位置后，将Task0发送给Slave0，指令Slave0发送小表到所有节点，而其他节点占接收到的子任务是等待接受小表的数据，接收到数据后将小表与大表连接并将数据返回给Master，当所有数据返回完成则这个Job完成。

3. 分布式索引

  MapReduce对每个查询都是直接从分布式文件系统中读入原始数据文件，I/O代价远高于数据库，相对于MapReduce架构以及在其之上的SQL解析器Hive，数据立方引入了一种高效的分布式索引机制，不同于并行数据库的Shared-nothing和Shared-disk架构，数据立方的数据文件与索引文件都存放在分布式文件系统之上。

  数据在入库的同时B+树索引在内存中同步生成，B+树中的叶子节点存储的是数据文件路径与记录在文件中的偏移量。在B+树中的叶子节点达到设置上限后，索引将被序列化到分布式文件系统之上，在根据条件进行单表查询的时，Job被提交到并行计算框架。Master节点首先分析该表的索引文件根据索引文件，所在的节点将Task发送到相应的节点，每个节点在查询本地的索引文件之后将符合条件的数据文件路径+偏移量打包成Task，根据数据文件位置进行再次分发，在数据文件中的记录查询出来之后将结果返回，如图所示。

4. 数据立方大数据一体机

  处理海量数据的高效分布式软/硬件集合的云处理平台。该平台可以从TB乃至PB级的数据中挖掘出有用的信息，并对这些海量信息进行快捷、高效的处理。平台支持100Gbps以上量级的数据流实时索引，秒级响应客户请求，秒级完成数据处理、查询和分析工作。平台可以对入口数据进行实时索引，对数据进行分析、清理、分割，并将其存储在云存储系统上，不仅在入库和检索时具有非常高的性能优势，还可以支持数据深度挖掘和商业智能分析等业务。如图所示。