從Android部門轉(zhuǎn)崗到數(shù)據(jù)智能中心已經(jīng)一年多，這段時(shí)間主要是知識接收的階段，精力也逐步放在大數(shù)據(jù)相關(guān)知識上，所以后續(xù)也不準(zhǔn)備更新Android對應(yīng)的博客了计贰。經(jīng)過一番踩坑，嘗試著從小白的角度對大數(shù)據(jù)進(jìn)行整體的講解蒂窒，也是對初期學(xué)習(xí)的總結(jié)躁倒，歡迎對大數(shù)據(jù)感興趣的童鞋品嘗荞怒。

一、前言

在正式介紹之前需要思考一下秧秉，為何我們要專門搭建Hadoop體系為首的大數(shù)據(jù)分析平臺褐桌，要知道一個(gè)生產(chǎn)環(huán)境的大數(shù)據(jù)平臺就像搭積木一樣，需要對使用形形色色的組件進(jìn)行構(gòu)建福贞，直接使用關(guān)系型數(shù)據(jù)庫(比如MySQL)豈不是更加方便快捷撩嚼，就此引出了以下概念：

1.1在線事務(wù)處理（OLTP, OnLine Transaction Processing）

這種模式對于從事后端的童鞋來說應(yīng)該很熟悉，因?yàn)橹苯由婕暗饺粘５臉I(yè)務(wù)挖帘，比如日常的用戶的交易行為：

• 注冊了一個(gè)賬號
• 用戶對商品下訂單
• 用戶進(jìn)行支付

這些操作一般要求數(shù)據(jù)庫進(jìn)行事務(wù)處理來保障數(shù)據(jù)的一致性， 而且還得要求客戶端查詢修改速度要盡可能的快恋技，也就是低延遲的讀取和寫入 —— 而不是批量處理作業(yè)（這些作業(yè)只能定期運(yùn)行拇舀，比如每天一次）。應(yīng)用程序通常使用索引通過某個(gè)鍵查找少量記錄進(jìn)行隨機(jī)訪問蜻底，再根據(jù)用戶的輸入插入或更新記錄骄崩。由于這些應(yīng)用程序是交互式的，因此訪問模式被稱為在線事務(wù)處理（OLTP, OnLine Transaction Processing）薄辅。

1.2在線分析處理（OLAP, OnLine Analytice Processing）

數(shù)據(jù)庫也開始越來越多地用于數(shù)據(jù)分析決策要拂，這些數(shù)據(jù)分析具有非常不同的訪問模式。通常站楚，分析查詢需要掃描大量記錄脱惰，比如上千萬條記錄，每個(gè)記錄只讀取幾列窿春，并計(jì)算匯總統(tǒng)計(jì)信息（如求平均值）拉一，而不是將原始數(shù)據(jù)返回給用戶。例如旧乞，如果您的數(shù)據(jù)是一個(gè)用戶的訂單表蔚润，那么分析查詢可能是：

• 這個(gè)月產(chǎn)品的銷售額？
• 最近運(yùn)營的推廣活動中有多少增收尺栖？
• 買A產(chǎn)品的用戶是否也會一起購買B嫡纠？

這些查詢通常由業(yè)務(wù)分析師編寫，并提供給幫助公司管理層做出更好決策（BI商業(yè)智能）的報(bào)告延赌。為了區(qū)分這種使用數(shù)據(jù)庫的事務(wù)處理模式除盏，它被稱為在線分析處理（OLAP, OnLine Analytice Processing）。

1.3數(shù)據(jù)倉庫

表1-1 比較事務(wù)處理和分析系統(tǒng)的特點(diǎn)

通過OLTP系統(tǒng)和OLAP對比分析屡贺，OLTP通常要保證高可用蠢棱、低延遲锌杀、數(shù)據(jù)一致性，這些日常業(yè)務(wù)系統(tǒng)對我們至關(guān)重要泻仙，一旦出現(xiàn)問題會對線上用戶造成較大的影響糕再，對公司的經(jīng)濟(jì)也會造成損失。因此公司通常不愿意讓業(yè)務(wù)分析人員在OLTP數(shù)據(jù)庫上運(yùn)行臨時(shí)分析查詢玉转，因?yàn)檫@些查詢需要掃描大部分?jǐn)?shù)據(jù)集突想，代價(jià)很昂貴且有風(fēng)險(xiǎn)，會影響到線上用戶正常使用究抓。
為了避免這種情況發(fā)生猾担，可以在單獨(dú)的數(shù)據(jù)庫上運(yùn)行分析任務(wù)，與線上業(yè)務(wù)分離開來刺下，這個(gè)單獨(dú)的數(shù)據(jù)庫被稱為數(shù)據(jù)倉庫（data warehouse）绑嘹。

