《數據實時處理flink》課件-第一章 大數據技術概述

大數據技術概述牛津大學教授維克托·邁爾-舍恩伯格（ViktorMayer-Sch?nberger）指出，大數據帶來的信息風暴正在改變我們的生活、工作和思維。理解大數據并對這些數據進行有效的處理和分析是企業(yè)和政府的機遇，更是一種挑戰(zhàn)。數據流的處理必須滿足高吞吐和低延遲的特性，ApacheFlink（以下簡稱Flink）是一種針對數據流的大數據處理框架。讀完本章之后，讀者可以了解以下內容。大數據的特點、大數據分而治之的處理思想。批處理和流處理的區(qū)別。流處理的基礎概念。流處理框架的技術更迭和架構演進。Flink開發(fā)的常用編程語言。什么是大數據從批處理到流處理代表性大數據技術從Lambda到Kappa流式處理基礎概念編程語言的選擇大數據的5個VVolume：數據量大Velocity：數據產生速度快Variety：數據類型繁多Veracity：數據真實性Value：數據價值大數據單臺計算機無法處理所有數據，使用多臺計算機組成集群，進行分布式計算。分而治之：將原始問題分解為多個子問題多個子問題分別在多臺計算機上求解將子結果匯總比較經典的模式和框架：MPIMapReduce大數據分而治之MPI：MessagePassingInterface消息傳遞接口使用分治法將問題分解成子問題，在不同節(jié)點上分而治之地求解。MPI提供數據發(fā)送和數據接收操作：將本進程中某些數據發(fā)送給其他進程接收其他進程的數據自行設計分治算法，將復雜問題分解為子問題優(yōu)勢：以很細的粒度控制數據的通信劣勢：難度大，開發(fā)調試時間成本高MPI程序員只需要定義兩個操作：Map和Reduce案例：三明治制作Map階段將原材料在不同的節(jié)點上分別進行處理Shuffle/Group階段將不同的中間食材進行組合Reduce階段最終將一組中間食材組合成三明治成品學習門檻比MPI低MapReduce什么是大數據從批處理到流處理代表性大數據技術從Lambda到Kappa流式處理基礎概念編程語言的選擇單條數據被稱為事件（Event）或者被稱為一條數據或一個元素。事件按照時序排列會形成一個數據流（Data

Stream）。數據流一般是無界（Unbounded）的，某段有界數據流（BoundedDataStream）可以組成一個數據集。數據與數據流批處理（BatchProcessing）：對一批數據進行處理案例：微信運動統(tǒng)計步數，銀行信用卡賬單統(tǒng)計…

數據總量大，計算非常耗時流處理數據本質上是流，流處理（StreamProcessing）對數據流進行處理案例：查看電商實時銷售業(yè)績、股票交易…批處理與流處理流處理一般使用生產者-消費者模型股票交易案例：輔助人工決策實現消費者側代碼，以10秒為一個時間窗口，統(tǒng)計窗口內的交易情況可擴展性：隨著數據不斷增多，能否保證我們的程序能夠快速擴展到更多的節(jié)點上。數據傾斜：數據沒有均勻分布到分布式系統(tǒng)各個節(jié)點上。容錯性：系統(tǒng)崩潰重啟后，之前的那些計算如何恢復。時序錯亂：數據到達的時間和實際發(fā)生的時間是不一致的，有一定的延遲，需要設計等待策略。Flink：為流處理而生。流處理框架必要性生產者-消費者模型什么是大數據從批處理到流處理代表性大數據技術從Lambda到Kappa流式處理基礎概念編程語言的選擇MapReduce編程模型的一種實現，逐漸形成了一整套生態(tài)圈。主要組件：HadoopMapReduce：數據處理模型，面向批處理。HDFS：分布式文件系統(tǒng)，提供存儲支持。YARN：資源調度器，分配計算資源。其他著名組件：Hive：SQL-on-HadoopHbase：基于HDFS的分布式數據庫，毫秒級實時查詢Kafka：消息隊列ZooKeeper：分布式環(huán)境的協(xié)調HadoopHadoop生態(tài)圈Spark初衷：改良HadoopMapReduce的編程模型，提高運行速度，優(yōu)化機器學習性能。易用性：比MapReduce更好用，提供了多種編程語言API，支持SQL、機器學習和圖計算。速度快：盡量將計算放在內存中。完美融入進Hadoop生態(tài)圈。流處理：SparkStreaming，mini-batch思想，將輸入數據流拆分成多個批次。Spark是一個批流一體的計算框架。SparkSpark生態(tài)圈Spark

