一些概念

【什么是大數據、大數據技術】

大數據,又稱巨量資料,指的是所涉及的數據資料量規模巨大到無法在合理時間內通過傳統的應用軟件工具進行抓取、收集、管理、分析處理。簡單來說,大數據就是海量數據的高效處理
大數據技術,從本質上講是從類型各異、內容龐大的數據中快速獲得有價值信息的技術。目前,隨著大數據領域被廣泛關注,大量新的技術已經開始涌現出來,而這些技術將成為大數據采集、存儲、分析、表現的重要工具。
大數據處理的關鍵技術主要包括:數據采集、數據預處理(數據清理、數據集成、數據變換等)、大數據存儲、數據分析和挖掘、數據的呈現與應用(數據可視化、數據安全與隱私等)。

【大數據的4V特征(Volume、Variety、Value、Velocity)】

1、數據體量巨大(Volume)。包括采集、存儲和計算的量都非常大。大數據的起始計量單位至少是P(1000個T)、E(100萬個T)或Z(10億個T)。
2、數據類型繁多(Variety)。這種類型的多樣性也讓數據被分為結構化數據和非結構化數據。相對于以往便于存儲的以文本為主的結構化數據,非結構化數據越來越多,包括網絡日志、音頻、視頻、圖片、地理位置信息等,這些多類型的數據對數據的處理能力提出了更高要求。
3、價值密度低(Value)。價值密度的高低與數據總量的大小成反比。以視頻為例,一部1小時的視頻,在連續不間斷的監控中,有用數據可能僅有一二秒。如何通過強大的機器算法更迅速地完成數據的價值“提純”成為目前大數據背景下亟待解決的難題。
4、處理速度快(Velocity)。數據增長速度快,處理速度也快,時效性要求高。比如搜索引擎要求幾分鐘前的新聞能夠被用戶查詢到,個性化推薦算法盡可能要求實時完成推薦。這是大數據區別于傳統數據挖掘的顯著特征。

【什么是云計算】

云計算(Cloud Computing)是分布式計算(Distributed Computing)、并行計算(Parallel Computing)、效用計算(Utility Computing)、 網絡存儲(Network Storage Technologies)、虛擬化(Virtualization)、負載均衡(Load Balance)、熱備冗余(High Available)等傳統計算機和網絡技術發展融合的產物。
云計算中的“云”是指通過 Internet(“云”)交付計算服務器、存儲和帶寬資源等服務。“云”將計算資源集中起來,并通過專門軟件實現自動管理。用戶可以動態申請部分資源,支持各種業務的運轉,無需自己搭建服務器而從“云”獲取計算和存儲能力,從而提高效率、降低成本,可以更專注于重要的業務目標以及創新。提供這些計算服務的公司稱為云提供商,他們通常基于用戶使用對云計算服務進行收費,類似于家用水電的計費方式。
云計算早期,就是簡單一點的分布式計算,解決任務分發,將計算結果合并,也叫網格計算。很多大企業早期可能也只是想解決自己的效率與計算問題,到后來這個能力也可以提供給外部使用,所以就出現了公共云(public cloud)計算 ,把計算機的計算能力直接放在網上賣出去。未來的云計算,就像我們使用水電煤氣一樣,我們從來不會想著去建電廠,也不關心電廠在哪里,只要插上插頭,就能用電。簡單來說,云計算是硬件資源的虛擬化

【云計算有哪些特點】

1.超大規模
“云”具有相當的規模,Google的云計算擁有100多萬臺服務器,Amazon、Microsoft、Yahoo等擁有幾十萬臺服務器。所以“云”可以為用戶提供超強的計算和存儲能力。
2.費用低
“云”就是一個龐大的資源池,用戶可以按需購買資源,像水電煤那樣計費。無需在購買硬件和軟件以及設置和運行現場數據中心(包括服務器機架、用于供電和冷卻的全天不間斷電力、管理基礎結構的 IT 專家)上進行額外的資金投入。
3.高伸縮性
“云”的規模可以動態伸縮,具備彈性擴展能力,以滿足應用或者用戶增長的需要。例如更多或更少的計算能力、存儲空間、帶寬。因此通常只需點擊幾下鼠標,即可在數分鐘內調配海量計算資源,賦予企業非常大的靈活性,并消除了容量規劃的壓力。
4.通用性
“云”不是針對特定的服務,同一片“云”可以支撐各種各樣的服務。
5.虛擬化
云計算支持用戶在任意位置、使用各種終端獲取應用服務。所請求的資源來自“云”,而不是固定的有形的實體。應用在“云”中某處運行,但實際上用戶無需了解、也不用擔心應用運行的具體位置。只需要一臺筆記本或者一個手機,就可以通過網絡服務來實現我們需要的一切,甚至包括超級計算這樣的任務。
6.可靠性
“云”采用數據多副本容錯、計算節點同構可互換等多種手段保障服務可靠性。

【云服務類型:IaaS、PaaS、SaaS】

1、基礎結構即服務 (IaaS)
云計算服務的最基本類別。使用 IaaS 時,以即用即付的方式從服務提供商處租用IT基礎結構,如服務器和虛擬機(VM)、存儲空間、網絡和操作系統。
2、平臺即服務 (PaaS)
平臺即服務 (PaaS) 是指云計算服務,它們可以按需提供開發、測試、交付和管理軟件應用程序所需的環境。PaaS 旨在讓開發人員能夠更輕松地快速創建 Web 或移動應用,而無需考慮對開發所必需的服務器、存儲空間、網絡和數據庫基礎結構進行設置或管理。
3、軟件即服務 (SaaS)
軟件即服務 (SaaS) 是通過 Internet 交付軟件應用程序的方法,通常以訂閱為基礎按需提供。使用 SaaS 時,云提供商托管并管理軟件應用程序和基礎結構,并負責軟件升級和安全修補等維護工作。用戶(通常使用電話、平板電腦或 PC 上的 Web 瀏覽器)通過 Internet 連接到應用程序。

【云部署類型:公共、私有、混合】

1、公有云
公有云為第三方云服務提供商所擁有和運營,他們通過 Internet 提供其計算資源(如服務器和存儲空間)。Microsoft Azure 是公有云的一個示例。在公有云中,所有硬件、軟件和其他支持性基礎結構均為云提供商所擁有和管理。使用 Web 瀏覽器訪問這些服務和帳戶管理。
2、私有云
私有云是指專供一個企業或組織使用的云計算資源。私有云可以實際位于公司的現場數據中心之上。私有云對數據保密、數據安全、服務質量都能有效控制,其最大的特點是安全性與私有化,是訂制化解決方案的根本,對于對數據安全與穩定有要求的企業來說是非常好的選擇。
3、混合云
混合云組合了公有云的方便便捷與私有云的安全穩定的特點,企業出于安全考慮會希望將數據存放在私有云上面,同時又希望能使用公有云的資源,混合云為企業提供更大的靈活性和更多的部署選項。

【云計算的安全如何保證】

公有云的數據安全不是一個孤立的問題,廣義的安全,也包括數據的完整性、數據的私密性。
1、網絡安全防護:高吞吐量的 DDoS 外網防護更完善的防火墻,入侵檢測,WAF更完善的流量清洗規則。
2、數據庫安全防護:高可用:主備切換數據零丟失高可靠:同城雙活,異地備份安全性:訪問控制,IP白名單。
3、存儲安全防護:高可靠:超大容量,三份備份,異地同步安全性:訪問控制,防盜鏈。
4、運維安全:數據對運維也是機密的,需要流程保障不斷更新的虛擬機和容器鏡像建設漏洞不斷更新的病毒庫

【大數據與云計算的關系】

