大數據與機器學習

第十章Flink介紹產生背景因為Spark是流處理的實時計算，還有0.5秒延遲。而ApacheStorm雖然是實時計算引擎，但其吞吐量較小，還會有數據丟失和重復（最多一次和最少一次），而Flink做到了嚴格一次的容錯語義，且底層是真正的流式計算。原理Flink主要有兩類進程:JobManager和TaskManagerJobManager(masters)：協調分布式計算、任務調度，協調checkpoints，錯誤調度等，相當于一個指揮官吧(實際部署時，至少需要一個JobManager，實際生產環境部署時都會做HA，部署多個JobManager；這個時候，只有一個leader，其他都是standby模式)TaskManager(workers)：真正執行dataflow的，并對streams進行緩存和交換總的來說，運行中的Flink集群至少有一個JobManager進程和一個TaskManager進程。如果將客戶端也算進去的話，那么還有一個Client進程。各個進程一般部署在不同的機子上，不過也可以部署在同一臺機子上，就比如說在本地啟動一個集群時(Local模式，通常用于開發調試)，JobManager進程和TaskManager進程就是跑在同一臺服務器上。Flink是基于AkkaActor實現的JobManager和TaskManager，所以JobManager和TaskManager以及Client之間的信息交互都會通過事件的方式來進行處理的。一個簡單的流程就是，Client提交任務作業給JobManager，JobManager負責該作業的調度和資源分配（在Flink集群中，計算資源被定義為TaskSlot。每個TaskManager會擁有一個或多個Slots），隨后將作業分給對應的TaskManager，TaskManager收到任務后，啟動線程去執行，并向JobManager報告任務狀態和自身運行狀態等。當任務結束后，JobManager將收到通知，并統計數據后發送給Client。Flink認為批處理是流處理的一個特例，這與Spark相反，他將流處理按時間切割，然后批處理。Flink底層引擎是一個流式引擎，在其上實現了流處理和批處理。而Flink的窗口將流處理（無界數據）轉變為批處理（有界數據）。Flink將窗口內的數據進行聚合計算。Flink是事件型處理，即通過事件觸發來進行流式處理。其窗口分為三類：事件觸發時間event-time:進入時間IngesingtTime:處理時間Processing-time:第十一章HBase介紹Hbase產生背景HBase為NOSQL非關系型數據庫，所以支持半結構和非結構化的海量大數據存儲。是關系型數據庫無法滿足海量數據需求而誕生的。HBase依賴HDFS的物理存儲，是海量數據實時查詢工具。因其列存儲特性而查詢速度快，被廣泛使用實時數據查詢與監控。但僅可支持簡單查詢，隨機查詢。列式存儲：一條記錄按照姓名進行一列存儲。行式存儲：一條記錄按照姓名，年齡，性別的行式存儲。隨機查詢：相對于順序查詢，可隨機抽取數據查詢。HIVE與HBase區分HIVE是數據統計查詢：即通過SQL調用MapReduce的數據統計后的數據，即在統計一段時間內的數據計算后的結果數據。HBase是海量數據的簡單實時查詢，即實時查詢網站生成的數據（非統計結果數據），而后通過NOShhQL并以列存儲方式存儲在HDFS上。總結：HIVE數倉工具從HDFS中通過SQL啟動MapReduce來取數據進行數據分析。而HBASE是將日志文件數據寫入HDFS過程。當然也可以快速隨機查詢海量數據中的某一列或多列數據，但僅查詢。不像Reduce是進行統計。HBase架構原理HBase簡介 Hbase是分布式，列式數據庫，適用于非結構化數據存儲。它是基于Hadoop中的Bigtable論文思想產生的，即世界上的事務都可以通過Bigtable來表示。即Bigtable用若干Key-Value來存儲表示。如<學號：課程><學號：姓名><學號：分數>產生背景由于HDFS無法對存儲數據修改，因此產生了HBASE，可以在HBAS上進行數據修改，但每次修改只是插入一條有時間戳的新版本的數據，而不覆蓋舊數據。可通過版本號來區分數據。而新的數據提取可按照兩種方式：版本指定：通過指定版本保存的范圍。如只提取前10個版本。時間戳指定：通過指定時間保存的范圍。如數據只保存7天。列族與元素每個列構成列族。列族可以包含多個列。列族需要通過限定符提前定義格式。<列族>：<限定符>，HBASE按照列族存儲數據，適于數據分析和壓縮數據，提高讀寫速率。行鍵RowKEY相同時，按照B+數據索引進行相同列族ColumnFamily數據索引查詢，列族在相同時候，進行TimeStamp時間戳快速排序后查詢。HBASE先橫向切分行數據，在縱向切分列數據。切分的行列數據為元素。元素保存同一份數據的多個版本，由時間戳區分。行Key時間戳列族...列族19Contexts:html...Key:Value行鍵：行數據檢索的主鍵和唯一標識。最大不超過64KB任意字符，按照數據字典存儲。物理模型HLog日志文件：操作寫入日志，以便掛掉時候，重新讀取日志恢復。WAL（Write-Ahead-Log預寫日志）將更新操作先寫入MemStore內存然后持久化寫入HFile，這樣保證了一旦RegionServer掛掉時，還沒將數據寫入HFile時數據會丟失。此時從日志中讀取操作可以恢復數據。主從節點HMaster和HRegionServer：HMaster負責分配Region給Server。Region就是列族，含有多個列的分布式存儲單元。HMaster將元數據信息（Server位置和表、列族位置）存入ZooKeeper，以便Client端讀取。Region含有多個Store即一列數據，多個列Store構成一個列族即Region，多個列族Region構成一個表，即RegionServer里只存放一個表的數據。而RegionServer數據大小是按照HDFS中默認的BLOCK行切割，即橫向切割而來的。比如把一個文件橫向相同行間隔128M切割多份保存到Server。當RegionServer底層文件HFile越來越大時候，將把原有的Region分列開兩個新的表，即分開為兩個RegionServer分別分布式存儲在新的一臺服務器上后，將原有的表刪除。ZooKeeper為HMaster提供HA（HighlyAvailable雙機）方案，保證至少一臺Master處于運行狀態。詳細查看Kafka的failover相似過程。Store即列族中包含MemStore內存緩存和StoreFile實際物理存儲在HDFS上的文件MemStore是HBASE先將數據讀入內存，當內存滿了的時候，在將文件寫入多個小文件HFile，當多個小文件File達到閥值標準時候就自動組合成一個大文件StoreFile。此過程與Map和Reduce過程是一樣的，先寫內存在寫小文件最后組合成大文件。BlockCache是ReginoServer內存構成的兩個部分之一。Memstore是寫數據，BlockCache是讀數據。讀請求先到MStore查數據，查不到就去BlockCache查，再查不到就去StoreFile中去讀，并把讀的結果放入BlockCache，客戶端會緩存讀取記錄，方便下次查詢直接使用。StoreFile是由多個HFile組成，StoreFile把多個HFile在進行封裝。封裝信息和格式如下：首先HFile文件是不定長的，長度固定的只有其中的兩塊：Trailer和FileInfo。正如圖中所示：Trailer中有指針指向其他數據塊的起始點。FileInfo中記錄了文件的一些Meta信息，例如：AVG_KEY_LEN,AVG_VALUE_LEN,LAST_KEY,COMPARATOR,MAX_SEQ_ID_KEY等。HFile分為六個部分：DataBlock

