本文講述了大數(shù)據(jù)的相關(guān)問(wèn)題,以及“大數(shù)據(jù)架構(gòu)”得名的由來(lái)。
大數(shù)據(jù)的問(wèn)題
或許所有讀者都明白這一點(diǎn):數(shù)據(jù)正在飛速增長(zhǎng)。若是能夠有效利用的話,我們能從這些數(shù)據(jù)中找到非常有價(jià)值的見(jiàn)解;傳統(tǒng)技術(shù)有很多都是在40年前設(shè)計(jì)的,比如RDBMSs,不足以創(chuàng)造“大數(shù)據(jù)”炒作所宣稱的商業(yè)價(jià)值。在大數(shù)據(jù)技術(shù)的使用上,常見(jiàn)的案例是“客戶單一視圖”;將關(guān)于客戶所知道的一切內(nèi)容放在一起,以便最大化服務(wù)提供與自身收入,比如確定具體需要采用什么促銷方式,又是在什么時(shí)候、通過(guò)什么渠道來(lái)發(fā)送。
盡管大數(shù)據(jù)的問(wèn)題在于,讓我們將這種潛力變?yōu)楝F(xiàn)實(shí),高等級(jí)的關(guān)鍵功能至少包括下面這些能力:
合并信息孤井、外在因素與數(shù)據(jù)流;
控制數(shù)據(jù)訪問(wèn);
根據(jù)需要轉(zhuǎn)化數(shù)據(jù);
整合數(shù)據(jù);
為數(shù)據(jù)分析提供工具;
發(fā)布數(shù)據(jù)報(bào)告;
將見(jiàn)解體現(xiàn)在運(yùn)營(yíng)過(guò)程中;
最小化工作完成的總擁有成本與響應(yīng)時(shí)間。
用數(shù)據(jù)湖作為答案
很多公司正在觀望一個(gè)被某些人稱為數(shù)據(jù)湖的架構(gòu),這個(gè)數(shù)據(jù)平臺(tái)在合并信息孤井?dāng)?shù)據(jù)流以及在單獨(dú)的邏輯位置中執(zhí)行數(shù)據(jù)持久化方面具有靈活性,能夠從企業(yè)自身以及第三方的數(shù)據(jù)中挖掘出見(jiàn)解。將Hadoop(包括Spark在內(nèi))用于數(shù)據(jù)湖已成大勢(shì)所趨,原因很多:使用總擁有成本較低的普通硬件就能進(jìn)行擴(kuò)展,允許用讀時(shí)模式(schema-on-read)收取大量數(shù)據(jù),支持開(kāi)源,包括用SQL和普通語(yǔ)言構(gòu)建分布式處理層。此外,像雅虎和谷歌這樣的webscale公司都是早期標(biāo)桿,借用這種架構(gòu)在解決網(wǎng)站索引相關(guān)的問(wèn)題時(shí)獲得了巨大的成功。
Hadoop中的數(shù)據(jù)持久化選項(xiàng)
這樣一來(lái),從這里開(kāi)始評(píng)估數(shù)據(jù)湖解決方案的前景似乎很合理。一旦開(kāi)始從更深的層次理解Hadoop的內(nèi)涵,你就會(huì)發(fā)現(xiàn)里面所包含的項(xiàng)目真的是包羅萬(wàn)象,涵蓋了數(shù)據(jù)處理的方方面面。用Hadoop在數(shù)據(jù)湖中探測(cè)存儲(chǔ)的數(shù)據(jù)時(shí),有兩個(gè)主要選項(xiàng):HDFS和HBase。使用HDFS時(shí),可以自行決定如何在只添加文件中對(duì)數(shù)據(jù)進(jìn)行編碼,包括JSON、CSV、Avro等等,因?yàn)镠DFS只是一個(gè)文件系統(tǒng),編碼方式全由你決定。相反,HBase是一個(gè)數(shù)據(jù)庫(kù),其特有的數(shù)據(jù)編碼方式可以將記錄寫入的速度最優(yōu)化,在通過(guò)主鍵查詢時(shí)執(zhí)行只讀的速度相對(duì)也很快。
這也是用Hadoop的數(shù)據(jù)湖之魅力所在,它能實(shí)現(xiàn)真實(shí)情況下的需求。因此,我們就能使用Hadoop來(lái)執(zhí)行上面列出的高層次需求了。在像Spark和Hive這樣的Hadoop生態(tài)系統(tǒng)中,仍需用到分布式處理層,但不需HDFS或HBase了,因此你可以從分布式處理層中選擇持久化層面。之前的博文中有相關(guān)案例,描述了使用Spark在MongoDB中讀寫數(shù)據(jù)。還有一篇博文也很類似,證明了MongoDB只是讀取數(shù)據(jù)的另一個(gè)Hive表格。
索引仍舊很重要
大多熟悉RDBMSs的技術(shù)人員發(fā)現(xiàn),從表達(dá)查詢能力到二級(jí)索引,再到加速查詢?nèi)純r(jià)值巨大(即便模式固定、總擁有成本高以及RDBMSs的可擴(kuò)展性有限,這些使得它很難被用作數(shù)據(jù)湖)。如果我們?cè)跀?shù)據(jù)庫(kù)持久化中只用到HDFS和HBase,就無(wú)法實(shí)現(xiàn)我們期待的數(shù)據(jù)庫(kù)臨時(shí)索引了,特別是遇到下面幾個(gè)限制時(shí):
臨時(shí)切片:不通過(guò)二級(jí)索引,我們?nèi)绾螌?duì)不止一個(gè)主鍵標(biāo)識(shí)出的數(shù)據(jù)切片進(jìn)行有效地分析呢,例如對(duì)我們的最佳客戶——那些消費(fèi)金額超過(guò)X的客戶進(jìn)行分析?由于數(shù)據(jù)太過(guò)巨大,想要通過(guò)掃描找出最佳客戶都會(huì)令工作卡住。
低延遲報(bào)告:如果沒(méi)有靈活的索引方式,我們?nèi)绾卧诖蚊爰?jí)時(shí)間內(nèi)響應(yīng)客戶的需求,為他們提供有價(jià)值的數(shù)據(jù)報(bào)告呢?再次,我們只能使用消費(fèi)者的賬戶號(hào)或者其他主鍵來(lái)進(jìn)行快速報(bào)告,而不是通過(guò)消費(fèi)者的姓名、電話號(hào)碼、郵編、花費(fèi)等等。特別提到:MongoDB剛剛為基于SQL的報(bào)告工具發(fā)布了BI Connector。
運(yùn)營(yíng)化:同樣地,我們?nèi)绾螌⒂袃r(jià)值的見(jiàn)解引入應(yīng)用運(yùn)營(yíng)中,從而在最大化影響公司和消費(fèi)者的同時(shí)將數(shù)據(jù)變現(xiàn)?想象一下客服專員(CSR)告知消費(fèi)者,因?yàn)閿?shù)據(jù)湖僅支持這個(gè)主鍵,他必須提供賬號(hào)才能查詢所有的信息;或者查詢需要10分鐘時(shí)間。
當(dāng)然,其中有些問(wèn)題可以通過(guò)變通方法解決,不過(guò)會(huì)導(dǎo)致總擁有成本更高、開(kāi)發(fā)或運(yùn)營(yíng)工作更多、延遲也更高。例如,使用搜索引擎或者實(shí)體化視圖而不是通過(guò)主鍵來(lái)查詢;不過(guò)稍后還需返回到數(shù)據(jù)庫(kù),在有完整記錄的數(shù)據(jù)庫(kù)中對(duì)主表進(jìn)行再次查詢,以獲得所需的完整信息。除了延遲翻倍之外,還需要耗費(fèi)額外的管理、開(kāi)發(fā)工作,以及單獨(dú)搜索引擎需要的基礎(chǔ)設(shè)施,還有實(shí)體化視圖所需的維護(hù),加上將數(shù)據(jù)寫入到其他地方造成的一致性問(wèn)題。保持我們的設(shè)計(jì)原則,只用我們用慣的普通靈活索引不是很好么?
MongoDB是一個(gè)有效數(shù)據(jù)湖的重要部分
我們開(kāi)始討論,探索單用Hadoop是否能滿足數(shù)據(jù)湖的需求,并發(fā)現(xiàn)了至少3個(gè)問(wèn)題。我們能否在架構(gòu)中另加一層持久化層面來(lái)解決這些問(wèn)題,同時(shí)保持設(shè)計(jì)原則——使用低總擁有成本的普通硬件、開(kāi)源模式、讀時(shí)模式還有Hadoop分布式數(shù)據(jù)層——與之前一致呢?
我選擇本文的主題是因?yàn)椋琈ongoDB就是在Hadoop-only數(shù)據(jù)湖中,補(bǔ)位最優(yōu)秀的數(shù)據(jù)庫(kù)。如果使用另一個(gè)開(kāi)源NoSQL數(shù)據(jù)庫(kù),就會(huì)發(fā)現(xiàn)其中幾乎不含二級(jí)索引(使用二級(jí)索引會(huì)導(dǎo)致無(wú)法同步數(shù)據(jù)),也沒(méi)有分組和聚合功能。你可以使用其中一些數(shù)據(jù)庫(kù)將數(shù)據(jù)寫入數(shù)據(jù)湖,不過(guò)如果出于商業(yè)需求想要以靈活的方式使用二級(jí)索引讀取的話,是做不到的。如果想要在數(shù)據(jù)湖中使用開(kāi)源RDBMS,我們已經(jīng)說(shuō)過(guò),它們固定的模式、昂貴的垂直擴(kuò)展模型都違背了我們?cè)O(shè)計(jì)數(shù)據(jù)湖的原則。
因此,推薦使用下面的架構(gòu)來(lái)構(gòu)建數(shù)據(jù)湖。
MongoDB對(duì)數(shù)據(jù)湖非常重要
這個(gè)架構(gòu)將MongoDB作為持久化層面加入任何需要表達(dá)查詢的數(shù)據(jù)集中,正與你需要索引的三個(gè)原因(上面列舉了)相關(guān)。由于需求數(shù)據(jù)來(lái)自消費(fèi)者,無(wú)論是否將數(shù)據(jù)發(fā)布到HDFS和/或MongoDB中,我推薦用governance function來(lái)確定。無(wú)論存儲(chǔ)到HDFS或者M(jìn)ongoDB上,就可以運(yùn)行分布式處理任務(wù),比如Hive和Spark。不過(guò)如果數(shù)據(jù)在MongoDB上,因?yàn)楹Y選標(biāo)準(zhǔn)下放到數(shù)據(jù)庫(kù)中,不像在HDFS中那樣掃描文件,你就能在數(shù)據(jù)臨時(shí)切片上運(yùn)行有效分析了。與此相似,MongoDB中的數(shù)據(jù)也可用于實(shí)時(shí)、低延遲報(bào)告,并為構(gòu)建的應(yīng)用所用到的所有系統(tǒng)提供運(yùn)營(yíng)數(shù)據(jù)平臺(tái)服務(wù)。
如今一些公司只是將數(shù)據(jù)復(fù)制到Hadoop中進(jìn)行轉(zhuǎn)換,然后再?gòu)?fù)制到其他地方,用于完成有價(jià)值的工作。為什么不直接利用數(shù)據(jù)湖,發(fā)揮最大價(jià)值呢?使用MongoDB可以將價(jià)值多次翻倍。
結(jié)論
觀察長(zhǎng)期與短期需求,確保這些需求可以通過(guò)核心Hadoop分布中的最佳工具,以及MongoDB這樣的生態(tài)環(huán)境實(shí)現(xiàn),數(shù)據(jù)湖對(duì)你而言就是有價(jià)值且而可行的。一些企業(yè)在使用數(shù)據(jù)湖時(shí),只花費(fèi)一年時(shí)間清洗所有數(shù)據(jù),然后將其寫入HDFS,希望在未來(lái)能用這些數(shù)據(jù)獲取價(jià)值。結(jié)果卻失望地發(fā)現(xiàn)這些數(shù)據(jù)毫無(wú)價(jià)值,事實(shí)上在數(shù)據(jù)與消費(fèi)者之間還存在另一種batch layer層面。
通過(guò)將Hadoop與MongoDB合并,數(shù)據(jù)庫(kù)可以確保成功,并是一個(gè)保持較低的總擁有成本,最快響應(yīng)所有用戶(數(shù)據(jù)科學(xué)家、分析師、商業(yè)用戶、消費(fèi)者自身)的靈活數(shù)據(jù)平臺(tái)。有了數(shù)據(jù)湖,公司和員工就能用它來(lái)獲取獨(dú)特的見(jiàn)解,與客戶進(jìn)行有效溝通,將數(shù)據(jù)變現(xiàn)并戰(zhàn)勝競(jìng)爭(zhēng)對(duì)手。
原文鏈接: https://dzone.com/articles/the-future-of-big-data-architecture