2023離線和實(shí)時(shí)大數(shù)據(jù)開發(fā)實(shí)戰(zhàn)

離線和實(shí)時(shí)大數(shù)據(jù)開發(fā)實(shí)戰(zhàn)第11.1數(shù)據(jù)流程1.2數(shù)據(jù)技術(shù)1.3數(shù)據(jù)相關(guān)從業(yè)者和角色1.4本章小結(jié)第22.1離線數(shù)據(jù)平臺(tái)的架構(gòu)、技術(shù)和設(shè)計(jì)2.2實(shí)時(shí)數(shù)據(jù)平臺(tái)的架構(gòu)、技術(shù)和設(shè)計(jì)2.3數(shù)據(jù)管理2.4本章小結(jié)第3Hadoop原理實(shí)踐3.1開啟大數(shù)據(jù)時(shí)代的Hadoop3.2HDFS和MapReduce優(yōu)缺點(diǎn)分析3.3HDFS和MapReduce基本架構(gòu)3.4MapReduce內(nèi)部原理實(shí)踐3.5本章小結(jié)第4Hive原理實(shí)踐4.1離線大數(shù)據(jù)處理的主要技術(shù)：Hive4.2HiveSQL4.3HiveSQL執(zhí)行原理圖解4.4Hive函數(shù)4.5其他SQLonHadoop技術(shù)4.6本章小結(jié)第5Hive優(yōu)化實(shí)踐5.1離線數(shù)據(jù)處理的主要挑戰(zhàn)：數(shù)據(jù)傾斜5.2Hive優(yōu)化5.3join無關(guān)的優(yōu)化5.4大表join小表優(yōu)化5.5大表join大表優(yōu)化5.6本章小結(jié)第66.1大數(shù)據(jù)建模的主要技術(shù)：維度建模6.2維度表設(shè)計(jì)6.3深入事實(shí)表6.4大數(shù)據(jù)的維度建模實(shí)踐6.5本章小結(jié)第7Hadoop數(shù)據(jù)倉庫開發(fā)實(shí)戰(zhàn)7.1業(yè)務(wù)需求7.2Hadoop數(shù)據(jù)倉庫架構(gòu)設(shè)計(jì)7.3Hadoop數(shù)據(jù)倉庫規(guī)范設(shè)計(jì)7.4FutureRetailer數(shù)據(jù)倉庫構(gòu)建實(shí)踐7.5數(shù)據(jù)平臺(tái)新架構(gòu)——數(shù)據(jù)湖7.6本章小結(jié)第8Storm流計(jì)算開發(fā)8.1流計(jì)算技術(shù)的鼻祖：Storm技術(shù)8.2Storm實(shí)時(shí)開發(fā)示例8.3Storm高級(jí)原語Trident8.4Storm關(guān)鍵技術(shù)8.5本章小結(jié)第9SparkStreaming流計(jì)算開發(fā)9.1Spark生態(tài)和核心概念9.2Spark生態(tài)的流計(jì)算技術(shù)：SparkStreaming9.3SparkStreaming的實(shí)時(shí)開發(fā)示例9.4SparkStreaming調(diào)優(yōu)實(shí)踐9.5SparkStreaming關(guān)鍵技術(shù)9.6本章小結(jié)第10Flink流計(jì)算開發(fā)10.1流計(jì)算技術(shù)新貴：Flink10.2FlinkAPI10.3Flink實(shí)時(shí)開發(fā)示例10.4Flink關(guān)鍵技術(shù)詳解10.5本章小結(jié)第11Beam技術(shù)11.1意圖一統(tǒng)流計(jì)算的Beam11.2Beam技術(shù)核心：BeamModel11.3BeamSDK11.4Beam窗口詳解11.5本章小結(jié)第12StreamSQL實(shí)時(shí)開發(fā)實(shí)戰(zhàn)12.1流計(jì)算SQL原理和架構(gòu)12.2流計(jì)算SQL：未來主要的實(shí)時(shí)開發(fā)技術(shù)12.3StreamSQL12.4StreamSQL的實(shí)時(shí)開發(fā)實(shí)戰(zhàn)12.5撤回機(jī)制12.6本章小結(jié)第1章 數(shù)據(jù)大圖數(shù)據(jù)是原油，數(shù)據(jù)是生產(chǎn)資料，數(shù)據(jù)和技術(shù)驅(qū)動(dòng)，人類正從IT時(shí)代走向DT時(shí)代，隨著數(shù)說數(shù)據(jù)平臺(tái)是一個(gè)公司、機(jī)構(gòu)或組織內(nèi)“看”數(shù)據(jù)和“用數(shù)據(jù)”的關(guān)鍵基礎(chǔ)設(shè)施，已經(jīng)像水電煤一樣不可或缺，正是它們的存在才使得數(shù)據(jù)變現(xiàn)成為可能。因此本章首先對(duì)數(shù)據(jù)流程以及相應(yīng)的主要數(shù)據(jù)技術(shù)進(jìn)行介紹。同時(shí)，本章也將介紹數(shù)據(jù)的主要從業(yè)者，包括平臺(tái)開發(fā)運(yùn)維工程師、數(shù)據(jù)開發(fā)工程師、數(shù)據(jù)分析師、算法工程師等，并對(duì)他們的基本工作職責(zé)和日常工作內(nèi)容等進(jìn)行介紹，使讀者對(duì)數(shù)據(jù)相關(guān)的職位有基本的認(rèn)識(shí)和了解。數(shù)據(jù)流程不管是時(shí)髦的大數(shù)據(jù)還是之前傳統(tǒng)的數(shù)據(jù)倉庫，不管是目前應(yīng)用最為廣泛的離線數(shù)據(jù)還是越來越得到重視的實(shí)時(shí)數(shù)據(jù)，其端到端流程都包含：數(shù)據(jù)產(chǎn)生、數(shù)據(jù)采集和傳輸、數(shù)據(jù)存儲(chǔ)處理、數(shù)據(jù)應(yīng)用四大過程，具體的數(shù)據(jù)流程圖及其包含的關(guān)鍵環(huán)節(jié)如圖1-1所示。圖1-1 數(shù)據(jù)流程大圖下面詳述圖1-1所示的各個(gè)關(guān)鍵關(guān)節(jié)。數(shù)據(jù)產(chǎn)生數(shù)據(jù)產(chǎn)生是數(shù)據(jù)平臺(tái)的源頭，沒有數(shù)據(jù)，所謂的大數(shù)據(jù)也無從談起。所以首先要保證有數(shù)據(jù)。據(jù)和信息爆炸的時(shí)代。所以，即使一個(gè)企業(yè)和個(gè)人沒有數(shù)據(jù)，通過爬蟲工具和系統(tǒng)的幫到的，這些數(shù)據(jù)存在于各個(gè)公司、企業(yè)、政府機(jī)關(guān)和機(jī)構(gòu)的系統(tǒng)內(nèi)部。數(shù)據(jù)分類根據(jù)源頭系統(tǒng)的類型不同，我們可以把數(shù)據(jù)產(chǎn)生的來源分為以下幾種。業(yè)務(wù)系統(tǒng)業(yè)務(wù)系統(tǒng)指的是企業(yè)核心業(yè)務(wù)的或者企業(yè)內(nèi)部人員使用的、保證企業(yè)正常運(yùn)轉(zhuǎn)的IT系統(tǒng)，比如超市的POS銷售系統(tǒng)、訂單/庫存/供應(yīng)鏈管理的ERP系統(tǒng)、客戶關(guān)系管理的CRM系統(tǒng)、財(cái)務(wù)系統(tǒng)、各種行政系統(tǒng)等。不管何種系統(tǒng)，后臺(tái)的數(shù)據(jù)一般都存在后臺(tái)數(shù)據(jù)庫內(nèi)。早期的大部分?jǐn)?shù)據(jù)主要來源于這些業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫，管理人員和業(yè)務(wù)運(yùn)營人員查看的數(shù)據(jù)報(bào)表等基本來源于此。即便是目前，企業(yè)的業(yè)務(wù)系統(tǒng)依然是大部分公司數(shù)據(jù)平臺(tái)的主要數(shù)據(jù)來源，業(yè)務(wù)系統(tǒng)的數(shù)據(jù)通常是格式化和高質(zhì)量的。Web系統(tǒng)隨著互聯(lián)網(wǎng)的發(fā)展，很多系統(tǒng)都變成了Web系統(tǒng)，即互聯(lián)網(wǎng)或者局域網(wǎng)范圍內(nèi)通過瀏覽器就可以訪問，而不是必須安裝客戶端軟件才能訪問的系統(tǒng)（這種就是傳統(tǒng)的業(yè)務(wù)系統(tǒng)）。Web系統(tǒng)也會(huì)有用于存儲(chǔ)各種格式化數(shù)據(jù)的后臺(tái)數(shù)據(jù)庫，但除此之外，還有各種用戶行為日志，比如用戶通過何種途徑訪問了本網(wǎng)站（搜索引擎、直接輸入Web網(wǎng)址、其他系統(tǒng)跳轉(zhuǎn)等），在網(wǎng)站內(nèi)都有何種行為（訪問了哪些網(wǎng)頁、點(diǎn)擊了哪些按鈕、停留了多長時(shí)間）。通過cookie以及各種前端埋點(diǎn)技術(shù)，用戶的這些行為都可以被記錄下來，并保存到相應(yīng)的日志文件內(nèi)。Web系統(tǒng)的日志文件通常是非格式化的文本文件。Web系統(tǒng)和業(yè)務(wù)系統(tǒng)不是互相對(duì)立的，比如現(xiàn)在的ERP系統(tǒng)通常也支持Web和瀏覽器訪問。手機(jī)App在當(dāng)今的移動(dòng)互聯(lián)網(wǎng)時(shí)代，作為移動(dòng)互聯(lián)網(wǎng)的基礎(chǔ)設(shè)施，手機(jī)App已經(jīng)滲透到所有人的吃穿住行，毫不夸張地說，手機(jī)儼然稱得上是一個(gè)身體的“新器官”；另一方面，通過手機(jī)的內(nèi)置傳感器可以知道你是誰（指紋識(shí)別、虹膜識(shí)別、人臉識(shí)別），你在哪里（GPS、WiFi和移動(dòng)網(wǎng)絡(luò)）和你在干什么（吃穿住行App），當(dāng)然移動(dòng)App也會(huì)記錄你在該App上的各種行為，比如你打開了幾次App、點(diǎn)擊了哪些頁面和使用了哪些功能。外部系統(tǒng)很多企業(yè)除了自己內(nèi)部的數(shù)據(jù)，還會(huì)通過爬蟲工具與系統(tǒng)來爬取競爭對(duì)手的數(shù)據(jù)和其他各種公開的數(shù)據(jù)，此外企業(yè)有時(shí)也會(huì)購買外部的數(shù)據(jù)，以作為內(nèi)部數(shù)據(jù)的有益補(bǔ)充。人工整理盡管通過各種內(nèi)部和外部系統(tǒng)可以獲取到各種數(shù)據(jù)，但有些數(shù)據(jù)是無法直接由系統(tǒng)處理過OCR識(shí)別軟件可以自動(dòng)識(shí)別從而簡化和加快這類工作。以上從IT系統(tǒng)的類型介紹了數(shù)據(jù)產(chǎn)生的源頭，從數(shù)據(jù)的本身特征，數(shù)據(jù)還可以分為以下幾類。結(jié)構(gòu)化數(shù)據(jù)結(jié)構(gòu)化數(shù)據(jù)的格式非常規(guī)范，典型的例子是數(shù)據(jù)庫中的數(shù)據(jù)，這些數(shù)據(jù)有幾個(gè)字段，每個(gè)字段的類型（數(shù)字、日期還是文本）和長度等都是非常明確的，這類數(shù)據(jù)通常比較容易管理維護(hù)，查詢、分析和展示也最為容易和方便。半結(jié)構(gòu)化數(shù)據(jù)半結(jié)構(gòu)化數(shù)據(jù)的格式較為規(guī)范，比如網(wǎng)站的日志文件。這類數(shù)據(jù)如果是固定格式的或者固定分隔符分隔的，解析會(huì)比較容易；如果字段數(shù)不固定、包含嵌套的數(shù)據(jù)、數(shù)據(jù)以XML/JSON等格式存儲(chǔ)等，解析處理可能會(huì)相對(duì)比較麻煩和繁瑣。非結(jié)構(gòu)化數(shù)據(jù)非結(jié)構(gòu)化數(shù)據(jù)主要指非文本型的、沒有標(biāo)準(zhǔn)格式的、無法直接處理的數(shù)據(jù)，典型代表為圖片、語音、視頻等，隨著以深度學(xué)習(xí)為代表的圖像處理技術(shù)和語音處理技術(shù)的進(jìn)步，這類數(shù)據(jù)也越來越能得到處理，價(jià)值也越來越大（比如最近Facebook公布了他們基于深度學(xué)習(xí)技術(shù)的研究成果，目前已經(jīng)可以初步識(shí)別圖片中的內(nèi)容并就圖片內(nèi)容標(biāo)注標(biāo)簽）。通常進(jìn)行數(shù)據(jù)存儲(chǔ)時(shí)，數(shù)據(jù)平臺(tái)僅存儲(chǔ)這些圖片、語音和視頻的文件地址，實(shí)際文件則存放在文件系統(tǒng)上。數(shù)據(jù)埋點(diǎn)后臺(tái)數(shù)據(jù)庫和日志文件一般只能夠滿足常規(guī)的統(tǒng)計(jì)分析，對(duì)于具體的產(chǎn)品和項(xiàng)目來說，一般還要根據(jù)項(xiàng)目的目標(biāo)和分析需求進(jìn)行針對(duì)性地“數(shù)據(jù)埋點(diǎn)”工作。所謂埋點(diǎn)，就是在額外的正常功能邏輯上添加針對(duì)性的統(tǒng)計(jì)邏輯，即期望的事件是否發(fā)生，發(fā)生后應(yīng)該記錄哪些信息，比如用戶在當(dāng)前頁面是否用鼠標(biāo)滾動(dòng)頁面、有關(guān)的頁面區(qū)域是否曝光了、當(dāng)前用戶操作的時(shí)間是多少、停留時(shí)長多少，這些都需要前端工程師進(jìn)行針對(duì)性地埋點(diǎn)才能滿足有關(guān)的分析需求。數(shù)據(jù)埋點(diǎn)工作一般由產(chǎn)品經(jīng)理和分析師預(yù)先確定分析需求，然后由數(shù)據(jù)開發(fā)團(tuán)隊(duì)對(duì)接前端開發(fā)和后端開發(fā)來完成具體的埋點(diǎn)工作。隨著數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品理念和數(shù)據(jù)化運(yùn)營等理念的日益深入，數(shù)據(jù)埋點(diǎn)已經(jīng)深入產(chǎn)品的各個(gè)方面，變成產(chǎn)品開發(fā)中不可或缺的一環(huán)。數(shù)據(jù)埋點(diǎn)的技術(shù)也在飛速發(fā)展，也出現(xiàn)了一批專業(yè)的數(shù)據(jù)分析服務(wù)提供商（如國外的Mixpanle和國內(nèi)的神策分析等），盡管這些公司提供專門的SDK可以通用化和簡化數(shù)據(jù)埋點(diǎn)工作，但是很多時(shí)候在具體的產(chǎn)品和項(xiàng)目實(shí)踐中，還是必須進(jìn)行專門的前端埋點(diǎn)和后端埋點(diǎn)才可以滿足數(shù)據(jù)分析與使用需求。數(shù)據(jù)采集和傳輸業(yè)務(wù)系統(tǒng)、Web系統(tǒng)、手機(jī)App等產(chǎn)生的數(shù)據(jù)文件、日志文件和埋點(diǎn)日志等分散于各個(gè)系統(tǒng)與服務(wù)器上，必須通過數(shù)據(jù)采集傳輸工具和系統(tǒng)的幫助，才能匯總到一個(gè)集中的區(qū)域進(jìn)行關(guān)聯(lián)和分析。在大數(shù)據(jù)時(shí)代，數(shù)據(jù)量的大當(dāng)然重要，但更重要的是數(shù)據(jù)的關(guān)聯(lián)，不同來源數(shù)據(jù)的結(jié)合往往能產(chǎn)生1+1＞2甚至1+1＞10的效果。另一個(gè)非常關(guān)鍵的點(diǎn)是數(shù)據(jù)的時(shí)效性，隨著時(shí)間的流失，數(shù)據(jù)的價(jià)值會(huì)大打折扣，只有在最恰當(dāng)?shù)臅r(shí)間捕捉到用戶的需求，才會(huì)是商機(jī)，否則只能是錯(cuò)失時(shí)機(jī)。試想一下，如果中午用戶在搜索“西餐廳”，只有在這一刻對(duì)用戶推送西餐廳推薦才是有效的，數(shù)分鐘、數(shù)十分鐘、數(shù)小時(shí)后的推送效果和價(jià)值將逐步遞減。而實(shí)現(xiàn)這些必須借助于專業(yè)的數(shù)據(jù)采集傳輸工具和系統(tǒng)的幫助。過去傳統(tǒng)的數(shù)據(jù)采集和傳輸工具一般都是離線的，隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展以及各種個(gè)性化推薦系統(tǒng)的興起，實(shí)時(shí)的數(shù)據(jù)采集和傳輸工具越來越得到重視，可以毫不夸張地說，數(shù)據(jù)采集傳輸工具和系統(tǒng)已是大數(shù)據(jù)時(shí)代的關(guān)鍵基礎(chǔ)設(shè)施。數(shù)據(jù)產(chǎn)生的來源有很多，但是其物理存在表現(xiàn)形式主要為文本文件和數(shù)據(jù)庫兩種。理論上來說，數(shù)據(jù)采集和傳輸無非就是把一個(gè)地方的數(shù)據(jù)從源頭復(fù)制到目的地，文本文件可直接復(fù)制，數(shù)據(jù)庫也可以通過創(chuàng)建數(shù)據(jù)庫連接直接拖數(shù)據(jù)，但是數(shù)據(jù)采集傳輸?shù)奶魬?zhàn)在于：數(shù)據(jù)可能分布在不同的數(shù)據(jù)中心，數(shù)據(jù)庫也可能是分庫分表的，而數(shù)據(jù)采集也不能對(duì)生產(chǎn)系統(tǒng)庫有任何性能上的影響，最好也不需要產(chǎn)品開發(fā)、DBA或系統(tǒng)管理員的過多介入，有時(shí)候還必須能夠做到毫秒級(jí)的實(shí)時(shí)采集，而這些都必須借助專業(yè)的數(shù)據(jù)采集傳輸工具和系統(tǒng)才能完成，比如專業(yè)的數(shù)據(jù)采集傳輸工具不會(huì)通過建立數(shù)據(jù)庫連接來采集數(shù)據(jù)，而會(huì)通過解析數(shù)據(jù)庫日志來進(jìn)行[1]。在無須數(shù)據(jù)庫DBA、系統(tǒng)管理員和產(chǎn)品開發(fā)介入的情況下（只需要開通權(quán)限即可）高效地完成數(shù)據(jù)采集和同步的任務(wù)。數(shù)據(jù)存儲(chǔ)處理數(shù)據(jù)采集同步后的數(shù)據(jù)是原始的和雜亂的，必須經(jīng)過專門的清洗、關(guān)聯(lián)、規(guī)范化和精心的組織建模，而且要通過數(shù)據(jù)質(zhì)量檢測后才能進(jìn)行后續(xù)的數(shù)據(jù)分析或用于提供數(shù)據(jù)服務(wù)，而這就是數(shù)據(jù)平臺(tái)構(gòu)建的第三個(gè)關(guān)鍵關(guān)節(jié)——數(shù)據(jù)存儲(chǔ)處理。大數(shù)據(jù)項(xiàng)目和數(shù)據(jù)平臺(tái)構(gòu)建的實(shí)踐表明，數(shù)據(jù)存儲(chǔ)處理通常占用整個(gè)項(xiàng)目至少1/3以上的時(shí)間，這一環(huán)節(jié)的設(shè)計(jì)是否合理、最終的數(shù)據(jù)是否穩(wěn)定可靠、建模是否靈活可擴(kuò)展直接決定后續(xù)數(shù)據(jù)應(yīng)用的成敗，也決定了整個(gè)數(shù)據(jù)平臺(tái)項(xiàng)目的成敗。數(shù)據(jù)存儲(chǔ)處理也是數(shù)據(jù)領(lǐng)域最為激動(dòng)人心和百花齊放的領(lǐng)域，各種開源技術(shù)框架和創(chuàng)新層出不窮，但是萬變不離其宗，根據(jù)下游數(shù)據(jù)使用方的時(shí)效性，我們可以把數(shù)據(jù)存儲(chǔ)處理工具和技術(shù)分為離線處理、近線處理和實(shí)時(shí)處理，處理后的數(shù)據(jù)也相應(yīng)地存儲(chǔ)于離線數(shù)據(jù)倉庫、近線數(shù)據(jù)存儲(chǔ)區(qū)和實(shí)時(shí)數(shù)據(jù)存儲(chǔ)區(qū)。離線處理一般按天進(jìn)行數(shù)據(jù)處理，每天凌晨等數(shù)據(jù)采集和同步的數(shù)據(jù)到位后，相關(guān)的數(shù)據(jù)處理任務(wù)會(huì)被按照預(yù)先設(shè)計(jì)的ETL（抽取、轉(zhuǎn)換、加載，一般用來泛指數(shù)據(jù)清洗、關(guān)聯(lián)、規(guī)范化等數(shù)據(jù)處理過程）邏輯以及ETL任務(wù)之間的拓?fù)潢P(guān)系依次調(diào)用，最終的數(shù)據(jù)會(huì)被寫入離線數(shù)據(jù)倉庫中。離線數(shù)據(jù)倉庫中的數(shù)據(jù)通常是按照某種建模思想（最常用的是維度建模思想）精心組織的，這樣既可以使下游用戶非常直觀和方便地使用，又可以使數(shù)據(jù)處理過程很方便地?cái)U(kuò)展和修改。從各個(gè)源頭系統(tǒng)采集同步過來的離線數(shù)據(jù)，通常放在一個(gè)StagingArea（暫存區(qū)，也叫登臺(tái)區(qū)），進(jìn)行便于后續(xù)的離線ETL處理。離線數(shù)據(jù)的存儲(chǔ)處理技術(shù)發(fā)展已經(jīng)比較成熟，也有很多成熟的ETL工具、商業(yè)/開源數(shù)據(jù)倉庫和解決方案[2]。這些商業(yè)或者開源的數(shù)據(jù)倉庫工具和解決方案在數(shù)據(jù)量不是很大和解決結(jié)構(gòu)化數(shù)據(jù)方面還是比較成功的，但是隨著Google關(guān)于分布式計(jì)算三篇論文的發(fā)表內(nèi)容主體分別是分布式文件系統(tǒng)GoogleFileSystem，分布式計(jì)算框架MapReduce，分布式數(shù)據(jù)庫Bigtable）和基于Google三篇論文開源實(shí)現(xiàn)的Hadoop生態(tài)系統(tǒng)（分別對(duì)應(yīng)Google三篇論文——HDFS，MapReduce，HBase）興起，大數(shù)據(jù)時(shí)代真正到來，這些傳統(tǒng)的商業(yè)和開源數(shù)據(jù)倉庫工具與解決方案在成本及可擴(kuò)展性方面的劣勢日益顯現(xiàn)，不僅僅是互聯(lián)網(wǎng)公司，越來越多的傳統(tǒng)公司也日漸轉(zhuǎn)向基于Hadoop生態(tài)系統(tǒng)的數(shù)據(jù)倉庫工具和解決方案。大數(shù)據(jù)時(shí)代對(duì)于數(shù)據(jù)的使用已經(jīng)不限于離線數(shù)據(jù)的分析，實(shí)時(shí)數(shù)據(jù)正變得越來越重要，而這必須借助專業(yè)的流計(jì)算工具和框架才能實(shí)現(xiàn)。目前最為流行和使用廣泛的流計(jì)算框架是Storm/類Storm的流處理框架和Spark生態(tài)的SparkStreaming等。國內(nèi)外大廠在使用這些開源框架的同時(shí)，還結(jié)合自身的使用實(shí)踐對(duì)這些流計(jì)算框架從不同層面進(jìn)行改進(jìn)和創(chuàng)新，如穩(wěn)定性、可擴(kuò)展性、性能等，但是筆者認(rèn)為這其中最具革命性的是SQL抽象層的出現(xiàn)。SQL抽象層使得實(shí)時(shí)開發(fā)用戶不必寫Java或者其他編程語言來開發(fā)實(shí)時(shí)處理邏輯，不但大大加快了實(shí)時(shí)開發(fā)的效率，而且大大降低了實(shí)時(shí)開發(fā)的門檻。通常，實(shí)時(shí)處理的結(jié)果會(huì)寫入實(shí)時(shí)存儲(chǔ)區(qū)（比如HBase），以提供高可靠和高并發(fā)的實(shí)時(shí)數(shù)據(jù)服務(wù)，比如用戶的實(shí)時(shí)畫像和實(shí)時(shí)搜索請(qǐng)求，后續(xù)的個(gè)性化推薦系統(tǒng)或者智能處理程序直接訪問此實(shí)時(shí)存儲(chǔ)區(qū)就可以實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)服務(wù)。近線數(shù)據(jù)的時(shí)效性于離線（以“天”為單位）和實(shí)時(shí)（以毫秒/秒為單位）之間，比如最近1小時(shí)的數(shù)據(jù)或者最近15分鐘的數(shù)據(jù)。近線數(shù)據(jù)兼有離線批次處理的便捷性和實(shí)時(shí)數(shù)據(jù)的時(shí)效性優(yōu)勢，通常是業(yè)務(wù)需求和技術(shù)可實(shí)現(xiàn)性折中的結(jié)果。近線數(shù)據(jù)可以通過提高離線任務(wù)調(diào)度頻次來實(shí)現(xiàn)，但是必須有相關(guān)的數(shù)據(jù)采集同步工具提供近線數(shù)據(jù)源頭的支持。離線和在線以及近線的劃分，是目前數(shù)據(jù)工業(yè)界的技術(shù)現(xiàn)狀，但這樣是合理的嗎？為什么同樣的業(yè)務(wù)邏輯必須用離線和在線兩種技術(shù)分別實(shí)現(xiàn)？離線的批處理難道不是實(shí)時(shí)流處理的一種特例嗎？離線的批處理和實(shí)時(shí)的流處理為什么不能實(shí)現(xiàn)融合（用一種技術(shù)來實(shí)現(xiàn)），同樣的邏輯為什么要存在于離線和實(shí)時(shí)兩個(gè)地方？2015年和2016年以來涌現(xiàn)出來的ApacheFlink和ApacheBeam等就是同時(shí)針對(duì)流數(shù)據(jù)和批數(shù)據(jù)兩者的分布式數(shù)據(jù)處理引擎，這些技術(shù)已經(jīng)逐漸成熟并大量進(jìn)入生產(chǎn)環(huán)境中使用，這些技術(shù)代表了未來大數(shù)據(jù)處理的方向。數(shù)據(jù)應(yīng)用環(huán)節(jié)。數(shù)據(jù)應(yīng)用最廣泛的方式是“看”，比如決策層和管理人員定時(shí)查看的公司/部門業(yè)務(wù)日?qǐng)?bào)、地說，一個(gè)企業(yè)“看”數(shù)據(jù)的能力代表了這個(gè)企業(yè)的數(shù)據(jù)應(yīng)用能力水平，也是其核心競爭力之一。隨著大數(shù)據(jù)時(shí)代和人工智能熱潮的到來，數(shù)據(jù)已經(jīng)不僅局限于“看”。Google的超級(jí)搜索框、淘寶的“千人千面”個(gè)性化推薦系統(tǒng)、新聞聚合推薦App今日頭條都代表著數(shù)據(jù)和算法結(jié)合的成功，也彰顯著數(shù)據(jù)+算法的威力。借助數(shù)據(jù)挖掘、機(jī)器學(xué)習(xí)算法和深度學(xué)習(xí)算法以及在線數(shù)據(jù)服務(wù)等技術(shù)，數(shù)據(jù)已經(jīng)成為在線生產(chǎn)系統(tǒng)的一部分。MySQL的BinLog，數(shù)據(jù)庫日志包含了對(duì)數(shù)據(jù)庫的所有變更信息，以二進(jìn)制形式保存，包含了修改前和修改后的數(shù)據(jù)快照，主要用于數(shù)據(jù)庫的備份和恢復(fù)。商業(yè)性的有微軟的SSIS可視化ETL工具和SQLServer數(shù)據(jù)庫，IBM的datastage可視化數(shù)據(jù)庫，甲骨文的PL/SQL以及Oracle的數(shù)據(jù)庫等；開源的有Kettle可視化ETL工具和開源的MySQL數(shù)據(jù)庫等。數(shù)據(jù)技術(shù)目前大數(shù)據(jù)相關(guān)的技術(shù)可以說是蓬勃發(fā)展、百花齊放，對(duì)于初入者來說，一個(gè)個(gè)響亮的名字，一個(gè)個(gè)眼花繚亂的框架，之前剛了解了一個(gè)，很快又跳出來一個(gè)，正如白居易的《錢塘湖春行》所言，真的是“亂花漸欲迷人眼”。但是萬變不離其宗，不管這些技術(shù)如何變化、名詞如何新穎，它們都屬于1.1節(jié)介紹的某個(gè)具體流程和環(huán)節(jié)，因此下面將結(jié)合前面所述的數(shù)據(jù)流程來介紹當(dāng)前主要的數(shù)據(jù)技術(shù)和框架。結(jié)合1.1節(jié)的數(shù)據(jù)流程圖，當(dāng)前大數(shù)據(jù)生態(tài)系統(tǒng)的主要開源技術(shù)和框架如圖1-2所示。圖1-2 當(dāng)前大數(shù)據(jù)生態(tài)系統(tǒng)的主要開源技術(shù)和框架出于篇幅和開源框架實(shí)際情況考慮，圖1-2并沒有列出所有數(shù)據(jù)相關(guān)的開源技術(shù)框架，比如SQLonHadoop方面的技術(shù)還有很多（如ClouderaImpala、Presto、Shark、Dremel等），數(shù)據(jù)采集傳輸還有Chukwa、RabbitMQ等，數(shù)據(jù)存儲(chǔ)還包含Redis緩存數(shù)據(jù)庫以及MySQL等關(guān)系型數(shù)據(jù)庫。此外，IBM、微軟、Oracle、Informatica等大公司的商業(yè)軟件和技術(shù)尚不在此列。但正是這些所有的數(shù)據(jù)技術(shù)一起構(gòu)成了目前大數(shù)據(jù)的生態(tài)系統(tǒng)，各種技術(shù)你中有我，我中有你，互相借鑒，互相啟發(fā)。實(shí)際上很多技術(shù)甚至其基本原理都是類似的，只是由于商業(yè)的、社區(qū)的或者甚至私人的各種原因，它們才獨(dú)立出來。也許正是這樣，才促成了目前大數(shù)據(jù)整個(gè)生態(tài)圈的繁榮和欣欣向上，正如一句詩所言：“一花獨(dú)放不是春，萬紫千紅春滿園”。下面逐一介紹圖1-2中提到的各種技術(shù)。數(shù)據(jù)采集傳輸主要技術(shù)數(shù)據(jù)采集傳輸工具和技術(shù)主要分為兩大類：離線批處理和實(shí)時(shí)數(shù)據(jù)采集和傳輸。顧名思具是Sqoop，下游的用戶主要是離線數(shù)據(jù)處理平臺(tái)（如Hive等）。實(shí)時(shí)數(shù)據(jù)采集和傳輸最為常用的則是Flume和Kafka，其下游用戶一般是實(shí)時(shí)流處理平臺(tái)，如Storm、Spark、Flink等。SqoopSqoop（發(fā)音：skup）作為一款開源的離線數(shù)據(jù)傳輸工具，主要用于Hadoop（Hive）與傳統(tǒng)數(shù)據(jù)庫（MySQL、PostgreSQL等）間的數(shù)據(jù)傳遞。它可以將一個(gè)關(guān)系型數(shù)據(jù)庫（例如MySQL、Oracle、PostgreSQL等）中的數(shù)據(jù)導(dǎo)入Hadoop的HDFS中，也可以將HDFS的數(shù)據(jù)導(dǎo)入關(guān)系型數(shù)據(jù)庫中。Sqoop項(xiàng)目開始于2009年，最早作為Hadoop的一個(gè)第三方模塊存在，后來為了讓使用者能夠快速部署，也為了讓開發(fā)人員能夠更快速地迭代開發(fā)，獨(dú)立為一個(gè)Apache項(xiàng)目。Flume隨著目前業(yè)務(wù)對(duì)實(shí)時(shí)數(shù)據(jù)需求的日益增長，實(shí)時(shí)數(shù)據(jù)的采集越來越受到重視，而目前這方面主流的開源框架就是Flume，國內(nèi)很多互聯(lián)網(wǎng)公司也都是基于Flume搭建自己的實(shí)時(shí)日志采集平臺(tái)。Flume是Cloudera提供的一個(gè)高可用、高可靠、分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)，目前已經(jīng)是Apache的頂級(jí)子項(xiàng)目。使用Flume可以收集諸如日志、時(shí)間等數(shù)據(jù)，并將這些數(shù)據(jù)資源集中存儲(chǔ)起來供下游使用（尤其是流處理框架，例如Storm）。和Flume類似的另一個(gè)框架是Scribe（Facebook開源的日志收集系統(tǒng)，它為日志的分布式收集、統(tǒng)一處理提供一個(gè)可擴(kuò)展的、高容錯(cuò)的簡單方案）。Kafka通常來說Flume采集數(shù)據(jù)的速度和下游處理的速度通常不同步，因此實(shí)時(shí)平臺(tái)架構(gòu)都會(huì)用一個(gè)消息中間件來緩沖，而這方面最為流行和應(yīng)用最為廣泛的無疑是Kafka。Kafka是由LinkedIn開發(fā)的一個(gè)分布式消息系統(tǒng)，以其可以水平擴(kuò)展和高吞吐率而被廣泛使用，目前主流的開源分布式處理系統(tǒng)（如Storm和Spark等）都支持與Kafka集成。Kafka是一個(gè)基于分布式的消息發(fā)布–訂閱系統(tǒng)，特點(diǎn)是快速、可擴(kuò)展且持久。與其他消息發(fā)布–訂閱系統(tǒng)類似，Kafka可在主題當(dāng)中保存消息的信息。生產(chǎn)者向主題寫入數(shù)據(jù)，消費(fèi)者從主題讀取數(shù)據(jù)。作為一個(gè)分布式的、分區(qū)的、低延遲的、冗余的日志提交服務(wù)，得益于其獨(dú)特的設(shè)計(jì)，目前Kafka使用非常廣泛。和Kafka類似的消息中間件開源產(chǎn)品還包括RabbitMQ、ActiveMQ、ZeroMQ等。數(shù)據(jù)處理主要技術(shù)數(shù)據(jù)處理是數(shù)據(jù)開源技術(shù)最為百花齊放的領(lǐng)域，離線和準(zhǔn)實(shí)時(shí)的工具主要包括MapReduce、Hive和Spark，流處理的工具主要包含Storm，還有最近較為火爆的Flink、Beam等。MapReduceMapReduce是Google公司的核心計(jì)算模型，它將運(yùn)行于大規(guī)模集群上的復(fù)雜并行計(jì)算過程高度抽象為兩個(gè)函數(shù)：map和reduce。MapReduce最偉大之處在于其將處理大數(shù)據(jù)的能力賦予了普通開發(fā)人員，以至于開發(fā)人員即使不會(huì)任何的分布式編程知識(shí)，也能將自己的程序運(yùn)行在分布式系統(tǒng)上處理海量數(shù)據(jù)。MapReduce是第3章的重點(diǎn)介紹內(nèi)容，在此不做過多闡述，第3章中將會(huì)重點(diǎn)介紹其架構(gòu)和原理等。HiveMapReduce將處理大數(shù)據(jù)的能力賦予了普通開發(fā)人員，而Hive進(jìn)一步將處理和分析大數(shù)據(jù)的能力賦予了實(shí)際的數(shù)據(jù)使用人員（數(shù)據(jù)開發(fā)工程師、數(shù)據(jù)分析師、算法工程師和業(yè)務(wù)分析人員等）。Hive是由Facebook開發(fā)并貢獻(xiàn)給Hadoop開源社區(qū)的，是一個(gè)建立在Hadoop體系結(jié)構(gòu)上的一層SQL抽象。Hive提供了一些對(duì)Hadoop文件中的數(shù)據(jù)集進(jìn)行數(shù)據(jù)處理、查詢和分析的工具，它支持類似于傳統(tǒng)RDBMS的SQL語言的查詢語言，以幫助那些熟悉SQL的用戶處理和查詢Hadoop中的數(shù)據(jù)，該查詢語言稱為HiveQL（下文將用HiveSQL指代，因?yàn)槠涓鼮橹庇^和便于理解）。HiveSQL實(shí)際上先被SQL解析器解析，然后被Hive框架解析成一個(gè)MapReduce可執(zhí)行計(jì)劃，并按照該計(jì)劃生成MapReduce任務(wù)后交給Hadoop集群處理。Hive目前仍然是包括國際大廠（如Facebook和國內(nèi)BAT）在內(nèi)的互聯(lián)網(wǎng)公司所使用的主流離線數(shù)據(jù)處理工具，詳細(xì)內(nèi)容參見第4章和第5章。Spark盡管MapReduce和Hive能完成海量數(shù)據(jù)的大多數(shù)批處理工作，并且在大數(shù)據(jù)時(shí)代成為企業(yè)大數(shù)據(jù)處理的首選技術(shù)，但是其數(shù)據(jù)查詢的延遲一直被詬病，而且也非常不適合迭代計(jì)算和DAG（有向無環(huán)圖）計(jì)算。由于Spark具有可伸縮、基于內(nèi)存計(jì)算等特點(diǎn)，且可以直接讀寫Hadoop上任何格式的數(shù)據(jù)，較好地滿足了數(shù)據(jù)即時(shí)查詢和迭代分析的需求，因此變得越來越流行。Spark是UCBerkeleyAMPLab（加州大學(xué)伯克利分校的AMP實(shí)驗(yàn)室）所開源的類HadoopMapReduce的通用并行框架，它擁有HadoopMapReduce所具有的優(yōu)點(diǎn)。但不同于MapReduce的是，Job中間輸出結(jié)果可以保存在內(nèi)存中，從而不再需要讀寫HDFS，因此能更好地適用于數(shù)據(jù)挖掘與機(jī)器學(xué)習(xí)等需要迭代的MapReduce算法。Spark也提供類Hive的SQL接口（早期叫Shark，現(xiàn)為SparkSQL），來方便數(shù)據(jù)人員處理和分析數(shù)據(jù)。此外，Spark還有用于處理實(shí)時(shí)數(shù)據(jù)的流計(jì)算框架SparkStreaming，其基本原理是將實(shí)時(shí)流數(shù)據(jù)分成小的時(shí)間片斷（秒或者幾百毫秒），以類似Spark離線批處理的方式來處理這小部分?jǐn)?shù)據(jù)。本書第9章將會(huì)專門介紹Spark和SparkStreaming技術(shù)。StormMapReduce、Hive和Spark是離線和準(zhǔn)實(shí)時(shí)數(shù)據(jù)處理的主要工具，而實(shí)時(shí)數(shù)據(jù)處理的開山鼻祖毫無疑問是Storm。Storm是Twitter開源的一個(gè)類似于Hadoop的實(shí)時(shí)數(shù)據(jù)處理框架，它原來是由BackType開發(fā)，后BackType被Twitter收購后，Twitter將Storm作為Twitter的主要實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)并貢獻(xiàn)給了開源社區(qū)。Storm對(duì)于實(shí)時(shí)計(jì)算的意義相當(dāng)于Hadoop對(duì)于批處理的意義。Hadoop提供了Map和Reduce原語，使對(duì)數(shù)據(jù)進(jìn)行批處理變得非常簡單和優(yōu)美。同樣，Storm也對(duì)數(shù)據(jù)的實(shí)時(shí)計(jì)算提供了簡單的Spout和Bolt原語。Storm集群表面上看和Hadoop集群非常像，但在Hadoop上面運(yùn)行的是MapReduce的Job，而在Storm上面運(yùn)行的是Topology（拓?fù)洌琒torm拓?fù)淙蝿?wù)和HadoopMapReduce任務(wù)一個(gè)非常關(guān)鍵的區(qū)別在于：1個(gè)MapReduceJob最終會(huì)結(jié)束，而1個(gè)Topology永遠(yuǎn)運(yùn)行（除非顯式地殺掉它），所以實(shí)際上Storm等實(shí)時(shí)任務(wù)的資源使用相比離線MapReduce任務(wù)等要大很多，因?yàn)殡x線任務(wù)運(yùn)行完就釋放掉所使用的計(jì)算、內(nèi)存等資源，而Storm等實(shí)時(shí)任務(wù)必須一直占用直到被顯式地殺掉。Storm擁有低延遲、分布式、可擴(kuò)展、高容錯(cuò)等特性，可以保證消息不丟失，目前Storm、類Storm或者基于Storm抽象的框架技術(shù)是實(shí)時(shí)處理、流處理領(lǐng)域主要采用的技術(shù)。Flink在數(shù)據(jù)處理領(lǐng)域，批處理任務(wù)與實(shí)時(shí)流計(jì)算任務(wù)一般被認(rèn)為是兩種不同的任務(wù)，一個(gè)數(shù)據(jù)項(xiàng)目一般會(huì)被設(shè)計(jì)為只能處理其中一種任務(wù)，例如Storm只支持流處理任務(wù)，而MapReduce、Hive只支持批處理任務(wù)。那么兩者能夠統(tǒng)一用一種技術(shù)框架來完成嗎？批處理是流處理的特例嗎？ApacheFlink是一個(gè)同時(shí)面向分布式實(shí)時(shí)流處理和批量數(shù)據(jù)處理的開源計(jì)算平臺(tái)，它能夠基于同一個(gè)Flink運(yùn)行時(shí)（FlinkRuntime），提供支持流處理和批處理兩種類型應(yīng)用的功能。Flink在實(shí)現(xiàn)流處理和批處理時(shí)，與傳統(tǒng)的一些方案完全不同，它從另一個(gè)視角看待流處理和批處理，將二者統(tǒng)一起來。Flink完全支持流處理，批處理被作為一種特殊的流處理，只是它的輸入數(shù)據(jù)流被定義為有界的而已?；谕粋€(gè)Flink運(yùn)行時(shí)，F(xiàn)link分別提供了流處理和批處理API，而這兩種API也是實(shí)現(xiàn)上層面向流處理、批處理類型應(yīng)用框架的基礎(chǔ)。BeamGoogle開源的Beam在Flink基礎(chǔ)上更進(jìn)了一步，不但希望統(tǒng)一批處理和流處理，而且希望統(tǒng)一大數(shù)據(jù)處理范式和標(biāo)準(zhǔn)。ApacheBeam項(xiàng)目重點(diǎn)在于數(shù)據(jù)處理的編程范式和接口定義，并不涉及具體執(zhí)行引擎的實(shí)現(xiàn)。ApacheBeam希望基于Beam開發(fā)的數(shù)據(jù)處理程序可以執(zhí)行在任意的分布式計(jì)算引擎上！ApacheBeam（原名GoogleCloudDataFlow）是Google于2016年2月貢獻(xiàn)給Apache基金會(huì)的Apache孵化項(xiàng)目，被認(rèn)為是繼MapReduce、GFS和Bigtable等之后，Google在大數(shù)據(jù)處理領(lǐng)域?qū)﹂_源社區(qū)的又一個(gè)非常大的貢獻(xiàn)。ApacheBeam項(xiàng)目重點(diǎn)在于數(shù)據(jù)處理的編程范式和接口定義，并不涉及具體執(zhí)行引擎（Runner）的實(shí)現(xiàn)。ApacheBeam主要由BeamSDK和BeamRunner組成，BeamSDK定義了開發(fā)分布式數(shù)據(jù)處理任務(wù)業(yè)務(wù)邏輯的API接口，生成的分布式數(shù)據(jù)處理任務(wù)Pipeline交給具體的BeamRunner執(zhí)行引擎。ApacheBeam目前支持的API是由Java語言實(shí)現(xiàn)的，Python版本的API正在開發(fā)之中。ApacheBeam支持的底層執(zhí)行引擎包括ApacheFlink、ApacheSpark以及GoogleCloudPlatform，此外ApacheStorm、ApacheHadoop、ApacheGearpump等執(zhí)行引擎的支持也在討論或開發(fā)當(dāng)中。數(shù)據(jù)存儲(chǔ)主要技術(shù)HDFSHadoopDistributedFileSystem，簡稱HDFS，是一個(gè)分布式文件系統(tǒng)。它是谷歌的GoogleFileSystem（GFS）提出之后，DougCutting受Google啟發(fā)而開發(fā)的一種類GFS文件系統(tǒng)。它有一定高度的容錯(cuò)性，而且提供了高吞吐量的數(shù)據(jù)訪問，非常適合大規(guī)模數(shù)據(jù)集上的應(yīng)用。HDFS提供了一個(gè)高容錯(cuò)性和高吞吐量的海量數(shù)據(jù)存儲(chǔ)解決方案。的整個(gè)架構(gòu)中，HDFS在MapReduce任務(wù)處理過程中提供了對(duì)文件操作和存儲(chǔ)等的支持，MapReduce在HDFS基礎(chǔ)上實(shí)現(xiàn)了任務(wù)的分發(fā)、跟蹤和執(zhí)行等工作，并收集結(jié)果，兩者相互作用，共同完成了Hadoop分布式集群的主要任務(wù)。HBaseHBase是一種構(gòu)建在HDFS之上的分布式、面向列族的存儲(chǔ)系統(tǒng)。在需要實(shí)時(shí)讀寫并隨機(jī)訪問超大規(guī)模數(shù)據(jù)集等場景下，HBase目前是市場上主流的技術(shù)選擇。HBase技術(shù)來源于Google論文《Bigtable：一個(gè)結(jié)構(gòu)化數(shù)據(jù)的分布式存儲(chǔ)系統(tǒng)》。如同Bigtable利用了GoogleFileSystem提供的分布式數(shù)據(jù)存儲(chǔ)方式一樣，HBase在HDFS之上提供了類似于Bigtable的能力。HBase解決了傳統(tǒng)數(shù)據(jù)庫的單點(diǎn)性能極限。實(shí)際上，傳統(tǒng)的數(shù)據(jù)庫解決方案，尤其是關(guān)系型數(shù)據(jù)庫也可以通過復(fù)制和分區(qū)的方法來提高單點(diǎn)性能極限，但這些都是后知后覺的，安裝和維護(hù)都非常復(fù)雜。而HBase從另一個(gè)角度處理伸縮性問題，即通過線性方式從下到上增加節(jié)點(diǎn)來進(jìn)行擴(kuò)展。HBase不是關(guān)系型數(shù)據(jù)庫，也不支持SQL，其中的表一般有這樣的特點(diǎn)。大：一個(gè)表可以有上億行、上百萬列。面向列：面向列表（簇）的存儲(chǔ)和權(quán)限控制，列（簇）獨(dú)立檢索。稀疏：為空（NULL）的列并不占用存儲(chǔ)空間，因此表可以設(shè)計(jì)得非常稀疏。一張表中不同的行可以有截然不同的列。單元格插入時(shí)的時(shí)間戳。數(shù)據(jù)類型單一：HBase中的數(shù)據(jù)都是字符串，沒有類型。數(shù)據(jù)應(yīng)用主要技術(shù)數(shù)據(jù)有很多種應(yīng)用方式，如固定報(bào)表、即時(shí)分析、數(shù)據(jù)服務(wù)、數(shù)據(jù)分析、數(shù)據(jù)挖掘和機(jī)器學(xué)習(xí)等。下面挑選典型的即時(shí)分析Drill框架、數(shù)據(jù)分析R語言、機(jī)器學(xué)習(xí)TensorFlow框架進(jìn)行介紹。DrillApacheDrill是一個(gè)開源實(shí)時(shí)大數(shù)據(jù)分布式查詢引擎，目前已經(jīng)成為Apache的頂級(jí)項(xiàng)目。Drill是開源版本的GoogleDremel。Dremel是Google的“交互式”數(shù)據(jù)分析系統(tǒng)，可以組建成規(guī)模上千的集群，處理PB級(jí)別的數(shù)據(jù)。MapReduce處理數(shù)據(jù)一般在分鐘甚至小時(shí)級(jí)別，而Dremel將處理時(shí)間縮短到秒級(jí)，即Drill是對(duì)MapReduce的有力補(bǔ)充。Dremel作為GoogleBigQuery的報(bào)表引擎，獲得了很大的成功。Drill兼容ANSISQL語法作為接口，支持對(duì)本地文件、HDFS、Hive、HBase、MongeDB作為存儲(chǔ)的數(shù)據(jù)查詢，文件格式支持Parquet、CSV、TSV以及JSON這種無模式（schema-free）的數(shù)據(jù)。所有這些數(shù)據(jù)都可以像使用傳統(tǒng)數(shù)據(jù)庫的表查詢一樣進(jìn)行快速實(shí)時(shí)查詢。Drill于2014年年底成為Apache的頂級(jí)項(xiàng)目，旨在為基于Hadoop應(yīng)用的開發(fā)者和BI分析人員的工作效率帶來巨大提升。R語言R是一種開源的數(shù)據(jù)分析解決方案，其實(shí)市面上也有很多優(yōu)秀的統(tǒng)計(jì)和制圖軟件，如SAS、SPSS和Stata等。那么為什么R變得這么流行，成了很多數(shù)據(jù)分析師的主要工具呢？原因如下。R帶有許多模塊和內(nèi)嵌統(tǒng)計(jì)函數(shù)，安裝好后可以直接實(shí)現(xiàn)許多常用的統(tǒng)計(jì)功能。R是一種可編程的語言。作為一個(gè)開放的統(tǒng)計(jì)編程環(huán)境，R前大多數(shù)最新的統(tǒng)計(jì)方法和技術(shù)都可以在R中直接得到。R具有很強(qiáng)的互動(dòng)性。除了圖形輸出是在另外的窗口，它的輸入/輸出都是在同一個(gè)窗口功能，可以隨時(shí)再現(xiàn)、編輯、修改以滿足用戶的需要，輸出的圖形可以直接保存為JPG、BMP、PNG等圖片格式，還可以直接保存為PDF文件。此外，R與其他編程語言和數(shù)據(jù)庫之間有很好的接口。TensorFlow隨著大數(shù)據(jù)時(shí)代和人工智能熱潮的到來，數(shù)據(jù)已經(jīng)不僅僅局限在“看”，數(shù)據(jù)和算法已經(jīng)是生產(chǎn)系統(tǒng)的一部分，眾多的開源機(jī)器學(xué)習(xí)平臺(tái)和深度學(xué)習(xí)平臺(tái)紛紛出現(xiàn)，而TensorFlow無疑是目前最為流行的一個(gè)。TensorFlow是一個(gè)非常靈活的框架，它能夠運(yùn)行在個(gè)人電腦或者服務(wù)器的單個(gè)/多個(gè)CPU和GPU上，甚至是移動(dòng)設(shè)備上。TensorFlow最早是Google大腦團(tuán)隊(duì)為了研究機(jī)器學(xué)習(xí)和深度神經(jīng)網(wǎng)絡(luò)而開發(fā)的，但后來發(fā)現(xiàn)這個(gè)系統(tǒng)足夠通用，能夠支持更加廣泛的應(yīng)用，于是將其開源。TensorFlow是基于數(shù)據(jù)流圖的處理框架，TensorFlow節(jié)點(diǎn)表示數(shù)學(xué)運(yùn)算（mathematicaloperations），邊表示運(yùn)算節(jié)點(diǎn)之間的數(shù)據(jù)交互。TensorFlow從字面意義上來講有兩層含義：第一層含義，Tensor代表的是節(jié)點(diǎn)之間傳遞的數(shù)據(jù)，通常這個(gè)數(shù)據(jù)是一個(gè)多維度矩陣（multidimensionaldataarrays）或者一維向量；第二層含義，F(xiàn)low指的是數(shù)據(jù)流，形象理解就是數(shù)據(jù)按照流的形式進(jìn)入數(shù)據(jù)運(yùn)算圖的各個(gè)節(jié)點(diǎn)。數(shù)據(jù)相關(guān)從業(yè)者和角色大數(shù)據(jù)時(shí)代，數(shù)據(jù)已經(jīng)變?yōu)樯a(chǎn)資料，但是數(shù)據(jù)真正從生產(chǎn)資料變成生產(chǎn)力變現(xiàn)必須借助專業(yè)數(shù)據(jù)人員的幫助。下面結(jié)合數(shù)據(jù)流程圖介紹數(shù)據(jù)相關(guān)的主要從業(yè)者和角色。數(shù)據(jù)平臺(tái)開發(fā)、運(yùn)維工程師數(shù)據(jù)的埋點(diǎn)、采集傳輸、存儲(chǔ)處理，乃至后續(xù)的分析、挖掘、數(shù)據(jù)服務(wù)等都離不開專業(yè)平臺(tái)和工具的支持。而這些正是數(shù)據(jù)平臺(tái)開發(fā)工程師和數(shù)據(jù)平臺(tái)運(yùn)維工程師的職責(zé)。數(shù)據(jù)平臺(tái)開發(fā)工程師以及數(shù)據(jù)平臺(tái)運(yùn)維工程師負(fù)責(zé)開發(fā)并運(yùn)維專門的埋點(diǎn)工具、專門的數(shù)據(jù)同步工具、離線計(jì)算平臺(tái)（如Hadoop、Hive等）、流計(jì)算平臺(tái)（如Storm、Spark、Flink等）、數(shù)據(jù)存儲(chǔ)工具和平臺(tái)（如HBase、MySQL、Redis等），乃至分析師使用的數(shù)據(jù)分析平臺(tái)和算法工程師使用的機(jī)器學(xué)習(xí)平臺(tái)等。這些專業(yè)性的支撐平臺(tái)是構(gòu)建數(shù)據(jù)平臺(tái)的基礎(chǔ)設(shè)施，也直接關(guān)系著最終公司數(shù)據(jù)平臺(tái)的成敗、成本、效率和穩(wěn)定性。Hive、Spark、HBase、Kafka以及近一兩年的Flink、Beam等，諸多開源數(shù)據(jù)框架些技術(shù)，知道其后臺(tái)原理和適用場合，然后合理利用這些技術(shù)，達(dá)到構(gòu)建數(shù)據(jù)平臺(tái)的目的。業(yè)的各種數(shù)據(jù)也都存儲(chǔ)于云上，基于云計(jì)算的大數(shù)據(jù)平臺(tái)工具也自然而然地快速得到發(fā)展。主流的國內(nèi)外云計(jì)算公司（如阿里云、亞馬遜、微軟、Google等）都提供了云端的數(shù)據(jù)處理平臺(tái)和工具。隨著企業(yè)IT系統(tǒng)的上云，筆者認(rèn)為未來云端的數(shù)據(jù)平臺(tái)和工具將成為主流。數(shù)據(jù)開發(fā)、運(yùn)維工程師數(shù)據(jù)開發(fā)、運(yùn)維工程師是本書主要面對(duì)的對(duì)象，也是一般企業(yè)里構(gòu)建數(shù)據(jù)平臺(tái)的中堅(jiān)力量。工程師和后端開發(fā)工程師確定數(shù)據(jù)接口，從而將數(shù)據(jù)分析需求落地。線和實(shí)時(shí)數(shù)據(jù)同步工具來采集與同步數(shù)據(jù)。據(jù)倉庫中。務(wù)。質(zhì)量和一致的?？趶饺绾?？數(shù)據(jù)質(zhì)量如何？務(wù)人員，是使用數(shù)據(jù)的窗口和中樞。保存和穩(wěn)定可靠。數(shù)據(jù)分析工程師數(shù)據(jù)分析工程師是企業(yè)和公司“看”數(shù)據(jù)的主要窗口。隨著數(shù)據(jù)化運(yùn)營思想以及數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品開發(fā)的日益深入，數(shù)據(jù)分析工程師在一個(gè)公司或項(xiàng)目中的地位越來越重要。數(shù)據(jù)分析工程師需要將公司的業(yè)務(wù)運(yùn)營報(bào)表化，并抽取出關(guān)鍵運(yùn)營指標(biāo)給公司和部門管理人員做決策參考，以監(jiān)控日常公司和部門的運(yùn)營情況。數(shù)據(jù)分析工程師也需要給產(chǎn)品的優(yōu)化提供數(shù)據(jù)支持，并用數(shù)據(jù)驗(yàn)證產(chǎn)品經(jīng)理的產(chǎn)品改進(jìn)效果。數(shù)據(jù)分析工程師是業(yè)務(wù)和數(shù)據(jù)的橋梁，數(shù)據(jù)分析工程師不但要了解數(shù)據(jù)，而且必須非常熟悉業(yè)務(wù)。此外，數(shù)據(jù)分析工程師還必須具有很強(qiáng)的表達(dá)能力和總結(jié)能力，能將關(guān)于業(yè)務(wù)的洞察以恰當(dāng)?shù)姆绞角逦髁说貍鬟f給決策人員、業(yè)務(wù)人員和產(chǎn)品人員，供決策和運(yùn)營分析使用。數(shù)據(jù)分析工程師也是數(shù)據(jù)開發(fā)工程師最為緊密的合作伙伴之一。算法工程師算法工程師使一個(gè)公司和企業(yè)應(yīng)用數(shù)據(jù)的能力不局限在“看”和分析上，而是能夠直接變現(xiàn)應(yīng)用在生產(chǎn)系統(tǒng)和產(chǎn)品上。比如Google的PageRank算法，正是有了PageRank算法的發(fā)明，才使得網(wǎng)頁重要性排名變成可以工程化的現(xiàn)實(shí)，也才奠定了Google搜索引擎和Google公司的成功基礎(chǔ)。這樣的例子還有很多，比如淘寶的“千人千面”個(gè)性化推薦系統(tǒng)，其中的推薦算法大大提高了用戶的轉(zhuǎn)化率，直接提高了整個(gè)網(wǎng)站的GMV，也直接帶來了經(jīng)濟(jì)效益，目前推薦系統(tǒng)已經(jīng)成為絕大多數(shù)電子商務(wù)網(wǎng)站的標(biāo)配，而這都離不開后臺(tái)算法工程師的直接貢獻(xiàn)。并不是每個(gè)算法工程師都要發(fā)明算法，但他們需要熟悉常見的各種算法并了解其適用場合，需要查閱文獻(xiàn)和論文，時(shí)刻關(guān)注業(yè)界進(jìn)展，并將它們應(yīng)用在業(yè)務(wù)實(shí)踐中。算法工程師必須具有一定的編程和工程能力，能夠?qū)?gòu)建的算法用代碼實(shí)現(xiàn)，并在數(shù)據(jù)集上測試驗(yàn)證，然后根據(jù)效果進(jìn)行相應(yīng)的算法調(diào)整、參數(shù)調(diào)優(yōu)等，如此反復(fù)，這就構(gòu)成了算法工程師日常的主要工作。業(yè)務(wù)人員一個(gè)公司和部門的分析師人數(shù)是有限的，固定每日運(yùn)行的報(bào)表也是有局限性的，業(yè)務(wù)人員經(jīng)常發(fā)現(xiàn)自己的數(shù)據(jù)分析需求處于分析師排期甚至無法支持的境地，這個(gè)問題的最終解決方法是業(yè)務(wù)人員自己具備數(shù)據(jù)分析的能力。隨著自助式數(shù)據(jù)分析工具的日益成熟，人人都可以成為數(shù)據(jù)分析師！從數(shù)據(jù)平臺(tái)的角度來講，數(shù)據(jù)平臺(tái)團(tuán)隊(duì)?wèi)?yīng)該提供自助式數(shù)據(jù)分析工具，賦能給每個(gè)業(yè)務(wù)接口人或者業(yè)務(wù)分析人員，因?yàn)闃I(yè)務(wù)團(tuán)隊(duì)才是最了解自己業(yè)務(wù)的，如果有了自助式分析工具的幫助并具備了一定的數(shù)據(jù)分析能力，對(duì)于業(yè)務(wù)人員來說，無疑是如虎添翼的。本章小結(jié)本章主要從整體上對(duì)數(shù)據(jù)進(jìn)行了概述，包括數(shù)據(jù)從產(chǎn)生到消費(fèi)的四大過程：數(shù)據(jù)產(chǎn)生、數(shù)據(jù)采集和傳輸、數(shù)據(jù)存儲(chǔ)處理以及數(shù)據(jù)應(yīng)用，每一個(gè)過程都涉及很多的技術(shù)、開源框架、工具和平臺(tái)，比如離線的主要數(shù)據(jù)處理技術(shù)是基于HadoopMapReduce的Hive，而Hive是一種SQLonHadoop的技術(shù)，但類似的SQLonHadoop技術(shù)和框架還有很多，比如Cloudera的Impala、Apache的Drill以及Presto和Shark等，初學(xué)者應(yīng)該以一種技術(shù)為主，輔助了解其他相關(guān)的技術(shù)，否則容易失去重點(diǎn)，從而不知所措。本章還對(duì)數(shù)據(jù)從業(yè)者的各種角色進(jìn)行了介紹，包括他們的主要職責(zé)以及日常工作內(nèi)容等。通過學(xué)習(xí)本章，讀者應(yīng)該對(duì)數(shù)據(jù)的概貌有了綱要性的認(rèn)識(shí)，下一章將把這些流程、技術(shù)和角色整合起來，也就是構(gòu)建數(shù)據(jù)平臺(tái)！第2章 數(shù)據(jù)平臺(tái)大圖什么是數(shù)據(jù)平臺(tái)呢？或者更時(shí)髦點(diǎn)，什么是大數(shù)據(jù)平臺(tái)呢？目前業(yè)界并沒有對(duì)數(shù)據(jù)平臺(tái)的精確定義，但通常所說的數(shù)據(jù)平臺(tái)主要包含三部分。數(shù)據(jù)相關(guān)的工具、產(chǎn)品和技術(shù)：比如批量數(shù)據(jù)采集傳輸?shù)腟qoopHadoop和Hive、實(shí)時(shí)流處理的Storm和Spark以及數(shù)據(jù)分析的R等。數(shù)據(jù)資產(chǎn)：不僅包含公司業(yè)務(wù)本身產(chǎn)生和沉淀的數(shù)據(jù)，還包括公司運(yùn)作產(chǎn)生的數(shù)據(jù)（財(cái)務(wù)、行政），以及從外界購買、交換或者爬蟲等而來的數(shù)據(jù)等。數(shù)據(jù)管理：有了數(shù)據(jù)工具，也有了數(shù)據(jù)資產(chǎn)，但是還必須對(duì)它們進(jìn)行管理才能讓數(shù)據(jù)產(chǎn)倉庫、數(shù)據(jù)建模、數(shù)據(jù)質(zhì)量、數(shù)據(jù)規(guī)范、數(shù)據(jù)安全和元數(shù)據(jù)管理等。上面是對(duì)數(shù)據(jù)平臺(tái)邏輯范疇上的一個(gè)劃分，實(shí)際上數(shù)據(jù)平臺(tái)從數(shù)據(jù)處理的時(shí)效性角度通常還是分為離線數(shù)據(jù)平臺(tái)和實(shí)時(shí)數(shù)據(jù)平臺(tái)。離線數(shù)據(jù)平臺(tái)通常以天為典型的數(shù)據(jù)處理周期，數(shù)據(jù)延遲也是以天為單位。離線數(shù)據(jù)平臺(tái)的數(shù)據(jù)應(yīng)用主要以“看”為主，就目前業(yè)界的數(shù)據(jù)現(xiàn)狀來看，離線數(shù)據(jù)平臺(tái)還是數(shù)據(jù)平臺(tái)的主戰(zhàn)場。但是隨著大數(shù)據(jù)應(yīng)用的日益深入以及人工智能浪潮的興起，產(chǎn)品的智能化趨勢越來越明大，當(dāng)然也變得越來越主流，隨著Spark、Flink、Beam技術(shù)的發(fā)展，未來有一天也許將會(huì)顛覆離線數(shù)據(jù)平臺(tái)的技術(shù)和架構(gòu)。本章將主要介紹數(shù)據(jù)平臺(tái)，出于邏輯清晰以及技術(shù)相關(guān)性考慮，將主要從離線數(shù)據(jù)平臺(tái)、實(shí)時(shí)數(shù)據(jù)平臺(tái)以及數(shù)據(jù)管理三個(gè)方面來對(duì)數(shù)據(jù)平臺(tái)相關(guān)的概念和技術(shù)進(jìn)行介紹。本章是后續(xù)各章技術(shù)的一個(gè)總覽，因此請(qǐng)讀者務(wù)必仔細(xì)閱讀本章，確保對(duì)數(shù)據(jù)平臺(tái)的整體架構(gòu)和大圖做到心中有數(shù)。后續(xù)各章將會(huì)聚焦在各個(gè)具體的技術(shù)上。離線數(shù)據(jù)平臺(tái)的架構(gòu)、技術(shù)和設(shè)計(jì)者一個(gè)月的銷售趨勢如何？哪些商品熱銷？哪些商品銷售不佳？哪些客戶在買我們的產(chǎn)務(wù)策略和打法，如此反復(fù)，形成閉環(huán)，這就是數(shù)據(jù)化運(yùn)營的基本思路。品決策。這類分析和“看”的需求正是離線數(shù)據(jù)平臺(tái)所擅長的，這類分析性的需求，數(shù)據(jù)的時(shí)效性并類問題。離線數(shù)據(jù)平臺(tái)是構(gòu)建公司和企業(yè)數(shù)據(jù)平臺(tái)的根本和基礎(chǔ)，也是目前數(shù)據(jù)平臺(tái)的主戰(zhàn)場，因此先來介紹離線數(shù)據(jù)平臺(tái)的有關(guān)核心概念和技術(shù)。離線數(shù)據(jù)平臺(tái)的整體架構(gòu)首先給出離線數(shù)據(jù)平臺(tái)的整體架構(gòu)大圖（見圖2-1），使讀者對(duì)離線數(shù)據(jù)平臺(tái)有全局性的認(rèn)識(shí)。離線數(shù)據(jù)平臺(tái)通常和Hadoop、Hive、數(shù)據(jù)倉庫、ETL、維度建模、數(shù)據(jù)公共層等聯(lián)系在一起。在大數(shù)據(jù)以及Hadoop沒有出現(xiàn)之前，離線數(shù)據(jù)平臺(tái)就是數(shù)據(jù)倉庫，數(shù)據(jù)部門也就是數(shù)據(jù)倉庫部門。即使在今天，在很多對(duì)數(shù)據(jù)相關(guān)概念和技術(shù)沒有較多了解的人看來，數(shù)據(jù)部門還是數(shù)據(jù)倉庫部門。Hadoop出現(xiàn)之前，數(shù)據(jù)倉庫的主要處理技術(shù)是商業(yè)化數(shù)據(jù)庫，比如微軟的SQLServer、甲骨文的Oracle、IBM的DB2等。隨著大數(shù)據(jù)的興起以及數(shù)據(jù)量的持續(xù)爆炸和指數(shù)級(jí)別增長，Hadoop以及MapReduce、Hive等大數(shù)據(jù)處理技術(shù)才得到越來越廣泛的應(yīng)用和接受。其實(shí)上面大圖中的Hadoop模塊也可以用商業(yè)化的工具替代，比如微軟的SQLServer、甲骨文的Oracle等關(guān)系數(shù)據(jù)庫，也可以用MPP架構(gòu)的Teradata、HPVertica、EMCGreenplum等分析性數(shù)據(jù)庫（MPP架構(gòu)也是分布式的分析型數(shù)據(jù)庫，但是和Hadoop相比，通?；诎嘿F硬件而且不可線性擴(kuò)展），實(shí)際上目前很多公司出于各種原因也正是采用這樣的方案，但是從當(dāng)前的技術(shù)現(xiàn)狀以及未來的技術(shù)發(fā)展來看，筆者認(rèn)為可線性擴(kuò)展Hadoop或者類Hadoop方案將會(huì)是主流和發(fā)展方向，因此本文主要基于Hadoop來介紹離線數(shù)據(jù)平臺(tái)。圖2-1 離線數(shù)據(jù)平臺(tái)的整體架構(gòu)大圖離線數(shù)據(jù)平臺(tái)的另一個(gè)關(guān)鍵技術(shù)是數(shù)據(jù)的建模，目前采用最為廣泛也最為大家認(rèn)同的是維度建模技術(shù)。此外，離線數(shù)據(jù)內(nèi)容建設(shè)出于最佳實(shí)踐，通常還會(huì)對(duì)精心加工后的數(shù)據(jù)進(jìn)行分層（ODS原始數(shù)據(jù)層、DWD明細(xì)數(shù)據(jù)層、DWS匯總層、ADS集市數(shù)據(jù)層等），本章也將對(duì)此進(jìn)行介紹。數(shù)據(jù)倉庫技術(shù)離線數(shù)據(jù)平臺(tái)是和數(shù)據(jù)倉庫的產(chǎn)生和發(fā)展緊密聯(lián)系在一起的，因此首先介紹數(shù)據(jù)倉庫的有關(guān)概念。OLTP和OLAP數(shù)據(jù)倉庫是隨著數(shù)據(jù)分析的需求逐漸發(fā)展起來的，最初的數(shù)據(jù)分析和報(bào)表都是基于業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫完成的，也就是OLTP數(shù)據(jù)庫，如商業(yè)性的Oracle、MSSQLServer和開源的MySQL等關(guān)系數(shù)據(jù)庫。OLTP的全稱是OnlineTransactionProcessing，顧名思義，OLTP數(shù)據(jù)庫主要用來進(jìn)行事務(wù)處理，比如新增一個(gè)訂單、修改一個(gè)訂單、查詢一個(gè)訂單和作廢一個(gè)訂單等。OLTP數(shù)據(jù)庫最核心的需求是單條記錄的高效快速處理，索引技術(shù)、分庫分表等最根本的訴求就是解決此問題。而這個(gè)和數(shù)據(jù)分析的需求是天然相反的，數(shù)據(jù)分析通常需要訪問大量的數(shù)據(jù)，單條數(shù)據(jù)的分析沒有任何意義。數(shù)據(jù)分析不僅需要訪問大量的數(shù)據(jù)，還要對(duì)其進(jìn)行頻繁的統(tǒng)計(jì)和查供數(shù)據(jù)分析人員使用是自然而然的選擇。解決了對(duì)生產(chǎn)庫的影響問題后，OLTP數(shù)據(jù)庫管理員很快發(fā)現(xiàn)備庫和復(fù)制庫還是不能滿足通常又是并發(fā)地全表掃描會(huì)造成OLTP數(shù)據(jù)庫響應(yīng)異常緩慢甚至宕機(jī)，必須有新的理論支撐和技術(shù)突破才能夠滿足這些分析請(qǐng)求。于是OLAP數(shù)據(jù)庫應(yīng)運(yùn)而生，它是專門的分析型數(shù)據(jù)庫，是為了滿足分析人員的統(tǒng)計(jì)分析需求而發(fā)展起來的。OLAP數(shù)據(jù)庫本身就能夠處理和統(tǒng)計(jì)大量的數(shù)據(jù)，而且不像OLTP數(shù)據(jù)庫需要考慮數(shù)據(jù)的增刪改查和并發(fā)鎖控制等。OLAP數(shù)據(jù)一般只需要處理數(shù)據(jù)查詢請(qǐng)求，數(shù)據(jù)都是批量導(dǎo)入的，因此通過列存儲(chǔ)、列壓縮和位圖索引等技術(shù)可以大大加快響應(yīng)請(qǐng)求的速度。OLTP和OLAP數(shù)據(jù)庫的簡單對(duì)比見表2-1，最核心的還是OLTP專注于單條記錄的處理，而OLAP專注于滿足分析人員大量數(shù)據(jù)的分析和統(tǒng)計(jì)。表2-1 OLTP和OLAP數(shù)據(jù)庫的簡單對(duì)比分析型數(shù)據(jù)庫專門分析型數(shù)據(jù)庫的出現(xiàn)標(biāo)志著數(shù)據(jù)倉庫由學(xué)術(shù)和概念階段正式進(jìn)入工業(yè)實(shí)用階段。國際大廠也紛紛推出了商業(yè)性的MPP或者類MPP架構(gòu)的數(shù)據(jù)倉庫產(chǎn)品，有代表性的為OracleExadata、天睿公司的Teradata、IBM收購的Netezza、EMC公司的Greenplum、惠普公司的HPVertica等。其中的領(lǐng)導(dǎo)者為Teradata，Teradata數(shù)據(jù)倉庫在企業(yè)級(jí)數(shù)據(jù)倉庫市場尤其金融、電信等中占有絕對(duì)的優(yōu)勢，也是最為高端、穩(wěn)定和成熟的數(shù)據(jù)倉庫產(chǎn)品。這些國際大廠不僅僅提供數(shù)據(jù)倉庫軟件和數(shù)據(jù)庫，隨著企業(yè)對(duì)數(shù)據(jù)和數(shù)據(jù)分析的日益重視，相關(guān)的IT預(yù)算越來越大，一站式解決方案和產(chǎn)品“一體機(jī)”應(yīng)運(yùn)而生。一體機(jī)不僅包含機(jī)是軟硬件一體化的解決方案型產(chǎn)品，可以做到開箱即用和一鍵部署。數(shù)據(jù)倉庫產(chǎn)品面對(duì)的主要是分析師和業(yè)務(wù)分析人員對(duì)大數(shù)據(jù)集的統(tǒng)計(jì)和聚合操作，其架構(gòu)、設(shè)計(jì)和原理和傳統(tǒng)數(shù)據(jù)庫產(chǎn)品（OLTP數(shù)據(jù)庫）截然不同。通常來說，數(shù)據(jù)倉庫產(chǎn)品一定是分布式的，但是其和OLTP數(shù)據(jù)庫的分布式要解決的問題有著明顯的不同。OLTP據(jù)庫的分布式（如分庫分表等技術(shù)）的是把所有用戶請(qǐng)求均勻分布到每個(gè)節(jié)點(diǎn)上，而OLTP的分布式是將用戶單次對(duì)大數(shù)據(jù)集的請(qǐng)求任務(wù)分配到各個(gè)節(jié)點(diǎn)上獨(dú)立計(jì)算然后再進(jìn)行匯總返回給用戶。此外，OLAP數(shù)據(jù)庫一般采用列式存儲(chǔ)，而OLTP通常采用行式存儲(chǔ)。所謂列式存儲(chǔ)就是縮和解壓縮，磁盤的I/O會(huì)大大減少。列存儲(chǔ)非常適合大數(shù)據(jù)量統(tǒng)計(jì)查詢的應(yīng)用場景，因?yàn)榉治鼋y(tǒng)計(jì)常常是針對(duì)某列或某些列的，列存儲(chǔ)的數(shù)據(jù)庫產(chǎn)品只需讀出對(duì)應(yīng)列并處理即可，而不是讀出整個(gè)表的所有行進(jìn)行處理。Hadoop數(shù)據(jù)倉庫在Hadoop出現(xiàn)以前及其還不太成熟和完善的階段，商業(yè)性的數(shù)據(jù)倉庫產(chǎn)品（如OracleExadata、天睿公司的Teradata、微軟的SQLServer、IBM的Netezza、EMC公司的Greenplum、惠普公司的HPVertica等）在企業(yè)數(shù)據(jù)分析和數(shù)據(jù)倉庫領(lǐng)域占據(jù)了主導(dǎo)地位。但是隨著這些年Hadoop的完善和Hadoop生態(tài)系統(tǒng)的崛起，短短幾年間，基于Hadoop的數(shù)據(jù)倉庫已經(jīng)完全占據(jù)了主賽道，尤其是在互聯(lián)網(wǎng)公司內(nèi)，基于Hadoop的數(shù)據(jù)倉庫基本是標(biāo)配。Hadoop的內(nèi)在技術(shù)基因決定了基于Hadoop的數(shù)據(jù)倉庫方案（目前主要是Hive）非常容易擴(kuò)展（可以很容易地增加節(jié)點(diǎn)，把數(shù)據(jù)處理能力從GB、TB擴(kuò)展PB甚至EB），成本也非常低廉（不用商業(yè)昂貴的服務(wù)器和存儲(chǔ)，只需要普通的硬件即可，Hadoop框架會(huì)進(jìn)行容錯(cuò)處理），這兩點(diǎn)也是Hadoop在互聯(lián)網(wǎng)公司內(nèi)日益流行的關(guān)鍵因素。試想一下，如果騰訊、阿里巴巴、百度把它們海量的數(shù)據(jù)存儲(chǔ)在商業(yè)性的數(shù)據(jù)倉庫產(chǎn)品（如Teradata、Oracle、MSSQLServer）內(nèi)，首先不論這些商業(yè)性的數(shù)據(jù)倉庫產(chǎn)品技術(shù)上是否能夠支持，但是費(fèi)用和成本就是一筆非常大的開銷，還不論因數(shù)據(jù)量增大需要商業(yè)數(shù)據(jù)產(chǎn)品增加節(jié)點(diǎn)所帶來的管理和維護(hù)開銷。實(shí)際上，國外的Facebook和國內(nèi)的BAT初始也是基于商業(yè)的數(shù)據(jù)倉庫解決方案來建設(shè)數(shù)據(jù)倉庫的，后來它們無一不轉(zhuǎn)向了基于Hadoop和類Hadoop的數(shù)據(jù)倉庫解決方案。基于Hadoop的數(shù)據(jù)倉庫解決方案，尤其是Hive，面臨最大的挑戰(zhàn)是數(shù)據(jù)查詢延遲（Hive的延遲一般是在分鐘級(jí)，取決于HiveSQL的復(fù)雜度和要處理的工作量，很多時(shí)候甚至需要運(yùn)行幾個(gè)小時(shí)。當(dāng)然，對(duì)于簡單的以及小數(shù)據(jù)量的HiveSQL，也可能幾秒鐘就返回結(jié)果）。由于Hive是翻譯為MapReduce任務(wù)后在Hadoop集群執(zhí)行的，而Hadoop是一個(gè)批處理系統(tǒng)，所以HiveSQL是高延遲的，不但翻譯成的MapReduce任務(wù)執(zhí)行延遲高，任務(wù)提交和處理過程中也會(huì)消耗時(shí)間。因此，即使Hive處理的數(shù)據(jù)集非常?。ū热鐜譓B），在執(zhí)行時(shí)也會(huì)出現(xiàn)延遲現(xiàn)象。但是相比其根植于Hadoop的近似線性的可擴(kuò)展性、低廉的成本和內(nèi)在容錯(cuò)等特性，這些都不是問題，都是隨著技術(shù)的發(fā)展可以完善和解決的，或者業(yè)務(wù)可以承受的。大數(shù)據(jù)和云計(jì)算是未來，未來的業(yè)務(wù)系統(tǒng)也都會(huì)執(zhí)行在云端，不管是私有云、公有云或者混合云。云端也決定了未來的架構(gòu)肯定是分布式的，能夠近似線性擴(kuò)展的，基于此，筆者認(rèn)為基于Hadoop和類Hadoop的數(shù)據(jù)倉庫解決方案未來將會(huì)成為主流和標(biāo)配，不管是對(duì)于互聯(lián)網(wǎng)公司來說，還是傳統(tǒng)企業(yè)來說。數(shù)據(jù)倉庫建模技術(shù)上一節(jié)介紹了搭建數(shù)據(jù)倉庫的三種主要方式：在傳統(tǒng)OLTP數(shù)據(jù)庫中搭建（如Oracle、MSSQLServer等）、在商業(yè)性數(shù)據(jù)倉庫產(chǎn)品中搭建（如MPP架構(gòu)的Teradata等）還有基于Hadoop來搭建等，但是不管在哪里搭建都面臨這樣的問題，例如，怎么組織數(shù)據(jù)倉庫中的數(shù)據(jù)？怎么組織才能使得數(shù)據(jù)的使用最為方便和便捷？怎么組織才能使得數(shù)據(jù)倉庫具有良好的可擴(kuò)展性和可維護(hù)性？從數(shù)據(jù)倉庫概念誕生以來，在數(shù)據(jù)倉庫領(lǐng)域，存在兩種得到廣泛認(rèn)可的方法來構(gòu)建數(shù)據(jù)倉庫。這兩派的代表人物分別是BillInmon和RalphKimball，BillInmon被稱為“數(shù)據(jù)倉庫之父”，而RalphKimball被稱為“商業(yè)智能之父”，他們的觀點(diǎn)主要公開發(fā)表于以下兩本經(jīng)典著作《TheDataWarehouseToolkit》（由RalphKimball和MargyRoss合著）和《CorporateInformationFactory》（由BillInmon、ClaudiaImhoff和RyanSousa合著）。從這兩種觀點(diǎn)誕生以來，圍繞“哪種架構(gòu)最佳”的爭論一致沒有休止，人們各抒己見，但是一直無法形成統(tǒng)一的結(jié)論，就像“哪種編程語言是最佳的編程語言”一樣，這可以稱為數(shù)據(jù)倉庫領(lǐng)域的“宗教戰(zhàn)爭”。本書并不打算給出一個(gè)結(jié)論，但是將會(huì)詳細(xì)介紹這兩種架構(gòu)并進(jìn)行對(duì)比，供用戶在不同的場合、針對(duì)不同的應(yīng)用場景選擇某個(gè)方法或者采用混合兩者的方法。RalphKimball建模方法論Kimball對(duì)數(shù)據(jù)倉庫的理論貢獻(xiàn)都與維度設(shè)計(jì)和建模有關(guān)。維度建模將客觀世界分為度量和上下文。度量是由機(jī)構(gòu)的業(yè)務(wù)過程以及支持它們的源系統(tǒng)來捕捉的，常以數(shù)值形式（如訂單金額、庫存數(shù)量等）出現(xiàn)，維度建模理論稱它為事實(shí)；事實(shí)由大量文本形式的上下文包圍著，而且這些上下文常被直觀地分割成多個(gè)獨(dú)立的邏輯塊，維度建模稱之為維，維描述了度量的5個(gè)W（When、Where、What、Who和Why）信息，比如什么時(shí)間下單、何種方式下單、買的什么、客戶是誰等。利用維度建模理論建模的Kimball數(shù)據(jù)倉庫常以星形架構(gòu)來呈現(xiàn)，如圖2-2所示，在星形架構(gòu)中間的是事實(shí)表，事實(shí)表周圍的則是各個(gè)角度的維度表。圖2-2 Kimball維度建模的星形架構(gòu)在維度建模中，由于星形模式緊貼業(yè)務(wù)過程，非常直觀和符合業(yè)務(wù)人員的視角，因此被廣泛和大量使用，星形模式也是Kimball對(duì)數(shù)據(jù)倉庫建模的一大貢獻(xiàn)。Kimball對(duì)數(shù)據(jù)倉庫建模理論的第二大貢獻(xiàn)是基于維度的“總線體系架構(gòu)”。實(shí)際項(xiàng)目中，企業(yè)的業(yè)務(wù)過程通常是多樣性和復(fù)雜的，存在于多個(gè)業(yè)務(wù)主題，總線體系架構(gòu)和一致性維度一起保證了多個(gè)主題的事實(shí)表和維度表能夠最終集成在一起，提供一致和唯一的口徑給業(yè)務(wù)人員。采用Kimball建模理論的數(shù)據(jù)倉庫體系架構(gòu)如圖2-3所示。圖2-3 采用Kimball建模理論的數(shù)據(jù)倉庫體系架構(gòu)可以看出，Kimball維度建模的主題以星形架構(gòu)為主，主題和主題之間則用一致性維度和企業(yè)總線體系架構(gòu)來保證數(shù)據(jù)倉庫的集成和一致性。BillInmon建模方法論在數(shù)據(jù)倉庫領(lǐng)域，BillInmon是第一個(gè)提出來OLAP和數(shù)據(jù)倉庫概念的人，所以被稱為“數(shù)據(jù)倉庫之父”。BillInmon撰寫了大量介紹其數(shù)據(jù)倉庫方法的文章，他認(rèn)為數(shù)據(jù)倉庫是“在企業(yè)管理和決策中面向主題的、集成的、與時(shí)間相關(guān)的、不可修改的數(shù)據(jù)集合”數(shù)據(jù)庫應(yīng)用不同的是，數(shù)據(jù)倉庫更像一種過程，對(duì)分布在企業(yè)內(nèi)部各處的業(yè)務(wù)數(shù)據(jù)的整合、加工和分析的過程，而不是一種可以購買的產(chǎn)品，這就是他所說的“企業(yè)信息化工廠”。圖2-4描述了BillInmon建模理論的企業(yè)級(jí)數(shù)據(jù)倉庫體系架構(gòu)。圖2-4 采用BillInmon建模理論的企業(yè)級(jí)數(shù)據(jù)倉庫體系架構(gòu)Inmon的企業(yè)信息化工廠包括源頭系統(tǒng)、準(zhǔn)備區(qū)、ETL、企業(yè)數(shù)據(jù)倉庫、數(shù)據(jù)集市等，而企業(yè)數(shù)據(jù)倉庫是企業(yè)信息化工廠的樞紐。不同于Kimball，Inmon認(rèn)為企業(yè)數(shù)據(jù)倉庫應(yīng)為原子數(shù)據(jù)的集成倉庫，應(yīng)該用第三范式和ER理論而非維度建模的事實(shí)表和維度表來建模。Inmon的企業(yè)信息化工廠涉及了“數(shù)據(jù)集市”的概念，所謂“集市”，就是部門級(jí)的數(shù)據(jù)倉庫。對(duì)于數(shù)據(jù)集市來說，Inmon的一致性。這樣帶來的問題是必須先有企業(yè)數(shù)據(jù)倉庫才可能開始建立部門級(jí)的數(shù)據(jù)集市，這是Inmon數(shù)據(jù)倉庫架構(gòu)和Kimball數(shù)據(jù)倉庫架構(gòu)的第二個(gè)主要不同。同時(shí)，Inmon也認(rèn)為應(yīng)該用Kimball的維度建模理論來構(gòu)建數(shù)據(jù)集市。數(shù)據(jù)倉庫建模實(shí)踐從上述對(duì)兩者數(shù)據(jù)架構(gòu)的介紹可以看出，Inmon的方法是一種由上而下（top-down）的數(shù)據(jù)倉庫構(gòu)建方法，其主張首先要對(duì)企業(yè)數(shù)據(jù)倉庫進(jìn)行總體規(guī)劃，并將不同的OLTP數(shù)據(jù)集中到面向主題、集成的、不易失的和時(shí)間變化的企業(yè)數(shù)據(jù)倉庫中。數(shù)據(jù)集市應(yīng)該是數(shù)據(jù)倉庫的子集，每個(gè)數(shù)據(jù)集市都是為獨(dú)立部門專門設(shè)計(jì)的。Kimball方法則相反，其是自下向上的（down-top）。Kimball認(rèn)為數(shù)據(jù)倉庫是一系列數(shù)據(jù)集市的集合，企業(yè)可以通過一致性的維度表和“企業(yè)總線架構(gòu)”來遞增式集成各個(gè)數(shù)據(jù)集市，從而構(gòu)建整個(gè)企業(yè)的數(shù)據(jù)倉庫。一句話總結(jié)它們的區(qū)別。Kimball：letpeoplebuildwhattheywantwhentheywantit，wewillintegratethemitallwhenandifweneedto.Inmon：don’tdoanythinguntilyouhavedesignedeverything.Inmon的方法部署和開發(fā)周期較長，但是容易維護(hù)而且高度集成；而Kimball的方法可以迅速響應(yīng)業(yè)務(wù)需求，快速構(gòu)建一個(gè)數(shù)據(jù)倉庫，但是后期集成和維護(hù)較為麻煩。沒有絕對(duì)的對(duì)與錯(cuò)，只有不同階段和不同場景下的利弊權(quán)衡。一般來說，在項(xiàng)目早期和互聯(lián)網(wǎng)領(lǐng)域，Kimball的方法更為實(shí)用和接地氣，因?yàn)樾枨笞兓欤尚б罂欤顿Y回報(bào)快。如果使用Inmon的方法，也許永遠(yuǎn)設(shè)計(jì)不出一個(gè)企業(yè)數(shù)據(jù)倉庫，因?yàn)闃I(yè)務(wù)一直在變，系統(tǒng)一直在變，數(shù)據(jù)一直在變，這種情況下，可以用Kimball的方法先建立數(shù)據(jù)集市，而后根據(jù)業(yè)務(wù)的進(jìn)展再沉淀出企業(yè)數(shù)據(jù)倉庫。而對(duì)于項(xiàng)目中后期或者其業(yè)務(wù)基本不變、不需要對(duì)短期投資回報(bào)率有很高要求的情況下，可以先設(shè)計(jì)企業(yè)數(shù)據(jù)倉庫，而后建立各個(gè)業(yè)務(wù)部門的數(shù)據(jù)集市。數(shù)據(jù)倉庫邏輯架構(gòu)設(shè)計(jì)離線數(shù)據(jù)倉庫通常基于維度建模理論來構(gòu)建，但是除此之外，離線數(shù)據(jù)倉庫通常還會(huì)從邏輯上進(jìn)行分層。數(shù)據(jù)倉庫的邏輯分層也是業(yè)界的最佳實(shí)踐。離線數(shù)據(jù)倉庫的邏輯分層主要是出于如下考慮。隔離性：用戶使用的應(yīng)該是數(shù)據(jù)團(tuán)隊(duì)精心加工后的數(shù)據(jù)，而不是來自于業(yè)務(wù)系統(tǒng)的原始的數(shù)據(jù)，非常容易理解和使用。好處之二是，如果上游業(yè)務(wù)系統(tǒng)發(fā)生變更甚至重構(gòu)（表結(jié)構(gòu)、字段、業(yè)務(wù)含義等），影響。性能和可維護(hù)性：專業(yè)的人做專業(yè)的事，數(shù)據(jù)分層使得數(shù)據(jù)的加工基本都在數(shù)據(jù)團(tuán)隊(duì)，任務(wù)，某層的數(shù)據(jù)加工出現(xiàn)問題，只需修復(fù)該層即可。必須基于一個(gè)明確的、公認(rèn)的口徑，此外表、字段以及指標(biāo)等也必須進(jìn)行規(guī)范。數(shù)據(jù)倉庫一般分為如下幾層。ODS層：數(shù)據(jù)倉庫源頭系統(tǒng)的數(shù)據(jù)表通常會(huì)原封不動(dòng)地存儲(chǔ)一份，這稱為ODS（OperationDataStore）層，ODS層也經(jīng)常會(huì)被稱為準(zhǔn)備區(qū)（stagingarea），它們是后續(xù)數(shù)據(jù)倉庫層（即基于Kimball維度建模生成的事實(shí)表和維度表層，以及基于這些事實(shí)表和明細(xì)表加工的匯總層數(shù)據(jù)）加工數(shù)據(jù)的來源，同時(shí)ODS者全量數(shù)據(jù)。DWD和DWS層：數(shù)據(jù)倉庫明細(xì)層（DataWarehouseDetail，DWD）和數(shù)據(jù)倉庫匯總層（DataWarehouseSummary，DWS）是數(shù)據(jù)平臺(tái)的主體內(nèi)容。DWD和DWS層的數(shù)據(jù)是ODS層數(shù)據(jù)經(jīng)過ETL清洗、轉(zhuǎn)換、加載生成的，而且它們通常都是基于Kimball的維度建模理論來構(gòu)建的，并通過一致性維度和數(shù)據(jù)總線來保證各個(gè)子主題的維度一致性。應(yīng)用層（ADS）：應(yīng)用層主要是各個(gè)業(yè)務(wù)方或者部門基于DWD和DWS建立的數(shù)據(jù)集市（DataMart，以下簡稱DM），數(shù)據(jù)集市DM是相對(duì)于DWD和DWS的數(shù)據(jù)倉庫（DataWarehouse，以下簡稱DW）來說的。一般來說，應(yīng)用層的數(shù)據(jù)來源于DW層，但原則上不允許直接訪問ODS層的。此外，相比DW層，應(yīng)用層只包含部門或者業(yè)務(wù)方自己關(guān)心的明細(xì)層和匯總層數(shù)據(jù)。采用上述ODS層→DW層→應(yīng)用層的數(shù)據(jù)倉庫邏輯分層架構(gòu)如圖2-5所示。圖2-5 數(shù)據(jù)倉庫邏輯分層架構(gòu)實(shí)時(shí)數(shù)據(jù)平臺(tái)的架構(gòu)、技術(shù)和設(shè)計(jì)離線數(shù)據(jù)平臺(tái)產(chǎn)出數(shù)據(jù)的周期一般是天，也就是說，今天看到的是昨天的數(shù)據(jù)，對(duì)于大部分的分析和“看”數(shù)據(jù)的場景來說，這種T+1的離線數(shù)據(jù)可以滿足業(yè)務(wù)分析的需求，但是隨著業(yè)務(wù)運(yùn)營日漸精細(xì)化，對(duì)數(shù)據(jù)的時(shí)效性要求越來越高，越來越多的業(yè)務(wù)場景需要馬上看到業(yè)務(wù)效果，尤其是在業(yè)務(wù)促銷活動(dòng)等（典型的如雙11大促、618大促等）場景下。更重要的是，隨著人工智能浪潮的興起，實(shí)時(shí)的數(shù)據(jù)已經(jīng)不是最好，而是必須。數(shù)據(jù)也不僅僅在分析和“看”，而是和算法一起成為生產(chǎn)業(yè)務(wù)系統(tǒng)的一部分。大數(shù)據(jù)和人工智能是天然的一對(duì)最佳搭檔，尤其是在實(shí)時(shí)數(shù)據(jù)方面。對(duì)于很多場景來說，實(shí)時(shí)數(shù)據(jù)訓(xùn)練的算法效果和離線數(shù)據(jù)訓(xùn)練的算法效果有著天壤之別，實(shí)時(shí)數(shù)據(jù)訓(xùn)練得到的算法用到的數(shù)據(jù)就是算法正式上線后輸入的數(shù)據(jù)，因此準(zhǔn)確性有保障，是算法工程師和業(yè)務(wù)的首選。而所有這些都必須借助于實(shí)時(shí)數(shù)據(jù)平臺(tái)。實(shí)時(shí)數(shù)據(jù)平臺(tái)近兩年越來越得到重視，盡管某些方面還不夠成熟，但是技術(shù)發(fā)展非常迅方面，當(dāng)然這一切還需時(shí)間來校驗(yàn)。實(shí)時(shí)數(shù)據(jù)平臺(tái)的整體架構(gòu)和離線數(shù)據(jù)平臺(tái)一樣，這里也首先給出實(shí)時(shí)數(shù)據(jù)平臺(tái)的整體架構(gòu)大圖（見圖2-6），使讀者對(duì)實(shí)時(shí)數(shù)據(jù)平臺(tái)有全局性的認(rèn)識(shí)和了解。圖2-6 實(shí)時(shí)數(shù)據(jù)平臺(tái)的整體架構(gòu)大圖實(shí)時(shí)數(shù)據(jù)平臺(tái)的支撐技術(shù)主要包含四個(gè)方面：實(shí)時(shí)數(shù)據(jù)采集（如Flume），消息中間件（如Kafka）、流計(jì)算框架（如Strom、Spark、Flink和Beam等），以及實(shí)時(shí)數(shù)據(jù)存儲(chǔ)（如列族存儲(chǔ)的HBase）。目前主流的實(shí)時(shí)數(shù)據(jù)平臺(tái)也都是基于這四個(gè)方面相關(guān)的技術(shù)搭建的。實(shí)時(shí)數(shù)據(jù)平臺(tái)首先要保證數(shù)據(jù)來源的實(shí)時(shí)性。數(shù)據(jù)來源通?？梢苑譃閮深悾簲?shù)據(jù)庫和日志文件。對(duì)于前者，業(yè)界的最佳實(shí)踐并不是直接訪問數(shù)據(jù)庫抽取數(shù)據(jù)，而是會(huì)直接采集數(shù)據(jù)庫變更日志[1]。數(shù)據(jù)采集工具（如Flume）采集的binlog事件，其產(chǎn)生速度和頻率通常取決于源頭系統(tǒng)。它和下游的實(shí)時(shí)數(shù)據(jù)處理工具（比如Storm、Spark、Flink等流計(jì)算框架和平臺(tái)）處理數(shù)據(jù)的速度通常是不匹配的。另外，實(shí)時(shí)數(shù)據(jù)處理通常還會(huì)有從某歷史時(shí)間點(diǎn)重啟以及多個(gè)實(shí)時(shí)任務(wù)都要使用同一源頭數(shù)據(jù)的需求，因此通常還會(huì)引入消息中間件來作為緩沖，從而達(dá)到實(shí)時(shí)數(shù)據(jù)采集和處理的適配。實(shí)時(shí)數(shù)據(jù)處理通常采用某種流計(jì)算處理框架，目前使用最為廣泛的是Storm（不僅指原生Storm，還包含其他類Storm框架如JStorm、StormTrident等）、Spark和Flink等。實(shí)時(shí)數(shù)據(jù)存儲(chǔ)根據(jù)下游數(shù)據(jù)使用的不同方式通常放在不同的數(shù)據(jù)存儲(chǔ)內(nèi)。對(duì)于數(shù)據(jù)在線服務(wù)（即數(shù)據(jù)使用方傳入某個(gè)業(yè)務(wù)ID，然后獲取到所有此ID的相關(guān)字段），通常放在HBase內(nèi)。對(duì)于實(shí)時(shí)數(shù)據(jù)大屏，通常放在某種關(guān)系數(shù)據(jù)庫（如MySQL）內(nèi)，有時(shí)為了提高性能并減輕對(duì)底層數(shù)據(jù)庫的壓力，還會(huì)使用緩存數(shù)據(jù)庫（如Redis）等。實(shí)時(shí)數(shù)據(jù)平臺(tái)最為核心的技術(shù)是流計(jì)算，因此下面重點(diǎn)介紹流計(jì)算的概念和技術(shù)。流計(jì)算技術(shù)流計(jì)算的開始流行和被大家所接受始于2011年左右誕生的Storm。Storm作為“實(shí)時(shí)的Hadoop”迅速被大家所知并接受。那么，什么是流計(jì)算呢？它和離線批量處理又有哪些區(qū)別呢？不同于離線批處理（如HadoopMapReduce），流計(jì)算有著下面典型的特征。算任務(wù)也需要始終運(yùn)行。觸發(fā)：不同于Hadoop發(fā)的。觸發(fā)是流計(jì)算一個(gè)非常重要的概念，在某些業(yè)務(wù)場景下，觸發(fā)消息的邏輯比較復(fù)雜，對(duì)流計(jì)算挑戰(zhàn)很大。延遲：很顯然，流計(jì)算必須能夠高效地、迅速地處理數(shù)據(jù)。不同于離線Hadoop任務(wù)至少有些特殊情況下才被接受。歷史數(shù)據(jù)：Hadoop離線任務(wù)如果發(fā)現(xiàn)歷史某天的數(shù)據(jù)有問題，通常很容易修復(fù)問題而且通常不會(huì)保存很久（一般幾天），一般只能從問題發(fā)現(xiàn)的時(shí)刻修復(fù)數(shù)據(jù)，歷史數(shù)據(jù)是無法通過流式方式來補(bǔ)的。從根源上講，流計(jì)算的實(shí)現(xiàn)機(jī)制目前有兩種處理方式：一種是模仿離線的批處理方式，也就是采用微批處理（即minibatch）。微批處理帶來了吞吐量的提升，但是相應(yīng)的數(shù)據(jù)延遲也會(huì)增大，基本在秒級(jí)和分鐘級(jí)，典型的技術(shù)是SparkStreaming。另一種是原生的消息數(shù)據(jù)，即處理單位是單條數(shù)據(jù)，早期原生的流計(jì)算技術(shù)延遲低（一般在幾十毫秒），但是數(shù)據(jù)吞吐量有限，典型的是原生的Storm框架，但是隨著Flink等技術(shù)的產(chǎn)生和發(fā)展，吞吐量也不再是問題。主要流計(jì)算開源框架Storm是最早的流計(jì)算技術(shù)和框架，也是目前最廣為所知的實(shí)時(shí)數(shù)據(jù)處理技術(shù)，但是實(shí)際上還有其他的開源流計(jì)算技術(shù)，如StormTrident、SparkStreaming、Samza、Flink、Beam等，商業(yè)性的技術(shù)還有GoogleMillWheel和亞馬遜的Kinesis等。除了這些五花八門的技術(shù)，流計(jì)算的另一個(gè)趨勢是開發(fā)語言不停向聲明式語言尤其是流計(jì)算SQL的發(fā)展。本章將不會(huì)深入上述具體的流計(jì)算技術(shù)，這些任務(wù)將在后續(xù)各章節(jié)中完成，但是這里將嘗試介紹這些技術(shù)的發(fā)展脈絡(luò)及其各自的特點(diǎn)。很多時(shí)候，技術(shù)平臺(tái)和框架都已經(jīng)選定，也就是說，一個(gè)數(shù)據(jù)開發(fā)人員，其實(shí)際工作的實(shí)時(shí)流計(jì)算技術(shù)可能已被選定，可能是上述技術(shù)其中的一種，但是作為一個(gè)合格的數(shù)據(jù)開發(fā)人員，還需要了解其他流計(jì)算技術(shù)及其優(yōu)缺點(diǎn)和適用場景等，做到心中有數(shù)。假設(shè)一個(gè)公司要選擇某種流計(jì)算技術(shù)，那么需要考慮哪些方面呢？從實(shí)際的項(xiàng)目實(shí)踐來看，需要考慮如下幾個(gè)方面。技術(shù)成熟度：即該流計(jì)算框架在工業(yè)界的實(shí)際應(yīng)用情況；該技術(shù)有沒有在生產(chǎn)環(huán)境和大否快速利用別人的經(jīng)驗(yàn)快速解決。性能：該技術(shù)是否能夠抗住現(xiàn)有的業(yè)務(wù)數(shù)據(jù)量，預(yù)留空間是多少，實(shí)時(shí)延遲是否能夠滿以到幾十毫秒。開發(fā)難度和速度：該技術(shù)是否提供高級(jí)的API，還是必須都從底層API構(gòu)建業(yè)務(wù)邏輯；底層API處理靈活，但是對(duì)開發(fā)人員的技能要求比較高，而且通常耗時(shí)較長，高級(jí)API（比如流計(jì)算SQL）的開發(fā)效率非常高，而且門檻低，但某些場景下SQL中需要綜合考慮?？删S護(hù)性：具體在流計(jì)算框架下，主要體現(xiàn)在狀態(tài)管理和容錯(cuò)性方面，比如任務(wù)失敗了、需要調(diào)優(yōu)或者業(yè)務(wù)邏輯更改升級(jí)了，需要暫停和重啟任務(wù)，流計(jì)算框架應(yīng)該支持從上一個(gè)狀態(tài)中恢復(fù)。可靠性：流計(jì)算的可靠性主要體現(xiàn)在流計(jì)算框架對(duì)atleastonce和exactlyonce的支持。atleastonce會(huì)丟失；exactlyonce的消息傳輸機(jī)制是每條消息有且只有一次，即消息傳輸既不會(huì)丟失也不會(huì)重復(fù)。下面從上述這些方面分別對(duì)主流的流計(jì)算框架進(jìn)行介紹。StormApacheStorm是大批量流式數(shù)據(jù)處理的先鋒，在Storm初期的宣傳中被稱為“實(shí)時(shí)的Hadoop”。Storm或者類Storm的流計(jì)算框架也是目前應(yīng)用最為廣泛和最流行的，目前國內(nèi)主要的互聯(lián)網(wǎng)公司最初基本都基于Storm搭建了自己的實(shí)時(shí)數(shù)據(jù)平臺(tái)。Storm是原生的流計(jì)算框架，數(shù)據(jù)一條一條被處理，所以其數(shù)據(jù)延遲可以非常低，基本在100ms之內(nèi)，調(diào)優(yōu)的情況下甚至可以到10ms。但是相應(yīng)地，代價(jià)就是處理性能，原生Storm的數(shù)據(jù)吞吐量一般，而且它不提供高級(jí)API，也不支持狀態(tài)的管理。數(shù)據(jù)可靠性方面，Storm不支持exactlyonce的處理，只支持實(shí)時(shí)消息的atleastonce處理。StormTrident正是由于原生Storm的上述缺點(diǎn)，導(dǎo)致了Trident的出現(xiàn)。Trident是對(duì)原生Storm的一個(gè)更高層次的抽象，其最大的特點(diǎn)是以minibatch的形式進(jìn)行流處理。同時(shí)，Trident簡化topology構(gòu)建過程，增加了窗口操作、聚合操作或者狀態(tài)管理等高級(jí)操作API。對(duì)應(yīng)于Storm提供的atmostonce可靠性，Trident還支持exactlyonce可靠性。但是微批處理引入、狀態(tài)管理等的支持也帶來了Trident數(shù)據(jù)延遲的增加，目前基于微批處理的流計(jì)算框架的延遲至少是在秒級(jí)，有些情況下甚至要到分鐘級(jí)。SparkStreamingSpark也是目前業(yè)界比較受歡迎也比較流行的實(shí)時(shí)數(shù)據(jù)處理方案，尤其對(duì)于采用Spark生態(tài)作為數(shù)據(jù)平臺(tái)解決方案的公司或者組織來說。從本質(zhì)上講，SparkStreaming也是基于微批處理的流計(jì)算框架，即它將源頭數(shù)據(jù)分成很小的批并以類似于離線batch的方式來處理這小部分?jǐn)?shù)據(jù)。不同于StormTrident的是，SparkStreaming微批處理框架底層依賴于SparkCore的RDD實(shí)現(xiàn)。如果實(shí)時(shí)數(shù)據(jù)架構(gòu)已經(jīng)在使用Spark，那么SparkStreaming是非常值得考慮的方案，但是需要記住其基于微批處理的局限性以及數(shù)據(jù)延遲的問題（一般至少是在秒級(jí)甚至分鐘級(jí)）。此外，Spark也有高級(jí)API，也支持流計(jì)算任務(wù)的狀態(tài)管理和exactlyonce可靠性機(jī)制。4.FlinkFlink項(xiàng)目開始得非常早，大概是在2008年，但是直到2016年才日漸受到重視并變成Apache的頂級(jí)項(xiàng)目。Flink是原生的流計(jì)算處理框架，提供高級(jí)API、狀態(tài)管理、exactlyonce可靠性等，同時(shí)數(shù)據(jù)處理吞吐量也很不錯(cuò)，從目前社區(qū)的發(fā)展來看，F(xiàn)link也非常有活力。此外，ApacheFlink是一個(gè)同時(shí)面向流處理和批處理的開源計(jì)算平臺(tái)，它能夠基于同一個(gè)Flink引擎，提供流處理和批處理兩種類型應(yīng)用的功能。在Flink中，批處理被當(dāng)作一種特殊的流處理，只是它的輸入數(shù)據(jù)流被定義為有界的而已。綜上所述，F(xiàn)link的流處理理念和設(shè)計(jì)非常不錯(cuò)，能滿足絕大多數(shù)的流計(jì)算應(yīng)用場景，因此目前很多人認(rèn)為它將成為未來主流的流計(jì)算框架。但是，目前Fli