點選上方藍色字型，選擇“設為星标”
回複”資源“擷取更多資源
大資料技術與架構
點選右側關注，大資料開發領域最強公衆号！
大資料真好玩
點選右側關注，大資料真好玩！
Spark Structured Streaming 特性介紹
作為 Spark Structured Streaming 最核心的開發人員、Databricks 工程師，Tathagata Das（以下簡稱“TD”）在開場演講中介紹了 Structured Streaming 的基本概念，及其在存儲、自動流化、容錯、性能等方面的特性，在事件時間的處理機制，最後帶來了一些實際應用場景。
首先，TD 對流處理所面對的問題和概念做了清晰的講解。TD 提到，因為流處理具有如下顯著的複雜性特征，是以很難建立非常健壯的處理過程：
- 一是資料有各種不同格式（Jason、Avro、二進制）、髒資料、不及時且無序；
- 二是複雜的加載過程，基于事件時間的過程需要支援互動查詢，和機器學習組合使用；
- 三是不同的存儲系統和格式（SQL、NoSQL、Parquet 等），要考慮如何容錯。
因為可以運作在 Spark SQL 引擎上，Spark Structured Streaming 天然擁有較好的性能、良好的擴充性及容錯性等 Spark 優勢。除此之外，它還具備豐富、統一、高層次的 API，是以便于處理複雜的資料和工作流。再加上，無論是 Spark 自身，還是其內建的多個存儲系統，都有豐富的生态圈。這些優勢也讓 Spark Structured Streaming 得到更多的發展和使用。
流的定義是一種無限表（unbounded table），把資料流中的新資料追加在這張無限表中，而它的查詢過程可以拆解為幾個步驟，例如可以從 Kafka 讀取 JSON 資料，解析 JSON 資料，存入結構化 Parquet 表中，并確定端到端的容錯機制。其中的特性包括：
- 支援多種消息隊列，比如 Files/Kafka/Kinesis 等。
- 可以用 join(), union() 連接配接多個不同類型的資料源。
- 傳回一個 DataFrame，它具有一個無限表的結構。
- 你可以按需選擇 SQL（BI 分析）、DataFrame（資料科學家分析）、DataSet（資料引擎），它們有幾乎一樣的語義和性能。
- 把 Kafka 的 JSON 結構的記錄轉換成 String，生成嵌套列，利用了很多優化過的處理函數來完成這個動作，例如 from_json()，也允許各種自定義函數協助處理，例如 Lambdas, flatMap。
- 在 Sink 步驟中可以寫入外部存儲系統，例如 Parquet。在 Kafka sink 中，支援 foreach 來對輸出資料做任何處理，支援事務和 exactly-once 方式。
- 支援固定時間間隔的微批次處理，具備微批次處理的高性能性，支援低延遲的連續處理（Spark 2.3），支援檢查點機制（check point）。
- 秒級處理來自 Kafka 的結構化源資料，可以充分為查詢做好準備。
Spark SQL 把批次查詢轉化為一系列增量執行計劃，進而可以分批次地操作資料。
在容錯機制上，Structured Streaming 采取檢查點機制，把進度 offset 寫入 stable 的存儲中，用 JSON 的方式儲存支援向下相容，允許從任何錯誤點（例如自動增加一個過濾來進行中斷的資料）進行恢複。這樣確定了端到端資料的 exactly-once。
在性能上，Structured Streaming 重用了 Spark SQL 優化器和 Tungsten 引擎，而且成本降低了 3 倍！
Structured Streaming 隔離處理邏輯采用的是可配置化的方式（比如定制 JSON 的輸入資料格式），執行方式是批處理還是流查詢很容易識别。同時 TD 還比較了批處理、微批次 - 流處理、持續流處理三種模式的延遲性、吞吐性和資源配置設定情況。
在時間視窗的支援上，Structured Streaming 支援基于事件時間（event-time）的聚合，這樣更容易了解每隔一段時間發生的事情。同時也支援各種使用者定義聚合函數（User Defined Aggregate Function，UDAF）。另外，Structured Streaming 可通過不同觸發器間分布式存儲的狀态來進行聚合，狀态被存儲在記憶體中，歸檔采用 HDFS 的 Write Ahead Log （WAL）機制。當然，Structured Streaming 還可自動處理過時的資料，更新舊的儲存狀态。因為曆史狀态記錄可能無限增長，這會帶來一些性能問題，為了限制狀态記錄的大小，Spark 使用水印（watermarking）來删除不再更新的舊的聚合資料。允許支援自定義狀态函數，比如事件或處理時間的逾時，同時支援Scala 和Java。
TD 在演講中也具體舉例了流處理的應用情況。在蘋果的資訊安全平台中，每秒将産生有百萬級事件，Structured Streaming 可以用來做缺陷檢測，下圖是該平台架構：
在該架構中，一是可以把任意原始日志通過 ETL 加載到結構化日志庫中，通過批次控制可很快進行災難恢複；二是可以連接配接很多其它的資料資訊（DHCP session，緩慢變化的資料）；三是提供了多種混合工作方式：實時警告、曆史報告、ad-hoc 分析、統一的 API 允許支援各種分析（例如實時報警系統）等，支援快速部署。四是達到了百萬事件秒級處理性能。
CarbonData 原理、應用和新規劃
華為大資料架構師蔡強在以 CarbonData 為主題的演講中主要介紹了企業對資料應用的挑戰、存儲産品的選型決策，并深入講解了 CarbonData 的原理及應用，以及對未來的規劃等。
企業中包含多種資料應用，從商業智能、批處理到機器學習，資料增長快速、資料結構複雜的特征越來越明顯。在應用內建上，需要也越來越多，包括支援 SQL 的标準文法、JDBC 和 ODBC 接口、靈活的動态查詢、OLAP 分析等。
針對目前大資料領域分析場景需求各異而導緻的存儲備援問題，CarbonData 提供了一種新的融合資料存儲方案，以一份資料同時支援支援快速過濾查找和各種大資料離線分析和實時分析，并通過多級索引、字典編碼、預聚合、動态 Partition、實時資料查詢等特性提升了 IO 掃描和計算性能，實作萬億資料分析秒級響應。蔡強在演講中對 CarbonData 的設計思路做了詳細講解。
- 在資料統一存儲上：通過資料共享減少孤島和備援，支援多種業務場景以産生更大價值。
- 大叢集：差別于以往的單機系統，使用者希望新的大資料存儲方案能應對日益增多的資料，随時可以通過增加資源的方式橫向擴充，無限擴容。
- 易內建：提供标準接口，新的大資料方案與企業已采購的工具和 IT 系統要能無縫內建，支撐老業務快速遷移。另外要與大資料生态中的各種軟體能無縫內建。
- 高性能：計算與存儲分離，支援從 GB 到 PB 大規模資料，十萬億資料秒級響應。
- 開放生态：與大資料生态無縫內建，充分利用雲存儲和 Hadoop 叢集的優勢。
資料布局如下圖，CarbonData 用一個 HDFS 檔案構成一個 Block，包含若幹 Blocklet 作為檔案内的列存資料塊，File Header/Fille Footer 提供中繼資料資訊，内置 Blocklet 索引以及 Blocklet 級和 Page 級的統計資訊，壓縮編碼采用 RLE、自适應編碼、Snappy/Zstd 壓縮，資料類型支援所有基礎和複雜類型：
Carbon 表支援索引，支援 Segment 級 (注: 一個批次資料導入為一個 segment) 的讀寫和資料靈活管理，如按 segment 進行資料老化和查詢等，檔案布局如下：
- Spark Driver 将集中式的索引存在記憶體中，根據索引快速過濾資料，Hive metastore 存儲表的中繼資料 (表的資訊等)。
- 一次 Load/Insert 對應生成一個 Segment, 一個 Segment 包含多個 Shard, 一個 Shard 就是一台機器上導入的多個資料檔案和一個索引檔案組成。每個 Segment 包含資料和中繼資料（CarbonData File 和 Index 檔案），不同的 Segment 可以有不同的檔案格式，支援更多其他格式（CSV, Parquet），采用增量的資料管理方式，處理比分區管理的速度快很多。
查詢時會将 filter 和 projection 下推到 DataMap（資料地圖）。它的執行模型如下：
- 主要包括 Index DataMap 和 MV DataMap 兩種不同 DataMap，三級 Index 索引架構減少了 Spark Task 數和磁盤 IO，MV 可以進行預彙聚和 join 的操作，用資料入庫時間換取查詢時間。
- DataMap 根據實際資料量大小選擇集中式或者分布式存儲，以避免大記憶體問題。
- DataMap 支援記憶體或磁盤的存儲方式。
最後，蔡強也分析了 CarbonData 的具體使用和未來計劃。
在使用上，CarbonData 提供了非常豐富的功能特性，使用者可權衡入庫時間、索引粒度和查詢性能，增量入庫等方面來靈活設定。表操作與 SparkSQL 深度內建，支援高檢測功能的可配置 Table Properties。文法和 API 保持 SparkSQL 一緻，支援并發導入、更新、合并和查詢。DataMap類似一張視圖表，可用于加速 Carbon 表查詢，通過 datamap_provider 支援 Bloomfilter、Pre-aggregate、MV 三種類型的地圖。流式入庫與 Structured Streaming內建，實作準實時分析。支援同時查詢實時資料和曆史資料，支援預聚合并自動重新整理，聚合查詢會先檢查聚合操作，進而取得資料傳回用戶端。準實時查詢，提供了 Stream SQL 标準接口，建立臨時的 Source 表和 Sink 表。支援類似 Structured Streaming（結構化流）的邏輯語句和排程作業。
CarbonData 從 2016 年進入孵化器到 2017 年畢業，一共釋出了 10 多個穩定的版本，今年 9 月份将會迎來 1.5.0 版的釋出。1.5.0 将支援 Spark File Format，增強對 S3 上資料的支援，支援 Spark2.3 和 Hadoop3.1 以及複雜類型的支援。而 1.5.1 主要會對 MV 支援增量的加載，增強對 DataMap 的選擇，以及增強了對 Presto 的支援。
Flink 在美團的實踐與應用
美團點評資料平台的進階工程師孫夢瑤介紹了美團的實時平台架構及目前痛點，帶來了美團如何在 Flink 上的實踐以及如何打造實時資料平台，最後介紹了實時名額聚合系統和機器學習平台是如何利用 Flink 進行賦能。
孫夢瑤首先介紹了美團目前實時計算平台的架構：
首先，在資料緩存層，Kafka 作為最大的資料中轉層（所有日志類的資料），支撐了美團線上的大量業務，包括離線拉取，以及部分實時處理業務等。其次，引擎層由計算引擎和存儲引擎來支撐，計算引擎由 Storm 和 Flink 混合使用，存儲引擎則提供實時存儲功能。接着，平台層為資料開發提供支援，為美團的日志中心、機器學習中心、實時名額聚合平台提供支撐。架構最頂層的資料應用層 就是由實時計算平台支撐的業務。
目前，美團實時計算平台的作業量已達到近萬，叢集的節點的規模達到千級别，天級消息量已經達到了萬億級，高峰期的秒級消息量則高達千萬條。但是，随着業務的快速擴增，美團點評在實時計算層面仍面臨着一系列的痛點及問題：
- 一是實時計算精确性問題：由于 Storm 的 At-Least-Once 特性導緻資料重複，而滿足 Exactly-Once 的 Trident 無法保證某些業務的毫秒級延遲要求。
- 二是流進行中的狀态管理問題：基于 Storm 的流處理的狀态如果管理不好，會引起故障難以恢複的尴尬狀況。
- 三是實時計算表義能力的局限性：基于對實時計算場景的業務需求，發現之前的系統在表義能力方面有一定的限制。
- 四是開發調試成本高：不同生态的手工代碼開發，導緻後續開發、調試、維護成本的增加。
在這樣的的背景下，美團點評基礎資料團隊也開始引入 Flink 并探索相對應的創新實踐之路。Flink 在美團點評的實踐主要包括三大次元：一是穩定性實踐，二是 Flink 的平台化，三是生态建設：
-
穩定性實踐層面，美團點評首先按不同的業務（取決于不同的高峰期、運維時間、可靠性、延遲要求、應用場景等）進行對應的資源隔離，隔離政策是通過 YARN 在實體節點上打标簽和隔離離線 DataNode 與實時計算節點。
其次，再實施基于 CPU、基于記憶體的智能排程，目前方案是從 CPU 和記憶體兩個方面進行排程優化。還包括對 Flink 的 JobManager 部署 HA(High Availability)，保證節點的高可用性。針對網絡連接配接故障，采用自動拉起的方式，通過 checkpoint 恢複失敗的作業。
此外，針對 Flink 對 Kafka 08 的讀寫逾時，美團點評會根據使用者的指定次數對異常進行重試，這種方式在解決大規模叢集的節點故障問題時可以做更好的平衡。在容災方面，其采用了多機房和各種熱備提升系統的抗故障能力，即使斷電斷網也能進行保證作業繼續進行資料處理。
- Flink 平台化層面，通過内部的作業管理的實時計算平台，其團隊可以看到總覽的作業狀态，以及資源運作和占用情況。針對實時作業中可能出現的狀态，比如延遲、失敗，提供監控報警并能便捷地進行消息預訂（電話，郵件，短信等方式）。針對顯著的性能差别，也提供了調優診斷的手段進行自助查詢、對比、診斷。
接下來，孫夢瑤還主要講解了 Flink 在美團的應用，其中主要包括兩點：一是在Petra 實時名額聚合系統的應用，二是用于 MLX 機器學習平台的建構。
- Petra 實時名額聚合系統主要完成對美團業務系統名額的聚合和展示。它對應的場景是整合多個上遊系統的業務次元和名額，確定低延遲、同步時效性及可配置。是以美團點評團隊充分利用了 Flink 基于事件時間和聚合的良好支援、Flink 在精确率（checkpoint 機制）和低延遲上的特性，以及熱點 key 散列解決了次元計算中的資料傾斜問題。
MLX 機器學習平台
MLX 機器學習平台主要通過特征資料的提取和模型的訓練，支援美團點評的搜尋和推薦以及其他業務的應用。它需要滿足提供離線模式——通過批處理抽取離線特征資料，同時也提供近線模式——通過 Flink 抽取實時日志系統中的特征資料。接着訓練綜合了離線和近線資料的特征資料叢集，提取特征并進行模型訓練，最終産生有意義的特征。目前，它能支援現有離線場景下的特征提取體系，通過 Flink 支援增量線上日志交易類資料，有了離線和線上資料就能較好的支援模型訓練、特征提取、線上預估、實時預測等。
未來，美團點評還将從三方面優化 Flink 相關實踐：
- 狀态的統一方面：對狀态進行統一的管理以及大狀态性能優化。
- SQL 開發效率的提升：基于 Flink 在語義上的優勢解決配置、查詢方面的問題，在性能、開發、維護方面做進一步優化。
- 新應用場景的探索：除流處理外，進一步整合業務場景下離線和線上資料，通過統一的 API 為業務提供更多的服務。
Flink 和 Spark 流架構對比 + 華為流計算技術演進
華為雲技術專家時金魁作為最後一位演講嘉賓，系統性地梳理、比較了 Flink／Spark 的流架構，同時介紹了華為流計算技術演進過程，并詳解了華為 CloudStream 的服務能力及應用。
時金魁一開始即列舉了最常用的流計算架構 Storm、Nifi、Spark 和 Flink 等。提供了下面常見開源流計算架構以便大家了解這個生态圈的最新情況。
其中，華為雲 CloudStream 同時支援 Flink 和 Spark（Streaming 和 Structured Streaming）。時金魁提到，華為流計算團隊在研發過程中發現，Spark Streaming 能力有限，無法完全滿足實時流計算場景，而華為自研多年的流架構生态不足，Storm 日薄西山，是以華為在 2016 年轉向 Flink 為主 Spark 為輔的組合。今年 Spark Structured 能力越來越豐富，與 Flink 之間的 gap 正快速縮小，也是幸事。
時金魁認為，流計算就是實時處理當下正在發生的流資料，逐條進行大資料分析或算法運算。它具備以下幾個特征：
- 資料先後順序不确定導緻的亂序問題。
- 記憶體計算。
- 流速不定（資料大小不能預測），資料傾斜（分布不均勻），導緻計算資源配置設定不均，能力受限。
- Long running 永遠不結束。
- 基于消息事件的逐條處理。
- 提供可靠的快照。
從新技術、使用者耐心、大資料增長幾個方面，時金魁介紹了實時流計算最大限度挖掘資料的價值，是商業驅動和市場價值的一種展現。實時流計算具有豐富的使用場景，如實時商品的廣告推薦、金融風控、交通物流、車聯網、智慧城市等等。隻要需要對實時的大資料推薦或者實時大資料分析，都能找到流計算的應用價值。
時金魁在演講中重點講解了資料流模型，即它是一個實時往下流的過程。在 Flink 中，客觀的了解就是一個無限的資料流，提供配置設定和合并，并提供觸發器和增量處理機制。如下圖所示：
時金魁介紹說，對華為而言，Spark，Flink 以及 CloudStream，這三部分構成了 LOGO 中的“三條杠”，華為實時流計算服務俗稱“華為雲三道杠”，為客戶主要提供雲計算的服務。
通過對 Flink 的核心分析以及運作分析，他解釋了如何實作一個完整的資料流處理過程：
- 解析：邏輯關系解析，生成 StreamTransformation
- 分析：建構 StreamGraph，DAG，為生成執行計劃準備
- 生成：建構 ExecutionGraph，為運作做準備
- 執行：申請資源，執行計劃（算子）
- 最後生成資料流（DataStream）
下圖是 Flink 的技術棧圖，包括了一個完整的資料流架構：
此外，時金魁還對 Flink 和 Spark 做了詳細的對比。Flink的優勢包括具備成熟的資料流模型，能提供大量易用的 API 供使用，在 SQL、Table、CEP、ML、Graph 方面都提供完善的功能。對比之下，Spark擁有活躍的社群和完善的生态，Structured Streaming 能提供統一标準，保證低延遲。
而華為根據 Flink 與 Spark 架構各自的特點，摒棄其劣勢，設計開發出一款全新的實時流計算服務 Cloud Stream Service（簡稱 CS）。CS 采用 Apache Flink 的 Dataflow 模型，實作完全的實時計算，同時采用線上 SQL 編輯平台編寫的 Stream SQL，自定義資料流入、資料處理、資料流出，并完全相容 Spark 和 Flink 的 API。
總結來說，Cloud Stream 具有易用、按需計費、開箱即用、低延時（毫秒）高吞吐（百萬消息每秒）、完整生态、完全可靠等幾大優勢。
例如，在易用性次元，Cloud Stream 利用可視化的 StreamSQL 編輯器，是以可以友善地定義 SQL，可線上調試和監控作業。
在安全性次元，華為實時流計算團隊在行業首創了全托管的 serverless 獨享叢集模式。第一，它采用實體隔離，使得使用者在作業運作時和資源上無共享，多使用者之間無交叉；二是在業務上實作隔離，使得連接配接、資料和計算互相獨立無幹擾；三是沙箱在共享資源池中很難完全防語言、應用、OS 等方面的共計，而且對 Spark 和 Flink 有一定的侵入性。
線上機器學習方面，CloudStream 通過了流式随機森林算法應用于實時故障檢測；通過特征工程應用于實時推薦；通過線上機器學習應用于智慧城市；通過地理分析函數應用于卡車運輸位置檢測。
最後，時金魁也分享了 CloudStream 支援對接使用者自己搭建的 Kafka、Hadoop、Elastic Search、RabbitMQ 等開源産品叢集；同時已支援連通華為雲上的其他服務，如消息通知服務、雲搜尋服務、智能邊緣平台等十幾個服務，進而為使用者提供一站式、生态豐富、功能強大的實時流計算平台。
版權聲明：
本文為大資料技術與架構整理，原作者獨家授權。未經原作者允許轉載追究侵權責任。
編輯｜冷眼丶
微信公衆号｜import_bigdata