如果僅僅這樣的話，數(shù)據(jù)倉庫（data warehouse）也可以通過關(guān)系型數(shù)據(jù)庫(例如MySQL)來實(shí)現(xiàn)橘茉，其提供的分庫分表功能也可以達(dá)到對大數(shù)據(jù)量進(jìn)行分析處理工腋，事實(shí)也正是如此，早期的商業(yè)分析系統(tǒng)(BI系統(tǒng))確實(shí)是基于關(guān)系型數(shù)據(jù)庫實(shí)現(xiàn)的畅卓。但是問題隨著時(shí)間推移逐漸暴露出來：

• 對于非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)的處理非常乏力擅腰，例如圖片、文本翁潘、音頻的存儲趁冈、分析。
• 為了保障數(shù)據(jù)安全唐础，機(jī)器性能要求比較高箱歧，而高端機(jī)器可能非常貴，如果分析的數(shù)據(jù)是低價(jià)值的話一膨，例如線上的用戶所有行為日志呀邢，性價(jià)比低。
• 當(dāng)數(shù)據(jù)量過大的時(shí)候豹绪，查詢速度極速下降价淌，性能出現(xiàn)瓶頸。
• 關(guān)系型數(shù)據(jù)庫為了保障數(shù)據(jù)的一致性有各種約束條件瞒津。但是數(shù)據(jù)倉庫通常來說是只讀的蝉衣，不需要對數(shù)據(jù)做修改和一致性的保障，所以這些約束反而會成為影響性能的因素巷蚪。
• 關(guān)系型數(shù)據(jù)庫是寫時(shí)模式病毡，數(shù)據(jù)加載進(jìn)來的時(shí)候就得明確定義特征，對于用于分析用戶行為多維度數(shù)據(jù)來說是很難提前確定的屁柏。

二啦膜、大數(shù)據(jù)分析平臺

在上述的一系列問題下有送，基于Hadoop的數(shù)據(jù)倉庫逐漸表現(xiàn)出優(yōu)異性，圍繞Hadoop體系的生態(tài)圈也不斷變大變強(qiáng)變快僧家。Hadoop類似于Unix操作系統(tǒng)雀摘，其通過MapReduce作業(yè)來對分布式文件系統(tǒng)進(jìn)行文件讀寫，該文件系統(tǒng)被稱為HDFS（Hadoop分布式文件系統(tǒng)）八拱，一個(gè)Google文件系統(tǒng)（GFS）的開源實(shí)現(xiàn)阵赠。

2.1 數(shù)據(jù)存儲

現(xiàn)在通過最簡單的例子來分析Hadoop的HDFS和MapReduce，假設(shè)收集以下客戶端日志肌稻，以文本格式存儲在HDFS下清蚀，如下:

{"name":"張三","price":66,"content":"手機(jī)殼"}
{"name":"李四","price":88,"content":"手機(jī)殼土豪版"}
{"name":"王五","price":188,"content":"手機(jī)殼至尊版"}
{"name":"張三","price":67,"content":"手機(jī)殼2"}
{"name":"李四","price":89,"content":"手機(jī)殼土豪版2"}

HDFS會日志進(jìn)行分布式存儲，主要是分區(qū)和復(fù)制灯萍，分區(qū)是文件大小超過閾值后會對其進(jìn)行分割（比如HDFS默認(rèn)block size是128M）轧铁，假設(shè)我們的日志大小超過閾值，分為log_1.txt：

{"name":"張三","price":66,"content":"手機(jī)殼"}
{"name":"李四","price":88,"content":"手機(jī)殼土豪版"}
{"name":"王五","price":98,"content":"手機(jī)殼至尊版"}

log_2.txt：

{"name":"張三","price":67,"content":"手機(jī)殼2"}
{"name":"李四","price":89,"content":"手機(jī)殼土豪版2"}

復(fù)制是存儲在多個(gè)不同的節(jié)點(diǎn)上以獲得容錯(cuò)能力旦棉，HDFS用戶存儲數(shù)據(jù)的服務(wù)器稱為DataNode，默認(rèn)把log文件放在3臺不同的DataNode上药薯，每個(gè)分區(qū)文件都有三個(gè)副本绑洛，這樣子只要不是3臺服務(wù)器同時(shí)出現(xiàn)問題就保證數(shù)據(jù)可用。
log.txt文件在HDFS中的分布大致如圖:

HDFS簡圖.png

當(dāng)然童本，這些對于使用者來說是透明的真屯，分布式存儲主要優(yōu)化的動作都在這一塊上面。

2.2 數(shù)據(jù)讀取之原始方式

已知在HDFS有文件log.txt穷娱，現(xiàn)在想計(jì)算每個(gè)用戶的支付總數(shù)绑蔫，一般情況下要進(jìn)行以下步驟:

