挑戰：支持多個存儲引擎

以下內容并不是新發現：行優化存儲適用于OLTP和運營工作負載，而列存儲適用于BI和分析工作負載。頻繁寫入的工作負載適用于行式存儲。對Hadoop而言，Hbase適合低延遲工作負載，列式ORC文件或Parquet適合BI和分析工作負載。業界（尤其是內存數據庫廠商）宣稱：列結構可以很好地為各種工作負載服務。實際上，當相同的數據結構用于處理不同訪問模式的工作負載時，通常存在性能折中。Cloudera承諾的Kudu存儲引擎將能滿足混合工作負載的要求，但它明確指出，低延時性能低于HBase，BI和分析工作負載性能低于Parquet。

NoSQL技術革新已經表明，為了滿足當今工作負載的不同需求，支持多種數據模型是很有必要的。但是，為了減少數據的復制和移動，理想方案是單個查詢引擎可以支持多個存儲引擎。數據可以駐留在數據結構/存儲引擎中，對于所需的數據訪問模式而言，這種情況是最理想的，而且查詢引擎可以透明地支持所有這些操作。為此，Hive、Impala、Drill、Spark、Presto和其他SQL-on-Hadoop解決方案支持多種數據結構。但是，這些查詢引擎還不支持OLTP或運營工作負載。

問題不僅在于存儲引擎無法服務于多種工作負載，而且查詢引擎也難以支持多個存儲引擎。為了支持混合工作負載，可能需要將數據從一個存儲引擎轉換和遷移到另一個存儲引擎，但這存在許多挑戰，接下來我們討論其中某些挑戰。

統計

如前所述，為了生成優良的查詢計劃、或理解工作負載是運行型或分析型，我們需要統計信息以支持所有類型的查詢工作負載。因此，當添加新的存儲引擎時，您還需要添加對收集統計信息的支持功能。存儲引擎有高效機制來對行進行抽樣嗎？通過增量統計，計算它是否有一個簡單的方法來查詢新的數據？它是否收集行數和其他可用于快速統計收集的指標？為了使查詢引擎決定何時對其統計信息做另一次更新，它是否收集增刪改查記錄的計數量？您需要回答諸如此類的一系列問題來設置對統計數據的收集，與存儲引擎高效地工作。

鍵結構

對于運營工作負載而言，鍵入訪問對亞秒級響應時間非常重要。單行訪問需要通過鍵進行訪問。由于事務或事實表總是具有多列鍵，理想情況下，鍵值應支持多列鍵。如果不支持多列鍵，則查詢引擎需要將多個主鍵列映射到單個存儲引擎鍵。此外，較短的運營查詢通常需要聚集訪問來檢索少量行。聚集鍵的范圍掃描有助于運營工作負載滿足服務級別協議（SLA， Service Level Agreements）。為了實現最高效的訪問，查詢引擎需要了解存儲引擎可用的鍵入訪問選項，并為其支持的每個存儲引擎優化此訪問。

分區

對于查詢引擎而言，了解存儲引擎如何跨磁盤和節點對數據進行分區，這一點非常重要。它是否支持哈希和/或范圍分區，或這些分區的組合？如何確定這種分區？為了平衡各個分區的負載和避免性能瓶頸，查詢引擎是否需要對數據進行加鹽（salt data）？如果需要，如何添加一個加鹽鍵（salt key）（例如，表格鍵的最左邊的列）并且仍然避免全表掃描？當集群在擴展或收縮時，存儲引擎是否重新分區或重新平衡分區，或者由查詢引擎來執行此操作？在對數據重新分區時，用戶可能需要全盤讀取和寫入，所以這可能會變得非常復雜。如果查詢引擎將對來自這些分區的數據執行并行處理，那么數據如何在分區間進行傳播是非常重要的。它需要嘗試將訪問本地化，減少數據的再分區（也稱為shuffle），或盡可能多地跨節點分布數據。在未理解存儲引擎的鍵和分區結構的情況下，不可能有效地處理查詢數據。運營查詢可能不會經常遇到并行處理數據的一些挑戰，但是，如何對數據進行分區將影響是否能通過訪問單個分區、磁盤或節點來處理快速運營查詢，而不必通過訪問多個分區來滿足具有嚴格服務級別的目標。

數據類型支持

