熱門論文
最新論文
基于Flink框架的電商平臺實時數 倉的設計與實現
發布時間：2022-08-20 11:24
目錄
第一章 緒論 1
1.1 研究的背景 1
1.2 數據倉庫架構發展演變 2
1.3 研究的主要內容和意義 3
1.4 論文的組織結構 4
第二章 相關技術介紹 6
2.1Spring Boot 框架 6
2.2MySQL 數據庫 7
2.3MyBatis 框架 9
2.4Kafka 消息中間件 10
2.5MaxWell 數據同步工具 12
2.6HBase 數據庫 13
2.7ClickHouse 數據庫 14
2.8Flink 框架 15
第三章 系統需求分析 19
3.1 系統需求概述 19
3.2 系統功能性需求分析 19
3.2.1電商平臺功能 19
3.2.2實時數倉功能 20
3.2.3可視化平臺功能 21
3.3 系統非功能性需求分析 23
3.3.1性能分析 23
3.3.2擴展性分析 23
3.3.3可靠性分析 23
第四章 系統概要設計 24
4.1 系統架構設計 24
4.2 系統功能設計 25
4.2.1電商平臺功能設計 25
4.2.2實時數倉功能設計 26
4.2.3可視化平臺功能設計 28
4.3 系統性能設計 28
4.4 系統數據庫設計 29
4.4.1MySQL 數據庫表結構設計 29
4.4.2HBase 數據庫表結構設計 36
4.4.3ClickHouse 數據庫表結構設計 38
第五章 系統詳細設計與實現 42
5.1 電商平臺詳細設計與實現 42
5.1.1用戶模塊詳細設計 42
5.1.2商品模塊詳細設計 43
5.1.3購物車模塊詳細設計 44
5.2數據ODS層詳細設計與實現 45
5.2.1日志數據收集 46
5.2.2業務數據收集 48
5.3數據DWD層詳細設計與實現 51
531日志數據分流Flink程序實現 52
532業務數據分流Flink程序實現 55
5.4數據DWM層詳細設計與實現 60
5.4.1UV日活訪客數據流Flink程序實現 61
5.4.2跳出行為數據流Flink程序實現 63
543訂單寬表數據流Flink程序實現 65
5.4.4支付寬表數據流Flink程序實現 70
5.5 數據 DWS 層詳細設計與實現 72
5.5.1訪客主題 Flink 程序實現 73
5.5.2商品主題 Flink 程序實現 76
5.5.3地區主題 Flink 程序實現 80
5.5.4關鍵詞主題 Flink 程序實現 82
5.6 可視化平臺詳細設計與實現 86
5.6.1訪客主題可視化實現 87
5.6.2商品主題可視化實現 89
5.6.3地區主題可視化實現 94
5.6.4關鍵詞主題可視化實現 95
5.6.5可視化大屏 97
第六章 系統測試 98
6.1 系統測試環境 98
6.2 系統功能測試 99
6.2.1電商平臺功能測試 99
6.2.2實時數倉功能測試 99
6.2.3可視化平臺功能測試 100
6.3 系統性能測試 101
6.3.1電商平臺性能測試 101
6.3.2實時數倉性能測試 102
6.3.3可視化平臺性能測試 103
第七章 總結與展望 104
7.1總結 104
7.2展望 105
參考文獻 106
致謝
圖目錄
圖 2-1 MySQL 體系架構圖 8
圖 2-2 MyBatis 流程層次架構圖 9
圖 2-3 Kafka 集群架構圖 11
圖 2-4 MaxWell 數據同步原理圖 12
圖 2-5 HBase 數據邏輯結構圖 13
圖 2-6 HBase 系統架構圖 14
圖 2-7 Flink 組件架構圖 16
圖 2-8 Flink 運行架構圖 17
圖 3-1 電商平臺功能用例圖 20
圖 3-2 實時數倉數據流程圖 20
圖 3-3 可視化平臺主題指標圖 22
圖 4-1 系統架構圖 24
圖 4-2 電商平臺功能結構圖 26
圖 5-1 用戶模塊 UML 順序圖 42
圖 5-2 商品模塊 UML 順序圖 43
圖 5-3 購物車模塊 UML 順序圖 44
圖 5-4 數據 OWD 層結構圖 45
圖 5-5 數據 DWD 層結構圖 51
圖 5-6 日志數據分流程序流程圖 52
圖 5-7 業務數據分流程序流程圖 55
圖 5-8 數據 DWM 層結構圖 60
圖 5-9 UV 日活訪客程序流程圖 62
圖 5-10 跳出行為程序流程圖 64
圖 5-11 訂單寬表程序流程圖 66
圖 5-12 支付寬表程序流程圖 70
圖 5-13 數據 DWS 層結構圖 72
圖 5-14 訪客主題程序流程圖 73
圖 5-15 商品主題程序流程圖 7 7
圖 5-16 地區主題程序流程圖 80
圖 5-17 關鍵詞主題程序流程圖 83
圖 5-18 可視化平臺結構圖 86
圖 5-19 可視化表格組件配置信息 89
圖 5-20 訪客主題表格組件示例圖 89
圖 5-21 商品主題組合組件示例圖 93
圖 5-22 地區主題省市熱力組件示例圖 95
圖 5-23 關鍵詞主題字符云組件示例圖 96
圖 5-24 可視化大屏示例圖 97
表目錄
表 4-1 數據分層設計對照表 27
表 4-2 主題指標與可視化組件對照表 28
表 4-3 商品信息表 SPU_INFO 30
表 4-4 品牌信息表 BASE_ TRADEMARK 30
表 4-5 品類信息表 BASE_CATEGORY 30
表 4-6 庫存單元信息表 SKU_INFO 30
表 4-7 購物車信息表 CART_INFO 31
表 4-8 訂單信息表 ORDER_INFO 32
表 4-9 訂單明細表 ORDER_DETAIL 33
表 4-10 支付信息表 PAYMENT_INFO 34
表 4-11 省市地區信息表 BASE_PROVINCE 34
表 4-12 用戶信息表 USER_INFO 35
表 4-13 動態分流配置信息表 TABLE_PROCESS 36
表 4-14 商品維度信息表 DIM_SPU_INFO 37
表 4-15 品牌維度信息表 DIM_BASE_ TRADEMARK 37
表 4-16 品類維度信息表 DIM_BASE_CATEGORY 37
表 4-17 庫存單元維度信息表 DIM_SKU_INFO 37
表 4-18 省市地區維度信息表 DIM_BASE_PROVINCE 38
表 4-19 用戶維度信息表 DIM_USER_INFO 38
表 4-20 訪客主題信息表 VISITOR_STATS 39
表 4-21 商品主題信息表 PRODUCT_STATS 39
表 4-22 地區主題信息表 PROVINCE_STATS 40
表 4-23 關鍵詞主題信息表 KEYWORD_STATS 41
表 5-1 數據可視化接口分層設計表 86
表 5-2 商品主題組件接口配置對照表 93
表 6-1 測試環境配置信息表 98
表 6-2 電商平臺功能測試用例表 99
表 6-3 實時數倉功能測試用例表 100
表 6-4 可視化平臺功能測試用例表 101
表 6-5 電商平臺性能測試用例表 101
表 6-6 實時數倉性能測試用例表 102
表 6-7 可視化平臺性能測試用例表 103
第一章 緒論
1.1研究的背景
隨著互聯網在國內普及程度的不斷提升，線上購物已經融入到民眾的日常生 活中，根據中國互聯網發展狀況統計報告數據：截至 2019 年 6 月，我國網民規 模達 8.54 億，互聯網普及率達 61.2%；網絡購物用戶規模達 6.39 億，占網民整 體的 74.8%［1］。相比于傳統購物模式，線上購物的優點主要集中在其較強的跨域 性和交互性方面，電商平臺則成為銷售方和購買方最主要的信息交互平臺，電商 平臺商品的信息展示也極大的影響著消費者的購買行為。
在電商平臺購物迅速發展的現代網絡經濟環境下，各類型商品信息持續不斷 的展示于廣大消費者面前。在見識到各類商品整體的品類和樣式后，消費者也由 原來對新生事物的期待心理逐漸趨于穩定，更加注重在眾多商品中挑選出符合自 身需求并且整體性價比更高的商品，并對該類型商品保持穩定消費。
上述網絡消費心理轉變的趨勢下，網絡經濟視角下的電商運營模式也在進行 順應時代發展的變革。當下電商平臺整體的運營策略應該時刻把握消費者的消費 心理和消費行為，統計分析出大眾消費者的消費方向和消費理念，所以電商對制 定的運營策論就不應該是靜態的，而是階段性動態的，所制定的運營策略就不應 該被動應對消費者的消費轉變，而是主動適應消費趨勢。這就要求電商在制定運 營策略時能夠根據消費者的消費行為變化做出靈活的變動，對當前階段的營銷內 容實行監管和預測，隨時獲取市場趨勢，將消費者需求放在運營策略選擇的首位， 真正考慮到消費者的需要［2］。
增強電商平臺對用戶行為的感知，繼而為顧客展示出更加具有吸引力的商品 信息，則會提高顧客的購買意愿。比如，可以依據平臺瀏覽用戶的點擊、加購、 下單以及搜索過的關鍵信息等實際行為統計分析，將最為優質的產品、產品優惠 信息及相關資訊信息優先推薦，讓用戶更快地找到合適的商品，提高電商平臺瀏 覽量，以此將用戶的關注意愿轉換為銷售增長點［3］。
實時數倉是一個能夠對平臺數據進行實時聚合處理的數倉服務，該服務還可以對接可視化工具實現業務主題指標數據的實時展示。因此為了增強電商平臺與 消費者的良性互動，為電商平臺搭建實時數倉能夠實時統計當前產品銷售情況、 用戶狀態、用戶行為等，以便于能更好的分析數據，跟蹤用戶的歷史行為，同時 根據分析結果預測出電商行業消費趨勢，能夠為電商平臺的發展提供切實的數據 支持。
1.2數據倉庫架構發展演變
比爾•恩門(Bill Inmon)于1990年出版的《建立數據倉庫》首次提出了數 據倉庫的概念，并詳述了整體的構建方法。確定數據倉庫是一個面向主題的、集 成的、相對穩定的和反映歷史變化的數據集合，主要用于支持管理決策［4］。Inmon 對于數倉整體構建理念的出發點是自上而下的，也就是在構建數倉的時候需要首 先將整體的業務邏輯以及數據結構整理清楚，分層設計。
接著Kimball發表的一書《The Data Warehouse Toolkit》，開啟了數據集市的 狂潮，開創了一種自下而上流數據倉庫建設的流派，以下層數據需求為目標反向 層層構建，最終確定業務系統的數據收集內容，由于該構建方式是以目標定需求， 非常有利于工作的開展，數據集市大行其道。最終在1998年， Inmon 集中了二 者的優點提出了 BI架構CIF (企業信息工廠)，成為了數據倉庫建設的框架性指 南。
隨著互聯網的發展，數據量的急劇增加，Kettle等傳統ETL工具逐漸變得不 穩定，數據庫等存儲技術也面臨著存儲緊張，為應對數據量的暴增，開始使用 HDFS 來進行存儲，數據計算也開始使用 Hive 來代替 Kettle、 Informatica 等 ETL 工具。此時僅僅是工具的取代，整體的架構沒發生變化，形成了離線大數據架構。
后來隨著網絡技術和通信技術的發展，能夠使得數據實現實時上傳，而且隨 著大數據應用的發展，為了保證數據的時效性，開始計算數據的實時指標，在原 來的離線數倉的基礎上，增加了實時計算的鏈路，實時指標與離線計算的結果進 行合并。由于此時的流式處理引擎還不夠完善，流處理計算的指標依然需要批處 理計算，最終以批處理為準，即每次批處理計算后會覆蓋流處理的結果。形成了 由 Storm 的作者 Nathan Marz 提出的一個實時數據處理框架 Lambda 架構。
Lambda 架構的優勢就是在于能夠支持海量數據批量計算處理（即離線處理），同 時也支持流式的實時處理（即熱數據處理）［5］。
Lambda 架構雖然滿足了實時的需求，但是其架構背景是流式處理引擎還不 完善，流處理的結果只作為臨時的和近似的值提供參考，而且該架構占用資源較 多，數據服務層的處理較為復雜，需要合并實時指標和離線計算結果。隨著對于 數據時效性要求越來越多，實時指標從次要部分演變成了主要信息部分，同時隨 著流式處理引擎的出現，特別是 Flink 的出現使得 Exactly-Once 和狀態計算成為 可能，使得流式處理技術發展成熟。2014年的夏天，Lickedln的Jay Kreps在他 的博文中正式提出了 Kappa 架構，其主要的思想就是使用流式處理引擎來進行 數據處理，實時數據與流式處理進行合并，用消息隊列代替數據通道。解決了 Lambda 架構里面的冗余部分，以數據可重播的超凡思想進行了設計，使整個架 構非常簡潔［6］。
在實際的項目構建中， Lambda 和 Kappa 架構都可以結合多種開源技術來使 用，例如：Kafka、HBase、Hadoop、Spark、Spark Streaming、Storm 和 Flink 等 ［7］。所以在應對不同的實際項目場景中，便形成了多樣的技術實現架構。
在國外，有較多的數據倉庫供應商，如 Oracle、 IBM、 CA、 Teradata、 Vertica、 SAP HANA 和 ParAccel 等，他們通過昂貴的商業許可來銷售其數據倉庫系統。 歐美等發達國家是最早通過對 OLAP 數據倉庫的探究與運用，在相應重要的業 務領域都取得了相應的成功。在我國，國家發改委提出大力推動大數據發展應用 促進中國數字經濟加快發展，使我國信息產業建設進入大數據時代的高速路，政 府及企業將逐漸完善大數據建設，加強自我研發能力。近些年，我國數據開發企 業也相繼研發出智能化數據分析平臺，在交通、醫療、物流等許多行業收獲了巨 大的經濟效益。
1.3研究的主要內容和意義
本文研究的主要內容包括三個部分，首先根據電商業務搭建一個具有核心業 務功能的電商平臺應用，為搜集用戶的行為和業務數據提供數據入口，然后基于 Flink 流數據處理框架搭建的實時計算服務與 Kafka 消息隊列服務、 HBase 和
ClickHouse數據庫相互配合，共同構建成了基于Flink框架的電商平臺實時數倉。 該實時數倉會對電商平臺實時產生的較為核心的用戶行為數據和業務數據實現 分層設計，完成數據的實時收集和處理，最后通過Spring Boot搭建的數據接口 服務與可視化工具共同實現了主題指標數據的可視化大屏展示。
本文的創新性主要體現在技術改造優化和內容結構設計兩個方面：
技術改造優化方面，本文將使用模板方法設計模式對Flink執行算子的結構 進行改造，使其能兼容多維度關聯，在數據匯聚擴展過程中，實現數據流的動態 關聯；使用配置分離設計并對數據序列化進行重構，使程序流程能夠進行多層分 流，在數據分解細化過程中，實現對業務數據的動態分流。通過對這兩個階段數 據處理的技術優化，彌補了 Flink算子在動態執行方面靈活度不足的缺點。
內容結構設計方面，本文將基于電商平臺核心的業務場景和數據結構，為電 商平臺提供一套完整且切實可行的數據處理和可視化展示方案，并揭示了實時數 倉數據轉換和流程計算的技術實現細節，通過對技術細節的展示間接地增強了 Flink 實時數倉的技術可信度。
本文提供的實時數倉設計方案和可視化展示方案，不僅能體現平臺數據的時 效價值，也能為平臺制定實時有效運營策略提供數據支持，具有現實意義；在數 據實時計算過程中，本文根據各場景實例，展示了 Flink多樣化的計算功能，并 通過技術改進展現出了 Flink數據處理框架在數據計算方面的巨大潛力，具有技 術推廣意義。
1.4論文的組織結構
本文主要分為 7 個章節:
第一章：主要綜述了研究的背景以及研究該課題的必要性，總結了數據倉庫 架構整體的演變過程，同時也指出了本文研究的主要內容和意義。
第二章：主要介紹了電商平臺和實時數倉在開發搭建和設計實現過程中用到 的相關技術和框架，為下文的論述提供技術支持。
第三章：根據系統實際的業務場景，以系統需要實現的功能為出發點，對各 子系統主要的功能進行需求分析。
4
第四章：從技術的角度出發，利用各類軟件產品的技術特點，并結合相關的 需求細節，設計出各子系統功能點的實現方式，為系統的搭建指明了技術方向。
第五章：根據上述系統的需求分析和概要設計，詳細的介紹各功能點實現的 細節和關鍵步驟。
第六章：對實現的系統編寫測試用例，對主要的功能點進行功能測試和性能 測試。
第七章：總結系統整體的分析設計和實現過程，并指明系統后期可改進和擴
展的方向。
第二章 相關技術介紹
2.1Spring Boot 框架
隨著各種動態語言的興起，例如：Ruby、Groovy、Scala、Node. Js 等,使得 Java在開發階段會顯得格外的笨重：繁多的配置、低下的開發效率、復雜的部署 流程以及第三方技術集成難度大。在這種環境下，Spring Boot應運而生。
Spring Boot 是由 Pivotal 團隊在 2013 年開始研發、 2014 年 4 月發布第一個 版本的全新開源的輕量級框架。它基于 Spring 4.0設計，不僅繼承了 Spring 框 架原有的優秀特性，而且還通過簡化配置來進一步簡化了 Spring 應用的整個搭 建和開發過程。此外， Spring Boot 還通過集成大量的框架，很好的解決了基于 Maven進行項目依賴管理出現的版本沖突以及引用不穩定等問題［8］。
Spring Boot 所具備的核心功能：
(1)可以創建獨立運行的 Spring 應用項目；
(2)可選擇內嵌的Servlet容器：Tomcat、Jetty或者Undertow，無需以War 包的形式部署項目；
(3)提供了一系列的 starter pom 簡化 Maven 的依賴配置；
( 4)自動配置 Spring 容器；
(5)準生產的應用監控。提供基于 http SSH telnet 對運行時的項目進行監 控；
(6)不借助代碼生成和XML配置［9］。
其中Out of box開箱即用是Spring Boot框架中一個非常重要的概念，依賴 包和工具包通過 Maven 構建依賴關系之后， Spring Boot 會自動創建和注入需要 的Spring Bean，省略了繁復的配置工作，實現開箱即用的目的，讓整個開發過程 更加注重業務邏輯，提高項目的開發效率。同時， Spring Boot 使用 Convention over configuration 約定優于配置的策略，盡量減少軟件開發人員對于多種方案的 應用決策。通過犧牲部分靈活性，以提升項目開發部署的效率［10］。并且 Spring Boot框架在實際的項目開發過程中，能夠通過簡單的配置集成其他開發框架。例
6如: Hibernate、 MyBatis、 JPA 等持久層框架；常用的 Oracle、 MySQL 和 DB2 等 數據庫；非關系性數據庫Redis和MongoDB等；Solr和Elasticsearch搜索引擎； 以及 Kafka 和 RabbitMQ 消息中間等。 Spring Boot 通過滿足多方面的集成極大的 簡化了應用服務系統搭建的開發難度。
2.2MySQL 數據庫
MySQL 是由瑞典 MySQL AB 公司開發一個小型的關系型數據庫管理系統， 現屬于Oracle旗下產品（MySQL AB公司在2008年被Sun公司收購，2009年 Sun 公司又被 Oracle 公司收購），是最流行的關系型數據庫管理系統之一。
MySQL 相比于 SQL Server 或 Oracle 數據庫來說是將數據保存在不同的表 單中，并不是將所有數據放置于一個大倉庫內，極大提升查詢速度和靈活性［11］。 MySQL 作為一款開源軟件，遵守 GPL 協議，使用最常用的標準化 SQL 語言， 使用C/C++語言編寫，可以在windows> Linux和MacOS多平臺使用，具有良好 的兼容性。 MySQL 憑借其操作簡潔性、較強的響應速度和開放源碼等特點，在
圖 2-1 MySQL 體系架構圖
MySQL整體由連接池、SQL接口、解析器、優化器、緩存和存儲引擎等組 件組成。如圖 2-1 所示，體系架構按照自上而下的大致可劃分為網絡連接層，數 據服務層，存儲引擎層和系統文件層四大部分。網絡連接層主要提供于 MySQL 服務器建立連接的作用，幾乎支持所有主流的服務端語言，各語言通過各自的 API 接口與 MySQL 建立連接；數據服務層是整個數據庫服務的核心，這一層完 成的工作也最多，比如對請求進行數據庫操作進行權限判斷，對語句進行解析、 查詢緩存、內置函數的處理和行處理進行優化等，主要包括了系統管理和控制工 具、連接池、 SQL 接口、解析器、查詢優化器和緩存等部分［13］；存儲引擎層主要 負責數據的寫入和讀取，與底層的文件進行交互。系統文件層主要包括 MySQL 中存儲數據的底層文件，負責與上層的存儲引擎進行交互，是 MySQL 文件的物 理存儲層。其存儲的文件主要包括：日志文件、數據文件、配置文件和管理文件 等。在 MySQL 中不可或缺的還有 Binlog 日志存儲功能，它是一個具有高效率和 靈活性的二進制日志，在記錄數據庫事務操作和數據恢復中起著舉足輕重的作用
[14]
2.3MyBatis 框架
MyBatis原名iBatis,是一個基于Java的持久層框架，本來是Apache Software Foundation的一個開源項目，于2010年遷移到Google code,并更名為MyBatis。 該框架支持自定義SQL，存儲過程以及高級映射。
如圖2-2所示，MyBatis的功能架構主要分為三層：API接口層主要提供給 外部進行數據庫操作；數據處理層主要負責 SQL 語句的查找，解析，執行和結 果映射；基礎支撐層負責最為基礎的功能支撐，包括連接管理，事務管理，配置 加載和緩存處理［15］。
與標準的數據庫訪問支持JDBC類庫相比，它封裝了所有的JDBC代碼和參 數的手工設置以及結果集的檢索，通過簡單的 Xml 語言或者注解來配置和映射 原始類型、接口和數據庫返回的記錄等信息［16-17］。與 Hibernate 這種全表映射框 架相比，MyBatis是一種半自動映射框架，需要手動設置SQL語句和映射關系， 對數據庫操作更加靈活，更加適合開發需求變更頻繁的互聯網系統［18］。
9
2.4Kafka 消息中間件
Kafka 最初由 LinkedIn 公司設計開發，于 2011 年開放源碼，成為了 Apache 軟件基金會開源項目之一。Kafka是一個分布式的、支持分區的、基于發布訂閱 模式的分布式消息系統［19］。分布式消息系統是以消息中間件為機制構建的分布 式架構, 目前分布式消息系統處理的核心模式是發布訂閱模式［20（］ 即消息的生產 者和消費者不直接進行信息關聯，由消息的代理方接收和發布信息，消費者對感 興趣的信息進行訂閱消費）。
Kafka 與現有主流的一些消息中間件相比，具有操作簡單，高吞吐，分布擴 展的優勢。在相同條件下， Kafka 消息的生產和消費性能要明顯優于 ActiveMQ 和RabbitMQ［2i］。通過對Kafka構建分布式系統，其吞吐量還能夠隨集群的擴展 而線性增加。
Kafka集群主要由三部分構成：生產者（Producer）負責將來源數據信息推送 到對應的topic主題隊列中；代理者（Broker）實現對推送來數據進行持久實例 化存儲；消費者（Consumer）負責訂閱拉取對應topic隊列中數據信息，進行后 續的數據處理［22］。
10
Kafka 集群架構圖如圖 2-3 所示，在實際應用中，對特定 Topic 主題進行 partition 分區操作是 Kafka 能夠實現負載均衡，體現高吞吐能力的有力保障。常 見的分區寫入策略(即將topic數據分配到不同分區的方式)有三種：輪詢策略 是按照順序輪流將每條數據分配到每個分區中，這種方式能夠最大限度的保證消 息的平均分配；隨機策略是通過每次獲取的隨機數來確定消息發送到哪個分區， 偶然性較大；按鍵保存策略則是在生產者發送消息時，指定key值，通過計算key 的 Hash 值確定保存消息的分區點［23］。其中分區的數量并不是越多越好，分區越 多，所占用消耗的資源也就越多，所以分區數則需要結合具體的業務場景來確定。
在Kafka集群中，一個topic主題通過分區對應多個partition，partition通過 hash計算分布在多個broken實例中。當然為解決Kafka集群因系統部分組件失 效,導致數據丟失的問題，Kafka還提供了副本機制(replication)，每個partition 的多個副本同樣通過 Hash 計算分布在其他的 broken 實例中，當某臺服務器 broken 實例發生意外后，其他的 partition 副本則可以迅速替代其對外提供服務， 保證集群的高可用。
11
2.5MaxWell 數據同步工具
MaxWell 是由美國 zendesk 在 Github 開源的 MySQL 數據同步工具，可以實 時讀取 MySQL 的二進制 Binlog 日志文件，并將讀取的數據組裝 Json 格式寫入 Kafka、RabbitMQ、Redis等中間件，常應用于ETL、緩存構建、監控收集、搜索 索引和服務間通信等眾多場景中［24］。
MaxWell 數據同步原理如圖 2-4 所示，其工作原理主要基于 MySQL 的主從 復制過程：首先打開 master 端的 Binlog 記錄功能，當對 MySQL 數據庫進行數 據變更操作時， MySQL master 主庫會將變更內容記錄在二進制 Binlog 文件中， Slave 從庫則向 MySQL master 發送 dump 協議，將 master 主庫的 binary log events 拷貝到它的中繼日志 Relay log 中，然后 Slave 從庫讀取中繼日志中變更內容，解 析成 SQL 語句并按照順序執行操作，實現主從數據庫數據同步［25］。 MaxWell 則 是模擬此過程的交互協議，將自身偽裝成 MySQL 數據庫的 Slave 從庫，向 master 發送向 dump 請求， MaxWell 在收到 master 主庫推送的 Binlog 文件更新內容后 解析獲取數據，然后 MaxWell 可以通過配置對接 Kafka、 RabbitMQ、 Redis 等中 間件，將解析組裝好的數據信息發送到對應的服務，實現變更數據的收集。
12
與阿里巴巴開源的解析工具Canal相比，MaxWell只支持Json格式，支持斷 點還原（即異常中斷重啟后，繼續上次文件位置讀取），而且基于bootstrap功能 能夠直接導入完整歷史數據用于初始化，在項目實際使用過程中更加輕便可靠。
2.6HBase 數據庫
HBase 是一個參考了 Google 的 Big Table 建模利用 Java 語言實現的開源的 分布式非關系性數據庫。它是 Apache 軟件基金會 Hadoop 項目的一部分，使用 Hadoop 中的 HDFS 作為其文件數據存儲系統， Zookeeper 作為其協同服務，為 Hadoop提供類似于Big Table規模的服務［26］。相較于傳統的基于行存儲的關系型 數據庫， HBase 是面向列的方式進行存儲，其列是允許擴展的，適用于存儲半結 構化或非結構化海量的數據［27］，在數據結構和系統架構方面存在著較大的差異。
Column Fainily（列族） •…
Column Qualifier (列標識) Column Qualifier (列標識)
rowKey (行鍵) cell （單元格） cell （單元格 )
value(tsl) value(ts2) value(ts3) value(tsl) value(ts2) value(ts3)
圖 2-5 HBase 數據邏輯結構圖
HBase數據存儲邏輯結構圖如圖2-5所示。HBase面向列的數據模型設計主 要包括表（Table），行（Row），列族（Column Family），列標識（Column Qualifier）， 單元格（cell）和時間戳（Time Stamp）組成。表：對應關系型數據庫中表的概念；行： 在 HBase 中通過行來進行數據存儲，使用行鍵來進行唯一標識，作為查詢檢出的 主鍵；列族：在HBase中的數據是以列族的方式進行存儲的，列族是由多個自身 定義所包含的字段列組成，在對數據表進行構建中，列族是不能改變的，以此列 族需要預先進行定義；列標識：與列族包含的字段定義一一對應，相互映射關聯； 單元格：在 HBase 中通過列族、列標識和行鍵來標識定位一個單元格，單元格內 保存著用時間戳來區分版本的數據值［26］。
13
HBase 系統架構圖如圖 2-6 所示， HBase 的系統架構遵循一種主從的服務器 體系模式，主要由 Hmaster 服務和 HregionServer 集群服務兩個模塊構成。其中 Client 客戶端，提供了訪問 HBase 的接口，同時使用 HBase 的遠程調用機制與 Hmaster 服務和 HregionServer 集群服務進行交互，分別實現數據管理類操作和讀 寫類操作； Zookeeper 負責 HBase 集群分布式協調、同步和配置管理，實時監控 HregionServer 服務，確保系統的正常運行，實現高可用； HregionServer 主要負責 響應用戶讀寫請求，與數據存儲底層 HDFS 交互； Hregion 則是由 HBase 依靠主 鍵將數據表拆分出來的物理塊，每一個 Hregion 就是一個 HBase 數據存儲的物理 分區； Hmaster 是 HBase 的控制節點，主要負責 HBase 中數據表和邏輯表與 Hregion 之間的管理，處理 Hregion 的分配或轉移［28-29］。
2.7ClickHouse 數據庫
ClickHouse 是由俄羅斯的 Yandex 公司開發的一種面向聯機分析處理的數據 庫管理系統，同時也是一個新的列式數據庫。于 2016 年 6 月開源發布，主要用 于在線分析處理查詢，并支持 SQL 查詢實時生成分析數據報告。
14
與傳統關系型數據庫相比，ClickHouse有著其獨有的特性：首先在分析數據 讀取性能方面， ClickHouse 作為一種列存儲型數據庫，無需像行式數據庫那樣， 在數據讀取后進行有效的字段過濾，可以直接獲取數據分析所需的列數據，讀取 速度非常快；在數據存儲方面，ClickHouse又支持基于磁盤存儲、數據壓縮、分 布式服務和數據復制等特點，增強了其存儲性能和系統容錯能力；同時還支持數 據實時寫入和絕大多數的 SQL 語法，使其用起來更加方便快捷［30-31］。如此眾多 特性使其可以支持多樣復雜的數據存儲分析應用場景，如：監控系統、用戶行為 分析、 BI 報表和特征分析等。
2.8Flink 框架
隨著互聯網不斷的發展，多維數據量急劇暴漲，數據分析決策逐步融入到日 常生活中。人們對于數據的實時性要求也越來越高， Flink 就是在這種背景驅動 下產生的一個基于流式數據處理平臺。 Flink 源于柏林理工大學的一個研究型項 目， 2014 年被 Apache 孵化器所接受，并迅速地成為 ASF（ Apache Software Foundation） 的頂級項目之一［32］，并且在世界范圍內得到了廣泛的應用和發展。
Flink 是一個能夠同時實現流式和批式數據處理的分布式處理引擎。其主要 的設計理念認為，對實時產生的數據本應進行流式處理（實時數據在一個節點處 理完之后，立即送往下一個節點進行處理），才能更好的體現出數據的時效價值， 批處理（當前節將需要處理的所有數據進行處理之后，才會將數據傳送到下一個 節點）只是作為流處理的特例存在。 Flink 通過設置數據的超時時間，來分別應 對流處理和批處理系統，當超時時間為零則執行流處理操作，超時時間為無窮大 則執行批處理，同時也可以通過設置超時時間的長短，來調節數據處理延遲和吞 吐量之間的動態平衡［33-34］。
15
圖 2-7 Flink 組件架構圖
Flink 組件架構圖如圖 2-7 所示，其組件架構按照邏輯主要分為：部署層、 核心計算層、 API 層和特定應用領域庫［35］。特定應用領域庫主要提供了用于機器 學習的 FlinkML 組件庫、圖像處理的 Gelly 組件庫、事務處理的 CEP 組件庫和 結構化查詢 Table API&SQL 組件庫。其中的 FlinkML 組件庫提供了支持向量機、 多重線性回歸、最優化路徑和K-近鄰等機器學習算法［36］； API層主要分為流處 理DataStream API和批處理DataSet API。API層提供豐富的數據處理高級API， 例如：Map、Flat Map等操作，同時也提供比較低級的Process Function API，用 戶可以直接操作狀態和時間等底層數據;核心計算層提供Flink核心的Distributed Streaming Dataflow 引擎，主要為上層不同類型的接口提供基礎服務，該層也是 F1ink 分布式計算框架的核心實現層，支持分布式 Stream 作業的執行、 JobGraph 和 ExecutionGraph 的映射轉換、任務調度等。將 DataStream 和 DataSet 轉成統一 的可執行的Operator，達到在流式引擎下同時處理批量計算和流式計算的目的； 部署層則針對不同環境和平臺的需要為 Flink 提供了三種服務部署方式：本地部 署方式（支持本地JAVA虛擬機環境運行）、集群部署方式（Standalone模式或 YARN模式）和Cloud云端部署方式（GCE谷歌/EC2亞馬遜）［37］。
16
(Worker)
Checkpoint
Coordin ator
(Master / YARN Application Master)
圖 2-8 Flink 運行架構圖
如圖 2-8 所示， Flink 運行主要由 JobManager 和 TaskManager 倆類型的進程 組成。與大多數典型的分布式系統類型，Flink也遵循Master-Slave設計原則，其 中 JobManager 為 Master 節點， TaskManager 為 Slave 節點。
JobManager作為Flink集群的管理者，主要負責監控管理TaskManager節點， 當 Flink 集群啟動后， JobManager 根據設置的并行度， 啟動一個或者多個 TaskManager 節點。 TaskManager 將自身占據的 CPU 核數和內存大小返回給 JobManager 進行管理，并執行用戶程序。 JobManager 當檢測到某個 TaskManager 節點運行停止后，負責啟動新的節點，將對應的用戶程序進行轉移［38］。
TaskManager 作為 Flink 的執行者，負責具體任務的執行和對應任務節點資 源的申請和管理。 TaskManager 從 JobManager 接受需要部署的任務，然后使用 Task Slot資源啟動Task，建立數據接入的網路連接，接受數據并開始數據處理。 同時 TaskManager 之間通過數據流的方式進行數據交互。組件之間的所有通訊都 是借助Akka框架，包括任務的狀態以及Checkpoint觸發信息。JobClient主要負 責接收Flink Program項目工程的任務請求，通過Akka與JobManager建立連接，
17
并與 JobManager 進行交互，獲取任務執行狀態。
第三章 系統需求分析
需求分析是項目建設的開端，是項目質量控制的首要階段，也是決定項目實 施成功的關鍵性因素［39］。需求分析旨在通過整合業務邏輯結構和軟件工具特性， 將復雜繁瑣的業務需求轉換為可以用軟件代碼實現的功能模塊，為項目系統分析 和軟件設計搭建一個具有業務指導性，技術過渡性的橋梁，為軟件項目建設提供 有利的保障。
3.1系統需求概述
系統的需求分析主要分為功能性需求分析和非功能性需求分析。其中功能性 需求分析主要從系統的業務使用，系統管理角度進行分析，并構建用例模型，明 確整個系統需要實現的具體行為功能。非功能性需求主要從系統整體操作性和性 能等方面進行分析。
3.2系統功能性需求分析
3.2.1電商平臺功能
系統的電商平臺是電商數據的入口，也是電商數據的主要來源。用戶是系統 的主要使用者，該平臺的功能要滿足用戶購物的需要。
在用戶服務方面，系統首先要保證用戶能夠正常使用系統，需要為用戶提供 注冊和登錄功能，同時對用戶個人信息進行頁面展示，保證信息的準確性。
在商品服務方面，系統首先需要對展示的商品進行歸類劃分，展示商品整體 的分類情況，并能夠根據選擇類別展示商品列表信息，然后對具體某一商品提供 商品詳情信息展示，保證用戶能夠獲取商品的庫存信息，并能夠對商品進行加購 和下單操作。
在購物車服務方面，用戶能夠進行商品對比，通過簡單操作能夠完成加購商 品數量的調整，并且對不滿意的商品能夠進行刪除操作，同時提供給用戶下單支 付功能，提高用戶的購物體驗。
19電商平臺需實現的核心功能用例圖如圖 3-1 所示。
3.2.2實時數倉功能
系統的實時數倉功能，作為數據流轉處理的核心模塊。其主要功能是完成對 電商平臺的數據匯總收集和數據分解細化，并能夠根據主題功能進行數據主題匯 聚。其數據流程圖如圖 3-2 所示。
對收集數據進行
分解細化
了
對細化數據
按業務主題
逬行匯聚
圖 3-2 實時數倉數據流程圖
首先需要將電商平臺中用戶行為數據和業務數據進行精準收集。其中用戶行
為數據主要體現平臺系統的吸引力和訪問力度；業務數據則體現平臺商品的關注
20 度和購買力度，從真實的下單和交易流程中，體現出各類商品的銷售熱度。
然后將收集到的數據進行分解細化，分解細化主要是根據數據的業務特性進 行分流，將同類型的數據分解提取到相同的數據流中，實現同類數據的高度聚合， 這樣能夠更好的體現出特性價值，并且為之后數據按照主題匯聚標明了各自的業 務特性。
然后對細化數據按照業務主題進行匯聚，該過程主要是對分解細化后的數據 流進行主題特性歸類，使同一主題的數據能夠進行匯總計算。
最后將聚合后的數據進行實時存儲，為可視化平臺中的指標計算提供數據支 持。
3.2.3可視化平臺功能
系統的可視化平臺是電商數據的展示窗口，也是企業進行管理決策的重要依 據。可視化平臺主要對主題數據進行對應的指標計算，通過對各主題指標數值的 動態展示，來為企業管理人員的商業決策提供數據支持。可視化平臺需要對多個 主題指標數據進行展示，其各主題需要展示的指標數據
圖 3-3 可視化平臺主題指標圖
訪客主題展示的指標數據有PV頁面訪問數、UV日活訪客數、用戶跳出率、 平均訪問頁面數和平均在線時長等數值。通過展示該主題內的指標數據能夠清楚 的了解該平臺訪客數量和受關注程度。
商品主題展示的指標數據有商品總成交金額、品牌 top 排名、品類 top 排名 和熱門商品排名等數值。通過展示該主題內的指標數據能夠清楚的了解各階段用 戶對商品的關注趨勢，以便于企業及時調整備貨方案。
地區主題根據省市進行區域劃分，主要展示省市訂單金額和省市訂單排名等 數值。通過展示該主題內的指標數據能夠宏觀的觀察出各省市地區的消費力度， 以便于企業能夠及時調整各地區的物流存儲規模。
除了上述的主題指標數據外，還可以根據平臺擴展模塊和維度主題進行其他 主題指標統計。
3.3系統非功能性需求分析
3.3.1性能分析
本系統需要收集大量的實時數據，并且對收集到的數據進行低延遲的計算處 理，這樣才能夠體現數據的實時價值，為決策人員的業務決策提供數據支持，所 以在系統搭建過程中需要充分考慮到數據收集的吞吐性和數據處理的延遲性，確 保系統在運行峰值階段能夠實現高吞吐和低延遲，確保不會降低數據的實時價值。
3.3.2擴展性分析
本系統中的實時數倉雖然是在實現電商核心業務功能基礎上搭建的，但是該 實時數倉不能僅滿足現有的業務功能和業務系統。隨著電商平臺后期業務擴展和 其他新業務系統的出現，該實時數倉要能夠處理擴展的業務需求和兼容新的業務 系統。所以該實時數倉在搭建之初就要考慮到整體的兼容性和可擴展性。同樣在 數倉基礎上搭建的可視化平臺也要能夠滿足對不同業務功能和業務系統的擴展 性。
3.3.3可靠性分析
本系統主要通過收集電商平臺數據來進行統計計算，將統計計算的結果進行 可視化平臺展示，供給企業決策人員進行業務決策。所以確保數據可靠收集和備 份存儲非常重要，這將直接影響可視化平臺展示信息的正確性。所以在搭建實時 數倉時，要充分保證系統運行的可靠性，即使在發生服務器宕機時，也要確保搜 集數據的持續性和可恢復性。
高校學術論文網提供專業的碩士畢業論文寫作、畢業論文輔導寫作、博士論文寫作發表、碩士論文寫作發表、SCI論文寫作發表、職稱論文寫作發表、英文論文潤色的服務網站，多年來,憑借優秀的服務和聲譽贏得了社會的廣泛認可和好評，為畢業生解決寫論文的煩惱
上一篇：高校學術論文網提供專業的碩士畢業論文寫作、畢業論文輔導寫作、博士論文寫作發表、碩士論文寫作發表、SCI論文寫作發表、職稱論文寫作發表、英文論文潤色的服務網站，多年來,憑借優秀
相關標簽:
