大數(shù)據(jù)與機器學習第十與十一章

大數(shù)據(jù)與機器學習

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

段–保存表中的數(shù)據(jù)，這部分可以被壓縮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通常采用壓縮方式存儲，壓縮之后可以大大減少網(wǎng)絡IO和磁盤IO，隨之而來的開銷當然是需要花費cpu進行壓縮和解壓縮。目標Hfile的壓縮支持兩種方式：Gzip，LZO。DataIndex和MetaIndex塊記錄了每個Data塊和Meta塊的起始點。DataBlock是HBaseI/O的基本單元，為了提高效率，HRegionServer中有基于LRU的BlockCache機制。每個Data塊的大小可以在創(chuàng)建一個Table的時候通過參數(shù)指定，大號的Block有利于順序Scan，小號Block利于隨機查詢。每個Data塊除了開頭的Magic以外就是一個個KeyValue對拼接而成,Magic內容就是一些隨機數(shù)字，目的是防止數(shù)據(jù)損壞。HFile里面的每個

KeyValue

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

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