1、云計算為大數據提供了有力的工具和途徑。云計算強大的計算能力和數據存儲能力能夠為大數據處理分析帶來豐富性和多元性,使其能夠提供更為便捷的服務。
2、大數據為云計算提供了很有價值的用武之地。大數據本身帶來的多元化應用使得云計算具有了強大的實際應用能力。
3、大數據為云計算深入到行業應用提供了強有力的切入點。
4、大數據更靠近應用,比云計算更容易落地,大數據需求明顯,處在價值鏈的上游,可有效利用已大量建設的云計算資源。
云計算作為計算資源的底層,支撐著上層的大數據處理,而大數據的發展趨勢是,實時交互式的查詢效率和分析能力。云計算和大數據勢相輔相成、優勢相長的關系,二者結合能夠提升對方的實用價值,并在對方的計算發展過程中相互促進,實現了傳統信息處理和分析技術無法理解和比擬的功能和優勢。

【大數據思維】

1、要分析所有數據,而不是少量的隨機數據樣本。在大數據時代的第一個轉變就是利用所有數據,而不再僅僅依靠一小部分數據。采樣分析的精確性隨著采樣隨機性的增加而大幅提高,但與樣本數量的增加關系不大。因此樣本選擇的隨機性比樣本數量更加重要。大數據的方法不采用隨機分析法,而是采用所有數據,即樣本=總體。
2、要追求數據的紛繁復雜,而不是精確性。在“小數據”時代,最重要的就是減少測量的錯誤,因為收集的信息較少,所以必須保證記錄盡可能精確,否則細微的錯誤會被放大。大數據為了擴大數據規模允許不精確。大數據的簡單算法比小數據的復雜算法更加有效。大數據要求我們接受紛繁性,放棄對精確性的追求,在大數據時代我們無法獲得精確性。
3、要關注事物的相關關系,而不是因果關系。通過監控一個現象的良好的關聯物,相關關系可以幫助我們捕捉現在和預測未來。大數據的相關關系分析法更加準確、更快,而且不易受傳統思維模式和特定領域里隱含的固有偏見的影響。建立在相關關系分析法上基礎上的預測是大數據的核心。

【大數據的數據分類】

1、結構化數據:即行數據,存儲在數據庫里,可以用二維表結構來邏輯表達實現的數據。任何一列遵循范式,數據項不可再分,同一列數據具有相同的數據類型。所有的關系數據庫中的數據均為結構化數據(如Oracle,DB2,MySQL,SQLServer)
2、非結構化數據:不方便用數據庫二維邏輯表來表現的數據,包括所有格式的辦公文檔、文本、圖片、XML、HTML、各類報表、圖像和音頻/視頻信息等,沒有固定結構的數據,通常保存為不同類型的文件。
3、半結構化數據:介于完全結構化數據(如關系型數據庫、面向對象數據庫中的數據)和完全無結構的數據(如聲音、圖像文件等)之間的數據。每條記錄可能會有預定義的規范,但是允許每條記錄包含不同的信息、字段數、字段名、字段類型,也允許嵌套格式。HTML文檔就屬于半結構化數據。它一般是自描述的,數據的結構和內容混在一起,沒有明顯的區分。

【企業級大數據運營流程】

針對企業內外部的各類數據源,通過數據采集、預處理、數據存儲及數據加工處理,為不同應用及使用對象提供多種數據服務。
數據源:整合的業務數據來源于B/O/M三域支撐系統、業務平臺等內部系統數據源,以及互聯網頁,政府數據等外部數據源。
數據采集:將不同來源、不同特征的數據源通過不同的方式進行抽取和收集。
數據處理:通過數處理對采集來的數據進行必要的裁剪、整理、匯總計算。
數據存儲:將經過預處理的數據裝載到分析平臺、并根據處理需要進行數據分層存儲。
數據治理:按照不同的數據架構、數據質量規則、安全規則等進行數據治理。
數據挖掘:針對不同的應用場景需求通過挖掘算法建立模型,挖掘數據間的潛在關系與價值。
數據應用:面向不同應用及使用對象,提供接口數據、頁面訪問等多種數據服務。

【大數據的預處理及存儲管理技術】

數據預處理主要完成對已接收數據的辨析、抽取、清洗等操作。
1、抽取:因獲取的數據可能具有多種結構和類型,數據抽取過程可以幫助我們將這些復雜的數據轉化為單一的或者便于處理的構型,以達到快速分析處理的目的。
2、清洗:對于大數據,并不全是有價值的,有些數據并不是我們所關心的內容,而另一些數據則是完全錯誤的干擾項,因此要對數據通過過濾“去噪”從而提取出有效數據。
大數據存儲與管理要用存儲器把采集到的數據存儲起來,建立相應的數據庫,并進行管理和調用。重點解決復雜結構化、半結構化和非結構化大數據管理與處理技術。其中非關系型數據庫主要指的是NOSQL數據,分為鍵值庫,列存儲數據庫,圖數據庫以及文檔數據庫等類型。關系型數據庫包含了傳統關系數據庫系統以及NewSQL數據庫。

【大數據的分析及挖掘技術】

數據挖掘就是從大量的、不完全的、有噪聲的、模糊的、隨機的實際應用數據中,提取隱含在其中的、人們事先不知道的、但又是潛在有用的信息和知識的過程。根據挖掘方法分,可粗分為:機器學習方法、統計方法、神經網絡方法和數據庫方法。機器學習中,可細分為:歸納學習方法(決策樹、規則歸納等)、基于范例學習、遺傳算法等。統計方法中,可細分為:回歸分析(多元回歸、自回歸等)、判別分析(貝葉斯判別、費歇爾判別、非參數判別等)、聚類分析(系統聚類、動態聚類等)、探索性分析(主元分析法、相關分析法等)等。神經網絡方法中,可細分為:前向神經網絡(BP算法等)、自組織神經網絡(自組織特征映射、競爭學習等)等。數據庫方法主要是多維數據分析或OLAP方法,另外還有面向屬性的歸納方法。

【批處理與流處理的差異】

批處理與流處理的不同,主要是數據獲取的方式不同。流處理的數據,就像流水一樣,一直在系統中流動處理。批處理的數據,則是暫存于數據庫中的離線數據,后期定時定量的一批一批的處理。
批處理的優點是支持對歷史時序數據的處理,實現簡單。但是批處理具有查詢數據量大,非實時的缺點,因此批處理不適合對處理時間要求較高的場合。流式處理的優點是數據實時計算,無需查詢原始數據,無需針對整個數據集執行操作,而是對通過系統傳輸的每個數據項執行操作。但是流式處理需要特殊處理寫入的歷史數據,也需要處理運算過程中崩潰的計算單元。流處理很適合用來處理必須對變動或峰值做出響應,并且關注一段時間內變化趨勢的數據。

【什么是Hadoop】

Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。用戶可以在不了解分布式底層細節的情況下,開發分布式程序,充分利用集群的威力進行高速運算和存儲。Hadoop實現了一個分布式文件系統(Hadoop Distributed File System),簡稱HDFS。HDFS有高容錯性的特點,并且設計用來部署在低廉的(low-cost)硬件上;而且它提供高吞吐量(high throughput)來訪問應用程序的數據,適合那些有著超大數據集(large data set)的應用程序。Hadoop的框架最核心的設計就是:HDFS和MapReduce。HDFS為海量的數據提供了存儲,而MapReduce為海量的數據提供了計算。

【Hadoop的起源】

