Apache Hadoop?生態系統的優勢之一就是能夠整合不同的技術,解決各種大數據問題。要實現良好的整合,就要注意易用性以及數據交換的速度和效率。

EsgynDB?是Esgyn公司的web-scale企業級SQL-on- Apache Hadoop?解決方案,現已支持與Apache ORC?文件的緊密集成。在本文中,我將介紹結合EsgynDB和ORC文件所帶來的好處,然后探討該集成解決的兩個重要用例。

EsgynDB?是基于Apache TrafodionTM(正在孵化)的高可擴展SQL引擎。Apache TrafodionTM是高可擴展的企業級數據庫引擎,HP在2014年將其開源。Apache TrafodionTM承載了聯機事務處理和數據倉庫20多年的研發成果,具有非常成熟的查詢優化和運行時技術。

所有的數據庫引擎都依賴于存儲表的存儲引擎層。自2015年誕生以來,EsgynDB就使用Apache HBaseTM作為存儲引擎。同時,逐漸增加對其他存儲引擎的支持(例如,Apache HiveTM TextFile和SequenceFile)。現在,還新增了對ORC文件的支持。

ORC是Hive項目的一個產物。由于通過編寫Java程序執行MapReduce無法高效地進行即席查詢處理(從開發者或用戶的角度),Hive應運而生。Hive通過自己的方式執行SQL語言,消除了Java編程的繁瑣性。

最初,Hive使用簡單的文本文件作為其存儲層。但很快就發現,創建優化格式的文件可以提高性能。然后,產生了RC文件,接著進一步優化為ORC。

ORC旨在進行分析型查詢處理,是一種列式存儲。一個ORC文件分為各個stripe,每個stripe都包含一個行集。在一個stripe中,各列分開存儲。每列都根據適合其數據類型的技術進行壓縮。例如,整型列使用行程長度(run-length)編碼壓縮,字符串列使用字典技術(dictionary)。通過索引結構,可以跳過某些值。每個stripe都知道各列的最小值和最大值,因此某些查詢可以跳過一些stripe。

連接ORC文件的庫支持謂詞下推,這是一項長期用于高效查詢處理的技術,使邏輯盡可能地靠近數據。

ORC還支持分區,分區計劃與其他的Hive文件格式相同:將一個或多個列定義為“PARTITIONED BY”列。為分區列每個不同的值創建一個ORC文件。列值存儲在文件名為給定分區的文件中。

這些功能(列式存儲、row striping、復雜壓縮、謂詞下推、分區)都使分析型查詢處理變得高效:成熟的查詢引擎可以快速地僅讀取需要的行和列。

EsgynDB就是這樣的查詢引擎。EsgynDB繼承了很多支持先進并行查詢的數據庫引擎,可以處理分區(例如,HBase存儲引擎)。通過對ORC的支持,添加了代碼,利用ORC分區結構在編譯和運行時消除不必要的分區訪問。此外,EsgynDB還可以并行處理其余的分區。EsgynDB的前身產品支持具有謂詞下推的存儲引擎。因此,向ORC添加謂詞下推是Esgyn架構的簡單擴展。EsgynDB已經具有了只選擇需要的列的概念,所以利用ORC的列式結構可以很容易地將信息傳遞到ORC層。壓縮是EsgynDB可以利用的功能;ORC客戶只需考慮受壓縮影響的ORC訪問成本計算。

簡而言之,EsgynDB和ORC文件可以實現自然、輕松的集成。

您可能會問:為什么不使用Hive查詢引擎?您當然可以使用Hive查詢引擎,但是EsgynDB引擎的成熟性更高。其一,Hive不是標準的SQL實現。其語法是非標準的,會顯示很多成熟引擎不應顯示的細節,降低了可移植性。而且,其語法是不完善的,缺少很多ANSI功能。其二,Hive的運行時引擎和優化器的性能還有很大的改進空間。

最近,Esgyn運行了一個內部的基準測試,使用TPC-DS數據庫和查詢集測試基準,比較EsgynDB和Hive在ORC文件上的性能。EsgynDB可以運行所有的99個查詢,只需進行ANSI和TPC-DS都允許的少量修改,甚至無需修改。Hive只能運行65個查詢。在這65個查詢的性能上,EsgynDB的速度是Hive的5倍。

