提起大数据平台的存储，我们能想到的技术有很多，比如分布式文件系统HDFS，以及在HDFS上的列式存储技术Parquet、ORC，还有以KV形式存储半结构化数据的HBase等。尽管它们都有鲜明的特点，但一种存储格式不能同时支持增删改查，这些存储技术都存在着一定的局限性。
这就是为什么有了如此多的存储技术，但亿信华辰公司还要开发出一款全新的数据存储平台？
现状：一种存储格式无法满足需求
通常，在 Hadoop 中存储的数据大体分为两类：
静态数据，通常都是使用二进制格式存放到 HDFS 上面，譬如 Apache Avro、Apache Parquet。这些存储格式都是为高吞吐连续访问数据这些场景设计的，都没有很好的支持单条 record 的更新，或者是提供好的随机访问的能力。
动态数据，一般使用半结构化的方式存储，比如 Apache HBase。它能低延迟的读写单条 record，但是对于一些像统计分析这样需要连续大量读取数据的场景，显得有点笨拙。
在以往的应用中，我们经常会存储两套数据分别用于实时读写与数据分析，先将数据写入HBase中，再定期ETL到Parquet进行同步。但是这样做有很多缺点：
1. 用户需要在两套数据间编写和维护复杂的ETL逻辑。
2. 时效性较差。ETL通常是分钟级、小时级、甚至是天级运行，这样数据从写入到可被分析之前会存在一个较为明显的“空档期”的。
3. 更新需求难以满足。在实际项目中时常会有一些对写入的数据更新需求，而对Parquet这种静态数据集的更新操作，代价是非常昂贵的。
4. 存储资源浪费。两套存储系统意味着占用更多的存储资源，造成了成本的提升。
方案：平衡随机读写和批量分析的性能
Parquet格式具有高吞吐量连续读取数据的能力；而HBase适用于低延迟的随机读写场景，那么有没有一种技术可以同时具备这两种优点呢？现在，亿信华辰实时大数据平台PetaBase-i提供了一种“折中”的选择，在开源行列混合存储系统基础上开发的PetaBase Hybrid C-store（以下简称HCs）。
HCs 的定位是一个既支持随机读写、又支持 OLAP 分析的大数据存储引擎。HCs 就是我们说的“折中”选择，在 HDFS 和 HBase 这两个偏科生中平衡了随机读写和批量分析的性能。HCs不但提供了行级的插入、更新、删除API，同时也提供了接近Parquet性能的批量扫描操作。使用同一份存储，既可以进行随机读写，也可以满足数据分析的要求。HCs在PetaBase-i中的架构如下图：
从用户角度来看，HCs是一种存储结构化数据表的存储系统。用户可以定义任意数量的table，每个table都需要预先定义好schema。每个table的列数是确定的，每一列都需要有名字和类型，每个表中可以把其中一列或多列定义为主键。从某种层面来说，HCs更像关系型数据库，这种设计可以带来如下好处：
1. 确定的列类型使HCs可以进行类型特有的编码。
2. 可以提供 SQL 接口给其他上层查询工具，比如BI、ETL工具。
HCs非常适合的场景通常包含如下特点：
1. 数据有更新需求，支持update和upsert操作
2. 大量数据复杂的实时分析，大范围的数据扫描
3. 同时有单点查询和统计分析的混合场景
4. 需要使用SQL对结构化数据进行增删改查，类似传统RDBMS
5. BI或数据仓库项目中架设ODS（Operational Data Store）层
应用：在更新更及时的数据上做更快的分析
HCs的应用场景很广泛，但我们一般更倾向于将其运用在实时的数据分析中，尤其是用于源端数据经常存在变化的实时数据应用等，下图向大家展示了融合Hcs和Kafka的实时流计算架构，一个基于Oracle GoldenGate的数据库日志解析和HCs的实时分析。
该架构用于实现DB和PetaBase-i大数据平台之间基于日志解析的数据同步。使用OGG或者Flume将DB事务日志解码，再接入Kafka进行缓存，PetaBase-i内置的Spark Streaming程序进行实时数据处理，生成HCs的Ins/Upd/Del事务并执行，实现数据同步，BI等分析应用查询PetaBase-i Hybrid C-Store中实时更新的数据。
HCs存储方案减少了实时流处理整体的架构复杂度，数据可以集中存储在HCs上，不需要再像以往那样借助两套存储系统，大大提升了实时性。同时，数据处理的链路也被简化了，这都得益于HCs对随机读写和数据分析操作的双重支持。
（部分内容来源网络，如有侵权请联系删除）