段–保存表中的數據，這部分可以被壓縮MetaBlock

段(可選的)–保存用戶自定義的kv對，可以被壓縮。FileInfo

段–Hfile的元信息，不被壓縮，用戶也可以在這一部分添加自己的元信息。DataBlockIndex

段–DataBlock的索引。每條索引的key是被索引的block的第一條記錄的key。MetaBlockIndex

段(可選的)–MetaBlock的索引。Trailer

段–這一段是定長的。保存了每一段的偏移量，讀取一個HFile時，會首先讀取Trailer，Trailer保存了每個段的起始位置(段的MagicNumber用來做安全check)，然后，DataBlockIndex會被讀取到內存中，這樣，當檢索某個key時，不需要掃描整個HFile，而只需從內存中找到key所在的block，通過一次磁盤io將整個block讀取到內存中，再找到需要的key。DataBlockIndex采用LRU機制淘汰。HFile的DataBlock，MetaBlock通常采用壓縮方式存儲，壓縮之后可以大大減少網絡IO和磁盤IO，隨之而來的開銷當然是需要花費cpu進行壓縮和解壓縮。目標Hfile的壓縮支持兩種方式：Gzip，LZO。DataIndex和MetaIndex塊記錄了每個Data塊和Meta塊的起始點。DataBlock是HBaseI/O的基本單元，為了提高效率，HRegionServer中有基于LRU的BlockCache機制。每個Data塊的大小可以在創建一個Table的時候通過參數指定，大號的Block有利于順序Scan，小號Block利于隨機查詢。每個Data塊除了開頭的Magic以外就是一個個KeyValue對拼接而成,Magic內容就是一些隨機數字，目的是防止數據損壞。HFile里面的每個

KeyValue

對就是一個簡單的byte數組。但是這個byte數組里面包含了很多項，并且有固定的結構。我們來看看里面的具體結構：

開始是兩個固定長度的數值，分別表示Key的長度和Value的長度。緊接著是Key，開始是固定長度的數值，表示RowKey的長度，緊接著是RowKey，然后是固定長度的數值，表示Family的長度，然后是Family，接著是Qualifier，然后是兩個固定長度的數值，表示TimeStamp和KeyType（Put/Delete）。Value部分沒有這么復雜的結構，就是純粹的二進制數據了。HBas