查詢引擎需要了解存儲引擎支持哪些數據類型，以及存儲引擎對這些類型實施的約束條件，以便查詢引擎可以執行存儲引擎不會執行的任何約束條件。例如，在某些情況下，如果存儲引擎只支持字符串存儲，那么查詢引擎最好將數據存儲在自己的編碼數據類型中。或者，如果查詢引擎會強制執行CHECK限制條件，那么它是否可以將CHECK約束轉包給存儲引擎，或由查詢引擎來執行它們？當然，存儲引擎一般不會支持引用約束檢查。
如果存儲引擎能提供完整的字符集支持，那么存儲引擎和查詢引擎便能通過UTF-8進行通信；排序規則也是如此。

存儲引擎是否提供壓縮或加密支持，或由查詢引擎提供上述支持？查詢引擎很可能發出DDL語句（創建表格），它還需了解哪些選項用于數據塊級別壓縮和鍵壓縮，以及需要向用戶公開的其他表結構選項。在一些情況下，可能會將存儲引擎表格映射到表的查詢引擎視圖。

投影和選擇

大多數存儲引擎支持投影，存儲引擎只返回需要的列，否則查詢引擎必須解壓數據并進行投影。同樣，需要了解存儲引擎是否可以提供謂詞求值的能力。 存儲引擎能夠為哪些謂詞（=、<、>、<>、between、LIKE）求值？它能在多列上評估謂詞或評估多列謂詞（（a，b）>（5,1））嗎？它能處理IN列表嗎？支持多長IN列表？一般來說，它是否能處理ORs和ANDs的組合以及能處理何種復雜級別？它能自動確定應用謂詞的最有效的順序（例如，首先評估能最大程度減少基數的列上的謂詞，尤其是當存儲引擎為列式存儲時）嗎？ 它能處理涉及同一表格的多個列的謂詞（例如，c1>c2）嗎？除了文字，能處理字符串表達式（STR（c1，3，2）='10'）或日期和時間表達式嗎？這些表達式有多復雜？存儲引擎如何處理缺省或缺失值（NULLs）？查詢引擎需要了解存儲引擎的所有這些方面，以確定下推哪些謂詞到存儲引擎、哪些謂詞由查詢引擎評估。

內存價格的下降讓我們能為每個節點配置大量的內存，非易失性存儲器的廣泛使用也即將實現。為了訪問事務和分析工作負載的數據，存儲引擎不僅在內存中設計高效的結構，而且正在實施使投影和選擇等操作更高效的技術。存儲引擎利用L1、L2和L3 CPU高速緩存來處理數據，其速度甚至比主存儲器處理數據的速度更快。通過矢量化方法同時處理多組行/列的數值，并提出其他的創新方式，例如，最小化或消除序列化/反序列化的成本，最大程度地提高數據處理速度的同時最大限度地利用硬件設施。這樣，瓶頸將從磁盤移動到主內存，最終移動到CPU。高效地使用CPU非常重要，查詢引擎必須挖掘存儲引擎的效率，并盡可能地減少CPU使用率。

可擴展性

為了在存儲引擎/服務器端實現更多功能，一些存儲引擎可以運行用戶自定義的代碼（例如，在HBase上的協處理器、前觸發器或后觸發器），從而減少信息流量開銷并提高效率。

例如，如果優化器能將聚合下推到存儲引擎，則它可能有處理積極聚合的能力。當數據在GROUP BY列聚集或分組數目較小時，該方法極為有效。如果存儲引擎不支持該操作，則查詢引擎能使用協處理器來執行相同操作。可以在此層級執行具有表達式和函數的復雜謂詞求值、并發連接和索引維護、安全執行和某些ANSI觸發器操作，甚至事務支持。

安全執行

安全處理是查詢引擎和存儲引擎之間的信息交互點。存儲引擎可能有自己的底層安全實現方式，如果它能良好地與SQL模型進行集成，則查詢引擎可以使用它。否則，在細粒度訪問控制的情況下，查詢引擎必須管理schema、表、列和行的權限。它可能需要將自己的授權框架與存儲引擎的授權框架進行集成（甚至映射）。考慮到其他安全問題，例如，Hadoop安全解決方案（Sentry或Ranger管理這些對象），查詢引擎需要與該安全框架進行集成。根據對安全日志及其他安全信息和事件管理（Security Information and Event Management, SIEM）功能的支持，查詢引擎必須能與存儲引擎和平臺功能進行集成，或自身提供相關功能。對于混合事務/分析處理（Hybrid Transaction / Analytical Processing，HTAP）而言，由于可能需要支持多個存儲引擎，這將變得更加復雜。

事務管理

