不多說，直接上乾貨！
那既然有了hbase，為什麼還需要kudu呢？
簡單的說，就是嫌棄hbase在olap（聯機分析處理）場合，sql／mr類的批量檢索場景中，效能不夠好。通常這種海量資料olap場景，要不走預處理的路，比如像ebay麒麟這樣走cube管理的，或者像谷歌mesa這樣按業務需求走預定義聚合操作。再有就是自己構建資料通道，串接實時和批量處理兩種系統，發揮各自的特長。
但是olap是個複雜的問題，場景眾多，必然不可能有完美的通用解決方案，kudu定位於應對快速變化資料的快速分析型資料倉儲，希望靠系統自身能力，支撐起同時需要高吞吐率的順序和隨機讀寫的應用場景（可能的場景，比如時間序列資料分析，日誌資料實時監控分析），提供乙個介於hdfs和hbase的效能特點之間的乙個系統，在隨機讀寫和批量掃瞄之間找到乙個平衡點，並保障穩定可**的響應延遲。
結構化資料儲存系統在 hadoop 生態系統裡面，通常分為兩類：
上面的兩種系統，各有自己的側重點，一類是低延遲的隨機訪問特定資料，而另一類就是高吞吐的分析大量資料。之前，我們並沒有這樣的系統可以融合上面兩種情況，所以通常的做法就是使用 pipeline，譬如我們非常熟悉的 kafka，通常我們會將資料快速寫到 hbase 等系統裡面，然後通過 pipeline，在匯出給其它分析系統。雖然我們在一定層面上面，我們其實通過 pipeline 來對整個系統進行了解耦，但總歸要維護多套系統。而且資料更新之後，並不能直接實時的進行分析處理，有延遲的開銷。所以在某些層面上面，並不是乙個很好的解決方案。
kudu 致力於解決上面的問題，它提供了簡單的來處理資料的插入，更新和刪除，同時提供了 table scan 來處理資料分析。通常如果乙個系統要融合兩個特性，很有可能就會陷入兩邊都做，兩邊都沒做好的窘境，但 kudu 很好的在融合上面取得了平衡。
那為什麼不能想辦法改進hbase呢？
kudu 的很多特性跟 hbase 很像，它支援索引鍵的查詢和修改。 cloudera 曾經想過基於 hbase 進行修改，然而結論是對 hbase 的改動非常大， kudu 的資料模型和磁碟儲存都與 hbase 不同。 hbase 本身成功的適用於大量的其它場景，因此修改 hbase 很可能吃力不討好。最後 cloudera 決定開發乙個全新的儲存系統。
既然有了HBase，為什麼還需要Kudu呢？
那既然有了hbase，為什麼還需要kudu呢？簡單的說，就是嫌棄hbase在olap 聯機分析處理 場合，sql mr類的批量檢索場景中，效能不夠好。通常這種海量資料olap場景，要不走預處理的路，比如像ebay麒麟這樣走cube管理的，或者像谷歌mesa這樣按業務需求走預定義聚合操作。再有就是自己...
有了互斥量，為什麼還需要條件變數？
一。互斥量和條件變數簡介 互斥量 mutex 從本質上說是一把鎖，在訪問共享資源前對互斥量進行加鎖，在訪問完成後釋放互斥量上的鎖。對互斥量進行加鎖以後，任何其他試圖再次對互斥鎖加鎖的執行緒將會阻塞直到當前執行緒釋放該互斥鎖。如果釋放互斥鎖時有多個執行緒阻塞，所有在該互斥鎖上的阻塞執行緒都會變成可執行...
為什麼有了IP位址還需要MAC位址？
長話短說，理由有三點。二.分層實現如果在ip包頭 header 中增加了 下一跳ip位址 這個字段，在邏輯上來說，如果ip位址夠用，交換機也支援根據ip位址 現在的二層交換機不支援這樣做 其實mac位址並不是必要的。但用mac位址和ip位址兩個位址，用於分別表示實體地址和邏輯位址是有好處的。這樣分層...