- Spark是一個實時處理框架
- Spark提供了兩套實施解決方案：Spark Streaming（SS）、Structured Streaming（SSS）
- 然后再結合其它框架：Kafka、HBase、Flume、Redis
- 項目流程：架構分析、數據產生、數據采集、數據收集、數據實時交換、實時流處理、結果可視化、調優
- 1）【項目啟動】架構分析
- 2）【環境部署】基礎開發環境搭建
- 2）【數據產生】
- 3）【數據采集】構建日志服務器（偏重於日志產生及存儲）
- 4）【數據收集】基於Flume構建分布式日志收集（偏重於數據從A地方到B地方的操作）
- 5）【消息隊列】基於Kafka構建實時數據交換
- 6）【實時流處理】Spark Streaming核心API
- 7）【實時流處理】應用Spark Streaming實現數據分析及調優
- 8）【實時流處理】Structured Streaming應用
- 9）【實時流處理】應用Structured Streaming實現數據分析及調優
- 10）【數據可視化】使用Echarts完成數據展示
- 架構圖
- 1）日志采集：自定義一個日志服務
- 2）數據收集交換：使用Flume將日志服務數據收集過來，落在Kafka上
- 3）實時處理：基於Spark Streaming（SS）、Structured Streaming（SSS）來對接Kafka的數據
- 4）數據存儲：第3）步處理后的數據，Spark Streaming處理的數據存儲至HBase中，Structured Streaming處理的數據存儲至Redis
- 5）查詢API：頁面的請求通過API，即使用Spring Boot、Spring Data來查詢HBase和Redis里的數據，並把數據放置可視化里。在可視化里是通過Echarts來展示。也會使用到React來封裝Echarts。
- 6）整個項目的運行環境：產商雲主機、物理機、虛擬機
- 更詳細的流程
- 1）客戶端所產生的日志，通過Nginx協議端過來后，給它負載均衡落在LogServer上，其中LogServer是自定義開發的。
- 2）然后，會使用兩層的Flume架構，第一層Flume用於收集LogServer上的數據，第二層Flume對接第一層並做聚合操作（這樣操作的原因，后續講解）
- 3）其次，Flume收集的數據，對接到Kafka
- 4）后面交給流處理引擎來處理，處理后的結果存儲到存儲層
- 5）最后，使用API這層，將存儲的結果通過UI進行可視化展示
- Spark和Kafka對接的offsets管理維護
- 1）首先，在Kafka集群里，做分區。
- 2）Kafka分區后，與Spark Streaming做對接
- 3）基於DStream，Spark Streaming可以進行一些處理，處理后將結果存儲下來。
- 4）處理的批次對應的offset是哪些呢？需要通過commit offsets存儲到HBase/Kafka/ZK/MySQL
- 5）如果作業掛掉/出現異常，機器重啟，在DStream處理時，應該從已經存儲過的offsets的HBase/Kafka/ZK/MySQL，往后進行操作，這樣才能保證數據是准確的。
- 展示效果
- 1）當天每小時用戶訪問時長（當天零點開始，到某一個時間點的用戶訪問時長（連帶輪動））
- 2）當天用戶時長的Top10
- 3）用戶訪問區域的統計（以地圖方式展示），根據具體日期展示各省份訪問次數的Top10
- 4）不同性別、年齡段訪問人數統計
- 環境參數
- 1）Spark：3*版本
- 2）Hadoop生態：CDH（5.16.2）
- 3）Kafka：2.5.0
- 4）Redis：6.0.6
- 5）JDK：1.8
- 6）Scala：2.12
- 7）Linux版本：CentOS 7
- 8）Maven：3.6.3
- 項目目的
- 1）從總體到細節掌握大數據實時處理的解決方案
- 2）各個框架各司其職，並做好各個框架之間的銜接
- 3）基於第二點，做到框架的高可用。在實際生產中，不僅僅要跑通，還要考慮每個環節的高可用。假如一個環節出問題，不能影響整體的一個流程。
- 技術選型
- 0）基礎：Hadoop
- 1）數據產生：SDK來完成，代碼的方式
- 2）數據采集：SpringBoot來構建日志服務器
- 3）數據收集：Flume
- 4）數據交換/消息隊列：Kafka
- 5）實時流處理：SS、SSS
- 6）結果存儲：HBase、Redis
- 7）可視化：Echarts、React
- 項目架構V1版本
- 1）用戶---（問題1/2）---->LogServer----(source)--->Flume----(sink)--->Kafka Clauster (Topic)(實時)（問題3）------->Spark------->DB------->API------->UI
- 2）V1版本存在的問題1：實際上LogServer是由很多機器構成，這些機器有着不同的IP地址。不同用戶的操作數據，上報到LogServer中不同的機器上，還需要去關注LogServer中不同機器的IP地址嗎？當然不應再去關注LogServer相關信息。
- 3）V1版本存在的問題2：每一個用戶的操作數據和LogServer中的機器，不可能一一對應，所以這里缺少負載均衡。所以用戶的操作數據通過負載均衡，讓數據比較均衡的落在LogServer中每個機器上。
- 4）V1版本存在的問題3：離線處理及實時處理的數據源都是一樣的。Kafka是實時處理，當然也可以放入HDFS中進行離線處理。單層的Flume是存在隱患的，它沒有任何負載均衡和容錯性可言，一旦sink出問題，會影響整個流程的運轉。
- 項目架構V2版本
- 1）用戶------->Nginx Cluster------->LogServer----(source)--->Flume 1----(sink)--->Flume 2------->Kafka Clauster (Topic)(實時)------->Spark------->DB------->API------->UI
- 2）Nginx Cluster來完成負載均衡
- 3）Flume 2 進行聚合操作，相當於是容錯機制。如果第一套sink出問題了，采用第二套sink。做一個高可用的配置，使得第一個sink出問題，也能保障整個流程運轉正常。