從分布式管理到多租戶實現(xiàn)，企業(yè)級大數(shù)據(jù)系統(tǒng)如何利用開源生態(tài)構建？

作者：陳冬 2017-06-01 15:02:17
大數(shù)據(jù)
分布式 在大數(shù)據(jù)生態(tài)發(fā)展的過程中，大數(shù)據(jù)系統(tǒng)的管理系統(tǒng)，大數(shù)據(jù)系統(tǒng)的安全，易用性，機器學習不斷的補充到生態(tài)系統(tǒng)中來并不斷完善。隨著互聯(lián)網(wǎng)的興旺發(fā)展，許多互聯(lián)網(wǎng)公司也逐漸開始把 Hadoop 變成內(nèi)部大數(shù)據(jù)處理系統(tǒng)的不二之選。隨著大數(shù)據(jù)概念的火爆，使得開始是行業(yè)領頭羊的巨頭在玩的東西逐漸被有機會普及到傳統(tǒng)領域。

創(chuàng)新互聯(lián)建站專注于企業(yè)成都全網(wǎng)營銷、網(wǎng)站重做改版、河津網(wǎng)站定制設計、自適應品牌網(wǎng)站建設、成都h5網(wǎng)站建設、商城網(wǎng)站建設、集團公司官網(wǎng)建設、成都外貿(mào)網(wǎng)站建設公司、高端網(wǎng)站制作、響應式網(wǎng)頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為河津等各大城市提供網(wǎng)站開發(fā)制作服務。

??

??

大數(shù)據(jù)系統(tǒng)的應用領域

首先回顧一下歷史。

??

?? 

從中我們可以看到一些趨勢，在大數(shù)據(jù)生態(tài)發(fā)展的過程中，大數(shù)據(jù)系統(tǒng)的管理系統(tǒng)，大數(shù)據(jù)系統(tǒng)的安全，易用性，機器學習不斷的補充到生態(tài)系統(tǒng)中來并不斷完善。

早期是 Google 一家獨有。2003 GFS paper 發(fā)表的時候，Google 的集群規(guī)模就達到上千臺，***。

之后是大家都知道的歷史，Doug Cutting 在為他的 lucene 分布式化的時候看到了 Google 的這篇論文，并把它實現(xiàn)出來，后來被 Yahoo 收編，得到一個機會和環(huán)境把 Hadoop 孵化出來。

隨著互聯(lián)網(wǎng)的興旺發(fā)展，許多互聯(lián)網(wǎng)公司也逐漸開始把 Hadoop 變成內(nèi)部大數(shù)據(jù)處理系統(tǒng)的不二之選。隨著大數(shù)據(jù)概念的火爆，使得開始是行業(yè)領頭羊的巨頭在玩的東西逐漸被有機會普及到傳統(tǒng)領域。

??

?? 

現(xiàn)在不斷能夠聽說新的大數(shù)據(jù)項目冒出來。

??

?? 

Hadoop 零基礎的同學會有一個模糊的認識，會把 Hadoop 當初數(shù)據(jù)庫，尤其是在使用 Hive 和 Impala 的時候，會在清醒和迷糊之間徘徊一段時間。

即使是領域內(nèi)的同學，也會持有一個觀點，沒有海量數(shù)據(jù)，搞什么大數(shù)據(jù)? 我個人愿意把大數(shù)據(jù)系統(tǒng)這樣定義：大數(shù)據(jù)系統(tǒng)是在大數(shù)據(jù)的時代背景下，由一個樸素的應用需求催生出的系統(tǒng)，在大數(shù)據(jù)的浪潮中，被賦予的不同的期待，逐漸成長起來的尚處于青少年期的生態(tài)。

總之，我是想說，這是有門檻的。

好處自然很多，橫向擴展的能力、機器學習的能力、圖計算、流式計算，許許多多的應用場景令人浮想聯(lián)翩。

門檻也有很多，1) 開源系統(tǒng)，大家知道開源系統(tǒng)如果你不把里里外外全部了然于心，使用的時候碰到的麻煩應該是有所體會的。2) 它還在快速的成長，很多功能可能還沒有，或者是 bug 很多，傳統(tǒng)行業(yè)(在這里我指除 IT 之外的行業(yè))應該是使用商業(yè)軟件居多。

