從分布式管理到多租戶實現，企業級大數據系統如何利用開源生態構建？
?? ??
大數據系統的應用領域
首先回顧一下歷史。
?? 
從中我們可以看到一些趨勢，在大數據生態發展的過程中，大數據系統的管理系統，大數據系統的安全，易用性，機器學習不斷的補充到生態系統中來并不斷完善。
早期是 Google 一家獨有。2003 GFS paper 發表的時候，Google 的集群規模就達到上千臺，***。
之后是大家都知道的歷史，Doug Cutting 在為他的 lucene 分布式化的時候看到了 Google 的這篇論文，并把它實現出來，后來被 Yahoo 收編，得到一個機會和環境把 Hadoop 孵化出來。
隨著互聯網的興旺發展，許多互聯網公司也逐漸開始把 Hadoop 變成內部大數據處理系統的不二之選。隨著大數據概念的火爆，使得開始是行業領頭羊的巨頭在玩的東西逐漸被有機會普及到傳統領域。
?? 
現在不斷能夠聽說新的大數據項目冒出來。
?? 
Hadoop 零基礎的同學會有一個模糊的認識，會把 Hadoop 當初數據庫，尤其是在使用 Hive 和 Impala 的時候，會在清醒和迷糊之間徘徊一段時間。
即使是領域內的同學，也會持有一個觀點，沒有海量數據，搞什么大數據? 我個人愿意把大數據系統這樣定義：大數據系統是在大數據的時代背景下，由一個樸素的應用需求催生出的系統，在大數據的浪潮中，被賦予的不同的期待，逐漸成長起來的尚處于青少年期的生態。
總之，我是想說，這是有門檻的。
好處自然很多，橫向擴展的能力、機器學習的能力、圖計算、流式計算，許許多多的應用場景令人浮想聯翩。
門檻也有很多，1) 開源系統，大家知道開源系統如果你不把里里外外全部了然于心，使用的時候碰到的麻煩應該是有所體會的。2) 它還在快速的成長，很多功能可能還沒有，或者是 bug 很多，傳統行業(在這里我指除 IT 之外的行業)應該是使用商業軟件居多。
但毫無疑問這個領域正在蓬勃發展。底層數據類型和格式非常廣的兼容性，計算模型的豐富和對于機器學習模型的支持。
那么什么樣的領域需要大數據系統?
- 海量數據：例如 IT 企業
- 數據非常雜：傳統企業
- 需要有新的數據處理模型的支持：AI 和實時運營決策公司(目前還很超前)。
例如下面這個場景：
- 5 年以上的老公司
- 跨國業務，數據需要到母公司匯總分析
- 數據鏈條很長，不同的業務會產生數據，數據應用和數據分析沒有分開
- 積累了歷史數據，還在繼續產生不知道如何分析的歷史數據
- 積累了一些問題，這些問題可以在數據中找到答案
- 行業競爭激烈，管理層很著急。。。
那么問題來了：
- 搭建這個平臺會遇到哪些困難?
- 要一個什么樣的數據平臺?
- 如何做數據管理和數據流程管理?
- 多久才能帶來價值?
?? 
這些問題先暫且放一放。
我們先看看這個問題，那么多的大數據系統的服務，如何能統一管理呢?這里的管理是指：
- 初始化安裝
- 配置文件修改發布
- 服務啟動停止
- 查看分布式的日志
- 服務升級
- 添加新的服務
- 系統調優
- 監控
- 到服務內部不同 web 應用的導航
- 集群元數據管理
還有在公有云和私有云提供創建實例接口的情況下，如何實現一鍵部署呢?下面以 Cloudera 的產品為例，講一下這些是如何設計實現的。
分布式系統的管理系統
先來看一下，如果修改一個沒有管理系統輔助的社區版的 Hadoop 系統的配置文件，它的復雜度是這樣的。
?? 
而事實上早期的集群維護的確就是這么做的，即使你用腳本把配置文件推送到其他節點，并且用腳本拉回日志檢查的話，還是非常不方便。
下面來看看 Cloudera manager 是怎么來解決這個問題的。
Cloudera manager 可以通過 RPM 手工安裝。Cloudera agent 可以通過 Cloudera manager 的界面添加。
?? 
?? 
?? 
Cloudera manager 通過 cloudera-scm-server 來中央控制整個集群的搭建、維護和監控。每臺機器上的管理工作交給 cloudera-scm-agent。
cloudera-scm-agent 借助開源項目 supervisord 來實現每臺機器的進程管理。supervisord 的好處是在單臺機器上實現對進程的集中管理。Cloudera-scm-agent 通過接受 cloudera-scm-server 的指令，調用 supervisord 的接口來進行控制本機上所有的進程和查詢本機上所有進程的狀態。
?? 
cloudera manager 把新改動與線上環境配置進行對比，如果發現有配置更新，提示用戶更新服務配置或者部署客戶端配置。
?? 
在更新服務配置的同時通過命令調用 cloudera agent，cloudera agent 調用 supervirsord 的接口，重啟各個服務器上的進程。在重啟完畢以后，cloudera manager 監控管理服務，通過調用服務接口檢測服務是否成功啟動，顯示服務的狀態，如果發現服務沒有成功啟動，用戶可以通過檢測結果判斷服務失敗的原因。
Cloudera RPM 安裝包中，還提供了監控的服務包。Cloudera manager 管理界面上可以啟動 Cloudera 的管理服務。其中有兩個監控服務，一個是 host monitor，其作用是接受 agent 上報來的節點數據，如磁盤使用情況，CPU capacity，CPU 用量，內存的大小和內存的用量，機器負載等。Service monitor 則是一個服務健康檢測服務，會定期的執行各種不同的檢測，把數據匯總到 web 界面供管理員查看。
?? 
同時 cloudera manager 提供統一入口的日志查詢 GUI，以一個搜索接口加過濾器的方式幫助用戶排查原因。
在有共有云服務的環境下，可以通過一個描述文件安裝整套 cloudera manager，cloudera agent 以及大數據服務。
cloudera director 通過調用云服務 API 創建集群所需要的實例。
?? 
通過云服務 API 得到地址信息，進而用 SSH 遠程命令調用安裝 cloudera manager 和 cloudera agent，并且啟動 cloudera manager 和 cloudera agent 服務。
?? 
通過調用 cloudera manager 的 REST 服務 API，進行大數據服務的安裝，部署和配置。
?? 
一些我了解的情況如下：
Cloudera 自己有自己的代碼倉庫，它的各種服務的代碼版本與社區發布的版本不一致。具體多大程度上不一致很難知曉。部分應該是由于 license 的原因，像 SPARKR 沒有集成到 cloudera 版本的 Spark 中去，應該是 license 的原因。
社區的大數據服務需要 Cloudera 進行定制才能集成到 Cloudera 的管理平臺上，支持的大數據服務的種類有限。
Cloudera 上面的服務版本更新還是比較慢的。
再來看看大數據系統在底層技術上是如何實現多租戶的?
數據平臺多租戶的實現
對于 Hadoop 平臺而言，多租戶是***的難點之一。大數據系統***的一個問題是資源浪費，早期單用戶，單任務。多租戶的目標可以有效的充分利用資源。多租戶的資源分配依賴于兩個技術：資源隔離，調度算法，在操作系統層面和服務層面(YARN)都可以做資源隔離。
YARN 在服務層面做資源隔離的是 JVM。YARN 的 node manager 響應 resource manager 的請求創建的 container，其實就是一個 JVM。通過 JVM 的參數來設置資源的大小，這個資源包括內存和 CPU。MR2 可以對于 Map 和 Reducer 的 JVM 大小分別做定義。Spark 的對應的 JVM 叫 executor，大小都是一樣的。還有一類 YARN 的框架需求也需要用到 JVM，那就是 application master，同樣也是 JVM。這其實就是 YARN 的核心功能，在 YARN 的層面之上的應用框架，無外乎是通過 YARN 和 HDFS 來分發應用程序邏輯，申請資源，把具體的應用層的框架邏輯注入到 JVM 中，而***用戶的業務邏輯再注入到應用層的框架邏輯之中。
應用層框架譬如就是 MR2 和 SPARK，用戶邏輯就是你的JAR包
?? 
操作系統層 Linux 用 CGROUPS 做靜態資源隔離。2006 年 Google 工程師在創建 CGROUPS 這個特性的時候，本來的名字不是 CGROUPS，而是進程容器，這也是這個特性的本意，就是在 Linux 內核級別創建一個容器的概念，使得這些進程只競爭容器內部的資源。容器內的應用不會收到容器外的應用對于操作系統資源，CPU、內存、網絡 IO、句柄的侵占，運行出現問題。CGROUPS 同時也是 Docker 的底層技術，Docker 在 CGROUPS 的基礎之上，實現了更加廣泛和易用的接口，和建立的一個廣泛的生態。
?? 
Hadoop 的這些服務中，也廣泛的應用 CGROUP 來對服務資源做靜態隔離。
?? 
只有革命性的底層技術，才能帶來上層應用的突飛猛進。不過 CGROUP 是 2007 年就有了***個版本，而 Docker 是 2013 年才出***個版本，中間間隔了 6 年。
對于內存、CPU 等資源，Hadoop 主要用的就是這兩種資源隔離的方式。其實想想這兩種方法仍然挺樸素的，我也相信，底層一定會有更好的技術來支持資源隔離。
調度算法
然后再講講調度算法。
在 YARN 之前，操作系統、數據庫都要用到調度算法，所以調度算法在工程領域有很多學術論文可以參考。
下面只是簡單以公平調度為例看一下大概是怎么回事。
?? 
?? 
根據上面的圖示，公平調度是在不同的 POOL 之間，首先滿足最小需求閾值，當實際需求低于最小需求閾值時，以實際需求為準。而實際需求高于最小保證的用量時，僅僅滿足最小用量，在整個請求者的最小用量得到滿足之后，再進行第二輪分配。第二輪分配以一個“迫切度”來做指標，即實際需求和已滿足的資源差額除以實際需求，需求最為迫切的分配剩余的資源。
以上策略是在不同池子中的競爭算法。在同一個池子中，按照時間片輪轉的方式為不同用戶分配資源。
多租戶環境的安全性實現
再講講多租戶環境的安全性實現。
安全性話題很大，先挑 3 個點講一下：
- authentication
- authorzation
- 服務層面的 impersonation 和 delegation
首先講***個點 authentication。
什么是 authentication 呢?authentication 就是如何證明你是你?可以叫身份驗證。
最常見的用戶單一服務環境，用的是 simple authentication，就是簡單身份驗證，方法是用戶名加密碼的方式。以一個網站服務為例，
?? 
那這種驗證方式，網絡功能邏輯和身份驗證是兩個非常解耦的功能，在一個多服務或者是海量服務的環境下，是有嚴重的效率問題的。看下圖。
?? 
有 N 個服務，就會有 N 套用戶信息系統。用戶就得記住 N 套密碼。而 LDAP 的用戶密碼驗證把驗證密碼的邏輯后移了，委托給了 LDAP 服務。使得多套密碼驗證只需要一個用戶名和密碼。
?? 
現在的系統有很多微服務，服務之間的解耦調用，服務和服務之間也需要做身份認證。當請求認證身份的主體由一個“人”變成一個服務的時候應該怎么辦呢?怎么防止惡意的服務程序來偽裝成一個另一個服務的客戶端非法請求數據呢?當海量服務相互調用的時候，采用名稱和密碼的方式顯然是不可行的，所以 KERBEROS 使用秘鑰。
?? 
服務在 KDC 上認證，訪問其他服務是通過向 KDC 申請 ticket 的方法。秘鑰采用非對稱加密，秘鑰信息不會通過網絡傳播。KDC 不知道 client 和服務之間通信的秘鑰，服務也不知道 client 和 KDC 之間的秘鑰。客戶的秘鑰不會經過服務。
以上是多租戶的認證方式。
權限控制
再講權限控制，在通信層的 SASL 的實現方式 GSSAPI，在底層支持了 impersonation，如下圖。
?? 
Impernation 也就是說，前端服務連接到后端服務，前端服務根據他本身登錄用戶的不同，偽裝成 Login User 在后端服務上執行任務。這樣做的好處是，便于做權限控制，也便于審計用戶的行為。在一個安全性要求比較高的平臺上，要注意集成到平臺上的前端服務是否支持這個特性，否則這個層面上惡意用戶可以繞開權限控制。
?? 
還有一種方式叫 delegation，代理的方式。譬如 rstudio 在連接 SPARK 的時候就是采用的這種方式。
?? 
RStudio 的用戶委托 RStudio 在與 Spark 的每個用戶 session 建立之前，先到服務器登錄用戶的 home 目錄地下做認證，拿到 ticket，然后到后端服務上執行任務。
企業辦公系統，Windows 是不二之選，而其他用戶認證和信息都是在微軟的 active directory 里面的。 Active Directory 集成了 LDAP 和 KERBEROS 的實現。所以多租戶的大數據系統的會跟 AD 集成來為企業用戶提供 single sign on。
?? 
權限管理
再講一下多租戶的權限管理，以 Apache Sentry 為例。
Apache Sentry 是一個開放性的服務，通過實現 Sentry 的接口可以為新的分布式服務增加權限控制的功能。目前 Hive，Impala，HBASE 等都可以用 Sentry 進行權限控制。
看一下，AD 和 Sentry 的概念圖，其中重疊部分是 GROUP。
?? 
Sentry 通過為 AD 里面的 Group 做 Role 的映射來賦予權限。當你企業的權限模型定義完備之后，那么只需要在 AD 里面操作 User 和 Group 的關系來為用戶賦予權限了，這是非常簡單的 windows 配置。
Sentry 通過一個接口協議為所有的服務提供權限定義和權限校驗。
?? 
Hive 是一個 MR 或者 Spark 處理引擎的 SQL 解釋接口，那么用戶可能繞開 Hive 的權限直接去 HDFS 上訪問數據。HDFS 的 name node 上的 Sentry 插件解決了這個問題。
?? 
Name Node 上的 Sentry 的插件會去把 Hive 的權限控制語轉換成 HDFS 層面的 ACL。HDFS 層面的 ACL 和 Linux 的類似的，都是擴展了簡單的 POSIX 用戶權限管理。ACL 跟 Linux 上的 ACL 原理一致，都是基于 POSIX 權限管理的補充。
企業級數據平臺的實踐
數據平臺需要有哪些參與者?用戶類型。
?? 
現在對于軟件開發生命周期都有比較成熟的系統和工具。源代碼管理工具，軟件開發版本特性 Bug 管理，開發環境和可持續交付與集成的測試框架和自動化部署。
數據管理和數據開發比較欠缺一個行業的標準流程。數據管理包括對于數據的權限控制和內容管理。在一個多租戶的環境下，經年累月平臺上會出現越來越多的數據，不知道 owner 是誰，也沒有數據的版本，長久以往一個平臺的環境就逐漸被破壞了。
如何進行數據管理?來參考下圖的例子。
?? 
大數據平臺是只寫的系統，不能在文件內部進行更新。數據源主要有兩個類別，一個是歷史記錄，例如服務器的日志或者是流水賬;另外一個類別是元數據快照，快照的頻率越高，那么數據量會線性增長。中間數據有平臺應用存儲的中間結果，也可能是平臺服務的中間結果，資源文件、日志記錄、服務函數庫等等。
上圖的例子中，可以按照數據特征把大數據平臺劃分成幾個區域。RAW 這個區域的特點是存儲的是日志或者流水，或者元數據快照，這塊數據的特點是數據量大，內容比較穩定不易改變。數據是由 ETL 或者數據管道來的。
第二層主要是用于一些測試的目的，在這個區域發現數據的特征，發現一些壞數據，或者發現數據的分布規律，或者是用來測試你的數據處理邏輯，數據格式是否得當。在這個區域用戶可以比較自由的發揮。也可以用來測試機器學習模型。
第三層是持久化層。主要是用來生產一些數據清洗完畢的寬表，統計結果。也用來跑每天的模型。
這么分層的好處是，在實際使用中，往往是“探索”這一類需求把數據平臺從 data lake 變成 data swamp。
“探索層”可以配一個腳本，掃描文件最近更新時間。可以參考如下配置，1 個月的歸檔并發送郵件提醒給數據 owner，二個月的時候發送刪除提醒，3 個月的時候刪除并發送郵件提醒。
“RAW”和“持久化”兩個區，需要有適合于企業的配套的流程。
1. checklist，問例如下面的問題：
- 該數據處理流程的元數據?
- 該數據處理流程的 owner?
- 該數據屬于哪個項目?
- 該數據的依賴和下游依賴?
2. 寫入這個區的數據必須要 approval，這兩個區的數據的元數據和數據相關的信息應該有程序化的集中的管理。
對于“持久化”區，以項目為單位。當項目開始時，就需要有項目的退出和結束策略。不同的項目之間因不要有數據依賴。當項目結束時，需要有方法根據項目的名稱找到所有的處理邏輯和產生的數據，然后刪除這些流程和對應的數據。
?? 
流程的執行需要有軟件和系統來保證，“用戶不應該做”和“用戶做不了”是兩碼事，目前這方面還缺少數據管理的配套軟件和系統。這也是在實踐中碰到的難點。
在大數據平臺實踐的過程中，發現的問題還有一些是來源于底層系統的集成。譬如 Linux 和 Windows 做 Single Sign On 的時候，SSSD 的 BUG，Linux 平臺與 window AD 集成的問題。
選型，除了 Cloudera 同類型的方案，Amazon 的 EMR 也是不錯的選擇。
bluedata 的基于 container 和 mesos 的大數據設計很好，但是具體實現還在成熟當中。而且 Cloudera 等一些大數據發行商目前并不打算支持基于 container 的方案。多久才能帶來價值?這個問題很難回答，其一價值很難度量，沒有辦法做 AB 測試，但是我想說的是，在數據驅動的這個浪潮下，只有在實踐和學習中擁抱數據，事實上很多企業也是這樣做的。