假設一個存儲引擎提供某種級別的高可用復制、備份和恢復以及某種級別的多數據中心支持。但是，事務性支持可以完全不同。事務管理具有ACID模型（原子性 [Atomic]、一致性 [Consistent]、隔離性 [Isolated] 和持久性[Durable]）以及BASE模型（基本業務可用性 [Basic Availability]、柔性狀態[Soft-state] 和 [Eventual consistency]）。根據搜索引擎提供的支持，查詢引擎可能需要提供完整的多行、多表格和多語句的事務支持，任一時間點的在線備份和事務一致性恢復，以及為多數據中心提供雙活同步更新和最終一致性的支持。查詢引擎需要與預寫式日志和存儲引擎的其他機制集成，以便利用引擎的底層復制和其他高可用性功能。這些可以具有很大差別，例如Cassandra、HBase或Hive，它們各自都有自己的事務模型。

此外，回到存儲引擎功能的可擴展性（例如，HBase的協處理器），查詢引擎需要實現此事務功能，盡可能地與查詢引擎接近并進行集成，以獲得可分布和最佳性能。否則，它最終只是一個更通用的、而不是可擴展的和高效的實現方式。

元數據支持

查詢引擎需要為正在支持的存儲引擎表添加元數據支持。存在可能映射（例如，目錄、名稱、位置和數據類型映射）；針對存儲引擎的特定擴展選項（例如，壓縮選項）；支持多列族 – 例如，將數據分區選項映射到底層存儲引擎結構（例如，Hbase regions）等。當有人在外部更改存儲引擎表時，如何更新該元數據？或者如何將其標記為無效，直到有人修復了差異？

實際上，如果數據庫能訪問外部存儲引擎，那么需要處理大量不可預知的問題，例如，如何保證事務一致性和數據完整性？如果列中的數據與其應該具有的數據類型不一致、或包含無效數據（可能它已通過其他方式更新），那么查詢引擎應如何操作？此外，您是否允許在此類表格上創建二級索引、視圖、限制條件和物化視圖等？上述情況不僅需要提供元數據支持，而且必須解決可能由外部訪問引起的潛在的不一致性問題。

運營工作負載與BI和分析工作負載所需的元數據支持存在差異。例如，運營功能需要參照完整性、觸發器和存儲過程，而BI不需要；運營工作負載不太需要物化視圖。

性能、擴展和并發性考慮事項

查詢引擎為了支持HTAP負載，在和不同的存儲引擎集成時，需考慮不同存儲引擎的性能、擴展性和并發性等關鍵因素。例如，是否有可用的批量加載機制，以及它在此類加載期間對事務一致性和可用性有什么影響？是否支持批量插入，從而可以有效地進行大量插入操作？批量提取功能是否可用，以在每個緩沖區返回行集，而不是一次返回一行的接口？是否有更快的掃描選項（例如，快照掃描）？當查詢引擎了解將會掃描大量數據時（可能是針對數據抽取或大型復雜查詢），能請求預取大塊數據嗎？查詢引擎如何進行并行更新和訪問存儲引擎？如果查詢引擎支持執行進程進行并行查詢，那么它如何最高效地訪問存儲引擎文件/分區和區域？存儲引擎能支持什么級別的并發訪問？查詢引擎如何最高效地利用存儲引擎所支持的功能和填補其不支持的功能？這些都很難確定，更難以實現。

錯誤處理

查詢引擎可能需要支持HTAP，因此，每個存儲引擎的錯誤處理方式也不相同。存儲引擎提供的錯誤處理機制是什么？如何記錄這些錯誤？存儲引擎記錄錯誤嗎？或者查詢引擎需要解釋每種錯誤類型并記錄它嗎？需要向用戶提供某些重大錯誤消息和補救指導嗎？

其他運營考慮事項

除了前文提到的錯誤處理，還需要考慮其他方面。例如，HBase的合并或拆分問題。這些對性能和用戶工作負載很重要，對事務工作負載的影響更大。如何通過查詢引擎管理這些以提供最佳客戶體驗？

簡單地說，支持存儲引擎并非一項簡單任務。當然，您可以走捷徑，例如，支持 InputFormat或OutputFormat；甚至使用UDF或某些連接器技術來使查詢引擎與存儲引擎進行通信。但要真正集成存儲引擎，讓其發揮最佳性能，并提供最高效的并行處理，需要投入大量的努力。如果您需要支持多個存儲引擎，以獲取在多個存儲引擎之上的查詢引擎的終極數據庫，這是非常困難的。