但毫無疑問這個領域正在蓬勃發(fā)展。底層數(shù)據(jù)類型和格式非常廣的兼容性，計算模型的豐富和對于機器學習模型的支持。

那么什么樣的領域需要大數(shù)據(jù)系統(tǒng)?

1. 海量數(shù)據(jù)：例如 IT 企業(yè)
2. 數(shù)據(jù)非常雜：傳統(tǒng)企業(yè)
3. 需要有新的數(shù)據(jù)處理模型的支持：AI 和實時運營決策公司(目前還很超前)。

例如下面這個場景：

1. 5 年以上的老公司
2. 跨國業(yè)務，數(shù)據(jù)需要到母公司匯總分析
3. 數(shù)據(jù)鏈條很長，不同的業(yè)務會產(chǎn)生數(shù)據(jù)，數(shù)據(jù)應用和數(shù)據(jù)分析沒有分開
4. 積累了歷史數(shù)據(jù)，還在繼續(xù)產(chǎn)生不知道如何分析的歷史數(shù)據(jù)
5. 積累了一些問題，這些問題可以在數(shù)據(jù)中找到答案
6. 行業(yè)競爭激烈，管理層很著急。。。

那么問題來了：

1. 搭建這個平臺會遇到哪些困難?
2. 要一個什么樣的數(shù)據(jù)平臺?
3. 如何做數(shù)據(jù)管理和數(shù)據(jù)流程管理?
4. 多久才能帶來價值?

??

?? 

這些問題先暫且放一放。

我們先看看這個問題，那么多的大數(shù)據(jù)系統(tǒng)的服務，如何能統(tǒng)一管理呢?這里的管理是指：

1. 初始化安裝
2. 配置文件修改發(fā)布
3. 服務啟動停止
4. 查看分布式的日志
5. 服務升級
6. 添加新的服務
7. 系統(tǒng)調(diào)優(yōu)
8. 監(jiān)控
9. 到服務內(nèi)部不同 web 應用的導航
10. 集群元數(shù)據(jù)管理

還有在公有云和私有云提供創(chuàng)建實例接口的情況下，如何實現(xiàn)一鍵部署呢?下面以 Cloudera 的產(chǎn)品為例，講一下這些是如何設計實現(xiàn)的。

分布式系統(tǒng)的管理系統(tǒng)

先來看一下，如果修改一個沒有管理系統(tǒng)輔助的社區(qū)版的 Hadoop 系統(tǒng)的配置文件，它的復雜度是這樣的。

??

?? 

而事實上早期的集群維護的確就是這么做的，即使你用腳本把配置文件推送到其他節(jié)點，并且用腳本拉回日志檢查的話，還是非常不方便。

下面來看看 Cloudera manager 是怎么來解決這個問題的。

Cloudera manager 可以通過 RPM 手工安裝。Cloudera agent 可以通過 Cloudera manager 的界面添加。

??

??    

??

?? 

??

?? 

Cloudera manager 通過 cloudera-scm-server 來中央控制整個集群的搭建、維護和監(jiān)控。每臺機器上的管理工作交給 cloudera-scm-agent。

cloudera-scm-agent 借助開源項目 supervisord 來實現(xiàn)每臺機器的進程管理。supervisord 的好處是在單臺機器上實現(xiàn)對進程的集中管理。Cloudera-scm-agent 通過接受 cloudera-scm-server 的指令，調(diào)用 supervisord 的接口來進行控制本機上所有的進程和查詢本機上所有進程的狀態(tài)。

??

?? 

cloudera manager 把新改動與線上環(huán)境配置進行對比，如果發(fā)現(xiàn)有配置更新，提示用戶更新服務配置或者部署客戶端配置。

??

?? 

在更新服務配置的同時通過命令調(diào)用 cloudera agent，cloudera agent 調(diào)用 supervirsord 的接口，重啟各個服務器上的進程。在重啟完畢以后，cloudera manager 監(jiān)控管理服務，通過調(diào)用服務接口檢測服務是否成功啟動，顯示服務的狀態(tài)，如果發(fā)現(xiàn)服務沒有成功啟動，用戶可以通過檢測結果判斷服務失敗的原因。

