優點：
極高的裝載速度 （最高可以等於所有硬碟io 的總和，基本是極限了）
適合儲存大量資料
實時載入資料僅限於增加（刪除和更新需要解壓縮block 然後計算然後重新壓縮儲存）
高效的壓縮率，不僅節省儲存空間也節省計算記憶體和cpu。
非常適合做聚合操作。
缺點：
不適合掃瞄小量資料
不適合隨機的更新
批量更新情況各異，有的優化的比較好的列式資料庫（比如vertica）表現比較好，有些沒有針對更新的資料庫表現比較差。
不適合做含有刪除和更新的實時操作。
zookeeper是大資料生態圈中的重要元件，用一句話對其進行定義就是：它是一套高吞吐的分布式協調系統。從中我們可以知道zookeeper至少具有以下特點：
1、zookeeper的主要作用是為分布式系統提供協調服務，包括但不限於：分布式鎖，統一命名服務，配置管理，負載均衡，主控伺服器選舉以及主從切換等。
2、zookeeper自身通常也以分布式形式存在。乙個zookeeper服務通常由多台伺服器節點構成，只要其中超過一半的節點存活，zookeeper即可正常對外提供服務，所以zookeeper也暗含高可用的特性。客戶端可以通過tcp協議連線至任意乙個服務端節點請求zookeeper集群提供服務，而集群內部如何通訊以及如何保持分布式資料一致性等細節對客戶端透明。
3、zookeeper是以高吞吐量為目標進行設計的，故而在讀多寫少的場合有非常好的效能表現。zookeeper具有高吞吐特性的主要原因有以下幾點：
（1）zookeeper集群的任意乙個服務端節點都可以直接響應客戶端的讀請求（寫請求不一樣），並且可以通過增加節點進行橫向擴充套件。這是其吞吐量高的主要原因。
（2）zookeeper將全量資料儲存於記憶體中，從記憶體中讀取資料不需要進行磁碟io，速度要快得多。
（3）zookeeper放鬆了對分布式資料的強一致性要求，即不保證資料實時一致，允許分布式資料經過乙個時間視窗達到最終一致，這也在一定程度上提高了其吞吐量。
而寫請求，或者說事務請求，因為要進行不同伺服器結點間狀態的同步，一定程度上會影響其吞吐量。故而簡單的增加zookeeper的伺服器節點數量，對其吞吐量的提公升並不一定能起到正面效果。伺服器節點增加，有利於提公升讀請求的吞吐量，但會延長伺服器節點資料的同步時間，必須視具體情況在這兩者之間取得乙個平衡。
首先，集群中的zookeeper需要超過半數，整個集群對外才可用。這裡所謂的整個集群對外可用，是指整個集群還能選出乙個leader來，zookeeper預設採用quorums來支援leader的選舉。
quorums機制有兩個作用：
1、保證集群中選出leader，且是唯一的乙個，不會出現腦裂（split-brain）；
2、當客戶端更新資料時，當大多數節點更新成功，客戶端就會被通知更新成功了，其他節點可以稍後再更新，以達到資料的最終一致性。
舉個例子：設集群的最少節點數為n，
集群總節點數
最少可用節點數
可容忍失效的節點數11
0220
3214
3153
2642
…………
……2n-1
nn-1
2nn+1
n-1由此可見，集群節點總數不能是1或2，因為可容忍失效的節點數都為0，所以要想保證zookeeper的高可用，至少需要3臺以上。同時，我們可以發現乙個規律，3個節點與4個節點的效果是一樣的，可容忍失效的節點數都是1，即2n-1與2n，可容忍失效的節點數都是n-1。2n-1個節點能達到的效果，就沒有必要用2n個節點實現，可以節省一台的成本。配置成偶數臺也不會有問題，只不過浪費了而已。
大資料工程師面試題
你曾經參與或主導過哪些大資料型別的專案？專案目標是什麼？你具體擔負的哪個角色？使用哪些演算法？使用哪些統計方法？如果解決使用者商品匹配的話，你會採用什麼型別的模型？二部圖模型有什麼缺陷？對應有什麼改進模型？標籤系統有什麼特徵？有什麼問題？使用者行為分析有什麼模型？說說你曾經專案中的模型迭代過程？成功...
測試工程師面試經驗
01.為什麼要在乙個團隊中開展軟體測試列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例.例如,在單元測試時曾列出的許多在模組中常見的錯誤.以前產品測試中曾經發現的錯誤等,這些就是經驗的總結.還有,輸入資料和輸出資料為0的情況.輸入 為空格或輸入 只有一行.這些都是容易發生錯...
大資料工程師簡歷 成為大資料工程師所需的技能
我們大多數人對資料工程師是誰有想法，但我們對大資料工程師的角色和責任感到困惑。一旦我們開始用適當的技能集對映這些角色和職責，並找到最有效和最有效的學習路徑，這種歧義就會增加。這個 大資料工程師技能 部落格將幫助您了解資料工程師的不同職責。因此，我將用適當的技能來規劃這些職責 將引導您通過適當的學習路...