??

[[192811]]

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

首先回顧一下歷史。

??

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

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

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

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

??

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

??

Hadoop 零基礎(chǔ)的同學(xué)會(huì)有一個(gè)模糊的認(rèn)識(shí)，會(huì)把 Hadoop 當(dāng)初數(shù)據(jù)庫，尤其是在使用 Hive 和 Impala 的時(shí)候，會(huì)在清醒和迷糊之間徘徊一段時(shí)間。

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

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

好處自然很多，橫向擴(kuò)展的能力、機(jī)器學(xué)習(xí)的能力、圖計(jì)算、流式計(jì)算，許許多多的應(yīng)用場(chǎng)景令人浮想聯(lián)翩。

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

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

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

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

例如下面這個(gè)場(chǎng)景：

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

那么問題來了：

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

??

這些問題先暫且放一放。

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

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

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

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

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

??

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

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

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

??

??

??

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

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

??

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

??

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

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

??

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

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

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

??

通過云服務(wù) API 得到地址信息，進(jìn)而用 SSH 遠(yuǎn)程命令調(diào)用安裝 cloudera manager 和 cloudera agent，并且啟動(dòng) cloudera manager 和 cloudera agent 服務(wù)。

??

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

??

一些我了解的情況如下：

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

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

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

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

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

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

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

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

??

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

??

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

??

只有革命性的底層技術(shù)，才能帶來上層應(yīng)用的突飛猛進(jìn)。不過 CGROUP 是 2007 年就有了***個(gè)版本，而 Docker 是 2013 年才出***個(gè)版本，中間間隔了 6 年。

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

調(diào)度算法

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

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

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

??

??

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

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

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

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

安全性話題很大，先挑 3 個(gè)點(diǎn)講一下：

1. authentication
2. authorzation
3. 服務(wù)層面的 impersonation 和 delegation

首先講***個(gè)點(diǎn) authentication。

什么是 authentication 呢?authentication 就是如何證明你是你?可以叫身份驗(yàn)證。

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

??

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

??

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

??

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

??

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

以上是多租戶的認(rèn)證方式。

權(quán)限控制

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

??

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

??

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

??

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

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

??

權(quán)限管理

再講一下多租戶的權(quán)限管理，以 Apache Sentry 為例。

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

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

??

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

Sentry 通過一個(gè)接口協(xié)議為所有的服務(wù)提供權(quán)限定義和權(quán)限校驗(yàn)。

??

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

??

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

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

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

??

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

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

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

??

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

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

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

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

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

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

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

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

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

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

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

??

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

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

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

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