IT行業齊心協力共同為查詢引擎創建標準接口，例如，Java數據庫連接（Java Database Connectivity, JDBC）和開放數據庫連接（Open Database Connectivity , ODBC）。如果不同的存儲引擎能為查詢引擎提供通用的接口，這將是一件非常好的事。查詢引擎能通過接口快速省力地識別存儲引擎的能力，再與存儲引擎進行集成，并充分利用存儲引擎的功能。如果能實現這個目標，IT行業將會到達發展的成熟階段。但目前來看，各種存儲引擎的API及其功能并不統一。

雖然某些挑戰看起來與數據聯邦引擎必須應對的挑戰極為相似，但不同的是，查詢引擎使用標準JDBC / ODBC接口與數據聯邦引擎連接，即將查詢轉包至另一個查詢引擎。這種抽象層次與更深層次的集成不同，更深層次的集成能大幅提高效率和性能，它用于查詢引擎和存儲引擎之間。試想將一個專有RDBMS，例如，將Oracle拆分成一個查詢引擎和一個存儲引擎，該方法與聯邦引擎連接至Oracle實例的過程不同。

挑戰：適于所有工作負載的相同數據模型

正如IT行業的許多其他模糊術語一樣，data model這個術語包含很多不同的含義。在RDBMS背景下，數據模型（data model）是實現的規范化級別。用于運營工作負載的數據是從第一范式到第六范式。對于BI和分析工作負載使用的歷史數據，您需要不同的數據模型，例如，星型schema或更復雜的包含維度表和事實表的雪花schema等。數據模型大相徑庭，以適應在OLTP和運營查詢中的不同訪問模式，這些訪問模式側重于特定實體，（例如，客戶、訂單、供應商和產品），而不是側重于BI或分析查詢的大量歷史數據。

HTAP是否無需描述數據模型？一些內存數據庫供應商聲稱已經達到這種效果，但尚未撰寫出任何性能基準報告——人工（TPC）或真實世界——即BI和分析工作負載在第三范式中性能良好。現在，還沒有任何數據表明OLTP /運營系統能在星型schema中表現良好，不管是內存數據庫還是非內存數據庫。除了基準外，性能還由客戶運行的工作負載的種類決定，這些工作負載與TPC基準不同，甚至不存在一點交集。

因此，您明白存在一定級別的數據重復、轉換、聚合以及從一個數據結構、數據模型和存儲引擎到另一個數據結構、數據模型和存儲引擎的移動，而且您希望查詢引擎能將所有都無縫集成。雖然這很難，但還是可以實現。然而，完全不同的是，您不需要復制、轉換、聚合或移動數據，也不需要為任何工作負載降低性能。隨著Kudu的問世，Cloudera希望市場上有需要單一數據副本、愿意降低高端運營和分析性能的需求，即為了提高設計、開發和運營簡單性，他們愿意降低性能。最終結論尚待分曉，但是，如果IT行業在積極地追尋了NonSQL若干年后，又將鐘擺搖回預期方向，這將非常有趣。如今，性能擴展和高并發不僅是一項要求，而是唯一要求。

但是，如前所述，數據模型（data model）有不同的定義：鍵值、有序鍵值、Bigtable、文檔、全文搜索和圖形數據模型。為了實現單個存儲引擎的終極數據庫，人們試圖讓這些數據模型處理它們本來不擅長的業務，從而充分挖掘它們的潛力。因此，文檔中的整個父-子關系表明不再需要RDBMS功能，并且文檔的存儲能滿足所有工作負載要求。或者，現在是圖形數據庫的時代嗎？我們是否可以在邊緣和頂點中填充各種參數以支持各種工作負載？事實上，即使每個數據模型確實解決了某些問題，但它們并不能獨立地支持當今企業需要解決的各種工作負載。

文檔功能、文本搜索（必要時）、圖形結構（需要快速訪問的層級或網絡類型關系）、支持半結構化或非結構化數據的基于鍵值的模型，和完全結構化的關系數據庫能針對不同需求給出不同的令人滿意的結果。盡管一些查詢引擎全力支持，但挑戰是有效地將存儲引擎與查詢引擎進行集成。另外，為其他數據模型加入標準SQL API（實際上它并非標準，因為每個數據庫有它特有的實施方式）和非標準API，這也是一項挑戰。

無論您怎樣理解“數據模型”一詞，如果HTAP以相同的查詢引擎來支持所有企業工作負載的多個（非全部）數據模型，那么它需要克服許多挑戰。

挑戰：企業級能力

