大數(shù)據(jù)架構(gòu)的未來(共6頁)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上大數(shù)據(jù)架構(gòu)的未來 本文講述了大數(shù)據(jù)的相關(guān)問題，以及“大數(shù)據(jù)架構(gòu)”得名的由來。大數(shù)據(jù)的問題或許所有讀者都明白這一點(diǎn)：數(shù)據(jù)正在飛速增長。若是能夠有效利用的話，我們能從這些數(shù)據(jù)中找到非常有價值的見解；傳統(tǒng)技術(shù)有很多都是在40年前設(shè)計的，比如RDBMSs，不足以創(chuàng)造“大數(shù)據(jù)”炒作所宣稱的商業(yè)價值。在大數(shù)據(jù)技術(shù)的使用上，常見的案例是“客戶單一視圖”；將關(guān)于客戶所知道的一切內(nèi)容放在一起，以便最大化服務(wù)提供與自身收入，比如確定具體需要采用什么促銷方式，又是在什么時候、通過什么渠道來發(fā)送。盡管大數(shù)據(jù)的問題在于，讓我們將這種潛力變?yōu)楝F(xiàn)實(shí)，高等級的關(guān)鍵功能至少包括下面這些能力： 合并信息

2、孤井、外在因素與數(shù)據(jù)流； 控制數(shù)據(jù)訪問； 根據(jù)需要轉(zhuǎn)化數(shù)據(jù)； 整合數(shù)據(jù)； 為數(shù)據(jù)分析提供工具； 發(fā)布數(shù)據(jù)報告； 將見解體現(xiàn)在運(yùn)營過程中； 最小化工作完成的總擁有成本與響應(yīng)時間。 用數(shù)據(jù)湖作為答案很多公司正在觀望一個被某些人稱為數(shù)據(jù)湖的架構(gòu)，這個數(shù)據(jù)平臺在合并信息孤井?dāng)?shù)據(jù)流以及在單獨(dú)的邏輯位置中執(zhí)行數(shù)據(jù)持久化方面具有靈活性，能夠從企業(yè)自身以及第三方的數(shù)據(jù)中挖掘出見解。將Hadoop（包括Spark在內(nèi)）用于數(shù)據(jù)湖已成大勢所趨，原因很多：使用總擁有成本較低的普通硬件就能進(jìn)行擴(kuò)展，允許用讀時模式（schema-on-read）收取大量數(shù)據(jù)，支持開源，包括用SQL和普通語言構(gòu)建分布式處理層。此外，像雅

3、虎和谷歌這樣的webscale公司都是早期標(biāo)桿，借用這種架構(gòu)在解決網(wǎng)站索引相關(guān)的問題時獲得了巨大的成功。Hadoop中的數(shù)據(jù)持久化選項(xiàng)這樣一來，從這里開始評估數(shù)據(jù)湖解決方案的前景似乎很合理。一旦開始從更深的層次理解Hadoop的內(nèi)涵，你就會發(fā)現(xiàn)里面所包含的項(xiàng)目真的是包羅萬象，涵蓋了數(shù)據(jù)處理的方方面面。用Hadoop在數(shù)據(jù)湖中探測存儲的數(shù)據(jù)時，有兩個主要選項(xiàng)：HDFS和HBase。使用HDFS時，可以自行決定如何在只添加文件中對數(shù)據(jù)進(jìn)行編碼，包括JSON、CSV、Avro等等，因?yàn)镠DFS只是一個文件系統(tǒng)，編碼方式全由你決定。相反，HBase是一個數(shù)據(jù)庫，其特有的數(shù)據(jù)編碼方式可以將記錄寫入的速度

4、最優(yōu)化，在通過主鍵查詢時執(zhí)行只讀的速度相對也很快。這也是用Hadoop的數(shù)據(jù)湖之魅力所在，它能實(shí)現(xiàn)真實(shí)情況下的需求。因此，我們就能使用Hadoop來執(zhí)行上面列出的高層次需求了。在像Spark和Hive這樣的Hadoop生態(tài)系統(tǒng)中，仍需用到分布式處理層，但不需HDFS或HBase了，因此你可以從分布式處理層中選擇持久化層面。之前的博文中有相關(guān)案例，描述了使用Spark在MongoDB中讀寫數(shù)據(jù)。還有一篇博文也很類似，證明了MongoDB只是讀取數(shù)據(jù)的另一個Hive表格。索引仍舊很重要大多熟悉RDBMSs的技術(shù)人員發(fā)現(xiàn)，從表達(dá)查詢能力到二級索引，再到加速查詢?nèi)純r值巨大（即便模式固定、總擁有成本高

5、以及RDBMSs的可擴(kuò)展性有限，這些使得它很難被用作數(shù)據(jù)湖）。如果我們在數(shù)據(jù)庫持久化中只用到HDFS和HBase，就無法實(shí)現(xiàn)我們期待的數(shù)據(jù)庫臨時索引了，特別是遇到下面幾個限制時：1. 臨時切片：不通過二級索引，我們?nèi)绾螌Σ恢挂粋€主鍵標(biāo)識出的數(shù)據(jù)切片進(jìn)行有效地分析呢，例如對我們的最佳客戶那些消費(fèi)金額超過X的客戶進(jìn)行分析？由于數(shù)據(jù)太過巨大，想要通過掃描找出最佳客戶都會令工作卡住。2. 低延遲報告：如果沒有靈活的索引方式，我們?nèi)绾卧诖蚊爰墪r間內(nèi)響應(yīng)客戶的需求，為他們提供有價值的數(shù)據(jù)報告呢？再次，我們只能使用消費(fèi)者的賬戶號或者其他主鍵來進(jìn)行快速報告，而不是通過消費(fèi)者的姓名、電話號碼、郵編、花費(fèi)等等。特

