大数据和hadoop的一些基础知识
一、前言
大數據這個概念不用我提大家也聽過很多了，前幾年各種公開論壇、會議等場合言必及大數據，說出來顯得很時髦似的。有意思的是最近擁有這個待遇的名詞是“人工智能/AI”，當然這是后話。
眾所周知，大數據的發展是來源于Google三駕馬車，分別是：
- Google File System（GFS） —2003
- MapReduce —2004
- Bigtable —2006
不得不說，Google真的是一家牛逼的公司，開源了這些思想造福了全球的IT事業。不過有意思的是，這三篇論文一開始并不是大數據相關的，而是為了更好地服務谷歌自家的搜索業務?；诖?#xff0c;出現了傳統的大數據框架三大組件：HDFS、MapReduce、Hbase，這就是Hadoop最開始的樣子。
二、Hadoop簡介
Hadoop是一個用Java編寫的Apache開源框架，現在我們提到Hadoop可能有兩種所指，一種是Hadoop幾個基本模塊，另一種是可以安裝在Hadoop之上的附加軟件包的集合，例如Hive、Impala、Oozie、Hue等等等等，也稱之為Hadoop家族。所以說，Hadoop技術產品是十分豐富并且在一直不停地演化，有些技術可能幾年后不流行了，又或者產生了新的技術。所以在大數據領域是需要不斷地學習的，這也導致了大數據領域的工作一般待遇都很豐厚，因為要求真的還蠻高的，需要掌握的技術線比較長。
隨便丟張圖了解下（圖隨便找的，有些技術可能已經不流行了，有些目前流行的技術沒有）：
Hadoop基本框架介紹
- Hadoop Common：這些是其他Hadoop模塊所需的Java庫和實用程序。這些庫提供文件系統和操作系統級抽象，并包含啟動Hadoop所需的Java文件和腳本；
- Hadoop YARN：這是一個用于作業調度和集群資源管理的框架；
- Hadoop Distributed File System (HDFS?)：分布式文件系統，提供對應用程序數據的高吞吐量訪問；
- Hadoop MapReduce：這是基于YARN的用于并行處理大數據集的系統。
MapReduce
實際上是兩個不同的任務：
Map（映射）：把讀入的數據用相同的方法拆分成小數據塊，然后把這些小數據塊分發到不同的工作節點上。每一個節點循環處理同樣的事，這就是一個分布式計算的過程。
Reduce（歸并）：此任務將map任務的輸出作為輸入，并將這些數據元組合并為較小的元組集合。 reduce任務總是在map任務之后執行。
圖解：
HDFS
HDFS是GFS的開源實現，它使用主/從結構，其中主節點由管理文件系統元數據的單個NameNode和存儲實際數據的一個或多個從節點DataNode組成。HDFS命名空間中的文件被拆分為幾個塊，這些塊存儲在一組DataNode中。 NameNode決定塊到DataNode的映射。DataNodes負責與文件系統的讀寫操作。它們還根據NameNode給出的指令來處理塊創建，刪除和復制。
HDFS架構圖：
YARN
舊的MapReduce過程是通過JobTracker和TaskTracker來完成的：
- JobTracker: 負責資源管理，跟蹤資源消耗和可用性，作業生命周期管理（調度作業任務，跟蹤進度，為任務提供容錯）
- TaskTracker: 加載或關閉任務，定時報告任務狀態舊MapReduce圖示：
可以一眼看出JobTracker是核心所在，存在單點問題和資源利用率問題。所以出現了新的YARN架構。
YARN將JobTracker的職責進行拆分，將資源管理和任務調度監控拆分成獨立的進程：一個全局的資源管理和一個單點的作業管理。ResourceManager和NodeManager提供了計算資源的分配和管理，而ApplicationMaster則完成應用程序的運行。
- ResourceManager: 全局資源管理和任務調度
- NodeManager: 單個節點的資源管理和監控
- ApplicationMaster: 單個作業的資源管理和任務監控
YARN架構圖示：
現在的Hadoop架構長這樣：
可以看出，一些Hadoop家族的技術產品也是通過YARN和Hadoop聯動的，YARN作為資源調度器起到一個中央管理的作用，這么多技術工具都在同一個集群上運轉，大家互相配合協調有序工作，就是依賴于YARN的分配管理。
三、Hadoop家族產品介紹
大數據領域的技術產品茫茫多，挑幾個我用過的或者很重要的組件簡單介紹下。
Hive
MapReduce的程序寫起來是一點都不方便，所以需要更高層更抽象的語言來描述算法和數據處理過程。于是Hive誕生了，它用類SQL語言來描述MapReduce，稱之為HQL。這簡直是個偉大發明。大量的數據分析人員終于也能直接使用Hadoop技術，我的SQL入門就是在Hive上操作的。Hive現在是Hadoop大數據倉庫的核心工具，它是由Facebook貢獻的，感謝臉書，感恩。
Impala
跟Hive一樣，也提供類SQL語言來查詢處理數據，稱之為Impala SQL。它是一種實時交互的查詢工具，不經由MapReduce批處理，而是通過使用分布式查詢引擎直接讀取HDFS或HBase中的內容，大大降低延遲。總結下，Hive適合于長時間的批處理查詢分析，而Impala適合于實時交互式SQL查詢。
就我個人的使用體會看，Impala的容錯性沒有Hive好，很多Hive能運行的SQL，在Impala中可能報錯，不過Impala的查詢速度的確甩開Hive很多，這也是MapReduce的局限性所在（這也導致了后續Spark的誕生），而且Impala也不支持UDF（自定義函數擴展，實現很多SQL難以實現或不好實現的功能）。所以在很多時候，我們都是Hive和Impala配合著使用，各有優劣。
Oozie
一個基于工作流引擎的開源框架。它能夠提供對Hadoop MapReduce和Pig Jobs的任務調度與協調。當我們需要讓一些數據處理過程自動周期地運行時會需要它，在Oozie上設定好工作流后，可以實現數據的自動導入HDFS-清洗-處理-導出同步的過程。
HBase
構建在HDFS之上的分布式，面向列的數據庫。HDFS缺乏隨即讀寫操作，HBase正是為此而出現。在需要實時讀寫、隨機訪問超大規模數據集時，可以使用HBase。它不是關系型數據庫，也不支持SQL，它是一種典型的NoSQL（Not Only SQL）。也是Google經典論文Bigtable的開源實現。
Storm
流計算平臺，為了達到更快更實時的數據更新，在數據流進來的時候就進行處理。流計算基本無延遲，但劣勢是不靈活，你想要處理的數據必須預先設計好，所以并不能完全替代批處理系統。
Spark
一個快速、通用的大規模數據處理引擎，在Hadoop的整個生態系統中，Spark和MapReduce在同一個層級，即主要解決分布式計算框架的問題。至于為什么會產生Spark，是因為Hadoop的計算框架MapReduce存在著局限性和不足。比如抽象層次低，代碼不好寫；表達力欠缺、中間結果存儲在HDFS中，速度不夠快；延時高，只適合批處理不適合交互處理和實時處理。所以Spark的誕生就是為了解決這些問題，它的中間輸出結果可以保存在內存中（內存放不下會寫入磁盤），避免了對HDFS的大量的讀寫，減少了I/O的開銷。
可以說，Spark是對Hadoop MapReduce的改進，同時又兼容Hadoop家族，它可以運行在YARN之上，負責存儲的仍然是HDFS，它替代的是MapReduce計算框架，獲取更高更快更強的計算速度。上層的話也有用對SQL的支持，叫做Spark SQL，也有Hive ON Spark的項目繼續使用我們可愛的Hive。所以說，Spark是有一定的野心來對Hadoop取而代之的，而且這樣的趨勢來越來越明顯。
其他
還有些我不太了解的就簡單提及：Zookeeper是高一致性的分布存取協同系統；Mahout是分布式機器學習庫；Sqoop是異構數據源海量數據交互工具。當然這個工具我沒用過，我用的是阿里開源的數據同步工具：DataX。
四、后話—Hadoop版本
Hadoop的部署是比較麻煩的，我自己也只是實現過偽分布式模式的部署，還是按照教程一步步來的，很多步驟都不是很明白到底在做什么，對于Linux和Java精通的程序員來說可能過程會比較友好。
Hadoop實際上有很多版本，有Apache Hadoop，這是開源版本，也叫社區版。實際上所有其他的發行版都是基于此衍生出來的。因為Apache Hadoop是開源的，允許任何人修改并作為商業版本發布。
最有名的發行版當屬Cloudera版本（CDH）和Hortonworks版本（HDP）了，其中Cloudera可是貢獻了很多Hadoop家族產品技術的公司，CDH也成為了很多人的選擇。有意思的是這些發行版也是免費的。
對于大公司來說，為了靈活和實現高度的定制化，基本會選擇Apache Hadoop，不過這需要一個Hadoop開發團隊來維護，小公司就會選擇付費的商業版，有專門的技術支持來解決疑問，也不用維持一個團隊，保留少量的管理員即可。
參考資料：https://blog.csdn.net/zhchs2012/article/details/80356920
轉載于:https://www.cnblogs.com/shujuxiong/p/9714017.html
總結
以上是生活随笔為你收集整理的大数据和hadoop的一些基础知识的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 给ztree节点赋值
- 下一篇： POJ 10107