Hadoop起源于Apache Nutch(一個開源的網絡搜索引擎),是Apach Lucene(文本搜索引擎庫,創始人Doug Cutting)的一部分。在2002-2004年間谷歌發布了三大論文介紹了其云計算的核心組成部分GFS(Google File System)、MapReduce以及BigTable。谷歌在自身多年的搜索引擎業務中構建了突破性的GFS,從此文件系統進入分布式時代。除此之外,Google在GFS上如何快速分析和處理數據方面開創了MapReduce并行計算框架,讓以往的高端服務器計算變為廉價的x86集群計算,也讓許多互聯網公司能夠從IOE(IBM小型機、Oracle數據庫以及EMC存儲)中解脫出來,Google雖然沒有將其核心技術開源,但是這三篇論文已經向開源社區指明了方向。得益于Google的啟發,Doug Cutting使用Java語言對Google的云計算核心技術(主要是GFS和MapReduce)做了開源的實現。后來,Apache基金會整合Doug Cutting以及其他IT公司(如Facebook等)的貢獻成果,開發并推出了Hadoop生態系統。

【Hadoop的四大特性】

1、 可擴展(Scalable):hadoop的分布式存儲和分布式計算是在集群節點完成的,可以方便地擴展到數以千計的節點中。
2、 低成本(Economical):可以通過普通機器組成的服務器群來分發以及處理數據。這些服務器群總計可達數千個節點。而且每個節點都是運行在開源操作系統Linux上面的。
3、 高效率(Efficient):通過分發數據,hadoop可以在數據所在的節點上并行地(parallel)處理它們,這使得數據處理非常的快速。
4、 高可靠性(Reliable):hadoop能自動地維護數據的多份復制,并且在任務失敗后能自動地重新部署(redeploy)計算任務。

【Hadoop生態圈主要項目】

Hadoop Common:一組分布式文件系統和通用I/O的組件與接口(序列化、Java RPC和持久化數據結構),用于支持其他Hadoop模塊。
MapReduce:并行計算框架,非常適合在大量計算機組成的分布式并行環境里進行數據處理。
HDFS:分布式文件系統,有著高容錯性特點,設計用來部署在低廉的硬件上,適合那些有著超大數據集的應用程序。
Zookeeper:一個分布式、高性能的協調服務,提供分布式鎖之類的基本服務用于構建分布式應用。
HBase:一個分布式、按列存儲數據庫,使用HDFS作為底層存儲,同時支持MapReduce的批量式計算和點查詢(隨機讀取)。
Pig:一種數據流語言和運行環境,用以檢索非常大的數據集,運行在MapReduce和HDFS的集群上。
Hive:數據倉庫工具,提供基于SQL的查詢語言(運行時翻譯成MapReduce作業)用于數據的離線分析。
Mahout:一個在Hadoop上運行的可擴展的機器學習算法和數據挖掘類庫。
Avro:一種支持高效、跨語言的RPC以及永久存儲數據的序列化系統。
Sqoop:在傳統數據庫和HDFS之間高效傳輸數據的工具。

【HDFS 概覽】

HDFS是一個Apache Software Foundation項目,是Apache Hadoop項目的一個子項目。HDFS非常適于存儲和管理大型數據(GB、TB、PB級),HDFS是一個高度容錯性的系統,適合部署在廉價的機器上。HDFS能提供高吞吐量的數據訪問,非常適合大規模數據集上的應用。HDFS放寬了一部分POSIX約束,來實現流式讀取文件系統數據的目的。
HDFS的設計思想“一次寫入,多次讀取(write-once-read-many)”,一個數據集一旦由數據源生成,就會被復制分發到不同的存儲節點中,然后響應各種各樣的數據分析任務請求。HDFS處理的應用一般是批處理,而不是用戶交互式處理,注重的是數據的吞吐量而不是數據的訪問速度。
HDFS特點:高容錯性、高吞吐量、故障的檢測和自動快速恢復、流式的數據訪問、大數據集、一次寫入,多次讀寫
HDFS不適用的場景:不適合大量小文件的存儲、不適合隨機讀寫、不支持對文件隨機修改。

【Hadoop構造模塊】

運行Hadoop的意思其實就是運行一組守護進程(daemons),每個進程都有各自的角色,有的僅運行在單個服務器上,有的則運行在集群多個服務器上,包括:
NameNode:整個文件系統的管理節點,負責文件系統名字空間(NameSpace)的管理與維護,同時負責客戶端文件操作的控制以及具體存儲任務的管理與分配。
Secondary NameNode:負責監控HDFS狀態的輔助后臺程序,與NameNode通訊,定期保存HDFS元數據快照。
DataNode:提供真實文件數據的存儲服務,負責處理文件系統客戶端的讀寫請求。
JobTracker:每個集群只有一個JobTracker守護進程,是用于處理作業的后臺程序,決定有哪些文件參與作業處理,分配task執行的節點,監控task并重啟失敗的task。
TaskTracker:管理各自所在節點上的task,與DataNode進行數據交互負責執行具體的任務。

【HDFS架構】

HDFS采用master/slave架構。一個HDFS集群是由一個Namenode和一定數目的Datanodes組成。Namenode是一個中心服務器,負責管理文件系統的名字空間(namespace)以及客戶端對文件的訪問。集群中的Datanode一般是一個節點一個,負責管理它所在節點上的存儲。HDFS暴露了文件系統的名字空間,用戶能夠以文件的形式在上面存儲數據。從內部看,一個文件其實被分成一個或多個數據塊,這些塊存儲在一組Datanode上。Namenode執行文件系統的名字空間操作,比如打開、關閉、重命名文件或目錄。它也負責確定數據塊到具體Datanode節點的映射。Datanode負責處理文件系統客戶端的讀寫請求。在Namenode的統一調度下進行數據塊的創建、刪除和復制。


HDFS Architecture.png

【HDFS的高可用(HA)機制】

Hadoop2.X版本之前,NameNode是HDFS集群的單點故障點(SPOF)
影響HDFS集群不可用主要包括兩種情況:1、類似機器宕機這樣的意外情況將導致集群不可用,只有重啟NameNode之后才可使用。2、計劃內的軟件或硬件升級(NameNode節點),將導致集群在短時間范圍內不可用
一個典型的HA(High Availability)集群,兩個單獨的機器配置為NameNode,在任何時候,一個NameNode處于活動狀態,另一個處于待機狀態,活動NameNode負責處理集群中所有客戶端的操作,待機時僅僅作為一個Slave,保持足夠的狀態,如果有必要提供一個快速的故障轉移機制。
為了提供快速的故障轉移,必須保證備用節點有最新的集群中塊的位置信息,為了達到這一點,DataNode節點需要配置兩個NameNode的位置,同時發送塊的位置信息和心跳信息到兩個NameNode。
同時為了防止"腦裂場景"的出現,必須為共享存儲配置至少一個fencing方法。在宕機期間,如果不能確定之間的活動節點已經放棄活動狀態,fencing進程負責中斷以前的活動節點編輯存儲的共享訪問,這可以防止任何進一步的修改名字空間,允許新的活動節點安全地進行故障轉移。

【HDFS的心跳機制】

主節點和從節點之間的通信是通過心跳機制(HeartBeat)實現的,如NameNode與DataNode之間,JobTracker和TaskTracker之間。所謂“心跳”是一種形象化描述,指的是持續的按照一定頻率在運行,類似于心臟在永無休止的跳動。客戶端每隔幾分鐘發送一個固定信息給服務端,服務端收到后回復一個固定信息如果服務端幾分鐘內沒有收到客戶端信息則視客戶端斷開。Namenode周期性地從集群中的每個Datanode接收心跳信號和塊狀態報告(Blockreport)。接收到心跳信號意味著該Datanode節點工作正常。Tasktracker周期性的向JobTracker發送心跳匯報節點和任務狀態信息,及時讓Jobtracker獲取各個節點上的資源使用情況和任務運行狀態。

【HDFS 聯邦(Federation)】