大企業開始將BI工作負載擴展至分析工作負載，再擴展至高級分析引用（例如，數據挖掘和機器學習），他們最初在專有數據庫和平臺上運行BI和分析工作負載，在Hadoop上運行大數據的其他工作負載。但隨后許多企業將某些在專有數據庫中運行的部分工作負載遷移至Hadoop上運行，一些企業正在提供運行全面的RDBMS OLTP和在Hadoop上運行運營工作負載的能力，從而將工作負載類型向混合事務型和分析模型擴展。但要真正處理所有工作負載，包括關鍵任務工作負載，則HTAP數據庫引擎需要提供企業級能力，我們將在以下部分對此進行討論。

高可用性

對任何數據庫而言，可用性是一項重要指標。例如，您可以通過HBase得到99.99％（也被稱為“4個9”）的可用性，即每年有約52.56分鐘的非計劃停機時間。許多關鍵任務應用都努力實現99.999%（也被稱為“5個9”），即每年5.26分鐘的停機時間。當然，可用性所增加的成本可能是巨大的。現在的問題是：查詢引擎與存儲引擎結合在一起，能提供何種程度的高可用性？

通常，數據庫很難實現高可用性。如果想要實現，需要解決以下問題：

• 當需要讀寫數據，在不能停機的情況下，您能將底層OS、Hadoop發行版、存儲或查詢引擎升級至新的軟件版本嗎——即，支持滾動更新嗎？
• 您可以將數據重新分配到已添加進集群的新的節點或磁盤嗎？或合并它們以減少節點或磁盤（完全在線，不停機）？與此相關的問題是重新分區數據的能力。您是否能在線完成？在線意味著在操作期間僅讀取數據、或同時讀取和寫入數據。
• 能在線為數據庫更改DDL嗎？例如，在不影響讀取和寫入的前提下，更改列的數據類型？數據庫能容易地添加和刪除非鍵列。
• 能在線創建和刪除二級索引嗎？
• 支持完全和增量在線備份嗎？

您的應用程序需要上述哪些功能取決于運營和分析工作負載的混合程度，以及高可用性對這些工作負載的重要程度。

安全

運營和分析工作負載的安全實現不同。對運營工作負載而言，通常在應用程序層管理安全性。應用程序與用戶交互，并管理數據庫的所有訪問。另一方面，BI和分析工作負載能使最終用戶通過報告和分析工具直接訪問數據庫。在這種情況下，可能會將授權推送至數據庫，查詢和存儲引擎需要管理安全性。

集成到SIEM系統也適用于分析工作負載，但很多運營工作負載需要更高程度的安全控制和可見性。

可管理性

管理數據庫及其工作負載的能力非常重要。從圖1-9中可以看出，可管理性需要很多功能，也許僅能實現部分功能

圖1-9 數據庫管理任務

由于HTAP工作負載的混合特性，某些管理任務變得越來越具挑戰性，特別是工作負載管理。衡量OLTP或運營工作負載時往往需要考慮事務或人機交互的能力。該理念是根據每秒完成的事務來評估服務水平目標。由于此類事務的延遲可能很小，所以跟蹤每一條SQL語句的性能或每一事務的表現成本將非常高。因此，您需要以某個時間間隔來統計信息并計算出平均值。而BI和分析適用于報表或查復雜查詢，這些查詢通常耗時較長，它們采集自身的運行指標值，并基于查詢級別統計信息進行監視和管理，以達到良好的性能。

根據優先級和/或資源分配，混合工作負載很難達到SLA的要求。分析工作負載的隨機特性使其不能很好地融入運營工作負載，即使在負載峰值期間，運營工作負載也要求亞秒級的響應時間。

如果查詢引擎正在與不同的存儲引擎進行集成，那么獲得所有的運行指標也具挑戰性。雖然查詢引擎可以跟蹤一些指標，例如，存儲引擎服務一項請求所花費的時間，但可能無法查看底層存儲引擎正在使用的資源。另外，很難在查詢引擎和存儲引擎之間細分出重要的CPU、內存和I / O指標以及諸如隊列長度和內存交換等信息，例如，如果您想獲得操作符（用于查詢計劃的每一步，例如，掃描、連接和聚合等）和被訪問的表在查詢中所使用資源的詳細信息，特別是并發執行和表被分區時，這將是一項非常困難的工作，除非利用插樁和回調函數收集端到端信息。再例如，如何找出遇到數據傾斜或瓶頸的原因？

在不久的將來，不同類型的工作負載可能在單個平臺上運行，但這篇報告并沒有詳盡列舉出與企業級運營能力相關的所有挑戰。例如，與YARN或Mesos的集成，它們會盡可能考慮如何管理跨集群的不同應用工作負載的資源。希望這些能幫助您理解目前的挑戰。