6、別提到：MongoDB剛剛為基于SQL的報告工具發(fā)布了BI Connector。3. 運(yùn)營化：同樣地，我們?nèi)绾螌⒂袃r值的見解引入應(yīng)用運(yùn)營中，從而在最大化影響公司和消費(fèi)者的同時將數(shù)據(jù)變現(xiàn)？想象一下客服專員（CSR）告知消費(fèi)者，因?yàn)閿?shù)據(jù)湖僅支持這個主鍵，他必須提供賬號才能查詢所有的信息；或者查詢需要10分鐘時間。當(dāng)然，其中有些問題可以通過變通方法解決，不過會導(dǎo)致總擁有成本更高、開發(fā)或運(yùn)營工作更多、延遲也更高。例如，使用搜索引擎或者實(shí)體化視圖而不是通過主鍵來查詢；不過稍后還需返回到數(shù)據(jù)庫，在有完整記錄的數(shù)據(jù)庫中對主表進(jìn)行再次查詢，以獲得所需的完整信息。除了延遲翻倍之外，還需要耗費(fèi)額外的管理、開發(fā)工作

7、，以及單獨(dú)搜索引擎需要的基礎(chǔ)設(shè)施，還有實(shí)體化視圖所需的維護(hù)，加上將數(shù)據(jù)寫入到其他地方造成的一致性問題。保持我們的設(shè)計原則，只用我們用慣的普通靈活索引不是很好么？MongoDB是一個有效數(shù)據(jù)湖的重要部分我們開始討論，探索單用Hadoop是否能滿足數(shù)據(jù)湖的需求，并發(fā)現(xiàn)了至少3個問題。我們能否在架構(gòu)中另加一層持久化層面來解決這些問題，同時保持設(shè)計原則使用低總擁有成本的普通硬件、開源模式、讀時模式還有Hadoop分布式數(shù)據(jù)層與之前一致呢？我選擇本文的主題是因?yàn)椋琈ongoDB就是在Hadoop-only數(shù)據(jù)湖中，補(bǔ)位最優(yōu)秀的數(shù)據(jù)庫。如果使用另一個開源NoSQL數(shù)據(jù)庫，就會發(fā)現(xiàn)其中幾乎不含二級索引（使用

8、二級索引會導(dǎo)致無法同步數(shù)據(jù)），也沒有分組和聚合功能。你可以使用其中一些數(shù)據(jù)庫將數(shù)據(jù)寫入數(shù)據(jù)湖，不過如果出于商業(yè)需求想要以靈活的方式使用二級索引讀取的話，是做不到的。如果想要在數(shù)據(jù)湖中使用開源RDBMS，我們已經(jīng)說過，它們固定的模式、昂貴的垂直擴(kuò)展模型都違背了我們設(shè)計數(shù)據(jù)湖的原則。因此，推薦使用下面的架構(gòu)來構(gòu)建數(shù)據(jù)湖。MongoDB對數(shù)據(jù)湖非常重要這個架構(gòu)將MongoDB作為持久化層面加入任何需要表達(dá)查詢的數(shù)據(jù)集中，正與你需要索引的三個原因（上面列舉了）相關(guān)。由于需求數(shù)據(jù)來自消費(fèi)者，無論是否將數(shù)據(jù)發(fā)布到HDFS和/或MongoDB中，我推薦用governance function來確定。無論存儲

9、到HDFS或者M(jìn)ongoDB上，就可以運(yùn)行分布式處理任務(wù)，比如Hive和Spark。不過如果數(shù)據(jù)在MongoDB上，因?yàn)楹Y選標(biāo)準(zhǔn)下放到數(shù)據(jù)庫中，不像在HDFS中那樣掃描文件，你就能在數(shù)據(jù)臨時切片上運(yùn)行有效分析了。與此相似，MongoDB中的數(shù)據(jù)也可用于實(shí)時、低延遲報告，并為構(gòu)建的應(yīng)用所用到的所有系統(tǒng)提供運(yùn)營數(shù)據(jù)平臺服務(wù)。如今一些公司只是將數(shù)據(jù)復(fù)制到Hadoop中進(jìn)行轉(zhuǎn)換，然后再復(fù)制到其他地方，用于完成有價值的工作。為什么不直接利用數(shù)據(jù)湖，發(fā)揮最大價值呢？使用MongoDB可以將價值多次翻倍。結(jié)論觀察長期與短期需求，確保這些需求可以通過核心Hadoop分布中的最佳工具，以及MongoDB這樣的生態(tài)環(huán)境實(shí)現(xiàn)，數(shù)據(jù)湖對你而言就是有價值且而可行的。一些企業(yè)在使用數(shù)據(jù)湖時，只花費(fèi)一年時間清洗所有數(shù)據(jù)，然后將其寫入HDFS，希望在未來能用這些數(shù)據(jù)獲取價值。結(jié)果卻失望地發(fā)現(xiàn)這些數(shù)據(jù)毫無價值，事實(shí)上在數(shù)據(jù)與消費(fèi)者之間還存在另一種batch layer層面。通過將Hadoop與MongoDB合并，數(shù)據(jù)庫可以確保成功，并是一個保持較低的總擁有成本，最快響應(yīng)所有用戶（數(shù)據(jù)科學(xué)家、分析師、商業(yè)用戶、消費(fèi)者自身）的靈活數(shù)據(jù)平臺。有了數(shù)據(jù)湖，公司和員工就能用它來獲取獨(dú)特的見解，與客戶進(jìn)行有效溝通，將數(shù)