告別“紛紛擾擾”—小米OLAP服務架構演進

本文從後設資料和許可權管理兩方面介紹了小米OLAP服務的架構演進。

What’s OLAP?

如果你是一名資料分析師，或者是一位經常和 SQL 打交道的研發工程師，那麼 OLAP這個詞對你一定不陌生。你或許聽說過 OLAP、OLTP 技術，但是今天文章的主角OLAP 是由雲技術平臺提供的一款分散式資料分析服務，下面先簡單介紹一下它。

小米 OLAP 是集儲存計算於一體的分散式資料分析型資料庫服務，透過 Kudu 實現“熱資料”的實時寫入和更新，透過自定義視窗定期遷移“冷資料”到HDFS，並以Parquet 格式儲存，實現了冷熱資料分離的架構，最終透過 SparkSQL 引擎提供同時對實時資料和歷史資料進行分析的能力。

OldArchitecture & Drawbacks

圖1. OLAP 1.0後設資料與許可權管理

過去究竟有哪些“紛紛擾擾”呢，讓我們先從 OLAP1.0 版本的後設資料與許可權管理圖說起。可以看到，在舊版的架構中，Kudu表相關的許可權和後設資料與Hive表相關的許可權和後設資料，無論在實現上還是底層儲存上都是分離的。前者透過我們自己實現的Metadata Cache 和 Privilege Cache 與 OLAP 服務的元件 Metastore Manager 及SparkSQL 引擎進行互動，資料儲存在 Kudu 上；後者則使用了獨立的服務 Hive Metastore(HMS) 和 Sentry 分別進行後設資料與許可權的管理，底層資料儲存在 MySQL 資料庫。瞭解完舊版本的架構，就可以更徹底地瞭解這樣的架構帶來了的問題：

1、使用者角度：

（1）使用者使用 OLAP 服務時，如果要訪問 Kudu 表，需要對 SparkSQL佇列進行特殊配置，以開啟對 Kudu 資料來源的支援。

（2）雖然早期架構在程式碼層對meta 做了合併，但是並未從根本上解決許可權分離的情況。比如使用者透過 Hive 授權的某個資料庫A，透過 OLAP 系統授權了某個資料庫B，在 OLAP 系統是無法看到資料庫A的相關表資訊的。還會出現使用者有Kudu表許可權但沒有 Hive 表許可權的情況。上述情況不利於使用者資料的打通，還會讓使用者在使用過程中產生疑惑。同時，使用者需要切換佇列配置重啟服務，使用上也不夠友好。

2、開發角度：

Metadata Cache 和 Privilege Cache 在實現上存在冗餘，其和底層後設資料的互動在兩個元件都存在。其維護和開發成本比較高，沒有統一入口和規範。同時，底層分離的後設資料和許可權並不利於後續統一的 SQL Proxy 的開發。

可以看到，無論從使用者的角度，還是開發者的角度，進行底層後設資料和許可權的架構整合都非常必要。

和“紛紛擾擾”說再見

介紹完了過往的“紛紛擾擾”，讓我們看看如何和“紛紛擾擾”說再見。從圖1可以看出，解決這種分離的最簡單方法就是複用現有的 HMS 和 Sentry 元件，將原有的後設資料和許可權資料遷移到 MySQL 資料庫，同時更改上層元件的在後設資料和許可權部分的互動方法，包括 SparkSQL 層和 OLAP 服務端元件(OLAP Server、Metastore Manager 和 Dynamic Manager)。

圖2. OLAP 2.0後設資料與許可權管理

更改後的後設資料與許可權管理圖如上所示。下面我們分為兩部分來介紹相關的工作。

MetadataFederation

後設資料整合方面，我們引入了 Kudu Storage Handler,其實現了 Hive Meta Hook的介面，繼承了 DefaultStorageHandler 類，可以與 HMS 進行互動，完成了對 Kudu meta 的相關操作。在原版的基礎上，我們補充了分割槽和表的相關操作，以及一些必要的rollup操作來保證 meta 的一致性。

在 SparkSQL 層，對 Kudu meta 的呼叫方式轉化為了直接使用 Kudu Storage Handler,原有的 Kudu 相關模組的功能直接整合進 Hive 模組，包括了查詢、建表、刪除表、修改表、展示建表語句等操作。我們大體相容了舊版本的 DML 語法，並透過 tblproperties 來傳遞各種 Kudu 相關的資訊，比如表名、range 分割槽資訊、hash分割槽資訊等，同時，我們自定義的資訊和資料流部分資訊也存在表屬性裡，供上層程式使用，比如是否 OLAP 表、OLAP 視窗值等。

在 OLAP 服務端，我們對所有後設資料相關的部分做了重構。原有的 Metadata Cache被移除，有關的後設資料的操作透過呼叫 HMS Client 提供的 API 來實現。同時，我們把系統相關的資料從 Kudu 遷移到 MySQL 資料庫，使整個服務端不再對 Kudu Client有直接的依賴。

經過上述整合，所有的meta操作統一到了 Hive MetastoreClient 層，透過 Kudu Storage Handler 實現，資料儲存在 MySQL,和對 Hive meta 的操作一致。對於開發者，這種架構整體上更為清晰，在修改和維護上也更方便。對於使用者來說，透過beeline 去操作 Kudu 表和 Hive 表除了在建表語法上不同，其他基本操作和 Hive 沒有區別，使用者在建表後基本不需要關心底層儲存介質，體驗上更加一致。

 PrivilegeFederation

許可權整合的前提是 Kudu 相關後設資料已經整合到了 HMS 中，這樣才能藉助 Sentry 進行許可權管理。基於此，我們需要實現鑑權和授權兩條通路。

在 SparkSQL 層，由於本身 Hive 模組就已經集合了 Sentry 用來做許可權鑑定，所以後設資料遷移過來以後，beeline 的操作都會透過 Sentry 進行鑑權，而授權部分目前SparkSQL 的語法還不支援。

在 OLAP 服務端，我們對原有許可權相關的操作進行了重構。原有的 Privilege Cache 被移除，所有許可權相關的操作透過呼叫 Sentry Client API 實現，包括鑑權、授權、移除許可權和許可權展示。在許可權展示方面，由於 Sentry 本身的模型限制，提供的 AP I無法滿足需求，我們根據自身需要進行了定製化開發，如增加了相應的 API 實現基於使用者角色的許可權獲取等。

經過許可權上的整合，Kudu 和 Hive 的所有許可權就打通了，並可以透過 Sentry 統一提供許可權相關的服務。

總結與展望

小結

經過後設資料與許可權的整合，OLAP 服務的後設資料範圍和許可權範圍都擴大了，同時意味著查詢的範圍也擴大了。新的架構如下圖所示，meta 相關的服務最終都由 Hive Metastore 來提供，許可權相關的服務最終都由 Sentry 來提供，我們只需要在各層透過客戶端介面進行呼叫即可。

New Architecture

 圖3. OLAP 2.0架構圖

展望

基於整合後的架構，未來我們可以提供更多的能力，比如基於HMS的後設資料服務，基於Sentry的許可權服務。未來，我們計劃支援更多的資料來源，比如MySQL資料來源，整合更多的SQL引擎，比如 Hive、Kylin 致力於打造統一的SQL引擎服務。