mini-batch流處理消息隊列：數據集成和系統(tǒng)解耦，某個應用系統(tǒng)專注于一個目標。企業(yè)將各個子系統(tǒng)獨立出來，子系統(tǒng)之間通過消息隊列來發(fā)送數據。Kafka

Kafka可以連接多個組件和系統(tǒng)主要面向流處理流處理框架經歷了三代演進StormSpark

StreamingFlink事件投遞保障：Exactly-Once：一條數據只影響一次最終結果毫秒級的延遲Flink什么是大數據從批處理到流處理代表性大數據技術從Lambda到Kappa流式處理基礎概念編程語言的選擇Lambda架構：批處理層、流處理層、在線服務層批處理層：等待一個批次數據，使用批處理框架計算，得到一個非實時的結果。比如，凌晨0點開始統(tǒng)計前一天所有商品的計算次數，計算需要幾個小時。流處理層：使用流處理框架生成結果。早期的流處理框架不成熟，結果近似準確。在線服務層：將來自批處理層準確但有延遲的預處理結果和流處理層實時但不夠準確的預處理結果做融合。程序員需要維護批處理和流處理兩套業(yè)務邏輯。Lambda架構Lambda架構Kafka等消息隊列可以保存更長時間的歷史數據，它不僅起到消息隊列的作用，也可以存儲數據，替代數據倉庫。Flink流處理框架解決了事件亂序下計算結果的準確性問題。程序員只維護一套流處理層，維護成本低。Kappa架構Kappa架構什么是大數據從批處理到流處理代表性大數據技術從Lambda到Kappa流式處理基礎概念編程語言的選擇延遲：一個事件被系統(tǒng)處理的總時間。案例：自助食堂，一位用餐者從進入食堂到離開食堂的總耗時。高峰時，總耗時會增加。分位延遲更能反映系統(tǒng)的性能。吞吐：系統(tǒng)最大能處理多少事件。與系統(tǒng)本身設計有關，也與數據源的數據量有關。延遲與吞吐相互影響，一起反映了系統(tǒng)的性能。優(yōu)化方式：優(yōu)化單節(jié)點內的計算速度，使用并行策略，分而治之地處理數據。延遲和吞吐延遲和吞吐更直觀的表現：用戶是否排隊。滾動窗口（TumblingWindow）：定義一個固定的窗口長度，長度是一個時間間隔。滑動窗口（SlidingWindow）：定義一個固定的窗口長度和一個滑動長度。會話窗口（SessionWindow）：窗口長度不固定，根據會話間隔（SessionGap）確定窗口，兩個事件之間的間隔大于SessionGap，則兩個事件被劃分到不同的窗口中。窗口三種時間窗口EventTime：事件實際發(fā)生的時間事件發(fā)生時，EventTime就已經確定ProcessingTime：事件被流處理框架處理的時間不同節(jié)點、系統(tǒng)內不同模塊、同一數據不同次處理都會產生不同的ProcessingTime案例：手機游戲，用戶需要與服務器實時交互，游戲根據實時數據計分。信號丟失，部分數據上傳有延遲，使用事件的Event

Time更準確。時間Watermark是插入到數據流的元素。Watermark元素到達，假設不會有比這個時間點更晚的上報數據?？梢栽O置不同的Watermark策略，是一種折中方案：Watermark等待時間短，保證低延遲，數據準確性下降。Watermark等待時間長，數據更準確，延遲高，維護難度大。Watermark無狀態(tài)：流處理中，不需要額外信息，給定一個輸入數據，直接得到輸出。將英文單詞轉化為小寫。有狀態(tài)：根據歷史信息，處理新流入數據。統(tǒng)計一分鐘內單詞出現次數，需要保存已經進入系統(tǒng)的歷史。使用檢查點（Checkpoint）技術，將狀態(tài)數據保存下來，用于故障后的恢復。狀態(tài)與檢查點有狀態(tài)計算和無狀態(tài)計算如果發(fā)生故障，數據是否被成功處理？At-Most-Once：每個事件最多被處理一次。有些數據被丟棄，最不安全。At-Least-Once：每個事件至少被處理一次，有些事件可能被處理多次。部分數據被處理多次，可能不準確。Exactly-Once：每個事件只被處理一次。事件不丟不重。實現難度最大。數據一致性保障什么是大數據從批處理到流處理代表性大數據技術從Lambda到Kappa流式處理基礎概念編程語言的選擇Java企業(yè)級編程語言有很多開源包大數據必備Scala函數式編程有一定學習門檻Flink目前絕大多數代碼和功能均由Java實現編程語言的選擇Python簡單易用PyFlinkSQL上手門檻很低大數據數據量大、產生速度快、類型多，為了獲取數據背后價值還