HDFS Federation是解決NameNode單點問題的一種水平橫向擴展方案。主要解決幾個問題:
1、命名空間的擴展。在HDFS Federation的情況下,元數據的管理與存放被分隔開,但真實數據的存儲還是共用。隨著集群使用時間的加長,HDFS上存放的數據也將會越來越多.這個時候如果還是將所有的數據都往一個NameNode上存放,這個文件系統會顯得非常的龐大。這時候可以進行橫向擴展,把一些大的目錄分離出去,使得每個NameNode下的數據看起來更加的精簡。
2、性能提升。當NameNode所持有的數據量達到了一個非常大規模的量級的時候(比如超過1億個文件),NameNode的處理效率會受到影響,比較容易會陷入繁忙的狀態。而整個集群將受限于一個單點NameNode的處理效率,從而影響集群整體的吞吐量。采多NameNode機制可以減輕壓力。
3、資源的隔離。通過多個命名空間,將關鍵數據文件目錄移到不同的NameNode上,避免這些關鍵數據的讀寫操作受到其他普通文件讀寫操作的影響,也就是說這些NameNode將會只處理特定的關鍵的任務所發來的請求,而屏蔽了其他普通任務的文件讀寫請求,以此做到了資源的隔離。

【HDFS安全模式】

安全模式主要是為了系統啟動的時候檢查各個DataNode上數據塊的有效性,同時根據策略進行必要的復制或者刪除部分數據塊。
設計安全模式的目的在于:HDFS啟動過程中,NameNode還無法獲取DataNode上各數據塊的狀態,無法保證可以正常對外提供數據存儲服務。為保護系統安全和數據的完整,在此期間不對外提供服務(不允許對文件修改、刪除)。待NameNode完全獲知各DataNode上各數據塊的狀態,并根據策略完成必要的復制或刪除數據塊后,再退出安全模式,對外開始提供服務。何時退出安全模式?啟動過程中,各DataNode向NameNode上報各個數據塊的狀態(含副本數)。當NameNode檢測到達到最小副本數(dfs.replication.min)的數據塊比率達到99.9%(可通過參數配置)時,自動退出安全模式。

【Hadoop的三種運行模式】

1、單機(本地)模式
這種模式在一臺單機上運行,沒有分布式文件系統,而是直接讀寫本地操作系統的文件系統。在單機模式(standalone)中不會存在守護進程,所有東西都運行在一個JVM上。單機模式適用于開發過程中運行MapReduce程序,在單機模式下調試MR程序非常高效方便,這也是最少使用的一個模式。
2、偽分布式模式
這種模式在一臺單機上運行,但用不同的Java進程模仿分布式運行中的各類節點,模擬一個小規模的集群。偽分布式適用于開發和測試環境,在這個模式中,所有守護進程都在同一臺機器上運行。
3、完全分布式模式
這種模式通常被用于生產環境,使用N臺主機組成一個Hadoop集群,Hadoop守護進程運行在各臺主機之上。這里會存在Namenode運行的主機,Datanode運行的主機,以及resourcemanager運行的主機等。在分布式環境下,主節點和從節點會分開。

【HDFS元數據】

NameNode在內存中保存著整個文件系統的名字空間和文件數據塊映射等元數據。如果NameNode宕機,那么整個集群就癱瘓了,所以需要對這些元數據進行持久化存儲。
元數據,正所謂數據的數據,包含有三類重要信息:
第一類是文件和目錄自身的屬性信息,例如文件名、目錄名、父目錄信息、文件大小、創建時間、修改時間等。
第二類記錄文件內容存儲相關信息,例如文件塊情況、副本個數、每個副本所在的Data Node 信息等。
第三類用來記錄HDFS中所有DataNode信息,用于DataNode管理。
HDFS元數據存儲機制:內存中有一份完整的元數據(內存meta data),磁盤有一個“準完整”的元數據鏡像(fsimage)文件(在namenode的工作目錄中)、以及用于銜接內存metadata和持久化元數據鏡像fsimage之間的操作日志(edits文件),當客戶 端對hdfs中的文件進行新增或者修改操作,操作記錄首先被記入edits日志文件中,當客戶端操作成功 后,相應的元數據會更新到內存meta.data中。

【HDFS元數據持久化原理】

上一篇說到HDFS文件系統的命名空間等元數據是由NameNode來存儲的,元數據保存著HDFS系統的重要信息。
NameNode用事務日志(EditsLog)來持久化每一個對文件系統的元數據的改變,即對元數據的每一步操作都會被記錄到EditsLog中.NameNode在本地文件系統中用一個文件來存儲這個EditsLog,完整的文件系統名字空間、文件塊的映射和文件系統的配置都存在一個叫Fsimage的文件中,Fsimage也是在NameNode的本地文件系統中。CheckPoint(檢查點):當NameNode啟動的時候,它會從磁盤中讀取Fsimage和EditsLog文件,然后將新的元數據刷新到本地磁盤中,生成一個新的Fsimage文件,至此EditsLog文件已經被處理并持久化的Fsimage中,任何對Fsimage和EditsLog的更新都會同步地更新每一個副本。如果NameNode宕機或是重啟,內存中沒有元數據,那hdfs重新啟動的時候,數據就從fsimage和edits這兩個文件中加載,恢復系統之前的狀態。

【HDFS讀寫流程】

HDFS采用master/slave架構。一個HDFS集群是由多個Namenode和一定數目的Datanodes組成。Namenode是一個中心服務器,負責管理文件系統的名字空間(namespace)以及客戶端對文件的訪問。集群中的Datanode一般是一個節點一個,負責管理它所在節點上的存儲。HDFS中的文件是一次性寫入的,并且嚴格要求在任何時候只能有一個寫入者。
文件寫入過程:1.Client向NameNode發起文件寫入的請求。2 .NameNode根據文件大小和文件塊配置情況,返回給Client它所管理部分DataNode的信息。3. Client將文件劃分為多個Block,根據DataNode的地址信息,按順序寫入到每一個DataNode塊中。
文件讀取過程:1. Client向NameNode發起文件讀取的請求。2. NameNode返回文件存儲的DataNode的信息。3. Client讀取文件信息。

【HDFS副本機制】

副本技術即分布式數據復制技術,是分布式計算的一個重要組成部分。該技術允許數據在多個服務器端共享,一個本地服務器可以存取不同物理地點的遠程服務器上的數據,也可以使所有的服務器均持有數據的拷貝。副本機制有一下優點:
1、提高系統可靠性,系統不可避免的會產生故障和錯誤,擁有多個副本的文件系統不會導致無法訪問的情況,從而提高了系統的可用性。另外,系統可以通過其他完好的副本對發生錯誤的副本進行修復,從而提高了系統的容錯性。2、負載均衡,副本可以對系統的負載量進行擴展。多個副本存放在不同的服務器上,可有效的分擔工作量,從而將較大的工作量有效的分布在不同的站點上。
提高訪問效率:將副本創建在訪問頻度較大的區域,即副本在訪問節點的附近,相應減小了其通信開銷,從而提高了整體的訪問效率。
HDFS中的默認三副本機制(三個以上的隨機存儲) ,第一副本:如果上傳節點是DN,則上傳該節點;如果上傳節點是NN,則隨機選擇DN ;第二副本:放置在不同機架的DN上 ;第三副本:放置在與第二副本相同機架的不同DN上

【Hadoop機架感知策略】

在分布式集群下,由于機架的的槽位和交換機網口數量的限制,使得集群上的機器不得不跨越機架,通常一個大型的集群會跨越很多機架。一般情況機架內機器的通訊會快于跨機架機器之間的通訊,并且機架之間機器的網絡通信通常受到上層交換機間網絡帶寬的限制。通過機架感知,可以帶來性能和安全性的提升。沒有配置機架信息時,所有的機器hadoop都默認在同一個默認的機架下,名為/default-rack,這種情況下,任何一臺 datanode機器,不管物理上是否屬于同一個機架,都會被認為是在同一個機架下,此時就很容易出現增加機架間網絡負載的情況。當配置了機架感知信息以后,hadoop在選擇三個datanode時就充分考慮副本機制存放策略,將副本分散在不同機架下,盡量地減少網絡帶寬資源的消耗。