Cloudera RPM 安裝包中，還提供了監(jiān)控的服務包。Cloudera manager 管理界面上可以啟動 Cloudera 的管理服務。其中有兩個監(jiān)控服務，一個是 host monitor，其作用是接受 agent 上報來的節(jié)點數(shù)據(jù)，如磁盤使用情況，CPU capacity，CPU 用量，內(nèi)存的大小和內(nèi)存的用量，機器負載等。Service monitor 則是一個服務健康檢測服務，會定期的執(zhí)行各種不同的檢測，把數(shù)據(jù)匯總到 web 界面供管理員查看。

??

?? 

同時 cloudera manager 提供統(tǒng)一入口的日志查詢 GUI，以一個搜索接口加過濾器的方式幫助用戶排查原因。

在有共有云服務的環(huán)境下，可以通過一個描述文件安裝整套 cloudera manager，cloudera agent 以及大數(shù)據(jù)服務。

cloudera director 通過調(diào)用云服務 API 創(chuàng)建集群所需要的實例。

??

?? 

通過云服務 API 得到地址信息，進而用 SSH 遠程命令調(diào)用安裝 cloudera manager 和 cloudera agent，并且啟動 cloudera manager 和 cloudera agent 服務。

??

?? 

通過調(diào)用 cloudera manager 的 REST 服務 API，進行大數(shù)據(jù)服務的安裝，部署和配置。

??

?? 

一些我了解的情況如下：

Cloudera 自己有自己的代碼倉庫，它的各種服務的代碼版本與社區(qū)發(fā)布的版本不一致。具體多大程度上不一致很難知曉。部分應該是由于 license 的原因，像 SPARKR 沒有集成到 cloudera 版本的 Spark 中去，應該是 license 的原因。

社區(qū)的大數(shù)據(jù)服務需要 Cloudera 進行定制才能集成到 Cloudera 的管理平臺上，支持的大數(shù)據(jù)服務的種類有限。

Cloudera 上面的服務版本更新還是比較慢的。

再來看看大數(shù)據(jù)系統(tǒng)在底層技術上是如何實現(xiàn)多租戶的?

數(shù)據(jù)平臺多租戶的實現(xiàn)

對于 Hadoop 平臺而言，多租戶是***的難點之一。大數(shù)據(jù)系統(tǒng)***的一個問題是資源浪費，早期單用戶，單任務。多租戶的目標可以有效的充分利用資源。多租戶的資源分配依賴于兩個技術：資源隔離，調(diào)度算法，在操作系統(tǒng)層面和服務層面(YARN)都可以做資源隔離。

YARN 在服務層面做資源隔離的是 JVM。YARN 的 node manager 響應 resource manager 的請求創(chuàng)建的 container，其實就是一個 JVM。通過 JVM 的參數(shù)來設置資源的大小，這個資源包括內(nèi)存和 CPU。MR2 可以對于 Map 和 Reducer 的 JVM 大小分別做定義。Spark 的對應的 JVM 叫 executor，大小都是一樣的。還有一類 YARN 的框架需求也需要用到 JVM，那就是 application master，同樣也是 JVM。這其實就是 YARN 的核心功能，在 YARN 的層面之上的應用框架，無外乎是通過 YARN 和 HDFS 來分發(fā)應用程序邏輯，申請資源，把具體的應用層的框架邏輯注入到 JVM 中，而***用戶的業(yè)務邏輯再注入到應用層的框架邏輯之中。

應用層框架譬如就是 MR2 和 SPARK，用戶邏輯就是你的JAR包

??

?? 

操作系統(tǒng)層 Linux 用 CGROUPS 做靜態(tài)資源隔離。2006 年 Google 工程師在創(chuàng)建 CGROUPS 這個特性的時候，本來的名字不是 CGROUPS，而是進程容器，這也是這個特性的本意，就是在 Linux 內(nèi)核級別創(chuàng)建一個容器的概念，使得這些進程只競爭容器內(nèi)部的資源。容器內(nèi)的應用不會收到容器外的應用對于操作系統(tǒng)資源，CPU、內(nèi)存、網(wǎng)絡 IO、句柄的侵占，運行出現(xiàn)問題。CGROUPS 同時也是 Docker 的底層技術，Docker 在 CGROUPS 的基礎之上，實現(xiàn)了更加廣泛和易用的接口，和建立的一個廣泛的生態(tài)。

