什么是數據尺上？

數據庫的ACID特性

• 原子性(Automicity)
• 一致性
• 隔離性
• 持久性

• 實時性
• 業(yè)務屬性(數據業(yè)務屬性不同處理方式不同)

什么是大數據蛉威？

流程數據再多日丹，也到不了大數據的級別
業(yè)務數據？什么類型的業(yè)務數據蚯嫌？
從Lucene到Nutch到Hadoop

傳統J2EE的瓶頸

數據存儲哲虾，數據檢索丙躏，多用戶同時訪問，關系型數據庫

為什么需要大數據技術束凑？大數據的技術體系

分布式晒旅，并行計算的出現，使得數據存儲與數據計算都發(fā)生了本質上的區(qū)別
大數據存儲與計算是怎樣的汪诉，有什么不同废恋。

計算機硬盤的發(fā)展趨勢：尋址時間的提升遠遠不敵于傳輸速率的提升。
尋址是將磁頭移動到特定硬盤位置進行讀/寫操作的過程扒寄，它是導致硬盤操作延遲的主要原因鱼鼓，而傳輸速率取決于硬盤的帶寬。

如果數據訪問模式中包含大量的硬盤尋址该编，那么讀取大量數據集就必然會花更長的時間迄本。
如果數據庫系統只更新一小部分記錄，那么傳統的B樹(關系型數據庫的數據結構课竣，受限于尋址的速率)就更有優(yōu)勢岸梨。但數據庫系統如果有大量數據更新時，B樹的效率就明顯落后于MapReduce稠氮。
讀時模式與寫時模式曹阔。
寫時模式在寫入時格式也要寫入？(本人理解的是否到位隔披？)
讀時模式在處理數據時才對數據進行解釋赃份。
Hadoop非常適合分析各種日志(非規(guī)范化數據記錄，關系型數據往往是規(guī)范的)文件奢米。
MapReduce以及Hadoop中其他的處理模型是可以隨著數據規(guī)模線性伸縮的抓韩。對數據分區(qū)后，函數原語(如map和reduce)能夠在各個分區(qū)上并行工作鬓长。這意味著谒拴，如果輸入的數據量是原來的兩倍，那么作業(yè)的運行時間也需要兩倍涉波。但如果集群規(guī)模擴展為原來的兩倍英上，那么作業(yè)的運行速度卻仍然與原來一樣快。SQL查詢一般不具備該特性啤覆。

與網格計算苍日、高性能計算(HPC)的區(qū)別

廣義上講，基于消息傳遞接口(Message Passing Interface,MPI)的高性能計算采用的方法是將作業(yè)分散到集群的各臺機器上窗声，這些機器訪問存儲區(qū)域網絡(SAN)所組成的共享文件系統相恃。這比較適用于“計算密集型”的作業(yè)，但如果節(jié)點需要訪問的數據量更龐大(高達幾百GB)笨觅，很多計算節(jié)點就會因為網絡帶寬的瓶頸問題而不得不閑下來等數據拦耐。
Hadoop盡量在計算節(jié)點上存儲數據耕腾，以實現數據的本地快速訪問∩迸矗“數據本地化(data locality)”特性是Hadoop數據處理的核心幽邓，并因此而獲得良好的性能。
意識到網絡帶寬是數據中心環(huán)境最珍貴的資源(到處復制數據很容易耗盡網絡帶寬)之后火脉，Hadoop通過顯式網絡拓撲結構來保留網絡帶寬牵舵，這種排列方式并沒有降低Hadoop對計算密集型數據進行分析的能力。

數據流的顯性倦挂、隱形

并行存儲與數據副本

為什么需要并行存儲畸颅？
單機讀寫瓶頸
為什么需要數據副本？
硬件故障問題方援，如果沒有副本没炒，一臺機器故障會遺失數據，只能等待機器恢復后犯戏，這部分數據才會恢復送火。

HDFS

帶副本的分布式存儲文件系統。
超大文件：幾百MB先匪，幾百GB种吸，甚至幾百TB大小的文件。
流式數據訪問
商用硬件：普通硬件呀非，故障率高坚俗。HDFS被設計成能夠繼續(xù)運行且不讓用戶察覺到明顯的中段。
低時間延遲的數據訪問：并不適合在HDFS上運行岸裙，HDFS式為高數據吞吐量應用優(yōu)化的猖败，這可能會以提高時間延遲為代價。對低延遲的訪問需求降允，HBase是更好的選擇恩闻。
大量的小文件：并不適合大兩小文件，會占滿namenode的內存剧董。
多用戶寫入幢尚，任意修改文件：并不支持，只支持單個寫入者送滞，并且寫操作是以append的方式添加的侠草。不支持多個寫入者的操作，也不支持在文件任意位置進行修改犁嗅。

