告別「紛紛擾擾」—小米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）用戶使用 OLAP 服務時，若是要訪問 Kudu 表，須要對 SparkSQL隊列進行特殊配置，以開啓對 Kudu 數據源的支持。

（2）雖然早期架構在代碼層對meta 作了合併，可是並未從根本上解決權限分離的狀況。好比用戶經過 Hive 受權的某個數據庫A，經過 OLAP 系統受權了某個數據庫B，在 OLAP 系統是沒法看到數據庫A的相關表信息的。還會出現用戶有Kudu表權限但沒有 Hive 表權限的狀況。上述狀況不利於用戶數據的打通，還會讓用戶在使用過程當中產生疑惑。同時，用戶須要切換隊列配置重啓服務，使用上也不夠友好。

二、開發角度：

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引擎服務。