【MapReduce簡介】

MapReduce是一種分布式計算模型,由Google提出,主要用于搜索領域,解決海量數據的計算問題。MapReduce的核心,就是對一個需要計算的任務進行拆分,然后并行處理。MapReduce合并了兩種經典函數:映射(Mapping)對集合里的每個目標應用同一個操作。化簡歸約(Reducing)遍歷集合中的元素來返回一個綜合的結果。首先Client向JobTracker提交一個任務。JobTracker將任務分配到一個或者多個TaskTracker進行處理。不同的TaskTracker上,有的運行的是Map階段的任務,有的運行是Reduce階段的任務。對于map階段,首先對輸入的內容進行分割(InputSplit),不同Mapper任務負責各自的分割后的內容的映射。對于Reduce階段,接受多個Mapper的輸出,進行歸一后,得到最終的輸出。

【MapReduce執行步驟】

  1. map任務處理
    1.1讀取輸入文件內容,對輸入文件的每一行,解析成key、value對。每一個鍵值對調用一次map函數。
    1.2寫自己的邏輯,對輸入的key、value處理,轉換成新的key、value輸出。
    1.3對輸出的key、value進行分區。
    1.4對不同分區的數據,按照key進行排序、分組。相同key的value放到一個集合中。
    1.5(可選)分組后的數據進行歸約。
    2.reduce任務處理
    2.1對多個map任務的輸出,按照不同的分區,通過網絡傳輸到不同的reduce節點。
    2.2對多個map任務的輸出進行合并、排序。執行reduce函數的具體數據處理邏輯,對輸入的key、value處理,轉換成新的key、value輸出。
    2.3將reduce的計算結果輸出保存到文件中。

【MapReduce的主要設計思想和特征】