??

?? 

Hadoop 的這些服務中，也廣泛的應用 CGROUP 來對服務資源做靜態(tài)隔離。

??

?? 

只有革命性的底層技術，才能帶來上層應用的突飛猛進。不過 CGROUP 是 2007 年就有了***個版本，而 Docker 是 2013 年才出***個版本，中間間隔了 6 年。

對于內(nèi)存、CPU 等資源，Hadoop 主要用的就是這兩種資源隔離的方式。其實想想這兩種方法仍然挺樸素的，我也相信，底層一定會有更好的技術來支持資源隔離。

調(diào)度算法

然后再講講調(diào)度算法。

在 YARN 之前，操作系統(tǒng)、數(shù)據(jù)庫都要用到調(diào)度算法，所以調(diào)度算法在工程領域有很多學術論文可以參考。

下面只是簡單以公平調(diào)度為例看一下大概是怎么回事。

??

??    

??

?? 

根據(jù)上面的圖示，公平調(diào)度是在不同的 POOL 之間，首先滿足最小需求閾值，當實際需求低于最小需求閾值時，以實際需求為準。而實際需求高于最小保證的用量時，僅僅滿足最小用量，在整個請求者的最小用量得到滿足之后，再進行第二輪分配。第二輪分配以一個“迫切度”來做指標，即實際需求和已滿足的資源差額除以實際需求，需求最為迫切的分配剩余的資源。

以上策略是在不同池子中的競爭算法。在同一個池子中，按照時間片輪轉(zhuǎn)的方式為不同用戶分配資源。

多租戶環(huán)境的安全性實現(xiàn)

再講講多租戶環(huán)境的安全性實現(xiàn)。

安全性話題很大，先挑 3 個點講一下：

1. authentication
2. authorzation
3. 服務層面的 impersonation 和 delegation

首先講***個點 authentication。

什么是 authentication 呢?authentication 就是如何證明你是你?可以叫身份驗證。

最常見的用戶單一服務環(huán)境，用的是 simple authentication，就是簡單身份驗證，方法是用戶名加密碼的方式。以一個網(wǎng)站服務為例，

??

?? 

那這種驗證方式，網(wǎng)絡功能邏輯和身份驗證是兩個非常解耦的功能，在一個多服務或者是海量服務的環(huán)境下，是有嚴重的效率問題的?？聪聢D。

??

?? 

有 N 個服務，就會有 N 套用戶信息系統(tǒng)。用戶就得記住 N 套密碼。而 LDAP 的用戶密碼驗證把驗證密碼的邏輯后移了，委托給了 LDAP 服務。使得多套密碼驗證只需要一個用戶名和密碼。

??

?? 

現(xiàn)在的系統(tǒng)有很多微服務，服務之間的解耦調(diào)用，服務和服務之間也需要做身份認證。當請求認證身份的主體由一個“人”變成一個服務的時候應該怎么辦呢?怎么防止惡意的服務程序來偽裝成一個另一個服務的客戶端非法請求數(shù)據(jù)呢?當海量服務相互調(diào)用的時候，采用名稱和密碼的方式顯然是不可行的，所以 KERBEROS 使用秘鑰。

??

?? 

服務在 KDC 上認證，訪問其他服務是通過向 KDC 申請 ticket 的方法。秘鑰采用非對稱加密，秘鑰信息不會通過網(wǎng)絡傳播。KDC 不知道 client 和服務之間通信的秘鑰，服務也不知道 client 和 KDC 之間的秘鑰?？蛻舻拿罔€不會經(jīng)過服務。

以上是多租戶的認證方式。

權限控制

再講權限控制，在通信層的 SASL 的實現(xiàn)方式 GSSAPI，在底層支持了 impersonation，如下圖。