以上,我介紹了集成EsgynDB和ORC的一些好處。現在,我想要介紹兩個相關的用例:混合事務/分析處理(HTAP)和多溫度數據。

維基百科將HTAP定義為“單個數據庫同時支持OLTP和OLAP的能力”。HTAP的想法是要在分析型處理的平臺上同時支持事務型工作負載。這個問題的棘手之處在于存儲引擎或數據庫引擎本身。

在存儲引擎方面,要支持這樣的混合型工作負載,就要為不同的工作選擇合適的工具。

對于事務型工作負載,您需要一個在小型訪問方面(一次幾行)高度優化的存儲引擎。您要能夠從一個或多個大表中插入、修改或獲取幾行數據,這就需要有一種高效的索引結構。您還要能夠使用ACID事務完成此類操作,因此還需要一個集成了事務引擎的鍵值存儲。EsgynDB基于的Apache Trafodion就可以做到這一點:Trafodion表存儲于HBase,Trafodion事務引擎通過HBase協處理器集成于HBase Region Server進程。

對于分析型工作負載,您需要一個能夠根據行或列,有效地訪問大表中大量數據的存儲引擎。正如我之前所述,ORC可以滿足這一條件。

需要注意的是,在多合一存儲引擎方面,已經有了一些嘗試。目前,這些嘗試在事務和/或分析的效率方面都有所下降。如果出現了成功的方法,EsgynDB將隨時利用這種引擎。

在數據庫引擎自身,如果只有幾行被直接訪問,則需要一個支持快速路徑的查詢引擎以及能夠有效處理大量行的分析路徑。此外,還需要一個查詢優化器,用于根據查詢特征選擇合適的路徑。得益于20多年的研發和前期產品,EsgynDB可以非常好地支持這些方面。

因此,可以將事務型數據存儲于HBase,將分析型數據存儲于ORC,并使用EsgynDB對這兩種數據進行查詢和管理。另外,EsgynDB可以將兩者結合起來:查詢既可以引用Trafodion(和本地HBase)表,也可以引用ORC表。

“多溫度數據”是指,既有“熱數據”(被頻繁訪問的數據)也有“冷數據”(很少被訪問的數據)的數據集。通常,“冷數據”的數據量會大大超過熱數據。例如,會隨著時間的推移逐漸累積的事務型數據。如果是當天銷售數據的SALES表,則該表可能就是“熱”的;如果是上周、上個月甚至去年銷售數據的SALES表,則該表可能就是“冷”的。另一個例子是log數據。最近事件的log數據會被頻繁引用,而過去事件的log數據僅用于說明或展現長期趨勢的查詢。

如果要支持“熱數據”,就需要一個能夠將“熱數據”緩存在內存中的存儲引擎。HBase能夠做到這一點,如果要支持“冷數據”,就需要一個能夠根據“溫度”(通常使用日期字段)存儲大量數據的存儲引擎。如果要同時支持這兩種數據,就需要一種有效的機制,將變冷的數據增量遷移至另一個存儲引擎;還需要一個能夠識別“溫度”的查詢引擎,根據數據的“溫度”,以優化的方式訪問數據。

HBase存儲引擎非常適合存儲“熱數據”。HBase將最新和被頻繁訪問的數據存儲在內存memstore中。隨著數據逐漸變冷,HBase將變冷的數據作為排序的日志文件寫出,并通過后臺處理進行結合和壓縮。隨著數據進一步變冷,可以通過EsgynDB將這些數據從HBase遷移至ORC(可以使用INSERT/SELECT語句,或使用UPSERT USING LOAD等變量)。EsgynDB引擎生成具有適當并行度的計劃,快速、有效地遷移數據。

從應用程序的角度來看,可以在EsgynDB中定義一個同時包含“熱數據”和“冷數據”的視圖。這樣,終端用戶可以無需考慮數據的存儲引擎,簡便地查詢數據。

Apache Hadoop的成功是由于為不同的工作集成了適當的工具。EsgynDB緊密集成了HBase和ORC,成為了Apache Hadoop中事務型和分析型工作負載的首選查詢引擎。

若要了解更多信息,請隨時與我取得聯系。