1、向“外”橫向擴展,而非向“上”縱向擴展(Scale “out", not “up”)
即MapReduce集群的構筑選用價格便宜、易于擴展的大量低端商用服務器,而非價格昂貴、不易擴展的高端服務器。
對于大規模數據處理,由于有大量數據存儲需要,基于低端服務器的集群遠比基于高端服務器的集群優越。
2、失效被認為是常態(Assume failures are common)
MapReduce集群中使用大量的低端服務器,因此節點硬件失效和軟件出錯是常態。
MapReduce并行計算軟件框架使用了多種有效的機制,如節點自動重啟技術,使集群和計算框架具有對付節點失效的健壯性,能有效處理失效節點的檢測和恢復。當失效節點恢復后能自動無縫加入集群,不會因為節點失效而影響計算服務的質量。
3、處理向數據遷移(Moving processing to the data)
MapReduce采用了數據/代碼互定位的技術方法,計算節點盡量負責計算其本地存儲的數據,以發揮數據本地化特點(locality),僅當節點無法處理本地數據時,再采用就近原則尋找其它可用計算節點,并把數據傳送到該可用計算節點。
4、順序處理數據、避免隨機訪問數據(Process data sequentially and avoid random access)
5、為應用開發者隱藏系統層細節(Hide system-level details from the application developer)
大規模數據處理時程序員需要考慮諸如數據分布存儲管理、數據分發、數據通信和同步、計算結果收集等諸多細節問題?。MapReduce提供了一種抽象機制隔離系統層細節,以致力于應用本身的算法設計。

【MapReduce提供的主要功能】

1、任務調度:計算作業(job)被細分為多個計算任務(tasks), 為任務分配計算節點; 同時負責監控節點的執行狀態和計算性能優化處理, 如對最慢的計算任務采用多備份執行、選最快完成者作為結果。
2、數據/代碼互定位:減少數據通信,本地化數據處理,即一個計算節點盡可能處理其本地磁盤上所分布存儲的數據,實現了代碼向數據的遷移;當無法進行這種本地化數據處理時,盡可能就近尋找數據以減少通信延遲。
3、出錯處理:MapReducer能檢測并隔離出錯節點,將調度分配新的節點接管出錯節點的計算任務
?4、Combiner和Partitioner:為了減少數據通信開銷,中間結果數據進入reduce節點前需要進行合并(combine)處理,把具有同樣主鍵的數據合并到一起避免重復傳送; 一個reducer節點所處理的數據可能會來自多個map節點。因此, map節點輸出的中間結果需使用一定的策略進行適當的劃分(partitioner)處理,保證相關數據發送到同一個reducer節點。

【Mapreduce之JobTracker】

JobTracker主要負責資源監控和作業調度。JobTracker監控所有TaskTracker與作業的健康狀況,一旦發現失敗情況后,其會將相應的任務轉移到其它節點。同時,JobTracker會跟蹤任務的執行進度、資源使用量等信息,并將這些信息告訴任務調度器,而調度器會在資源出現空閑時,選擇合適的任務使用這些資源。在Hadoop中,任務調度器是一個可插拔的模塊,用戶可以根據自己的需要設計相應的調度器。

【Mapreduce之TaskTracker】

TaskTracker會周期性地通過Heartbeat將本節點上資源的使用情況和任務的運行進度匯報給JobTracker,同時接收JobTracker發送過來的命令并執行相應的操作(例如啟動新任務、殺死任務等)。TaskTracker使用“slot”等量劃分本節點的數量,“slot”代表計算資源(CPU、內存等)。一個Task獲取到一個slot后才有機會運行,而Hadoop調度器的作用就是將各個TaskTracker上的空閑slot分配給Task使用。Slot分為Map slot和Reduce slot兩種,分別提供Map Task和Reduce Task。TaskTracker通過slot數目限定Task的并發度。

【Mapreduce之Task】

Task分為Map Task和Reduce Task兩種,均由TaskTracker啟動。HDFS以固定大小的block為基本單位存儲數據,而對于MapReduce而言,其處理基本單位是分片(split)。split是一個邏輯概念,它只包含一些元數據信息,比如數據起始位置、數據長度、數據所在節點等等。它的劃分方法完全由用戶自己決定,但是建議split的劃分大小與HDFS的block大小一致。但需要注意的是,split的多少決定Map Task的數目,因為每個split會交由一個Map Task處理。因此,合理地設置Job中Tasks數的大小能顯著的改善Hadoop執行的性能。增加task的個數會增加系統框架的開銷,但同時也會增強負載均衡并降低任務失敗的開銷。

【經典MapReduce(MRv1)的局限性】

經典MapReduce的最嚴重的限制主要在于可伸縮性、資源利用和對與MapReduce不同的工作負載的支持。在MapReduce框架中,作業執行受JobTracker和TaskTracker進程控制。大型的Hadoop集群會出現單個JobTracker導致的可伸縮性瓶頸。
此外,較小和較大的Hadoop集群都從未最高效地使用他們的計算資源。在HadoopMapReduce中,每個從屬節點上的計算資源由集群管理員分解為固定數量的map和reduceslot,這些slot不可替代。設定mapslot和reduceslot的數量后,節點在任何時刻都不能運行比mapslot更多的map任務,即使沒有reduce任務在運行。這影響了集群的利用率,因為在所有mapslot都被使用時,無法再使用任何reduceslot,即使它們可用,反之亦然。并且Hadoop設計為僅運行MapReduce作業。隨著替代性的編程模型的出現,除MapReduce外,越來越需要為可通過高效的、公平的方式在同一個集群上運行并共享資源的其他編程模型提供支持。

【YARN:下一代Hadoop計算平臺】

YARN(YetAnotherResourceNegotiator)是Hadoop2.0版本為集群引入的一個資源管理層。基本思想是將JobTracker的兩個主要功能:資源管理作業調度和監控分離,它將JobTracker守護進程的職責分離了出來。其中資源管理器(ResourceManager,RM)用來代替集群管理器,ApplicationMaster(AM)代替一個專用且短暫的JobTracker,節點管理器(NodeManager,NM)代替TaskTracker,一個分布式應用程序代替一個MapReduce作業。與第一版Hadoop中經典的MapReduce引擎相比,YARN在可伸縮性、效率和靈活性上有著明顯的優勢。小型和大型Hadoop集群都從YARN中受益匪淺。對于開發人員來說這些更改幾乎也是透明的,因此可以使用相同的MapReduceAPI和CLI運行未經修改的MapReduce作業。

【YARN:Container】

Container是YARN中的資源抽象,它封裝了某個節點上的多維資源,如CPU、內存、磁盤、網絡等。當ApplicationMaster向資源管理器RM申請資源時,RM向AM返回的資源便是用Container表示的。YARN會為每個任務分配一個Container,且該任務只能使用該Container中描述的資源。Container是一個動態資源劃分單位,是根據應用程序的需求自動生成的。目前,YARN僅支持CPU和內存兩種資源。既然一個Container指的是具體節點上的計算資源,這就意味著Container中必定含有計算資源的位置信息:計算資源位于哪個機架的哪臺機器上。所以應用在請求某個Container時,其實是向某臺機器發起請求,請求這臺機器上的CPU和內存資源。任何一個job或application必須運行在一個或多個Container中,在Yarn框架中,ResourceManager只負責告訴ApplicationMaster哪些Containers可以用,ApplicationMaster還需要去找NodeManager請求分配具體的Container。

【YARN:ResourceManager(RM)】

RM是一個全局的資源管理器,負責整個系統的資源管理和分配。它主要由兩個組件構成:調度器(Scheduler)和應用程序管理器(Applications Manager,ASM)。(1)調度器(分配Container)根據容量、隊列等限制條件,將系統中的資源分配給各個正在運行的應用程序。它不再從事任何與具體應用程序相關的工作,比如不負責監控或者跟蹤應用的執行狀態等,也不負責重新啟動因應用執行失敗或者硬件故障而產生的失敗任務,這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配。此外,該調度器是一個可插拔的組件,用戶可根據自己的需要設計新的調度器,YARN提供了多種直接可用的調度器,比如Fair Scheduler和Capacity Scheduler等。(2)應用程序管理器,負責管理整個系統中所有應用程序,包括應用程序提交、與調度器協商資源以啟動ApplicationMaster、監控ApplicationMaster運行狀態并在失敗時重新啟動等。

【YARN:ApplicationMaster(AM)和NodeManager(NM)】

在用戶提交一個應用程序時,ApplicationMaster 作為輕量型進程實例會啟動來協調應用程序內的所有任務的執行。這包括監視任務,重新啟動失敗的任務,推測性地運行緩慢的任務,以及計算應用程序計數器值的總和。這些職責以前分配給所有作業的單個 JobTracker。ApplicationMaster 和屬于它的應用程序的任務,在受 NodeManager 控制的資源容器中運行。NodeManager(NM)則是每個節點上的資源和任務管理器。一方面,它定時地向RM匯報本節點的資源使用情況和Container運行狀態;另一方面,它接受并處理來自AM的Container啟動/停止等各種請求。NodeManager沒有固定數量的map和reduce slots,它是TaskTracker的一種更加普通和高效的版本。

44. 【數據庫 VS 數據倉庫】

數據庫和數據倉庫其實是一樣的或者及其相似的,都是通過某個數據庫軟件,基于某種數據模型來組織、管理數據。數據庫通常更關注業務交易處理(OLTP),而數據倉庫更關注數據分析層面(OLAP),由此產生的數據庫模型上也會有很大的差異。
數據庫通常追求交易的速度,交易完整性,數據的一致性等,在數據庫模型上主要遵從范式模型,從而盡可能減少數據冗余,保證引用完整性。數據倉庫是一個面向主題的(Subject Oriented),集成的(Integrate),相對穩定的(Non-volatile),反映歷史變化(Time Variant)的數據集合,用于支持管理決策。主要區別在于:數據庫是面向事務的設計,數據倉庫是面向主題設計的;數據庫一般存儲在線交易數據,數據倉庫存儲的一般是歷史數據;數據庫設計是盡量避免冗余,數據倉庫在設計時有意引入冗余;數據庫是為了捕獲數據而設計,數據倉庫是為了分析數據而設計;

45. 【Hive簡介】

Hive是基于Hadoop的一個數據倉庫工具。它提供了一系列的工具,可以用來進行數據提取轉化加載(ETL),這是一種可以存儲、查詢和分析存儲在 Hadoop 中的大規模數據的機制,可以將結構化的數據文件映射為一張數據庫表。Hive 定義了簡單的類SQL查詢語言,稱為HQL,可以將sql語句轉換為MapReduce任務進行運行,它允許熟悉SQL的用戶查詢數據,其優點是學習成本低,可以通過類SQL語句快速實現簡單的MapReduce統計,不必開發專門的MapReduce應用,十分適合數據倉庫的統計分析。同時,這個語言也允許熟悉MapReduce開發者的開發自定義的mapper 和reducer來處理內建的mapper和reducer無法完成的復雜的分析工作。

46. 【Hive體系架構】

Hive是客戶端服務器(C/S)模式。
服務端組件:
Driver組件:該組件包括Complier、Optimizer和Executor,它的作用是將我們寫的HiveQL(類SQL)語句進行解析、編譯優化,生成執行計劃,然后調用底層的mapreduce計算框架。
Metastore組件:元數據服務組件,這個組件存儲hive的元數據,hive的元數據存儲在關系數據庫里,hive支持的關系數據庫有derby、mysql。元數據對于hive十分重要,因此hive支持把metastore服務獨立出來,安裝到遠程的服務器集群里,從而解耦hive服務和metastore服務,保證hive運行的健壯性。
Thrift服務:thrift是facebook開發的一個軟件框架,它用來進行可擴展且跨語言的服務的開發,hive集成了該服務,能讓不同的編程語言調用hive的接口。
客戶端組件:
CLI:command line interface,命令行接口。
Thrift客戶端:hive架構的許多客戶端接口是建立在thrift客戶端之上,包括JDBC和ODBC接口。
WEBGUI:hive客戶端提供了一種通過網頁的方式訪問hive所提供的服務。這個接口對應hive的hwi組件(hive web interface),使用前要啟動hwi服務。

47. 【Hive特點】

1、Hive 通過類 SQL 來分析大數據,而避免了寫 MapReduce 程序來分析數據,這樣使得分析數據更容易
2、將數據映射成數據庫和一張張的表,庫和表的元數據信息一般存在關系型數據庫上(比如 MySQL)
3、本身并不提供數據的存儲功能,數據一般都是存儲在 HDFS 上的(對數據完整性、格式要求并不嚴格)
4、容易擴展自己的存儲能力和計算能力,這個是繼承自 hadoop (適用于大規模的并行計算)
5、Hive支持用戶自定義函數,用戶可以根據自己的需求來實現自己的函數
6、良好的容錯性,節點出現問題SQL仍可完成執行
7、專為 OLAP(在線分析處理) 設計,不支持事務

48. 【Hive數據模型】

Hive沒有專門的數據存儲格式,也沒有為數據建立索引,用戶可以非常自由的組織Hive中的表,只需要在創建表的時候告訴
Hive數據中的列分隔符和行分隔符,Hive就可以解析數據。Hive中所有的數據都存儲在HDFS中,Hive中包含以下數據模型:表(Table),外部表(ExternalTable),分區(Partition),桶(Bucket)。
表:Hive中的Table和數據庫中的Table在概念上是類似的,每一個Table在Hive中都有一個相應的目錄存儲數據。
外部表:指向已經在HDFS中存在的數據,和Table在元數據的組織上是相同的,但實際數據的存儲則有較大的差異。當刪除一個外部表時,僅刪除元數據,表中的數據不會真正被刪。
分區:在Hive中,表中的一個Partition對應于表下的一個目錄,所有的Partition的數據都存儲在對應的目錄中。方便對表的管理以及提高查詢效率。
桶:Buckets對指定列計算hash,根據hash值切分數據,目的是為了并行,每一個Bucket對應一個文件。

49. 【Hive部署方式】

1、內嵌模式:使用內嵌的Derby數據庫作為存儲元數據,Derby只能接受一個Hive會話的訪問,不能用于生產; hive服務、metastore服務、derby服務運行在同一個進程中。
2、本地模式:本地安裝mysql,替代derby存儲元數據,是一個多用戶多客戶端的模式,作為公司內部使用Hive;hive服務和metastore服務運行在同一個進程中,mysql數據庫則是單獨的進程,可以同一臺機器,也可以在遠程機器上。
3、遠程模式(Remote): 遠程安裝mysql 替代derby存儲元數據;Hive服務和metastore在不同的進程內,也可能是不同的機器;

50. 【Hive常用的文件存儲格式】

  1. textfile:文本文件
    Hive默認格式,數據不做壓縮,磁盤開銷大,數據解析開銷大。
  2. Sequencefile:二進制文件
    SequenceFile是Hadoop API 提供的一種二進制文件,它將數據(key,value)的形式序列化到文件中。
    這種二進制文件內部使用Hadoop的標準的Writable接口實現序列化和反序列化。它與Hadoop API中的MapFile是互相兼容的。
    Hive中的SequenceFile繼承自Hadoop API 的SequenceFile,不過它的key為空,使用value 存放實際的值, 這樣是為了避免MR 在運行map階段的排序過程。
  3. Rcfile:
    RCFile是Hive推出的一種專門面向列的數據格式。 它遵循“先按列劃分,再垂直劃分”的設計理念。
    當查詢過程中,針對它并不關心的列時,它會在IO上跳過這些列。但在讀取所有列的情況下,RCFile的性能反而沒有SequenceFile高。

51. 【Hive數據類型】

  1. 基礎數據類型,與關系型數據庫類似:
    TINYINT,SMALLINT,INT,BIGINT,BOOLEAN,FLOAT,DOUBLE,STRING,BINARY,TIMESTAMP,DECIMAL,CHAR,VARCHAR,DATE。
  2. 復雜數據類型:
    包括ARRAY,MAP,STRUCT,UNION,這些復雜類型是由基礎類型組成的。
    ARRAY:ARRAY類型是由一系列相同數據類型元素組成的,這些元素可以通過下標來訪問。比如有一個ARRAY類型的變量fruits,它是由[‘apple’,’orange’,’mango’]組成,那么可以通過fruits[1]來訪問orange;
    MAP:MAP包含key->value鍵值對,可以通過key來訪問元素。比如"userlist"是一個map類型(其中username是key,password是value),那么我們可以通過userlist[‘username’]來得到這個用戶對應的password;
    STRUCT:STRUCT可以包含不同數據類型的元素。這些元素可以通過點的方式來得到,比如user是一個STRUCT類型,那么可以通過user.address得到這個用戶的地址。

52. 【Hive HQL】

hive中的HQL是一種SQL方言,支持絕大部分SQL-92標準,并對其做了一些擴展。
數據庫操作:
創建數據庫:hive > CREATE DATABASE IF NOT EXISTS test;
查看某個已存在的數據庫:hive> DESCRIBE DATABASE test;
表操作:
CREATE TABLE IF NOT EXISTS test.student(
name STRING COMMENT 'student name',
age INT COMMENT 'student age')
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\001'
LINES TERMINATED BY '\n'
STORED AS TEXTFILE
LOCATION '/user/hive/warehouse/test.db/student';
查看表:hive> DESC FORMATTED student
刪除表:hive> DROP TABLE IF EXISTS test
增加表分區:hive> ALTER TABLE test ADD PARTITION(x=x1,y=y2) LOCATION '/USER/TEST/X1/Y1'
刪除表分區:hive> ALTER TABLE test DROP PARTITION(x=x1,y=y2)
更多關于HQL詳細語法可參考Hive官方使用手冊說明:https://cwiki.apache.org/confluence/display/Hive/LanguageManual

53. 【hive大表關聯查詢數據傾斜解決方案】

傾斜原因:
map輸出數據按key Hash的分配到reduce中,由于key分布不均勻、業務數據本身的特性、建表時考慮不周、以及SQL語句編寫不當等原因造成的reduce 上的數據量差異過大。
解決方案

  1. 參數調節:
    hive.map.aggr = true
    hive.groupby.skewindata=true
    有數據傾斜的時候進行負載均衡,當選項設定位true,生成的查詢計劃會有兩個MR Job。第一個MR Job中,Map的輸出結果集合會隨機分布到Reduce中,每個Reduce做部分聚合操作,并輸出結果,這樣處理的結果是相同的Group By Key有可能被分發到不同的Reduce中,從而達到負載均衡的目的;第二個MR Job再根據預處理的數據結果按照Group By Key 分布到 Reduce 中(這個過程可以保證相同的 Group By Key 被分布到同一個Reduce中),最后完成最終的聚合操作。
  2. SQL 語句調節:
    1)、選用join key分布最均勻的表作為驅動表。做好列裁剪和filter操作,以達到兩表做join 的時候,數據量相對變小的效果。
    2)、大小表Join:
    使用map join讓小的維度表(1000 條以下的記錄條數)先進內存。在map端完成reduce.
    4)、大表Join大表:
    把空值的key變成一個字符串加上隨機數,把傾斜的數據分到不同的reduce上,由于null 值關聯不上,處理后并不影響最終結果。
    5)、count distinct大量相同特殊值:
    采用sum() group by的方式來替換count(distinct)完成計算。