??

?? 

Impernation 也就是說，前端服務連接到后端服務，前端服務根據(jù)他本身登錄用戶的不同，偽裝成 Login User 在后端服務上執(zhí)行任務。這樣做的好處是，便于做權限控制，也便于審計用戶的行為。在一個安全性要求比較高的平臺上，要注意集成到平臺上的前端服務是否支持這個特性，否則這個層面上惡意用戶可以繞開權限控制。

??

?? 

還有一種方式叫 delegation，代理的方式。譬如 rstudio 在連接 SPARK 的時候就是采用的這種方式。

??

?? 

RStudio 的用戶委托 RStudio 在與 Spark 的每個用戶 session 建立之前，先到服務器登錄用戶的 home 目錄地下做認證，拿到 ticket，然后到后端服務上執(zhí)行任務。

企業(yè)辦公系統(tǒng)，Windows 是不二之選，而其他用戶認證和信息都是在微軟的 active directory 里面的。 Active Directory 集成了 LDAP 和 KERBEROS 的實現(xiàn)。所以多租戶的大數(shù)據(jù)系統(tǒng)的會跟 AD 集成來為企業(yè)用戶提供 single sign on。

??

?? 

權限管理

再講一下多租戶的權限管理，以 Apache Sentry 為例。

Apache Sentry 是一個開放性的服務，通過實現(xiàn) Sentry 的接口可以為新的分布式服務增加權限控制的功能。目前 Hive，Impala，HBASE 等都可以用 Sentry 進行權限控制。

看一下，AD 和 Sentry 的概念圖，其中重疊部分是 GROUP。

??

?? 

Sentry 通過為 AD 里面的 Group 做 Role 的映射來賦予權限。當你企業(yè)的權限模型定義完備之后，那么只需要在 AD 里面操作 User 和 Group 的關系來為用戶賦予權限了，這是非常簡單的 windows 配置。

Sentry 通過一個接口協(xié)議為所有的服務提供權限定義和權限校驗。

??

?? 

Hive 是一個 MR 或者 Spark 處理引擎的 SQL 解釋接口，那么用戶可能繞開 Hive 的權限直接去 HDFS 上訪問數(shù)據(jù)。HDFS 的 name node 上的 Sentry 插件解決了這個問題。

??

?? 

Name Node 上的 Sentry 的插件會去把 Hive 的權限控制語轉(zhuǎn)換成 HDFS 層面的 ACL。HDFS 層面的 ACL 和 Linux 的類似的，都是擴展了簡單的 POSIX 用戶權限管理。ACL 跟 Linux 上的 ACL 原理一致，都是基于 POSIX 權限管理的補充。

企業(yè)級數(shù)據(jù)平臺的實踐

數(shù)據(jù)平臺需要有哪些參與者?用戶類型。

??

?? 

現(xiàn)在對于軟件開發(fā)生命周期都有比較成熟的系統(tǒng)和工具。源代碼管理工具，軟件開發(fā)版本特性 Bug 管理，開發(fā)環(huán)境和可持續(xù)交付與集成的測試框架和自動化部署。

數(shù)據(jù)管理和數(shù)據(jù)開發(fā)比較欠缺一個行業(yè)的標準流程。數(shù)據(jù)管理包括對于數(shù)據(jù)的權限控制和內(nèi)容管理。在一個多租戶的環(huán)境下，經(jīng)年累月平臺上會出現(xiàn)越來越多的數(shù)據(jù)，不知道 owner 是誰，也沒有數(shù)據(jù)的版本，長久以往一個平臺的環(huán)境就逐漸被破壞了。

如何進行數(shù)據(jù)管理?來參考下圖的例子。

??

?? 

大數(shù)據(jù)平臺是只寫的系統(tǒng)，不能在文件內(nèi)部進行更新。數(shù)據(jù)源主要有兩個類別，一個是歷史記錄，例如服務器的日志或者是流水賬;另外一個類別是元數(shù)據(jù)快照，快照的頻率越高，那么數(shù)據(jù)量會線性增長。中間數(shù)據(jù)有平臺應用存儲的中間結果，也可能是平臺服務的中間結果，資源文件、日志記錄、服務函數(shù)庫等等。

