大數據離線計算的架構與組件
作者：尹正傑
版權聲明：原創作品，謝絕轉載！否則將追究法律責任。
一.什么是大數據離線計算
1>.大數據離線計算概述
(1)所謂大數據離線計算，就是利用大數據的技術棧（主要是Hadoop），在計算開始前准備好所有輸入數據，該輸入數據不會產生變化，且在解決一個問題后就要立即得到計算結果的計算模式。
(2)離線（offline）計算也可以理解為批處理（batch）計算，與其相對應的是在線（online）計算或實時（realtime）計算
2>.離線計算的特點
(1)數據量巨大，保存時間長
(2)在大量數據上進行復雜的批量運算
(3)數據在計算之前已經完全到位，不會發生變化
(4)能夠方便地查詢計算結果
3>.大數據離線計算應用場景
（1）大數據離線計算主要用於數據分析、數據挖掘等領域。我們說這部分的技術棧主要是Hadoop，但在以Hadoop為代表的大數據技術出現之前，數據分析、數據挖掘已經經歷了長足的發展。尤其以BI系統為主的數據分析領域，已經有了比較成熟穩定的技術方案和生態系統。
（2）BI（全稱為Business Intelligence，即商業智能）系統能夠輔助業務經營決策。其需要綜合利用數據倉庫（基於關系型數據庫）、聯機分析處理（OLAP）工具（如各種SQL）和數據挖掘等技術。
（3）如Oracle、IBM、Microsoft等數據庫廠商都有自己的BI產品，MicroStrategy、SAP等獨立BI廠商也有自己的軟件產品。
4>.傳統BI暴漏的問題
然而傳統BI隨着時間的推移暴露出一些問題：
（1）BI系統以分析業務系統產生的結構化數據為主，對非結構化和半結構化數據處理困難，如文本、圖片、音視頻等。
（2）由於數據倉庫為結構化存儲，在數據從其它系統進入數據倉庫前需要一個ETL過程，ETL通常和業務強綁定，需要專門的人員去做這個工作。
（3）當數據量增大的時候，性能會成為瓶頸，傳統關系型數據庫在TB級別時已經表現得吃力，在PB級別時基本無能為力。
（4）數據庫的設計一般會遵循某種范式，其着力於解決數據冗余和一致性問題。但數據倉庫設計時為了性能和方便的考慮，通常會使用一些反范式的設計。如何在范式和反范式間權衡沒有確定的標准，需要小心設計。
（5）對於包含機器學習應用的BI系統，由於ETL的存在，其獲取到的數據為已經按某種假設清洗后的數據，會造成機器學習的效果不理想或完全沒有效果。
5>.大數據離線計算的優勢
針對這一系列問題，以Hadoop為代表的大數據解決方案表現出其優越性，Hadoop技術棧中的各種組件不斷豐富，已經完全能實現傳統BI的功能，並解決了其容量和性能的瓶頸。
但大數據技術也帶來了一些新問題： 從傳統數據倉庫升級到大數據的數據倉庫，不可能平滑演進，基本等於重新開發。這和軟硬件架構的不一致、SQL方言的差異都有關系。 大數據解決方案在功能和性能上有很多取舍，如HDFS不支持修改文件，Hive要支持update和delete的話有非常苛刻的限制且效率也遠低於關系型數據庫。類似這些都是大數據解決方案的局限性。
大數據離線計算側重於從以下幾個維度解決傳統BI面臨的瓶頸： 分布式存儲：
將大文件按照一定大小拆分成多份，分別存儲到獨立的機器上，並且每一份可以設置一定的副本數，防止機器故障導致數據丟失，這種存儲方式比傳統關系型數據庫/數據倉庫使用的集中式存儲，無論是容量、價格、吞吐率、魯棒性等各方面都有明顯優勢。 分布式計算：
核心思想是讓多個機器並行計算，並通過對數據本地性的利用，盡量處理本機器上的那一部分數據，減少跨網絡的數據傳輸。很多傳統的數據庫/數據倉庫也支持利用多核CPU、集群技術來進行分布式計算，但Hadoop的分布式計算架構更為徹底。 檢索和存儲的結合：
在早期的大數據組件中，存儲和計算相對比較單一，但目前的方向是對存儲進一步優化，ᨀ升查詢和計算的效率，其方法是除了存儲數據的內容外，還存儲很多元數據信息，如數據的schema、索引等。類似parquet、kudu等技術都是利用了這種思想。
二.大數據離線計算的架構
三.大數據離線計算涉及組件
1>.HDFS
HDFS
是Hadoop上的分布式文件系統。
HDFS采用主從模式，其架構主要包含NameNode，DataNode，Client三個部分：
NameNode:
用於存儲、生成文件系統的元數據。運行一個實例，因此需要解決單點故障問題。
DataNode：
用於存儲實際的數據，並將自己管理的數據塊信息上報給NameNode，運行多個實例。一個數據默認存儲3副本，分布在3個不同的DataNode上以保證可用性。
Client：
支持使用者讀寫HDFS，從NameNode、DataNode獲取元數據或實際數據返回給使用者。可以有多個實例，和業務一起運行。
2>.MapReduce on
MapReduce是Googleᨀ出的一種並行計算框架：
Map：
映射，對一些獨立元素組成的列表的每一個元素進行指定的操作。每個元素都是被獨立操作的，而原始列表沒有被更改。Map操作是可以高度並行的，這對高性能應用以及並行計算領域的需求非常有用。
Reduce：
化簡，對一個列表的元素進行適當的合並，雖然它不如Map那么並行，但是因為化簡總是有一個簡單的答案，大規模的運算相對獨立，所以化簡函數在高度並行環境下也很有用。
適合：
大規模數據集的離線批處理計算；任務分而治之，子任務相對獨立。
不適合：
實時的交互式計算，要求快速響應和低延遲，比如BI；流式計算、實時分析，比如廣告點擊計算；子任務之間相互依賴的迭代計算。
3>.YARN
Yarn是Hadoop2.0后的資源管理系統，它是一個通用的資源管理模塊，可為各類應用程序進行資源管理和調度
Yarn是輕量級彈性計算平台，除了MapReduce框架，還可以支持其他框架，比如Spark、Storm等
多種框架統一管理，共享集群資源：
資源利用率高
運維成本低
數據共享方便
4>.Hive
Hive是基於Hadoop的一個數據倉庫工具，可以將結構化的數據文件映射為一張數據庫表，並ᨀ供類SQL的查詢功能。其基本原理是將HQL語句轉換成MapReduce任務。
Impala是一個MPP架構的大數據分析引擎，提供交互式、即時SQL查詢能力。其大多數語法和Hive相同或類似，元數據也使用Hive的，因此可以直接操作Hive表。
5>.Hue
Hue（Hadoop User Experience）是一個開源的Apache Hadoop UI系統，由Cloudera Desktop演化而來，它是基於Python Web框架Django實現的。
通過Hue可以：
SQL編輯，支持Hive、Impala、SparkSQL和各種關系型數據庫
管理Hadoop和Spark任務
HBase數據的查詢和修改
Sqoop任務的開發和調試
管理Oozie的工作流
其他功能，例如瀏覽HDFS，瀏覽zookeeper……
6>.Sqoop
Sqoop是一個用來將Hadoop和關系型數據庫中的數據相互轉移的工具，可以在關系型數據庫（Mysql，Oracle，Postgre等）和Hadoop（Hive，HBase）等間雙向互導
通過MapReduce實現，因此是批量的、非實時的。如果需要實時，可以考慮Flume、StreamSets等解決方案
易用性較差
一些ETL工具也能實現Sqoop的功能，例如Kettle
7>.Oozie
Oozie是一個基於工作流引擎的服務器，可以在上面運行Hadoop的MapReduce、Pig等任務。它運行於web容器中（如tomcat）
Oozie使用關系型數據庫存儲：工作流定義；當前運行的工作流實例，包括實例的狀態和變量
Oozie工作流是放置在控制依賴DAG中的一組動作，其中指定了動作執行的順序。使用hPDL（一種XML流程定義語言）來᧿述這個圖。
8>.其他組件
Flume、StreamSets：這兩個組件都是用作數據采集的，在離線計算中當然可以用，例如將數據從外部數據源采集到HDFS。但它們更多的應用場景是在實時計算中，用於數據流的一部分. Kafka：
是一種消息隊列，同樣地也可以用於離線計算和實時計算中，也是數據流的一部。 HBase：
是一種面向列的數據存儲，可以ᨀ供類似OLTP數據庫的即席查詢能力，也能依靠另一個組件Phoenix來提供SQL形式的查詢能力。其在離線計算中也可以作為數據存儲使用，但鑒於其設計理念並非用於批量的數據分析場景，我們將其放入實時計算運維/開發的課程中。 Spark：
本質上其既可以用於離線的批量計算，又可以用於在線的實時計算（通過SparkStreamingᨀ供的微批能力），因為其非常重要，涉及的知識點又較多。