【數據庫事務四要素】

原子性(Atomicity):一個事務要么全部執行,要么全部不執行。一個事務不可能只執行了一半就停止了。比如一個事情分為兩步完成才可以完成,那么這兩步必須同時完成,要么一步也不執行,絕不會停留在某一個中間狀態。如果事物執行過程中,發生錯誤,系統會將事物的狀態回滾到最開始的狀態。
一致性(Consistency):事務的運行并不改變數據庫中數據的一致性。無論并發事務有多少個,必須保證數據從一個一致性的狀態轉換到另一個一致性的狀態。例如有 a、b 兩個賬戶,分別都是10。當a增加5時,b也會隨著改變,總值20是不會改變的。
隔離性(Isolation):指兩個以上的事務不會出現交錯執行(可能會導致數據不一致)的狀態。如果有多個事務,運行在相同的時間內,執行相同的功能,事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。這種屬性有時稱為串行化,為了防止事務操作間的混淆,必須串行化或序列化請求,使得在同一時間僅有一個請求用于同一數據。
持久性(Durability):事務執行成功以后,該事務對數據庫所作的更改永久保存在數據庫中,不會無緣無故的回滾。

【行存儲和列存儲】

行式存儲把一行中的數據值串在一起存儲起來,然后再存儲下一行的數據,以此類推。行存儲適合數據存儲寫入、更新較多的場景,比如OLTP。當數據量很大時,查詢性能遠不及列存儲。像SQLserver,Oracle,mysql等傳統數據庫屬于行式數據庫范疇。列式存儲把一列中的數據值串在一起存儲起來,然后再存儲下一列的數據,以此類推。列存儲不適合數據頻繁寫入、更新的場景,主要適合頻繁查詢的場景,大數據環境下優勢更明顯,比如分布式實時查詢。由于查詢中的選擇規則是通過列來定義的,因此整個數據庫是自動索引化的。按列存儲每個字段的數據聚集存儲,在查詢只需要少數幾個字段的時候,能大大減少讀取的數據量,同字段的數據聚集存儲,也容易為這種聚集存儲設計更好的壓縮、解壓算法,降低系統IO。Greenplum、Vertica、Hbase等屬于列式數據庫。