上圖的例子中，可以按照數(shù)據(jù)特征把大數(shù)據(jù)平臺劃分成幾個區(qū)域。RAW 這個區(qū)域的特點是存儲的是日志或者流水，或者元數(shù)據(jù)快照，這塊數(shù)據(jù)的特點是數(shù)據(jù)量大，內(nèi)容比較穩(wěn)定不易改變。數(shù)據(jù)是由 ETL 或者數(shù)據(jù)管道來的。

第二層主要是用于一些測試的目的，在這個區(qū)域發(fā)現(xiàn)數(shù)據(jù)的特征，發(fā)現(xiàn)一些壞數(shù)據(jù)，或者發(fā)現(xiàn)數(shù)據(jù)的分布規(guī)律，或者是用來測試你的數(shù)據(jù)處理邏輯，數(shù)據(jù)格式是否得當。在這個區(qū)域用戶可以比較自由的發(fā)揮。也可以用來測試機器學習模型。

第三層是持久化層。主要是用來生產(chǎn)一些數(shù)據(jù)清洗完畢的寬表，統(tǒng)計結果。也用來跑每天的模型。

這么分層的好處是，在實際使用中，往往是“探索”這一類需求把數(shù)據(jù)平臺從 data lake 變成 data swamp。

“探索層”可以配一個腳本，掃描文件最近更新時間?？梢詤⒖既缦屡渲?，1 個月的歸檔并發(fā)送郵件提醒給數(shù)據(jù) owner，二個月的時候發(fā)送刪除提醒，3 個月的時候刪除并發(fā)送郵件提醒。

“RAW”和“持久化”兩個區(qū)，需要有適合于企業(yè)的配套的流程。

1. checklist，問例如下面的問題：

• 該數(shù)據(jù)處理流程的元數(shù)據(jù)?
• 該數(shù)據(jù)處理流程的 owner?
• 該數(shù)據(jù)屬于哪個項目?
• 該數(shù)據(jù)的依賴和下游依賴?

2. 寫入這個區(qū)的數(shù)據(jù)必須要 approval，這兩個區(qū)的數(shù)據(jù)的元數(shù)據(jù)和數(shù)據(jù)相關的信息應該有程序化的集中的管理。

對于“持久化”區(qū)，以項目為單位。當項目開始時，就需要有項目的退出和結束策略。不同的項目之間因不要有數(shù)據(jù)依賴。當項目結束時，需要有方法根據(jù)項目的名稱找到所有的處理邏輯和產(chǎn)生的數(shù)據(jù)，然后刪除這些流程和對應的數(shù)據(jù)。

??

?? 

流程的執(zhí)行需要有軟件和系統(tǒng)來保證，“用戶不應該做”和“用戶做不了”是兩碼事，目前這方面還缺少數(shù)據(jù)管理的配套軟件和系統(tǒng)。這也是在實踐中碰到的難點。

在大數(shù)據(jù)平臺實踐的過程中，發(fā)現(xiàn)的問題還有一些是來源于底層系統(tǒng)的集成。譬如 Linux 和 Windows 做 Single Sign On 的時候，SSSD 的 BUG，Linux 平臺與 window AD 集成的問題。

選型，除了 Cloudera 同類型的方案，Amazon 的 EMR 也是不錯的選擇。

bluedata 的基于 container 和 mesos 的大數(shù)據(jù)設計很好，但是具體實現(xiàn)還在成熟當中。而且 Cloudera 等一些大數(shù)據(jù)發(fā)行商目前并不打算支持基于 container 的方案。多久才能帶來價值?這個問題很難回答，其一價值很難度量，沒有辦法做 AB 測試，但是我想說的是，在數(shù)據(jù)驅(qū)動的這個浪潮下，只有在實踐和學習中擁抱數(shù)據(jù)，事實上很多企業(yè)也是這樣做的。

分享名稱：從分布式管理到多租戶實現(xiàn)，企業(yè)級大數(shù)據(jù)系統(tǒng)如何利用開源生態(tài)構建？
文章位置：http://www.dlmjj.cn/article/dhcgidj.html