1. 大資料是什么?
1.1 大資料就是4V的特征
Volume (大量) , Velocity (高速) , Variety (多樣) , Value (價值) , 即資料體量巨大, 資料型別繁多, 價值密度低, 處理速度快.
1.2 JavaEE開發與大資料的區別
1.2.1 JavaEE開發流程
1.2.2 大資料開發流程
1.2.3 兩者區別
1) 架構層面
javaEE體系: 三層架構, 表現層 (Web) 業務層 (Service) 持久層 (Dao) .
大資料體系: 圍繞資料, 資料采集 (資料源) , 資料存盤, 資料計算 (分析) , 資料展示.
2) 技術層面
JavaEE: 成熟, 解決方案多, 技術點集中.
大資料: 相對年輕, 迭代更新快, 解決方案相對少, 技術相當繁瑣, 雜, 碎.
3) 開發層面
JavaEE: 代碼量很大, 偏向業務, 運維等任務相對較少, 固定搭配, 習慣用法較多.
大資料: 代碼量很少, 偏向技術 (原理, 知識) , 運維任務略多 (集群, 服務器等) , sql資料分析, 類sql, hql.
4) 市場層面
javaEE: 很成熟, 有自己的行業規范, 如日中天
大資料: 市場起步階段, 規范有待健全, 朝陽產業 (結合人工智能, 機器學習等) .
2. Apache Zookeeper
2.1 Zookeeper概述
Zookeeper是一個分布式協調服務的開源框架. 主要用來解決分布式集群中應用系統的一致性問題.
Zookeeper本質上是一個
分布式的小檔案存盤系統. 提供基于類似于檔案系統的目錄樹方式的資料存盤, 并且可以對樹種的節點進行有效管理.
維護和監控你存盤的資料的狀態變化, 通過監控這些資料狀態的變化, 從而可以達到基于資料的集群管理.
分布式程式, 可以多臺服務器部署 (可靠, 穩定) .
Zookeeper是一個主從結構集群.
2.2 Zookeeper特性
全域資料一致: 集群中每個服務器保存一份相同的資料副本, Client無論連接到哪個服務器, 展示的資料都是一致的, 這是最重要的特性.
可靠性: 如果訊息被其中一臺服務器接受, 那么將被所有的服務器接受.
順序性: 包括全域有序和偏序兩種: 全域有序是指如果一臺服務器上訊息a在訊息b前發布, 則在所有Server上訊息a都將在訊息b前被發布. 偏序是指如果一個訊息b在訊息a后被同一個發送者發布, 訊息a必將排在訊息b前面.
資料更新原子性: 一次資料更新要么成功 (半數以上節點成功) , 要么失敗, 不存在中間狀態.
實時性: Zookeeper保證客戶端將在一個時間間隔范圍內獲得服務器的更新資訊, 或者服務器失效的資訊
2.3 Zookeeper集群角色
Leader: Zookeeper集群作業的核心, 事務請求 (寫操作) 的唯一調度和處理者, 保證集群事務處理的順序性, 集群內部各個服務器的調度者.
對于create, setData, delete等有寫操作的請求, 則需要統一轉發給leader處理, leader需要決定編號, 執行操作, 這個程序稱為一個事務.
Follower: 處理客戶端非事務 (讀操作) 請求, 轉發事務請求給Leader. 參與集群Leader選舉投票.
此外, 針對訪問量較大的Zookeeper集群, 還可新增觀察者角色.
Observer: 觀察者角色, 觀察Zookeeper集群的最新狀態變化并將這些狀態同步過來, 其對于非事務請求可以進行獨立處理, 對于事務請求, 則會轉發給Leader服務器進行處理. 不會參與任何形式的投票只提供非事務服務, 通常用于在不影響集群事務處理能力的前提下提升集群的非事務處理能力.
可以分為主從主備兩種方式:
主從: 主角色 leader
從角色 follower
常見的一主多從的架構 (storm, hadoop等) , 主從架構各司其職, 互相配合.
主備: 主角色 active
備角色 standby
主備角色常用于解決單點故障問題, 常見的是一主一備, 只有主角色發生故障時, 備角色才會切換成主角色, 同一個時刻只能有一個主角色.
2.4 Zookeeper集群搭建
Zookeeper集群搭建指的是Zookeeper分布式模式安裝. 通常由2n+1臺servers組成. 這是因為為了保證Leader選舉 (基于Paxos演算法的實作) 能過得到多數的支持, 所以Zookeeper集群的數量一般為奇數.
如果要想使用Observer模式, 可在對應節點的組態檔添加配置: peerType=observer, 其次必須在組態檔指定哪些節點被指定為Observer, 如: server. 1:hadoop01:2181:3181:observer
2.5 Zookeeper資料模型
Zookeeper的資料模型, 在結構上和標準檔案系統非常相似, 擁有一個層次的命名空間, 都是采用樹形層次結構, Zookeeper樹中的每個節點被稱為--Znode. 和檔案系統的目錄樹一樣, Zookeeper樹中的每個節點可以擁有子節點. 但也有不同之處:
1) Zookeeper兼具檔案和目錄兩種特點: 既像檔案一樣維護著資料, 元資訊, ACL, 時間戳等資料結構, 又像目錄一樣可以作為路徑標識的一部分, 并可以具有子Znode. 用戶對Znode具有增刪改查等操作 (權限允許的情況下) .
2) Znode具有原子性操作: 讀操作將獲取與節點相關的所有資料, 寫操作也將替換掉節點的所有資料. 另外, 每一個節點都擁有自己的ACL (訪問控制串列) , 這個串列規定了用戶的極限, 即限定了特點用戶對目標節點可以執行的操作.
3) Znode存盤資料大小有限制: Zookeeper雖然可以關聯一些資料, 但并沒有被設計為常規的資料庫或者大資料存盤, 相反的是, 他用來管理調度資料, 比如分布式應用中的組態檔資訊, 狀態資訊, 匯集資訊等. 這些資料的共同特性就是他們都是很小的資料, 通常以KB為大小單位. Zookeeper的服務器和客戶端都被設計為嚴格檢查并限制每個Znode的資料大小至多1M, 當時常規使用中應該遠小于此值.
4) Znode通過路徑參考: 如同Unix中的檔案路徑. 路徑必須是絕對的. 因此他們必須由斜杠字符開頭. 除此以外, 他們必須是唯一的, 也就是說每一個路徑只有一個表示, 因此這些路徑不能改變. 在Zookeeper中, 路徑由Unicode字串組成, 并且有一些限制. 字串"/zookeeper"用以保存管理資訊, 比如關鍵配額資訊.
2.6 資料結構圖
圖中的每個節點稱為一個Znode. 每個Znode由3部分組成:
1) stat: 此為狀態資訊, 描述該Znode的版本, 權限等資訊
2) data: 與該Znode關聯的資料
3) children: 該Znode下的子節點
2.7 節點型別
Znode有兩種, 分別為臨時節點和永久節點
節點的型別在創建時即被確定, 并且不能改變
1) 臨時節點: 該節點的生命周期依賴于創建他們的會話. 一旦會話結束, 臨時節點將被自動洗掉, 當然也可以手動洗掉. 臨時節點不允許擁有子節點.
2) 永久節點: 該節點的生命周期不依賴于會話, 并且只有在客戶端顯示執行洗掉操作的時候, 他們才能被洗掉.
Znode還有一個序列化的特性, 如果創建的時候指定的話, 該Znode的名字后面會自動追加一個不斷增加的序列號. 序列號對于此節點的父節點來說是唯一的, 這樣便會記錄每個子節點創建的先后順序. 他的格式為"%10d" .
這樣便會存在四種型別的Znode節點, 分別對應:
1) 永久非序列化節點
2) 臨時非序列化節點
3) 永久序列化節點
4) 臨時序列化節點
2.8 節點屬性
每個Znode都包含了一系列屬性, 通過命令get, 可以獲得節點的屬性.
1) dataVersion: 資料版本號, 每次對節點進行set操作, dataVersion的值都會增加1 (即使設定的是相同資料) , 可有效避免了資料更新時出現的先后順序問題.
2) cversion: 子節點的版本號. 當Znode的子節點有變化時, cversion的值就會增加1.
3) cZxid: Znode創建的事務id.
4) mZxid: Znode被修改的事務id, 即每次對Znode的修改都會更新mZxid.
對于Zookeeper來說, 每次的變化都會產生一個唯一的事務id, zxid (Zookeeper Transaction ID) . 通過zxid, 可以確定更新操作的先后順序. 例如, 如果zxid1小于zxid2, 說明zxid1操作先于zxid2發生, zxid對于整個Zookeeper都是唯一的, 即使操作的是不同的Znode.
5) ctime: 節點創建的時間戳
6) mtime: 節點最新一次更新發生時的時間戳
7) ephemeralOwner: 如果該節點為臨時節點, ephemeralOwner值表示與該節點系結的session id, 如果不是, ephemeralOwner值為0.
在Client和Server通信之前, 首先需要建立連接, 該連接稱為session. 連接建立后, 如果發生連接超時, 授權失敗, 或者顯式關閉連接, 連接便處于CLOSED狀態, 此時session結束.
2.9 Zookeeper Watcher (監聽機制)
Zookeeper提供了分布式資料發布 / 訂閱功能, 一個典型的發布 / 訂閱模型系統定義了一種一對多的訂閱關系, 能讓多個訂閱者同時監聽某一個主題物件, 當這個主題物件自身狀態變化時, 會通知訂閱者, 使他們能夠做出相應的處理.
Zookeeper中, 引入了Watcher機制來實作這種分布式的通知功能. Zookeeper允許客戶端向服務端注冊一個Watcher監聽, 當服務端的一些事件觸發了這個Watcher, 那么就會指定客戶端發送一個事件通知來實作分布式的通知功能.
觸發事件種類很多: 節點創建, 節點洗掉, 節點改變, 子節點改變等.
總的可以概括Watcher為三個程序:
1) 客戶端向服務端注冊Watcher
2) 服務端事件發生觸發Watcher
3) 客戶端回呼Watcher得到觸發時間情況
Watcher機制特點:
一次性觸發: 事件發生觸發監聽, 一個WatcherEvent就會被發送到設定監聽的客戶端, 這種效果是一次性的, 后續再次發生同樣的事件, 不會再次觸發.
事件封裝: Zookeeper使用WatchedEvent物件來封裝服務端事件并傳遞.
WatcherEvent包含了每一個事件的三個基本屬性: 通知狀態 (KeeperState) , 事件型別 (EventType) , 節點路徑 (path) .
event異步發送: Watcher的通知事件從服務端發送到客戶端是異步的.
先注冊再觸發: Zookeeper中的Watch機制, 必須客戶端先去服務端注冊監聽, 這樣事件發送才會觸發監聽, 通知給客戶端.
2.10 通知狀態和事件型別
同一個事件型別在不同的通知狀態中代表的含義有所不同.
其中連接狀態事件 (type=None, path=null) 不需要客戶端注冊, 客戶端只要有需要直接處理就行了.
2.11 Zookeeper選舉機制
zookeeper默認的演算法是FastLeaderElection, 采用投票數大于半數則勝出的邏輯.
服務器ID: 編號越大在選擇演算法中的權重越大
選舉狀態: LOOKING, 競選狀態
FOLLOWING: 隨從狀態, 同步leader狀態, 參與投票
OBSERVING: 觀察狀態, 同步leader狀態, 不參與投票
LEADING: 領導者狀態
資料ID: 服務器中存放的最新資料version, 值越大說明資料越新, 在選舉演算法中資料越新權重越大
邏輯時鐘: 也叫投票的次數, 同一輪投票程序中的邏輯時鐘值是相同的. 每投完一次票這個資料就會增加, 然后與接收到的其他服務器回傳的投票資訊中的數值對比, 根據不同的值做出不同的判斷.
2.11.1 全新集群選舉
假設目前有5臺服務器, 每臺服務器均沒有資料, 他們的編號分別是1, 2, 3, 4, 5, 按編號依次啟動, 他們的選舉程序如下:
1) 服務器1啟動, 給自己投票, 然后發投票資訊, 由于其他機器還沒有啟動所有他收不到反饋資訊, 服務器1的狀態一直屬于LOOKING.
2) 服務器2啟動, 給自己投票, 同時與之前啟動的服務器1交換結果, 由于服務器2的編號大所以服務器2勝出, 但此時投票數沒有大于半數, 所以兩個服務器的狀態依然是LOOKING.
3) 服務器3啟動, 給自己投票, 同時與之前啟動的服務器1, 2交換資訊, 由于服務器3的編號最大所以服務器3勝出, 此時投票數正好大于半數, 所以服務器3稱為Leader, 服務器1, 2成為Follower.
4) 服務器4啟動, 給自己投票, 同時與之前啟動的服務器1, 2, 3交換資訊, 盡管服務器4的編號大, 但之前服務器3已經勝出, 所以服務器4只能成為Follower.
5) 服務器5啟動, 后面的邏輯同服務器4成為Follower.
2.11.2 非全新集群選舉
對于運行正常的zookeeper集群, 中途有機器down掉, 需要重新選舉時, 選舉程序就需要加入資料ID, 服務器ID, 邏輯時鐘.
資料ID: 資料新的version就大, 資料每次更新都會更新version.
服務器ID: 就是我們配置的mvid的值, 每個機器一個.
邏輯時鐘: 這個值從0開始遞增, 每次選舉對應一個值. 如果在同一次選舉中, 這個值是一致的.
這樣選舉的標準就變成:
1) 邏輯時鐘小的選舉結果被忽略, 重新投票.
2) 統一邏輯時鐘后, 資料id大的勝出.
3) 資料ID相同的情況下, 服務器ID大的勝出.
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/42191.html
標籤：大數據