【HBase 簡介】

Apache HBase是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統,利用HBase技術可在廉價PC上搭建起大規模存儲集群。
HBase利用Hadoop HDFS作為其文件存儲系統,基于行鍵、列鍵和時間戳建立索引,是一個可以隨機訪問存儲和檢索數據的"NoSQL" 數據庫。HBase不限制存儲的數據的種類,允許動態的、靈活的數據模型,不用SQL語言,也不強調數據之間的關系。HBase被設計成在一個服務器集群上運行,可以非常方便地橫向擴展。
適用場景于場景:存在高并發讀寫、表結構的列族經常需要調整、存儲結構化或半結構化數據、高并發的key-value存儲、key隨機寫入,有序存儲、針對每個key對應的值需要多版本保存。

【Hbase 特點】

1、海量存儲
Hbase適合存儲PB級別的海量數據,在PB級別的數據以及采用廉價PC存儲的情況下,能在幾十到百毫秒內返回數據。
2、列式存儲
數據在表中是按某列的數據聚集存儲,數據即索引,只訪問查詢涉及的列時,可以大量降低系統的I/O
3、易擴展
HBase底層基于HDFS,支持擴展,并且可以隨時添加或者減少節點。
4、高可靠:基于zookeeper的協調服務,能夠保證服務的高可用行。HBase使用WAL和replication機制,前者保證數據寫入時不會因為集群異常而導致寫入數據的丟失,后者保證集群出現嚴重問題時,數據不會發生丟失和損壞。
5、稀疏存儲
傳統行數存儲的數據存在大量NULL的列,也需要占用存儲空間,造成存儲空間的浪費,在列族中HBase為空的列并不占用空間,因此表可以設計的很稀疏。
6、高性能
底層的LSM數據結構、Region分區、RowKey有序排列、主鍵索引和緩存機制使得HBase支持高并發用戶數的高速讀寫訪問。

【Hbase 表邏輯結構】

表(table):劃分數據集合的概念,和傳統的db中的表的概念是一樣的。
行鍵(RowKey):一行數據的唯一標示,要想操作(read/write)一條數據,必須通過行鍵,任何字符串都可以作為行鍵。表中的行根據行鍵進行排序存儲。
列族(columnFamily):簡單的認為是一系列“列”的集合。列族是以單獨的文件進行存儲。
列限定符(columnQualifier):列族中的數據定位通過列限定符,每個列族可以有一個或多個列成員(ColumnQualifier),列成員不需要在表定義時給出,新的列族成員可以隨后按需、動態加入。
單元格(cell):由行鍵,列族:限定符,時間戳唯一決定,Cell中的數據是沒有類型的,全部以字節碼形式存貯,主要用來存儲數據。
時間戳(Timestamp):每個值都會有一個timestamp,作為該值特定版本的標識符。默認情況下,timestamp代表了當數據被寫入的時間,但也可以在把數據放到cell時指定不同的timestamp。

【HBase 相關模塊】

HBaseMaster:用于協調多個RegionServer,偵測各個RegionServer之間的狀態,并平衡RegionServer之間的負載。負責分配Region給RegionServer。HBase允許多個Master節點共存,但只有一個Master是提供服務的,其他的Master節點處于待命的狀態。當正在工作的Master節點宕機時,其他的Master則會接管HBase的集群。
RegionServer:一個RegionServer包括了多個Region。RegionServer的作用只是管理表格,以及實現讀寫操作。Client直接連接RegionServer獲取HBase中的數據。Region是真實存放HBase數據的地方,Region是HBase并行化的基本單元。如果當一個表格很大,并由多個CF組成時,那么表的數據將存放在多個Region,并且在每個Region中會關聯多個存儲的單元(Store)。
Zookeeper:作為HBaseMaster的HA解決方案。保證了至少有一個HBaseMaster處于運行狀態。并且Zookeeper負責Region和RegionServer的注冊。

【HBase 使用建議】

首先一點必須謹記:HBase并不適合所有問題,其設計目標并不是替代RDBMS,而是對RDBMS的一個重要補充,尤其是對大數據的場景。首先,要有足夠多數據,如有上億或上千億行數據,HBase才會是一個很好的備選。其次,需要確保業務上可以不依賴RDBMS的額外特性,例如,列數據類型,二級索引,SQL查詢語言等。再而,需要確保有足夠硬件規模。比如集群小于5個節點時并不能發揮出應有的性能。一個HBase數據庫是否高效,很大程度會和Row-Key的設計有關。因此,如何設計Row-key是使用HBase時一個非常重要的話題。隨著數據訪問方式的不同,Row-Key的設計也會有所不同。概括起來宗旨只有一個,那就是盡可能使數據均勻的分布在集群中。例如當客戶端需要頻繁的寫一張表,隨機的RowKey會獲得更好的性能。當客戶端需要頻繁的讀一張表,有序的RowKey則會獲得更好的性能。對于時間連續的數據(例如log),有序的RowKey會能方便查詢一段時間的數據(Scan操作)。

【HBase與RDBMS的對比】

HBase適合于非結構化數據存儲的數據庫。與傳統數據庫主要區別如下:
數據類型:HBase只有簡單的字符類型,所有的類型都是交由用戶自己處理,它只保存字符串。而關系數據庫有豐富的類型和存儲方式;
數據操作:HBase只有很簡單的插入、查詢、刪除、清空等操作,表和表之間是分離的,沒有復雜的表和表之間的關系,而傳統數據庫通常有各式各樣的函數和連接操作;
存儲模式:HBase基于列存儲,每個列族由幾個文件保存,不同列族的文件是分離的。傳統的關系數據庫是基于表格結構和行模式保存的;
可伸縮性: HBase能夠容易的增加或者減少硬件數量;
數據維護:HBase更新操作時,舊的版本仍然保留,實際上時插入了新數據。傳統關系數據庫是替換修改。

【HBase表的設計(RowKey的設計)】

Rowkey的設計一般都是根據具體業務需求來的,總的來說,需要根據rowkey的字典序排列,唯一性特性設計出高效讀取和負載均衡的rowkey,以下是幾個大概的設計原則:
長度原則:越小越好,最長不能超過64kb,一般10-100個字節;
個數原則:指列簇的個數,盡量控制在2個以內;
散列原則:region是根據rowkey劃分的,那么rowkey的散列就可以使得數據的負載變得均衡,一般來說可以通過 :
加隨機前綴、加hash值、rowkey反轉等方法;
rowkey唯一原則:必須在設計上保證其唯一性,rowkey是按照字典順序排序存儲的,因此設計rowkey的時候,要充分利用這個排序的特點,將經常讀取的數據存儲到一塊,將最近可能會被訪問的數據放到一塊。 比如:
我們需要某個時間端的數據進行分析,那么以timestamp-key的形式,我們很容易就可以查詢到連續的時間段的數據。

【Hbase表的設計(預分區)】

默認的hbase會有一個region,當數據越來越大,那么這個region管理的數據越來越多,當超過閾值就會發生split操作,而split操作會導致我們的hbase有一段不可用的時間,那么為了盡量規避這個問題,所以我們需要預分區。所謂預分區其實就是預先劃分好region,每個region都有一個startkey和一個endkey,這樣也就確定了這個region所管理的數據的范圍。劃分原則:首先需要對數據的分布和數據量的增長有一個預測,根據數據量確定分區數,然后再對數據進行合理的rowkey設計,以一個簡單的例子來說明:
假設預測數據會有50G,那么劃分為5個分區,分別是:[-∞ - 1),[1 - 2),[2 - 3),[3 - 4),[4 - +∞),
rowkey可以設計成 [0-5)的隨機數 + key,這樣數據就會均勻的分布在預先設計好的分區上。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容