• 1、一次性讀取全部文件內(nèi)容
• 2泵额、按行遍歷文件
• 3配深、以用戶名name為key聚合計(jì)算price

這種原始人的數(shù)據(jù)獲取方式在數(shù)據(jù)量小的時(shí)候還能用一下，要是數(shù)據(jù)量有上千萬上億條嫁盲，一次性獲取解析篓叶，費(fèi)時(shí)費(fèi)力，估計(jì)服務(wù)器內(nèi)存還得爆掉羞秤，完全沒有使用到HDFS的分區(qū)復(fù)制的特性缸托。
考慮一下，是否可以在多臺機(jī)器下瘾蛋，每臺機(jī)器讀取一個(gè)分區(qū)來計(jì)算俐镐，然后在另外的機(jī)器上聚合中間結(jié)果再生成最終結(jié)果。這個(gè)時(shí)候MapReduce出現(xiàn)了哺哼，可以使用它編寫代碼來處理HDFS等分布式文件系統(tǒng)中的大型數(shù)據(jù)集佩抹。

2.3 數(shù)據(jù)讀取之MapReduce

創(chuàng)建MapReduce作業(yè)叼风，你需要實(shí)現(xiàn)兩個(gè)回調(diào)函數(shù)，Mapper和Reducer匹摇。
Mapper
?Mapper會在每條輸入記錄上調(diào)用一次咬扇，其工作是從輸入記錄中提取鍵值。對于每個(gè)輸入廊勃，它可以生成任意數(shù)量的鍵值對懈贺。它不會保留從一個(gè)輸入記錄到下一個(gè)記錄的任何狀態(tài)，因此每個(gè)記錄都是獨(dú)立處理的坡垫。
Reducer
MapReduce框架拉取由Mapper生成的鍵值對梭灿，收集屬于同一個(gè)鍵的所有值，并使用在這組值列表上迭代調(diào)用Reducer冰悠。

MapReduce簡圖.png

使用MapReduce的話堡妒，獲取數(shù)據(jù)步驟如下：

• 1、在Mapper實(shí)現(xiàn)函數(shù)中解析每行記錄溉卓，以name為鍵皮迟，price為值
• 2、在Reduce實(shí)現(xiàn)函數(shù)中以name為鍵迭代求和
• 3桑寨、把代碼提交給調(diào)度器伏尼，計(jì)算結(jié)果會輸出。

MapReduce調(diào)度器試圖在其中一臺存儲輸入文件副本的機(jī)器上運(yùn)行每個(gè)Mapper尉尾，并且可以在多臺機(jī)器上并行執(zhí)行計(jì)算爆阶，而無需編寫代碼來顯式處理并行問題。

2.4 數(shù)據(jù)讀取之Hive

MapReduce針對于開發(fā)人員確實(shí)是可行的沙咏，但是很多底層細(xì)節(jié)需要開發(fā)人員自己維護(hù)辨图，而且這這只適用于有經(jīng)驗(yàn)的Java開發(fā)人員，因此將Hadoop放在了一個(gè)非程序員無法觸及的位置肢藐，即使這些用戶想通過Hadoop來分析他們的數(shù)據(jù)故河。
事實(shí)上，底層細(xì)節(jié)實(shí)際上是從一個(gè)任務(wù)到另一個(gè)任務(wù)的重復(fù)性操作窖壕，例如通過過濾得到所需的數(shù)據(jù)忧勿，以及執(zhí)行類似于SQL的連接(JOIN)等。這個(gè)時(shí)候瞻讽，基于一些高級工具比如Hive應(yīng)運(yùn)而生鸳吸，能自動布線組裝多個(gè)MapReduce階段，生成合適的工作流速勇。
Hive可以直接通過SQL語句進(jìn)行數(shù)據(jù)查詢晌砾，而無需編寫重復(fù)代碼及任務(wù)工作流之間的維護(hù)。
用Hive來執(zhí)行以上查詢的步驟：

// 大致的查詢思想如下
SELECT name,SUM(price) FROM log GROUP BY name;

三烦磁、總結(jié)

主要是通過數(shù)據(jù)的存和取兩方面來討論我們?yōu)楹问褂肏adoop以及一些工具出現(xiàn)的原因养匈，這里只是簡單的總結(jié)哼勇，后續(xù)會一步步深入學(xué)習(xí)總結(jié)，也可以關(guān)注我司公眾號靈機(jī)數(shù)據(jù)智能中心學(xué)習(xí)其它大佬們的深入文章呕乎。

參考：
1积担、《Hive編程指南》
2、《設(shè)計(jì)數(shù)據(jù)密集型應(yīng)用》
3猬仁、對比解讀五種主流大數(shù)據(jù)架構(gòu)的數(shù)據(jù)分析能力