數據塊

網絡拓撲

同一節(jié)點上的進程
同一機架上的不同節(jié)點
同一數據中心中不同機架上的節(jié)點
不同數據中心中的節(jié)點

Hadoop的默認布局策略是在運行客戶端的節(jié)點上放第1個復本（如果客戶端運行在集群之外，就隨機選擇一個節(jié)點晤碘，系統會避免挑選那些存儲太滿或太忙的節(jié)點）褂微。第2個復本放在與第一個不同且隨機另外選擇的某個機架中的節(jié)點上功蜓。第3個復本與第2個復本放在同一個機架上，且隨機選擇另一個節(jié)點宠蚂。其他復本放在集群中隨機選擇的節(jié)點上式撼，系統會盡量避免在同一個機架上放太多復本。

數據聚合

分布式存儲轉換為一個數據集求厕。

MapReduce

每個查詢需要處理整個數據集或至少一個數據集的絕大部分著隆。MR并不適合交互式分析，不可能執(zhí)行一條查詢并在幾秒內或更短的時間內得到結果呀癣。典型情況下美浦， 執(zhí)行查詢需要幾分鐘或更多時間。因此项栏，MR更適合沒有用戶現場等待查詢結果的離線使用場景浦辨。

怎么解決MR的在線訪問問題呢？

MapReduce的工作流
目前已經知道了MapReduce的應用開發(fā)機制沼沈，那么如何將數據處理問題轉化成MapReduce模型呢流酬？日常需要處理數據問題的場景都發(fā)生在什么時候？
數據入庫列另，數據查詢芽腾。

如果處理過程更復雜，這種復雜度一般是因為有更多的MapReduce作業(yè)页衙，而不是更復雜的map和reduce函數晦嵌。換言之，通常是增加更多的作業(yè)拷姿，而不是增加作業(yè)的復雜度惭载。對于更復雜的問題，可以(其實是必須)使用比MapReduce更高級的技術响巢，比如Pig描滔，Hive，Cascading踪古，Crunch含长，Spark。一個直接的好處是伏穆，有了它之后拘泞，就用不著處理到MapReduce作業(yè)的轉換，而是集中精力分析正在執(zhí)行的任務枕扫。

關系型數據庫的瓶頸陪腌？
關系型數據庫的索引原理：
B-Tree是最常用的索引數據結構。

JobControl

YARN(Yet Another Resource Negotiator)

Hadoop的集群資源管理系統。YARN被引入Hadoop 2诗鸭，最初是為了改善MapReduce的實現染簇，但它具有足夠的通用性，同樣可以支持其他的分布式計算模式强岸。
YARN提供請求和使用集群資源的API锻弓，但這些API很少直接用于用戶代碼。相反蝌箍，用戶代碼中用的是分布式計算框架提供的更高層API青灼，這些API建立在YARN之上且向用戶隱藏了資源管理細節(jié)。
一些分布式計算框架(MapReduce,Spark,Tez)作為YARN應用運行在集群計算層(YARN)和集群存儲層(HDFS和HBase)上妓盲。
還有一層應用是運行在計算框架之上的處理框架杂拨，如Pig，Hive本橙，Crunch等等扳躬。

YARN本身不會為應用的各部分（客戶端、master和進程）彼此間通信提供任何手段甚亭。大多數重要的人YARN應用使用某種形式的遠程通信機制（例如Hadoop的RPC層）來向客戶端傳遞狀態(tài)更新和返回結果贷币，但這些通信機制都是專屬于各應用的。

HA(High availability)

YARN中的調度 important？髡Ｒ畚啤！暇唾！

• FIFO調度
• 容量調度
• 公平調度

Hadoop生態(tài)圈

HBase:可以提供在線訪問的組件

使用HDFS作為底層存儲促脉。提供對單行數據的在線讀寫訪問，還提供對數據塊的讀寫批處理策州。

YARN

分布式集群資源管理系統瘸味，不僅能跑MapReduce，還能跑任何一個分布式程序基于Hadoop集群的數據而運行够挂。

Interactive SQL(交互式SQL)

利用MapReduce進行分發(fā)并使用一個分布式查詢引擎旁仿，使得在Hadoop上獲得SQL查詢低延遲響應的同時還能保持對大數據集規(guī)模的可擴展性。
impala
Hive

Iterative processing(迭代處理)

迭代處理孽糖，在內存中保存結果集
Spark

Stream processing(流式處理)

在無邊界數據流上運行實時枯冈、分布式計算
Storm
Spark Streaming
Samza

Search

Solr(基于Lucene)

Hadoop 的規(guī)模分析

根據需要制定多大規(guī)模的Hadoop集群？