提起大數據平臺的存儲，我們能想到的技術有很多，比如分佈式文件系統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對隨機讀寫和數據分析操作的雙重支持。
閱讀更多 億信華辰 的文章
