[9]，項目中主要用于管理Kafka。除此之外還可提供統(tǒng)一配置管理、域名集中訪問、分布式鎖和集群管理等服務(wù)。其系統(tǒng)結(jié)構(gòu)如圖2-4所示：圖2-3SpringMVC核心架構(gòu)圖2-4zookeeper系統(tǒng)結(jié)構(gòu)圖2.7Echarts一種純使用Javascript開發(fā)的圖表庫，對市面上絕大部分移動設(shè)備和PC都有很好的兼容性，用戶可以根據(jù)項目的需求去定制適合相關(guān)功能的可視化圖表，也可以編寫控制觸發(fā)函數(shù)，具有良好的用戶友好性。在提供了數(shù)據(jù)源的情況下，可以讓用戶更加直觀的感受到數(shù)據(jù)的變化。項目中主要使用了Echarts的柱狀圖并配置dataZoom，實現(xiàn)了圖表數(shù)據(jù)區(qū)的縮放功能。2.8電商平臺數(shù)據(jù)分析的重要概念介紹用戶/訪客：表示同一瀏覽器代表的用戶，一般指的是未登錄網(wǎng)站的用戶，唯一標(biāo)識用戶。會員：指的是一個網(wǎng)站的正常會員的所有用戶，一般指的是登錄成功的用戶。會話：一段時間內(nèi)的連續(xù)操作，就是一個會話中的所有操作，在客戶端創(chuàng)建，保存在Cookie中。PV：頁面瀏覽量或點擊量平均在線時間：平均訪問時間通常是指用戶在一定的統(tǒng)計時間內(nèi)花在瀏覽頁面或整個網(wǎng)站上的總時間的百分比，以及他們訪問該頁面或整個網(wǎng)站的次數(shù)。其計算公式為花費的總時間/總訪問次數(shù)=平均訪問時間。UV(uniquevisitor)：唯一身份訪問者代表您網(wǎng)站或單擊鏈接的不同訪問者的數(shù)量。同一用戶多次訪問一個網(wǎng)站或網(wǎng)頁會產(chǎn)生UV。從點擊網(wǎng)站到關(guān)閉網(wǎng)站的所有頁面計算為一次訪問。如果訪問者連續(xù)30分鐘未打開或刷新頁面，并且關(guān)閉瀏覽器，則視為訪問已結(jié)束。VV：查看訪問次數(shù)（訪問次數(shù)）：訪問者訪問用于記錄所有訪問者每天訪問網(wǎng)站的次數(shù)。當(dāng)訪問者完成瀏覽并關(guān)閉網(wǎng)站上的所有相關(guān)頁面時，訪問完成。同一位訪客一天可以有多次訪問，并且該數(shù)值是累積的。BounceRate跳出率：跳出率用于指示訪問者進(jìn)入網(wǎng)站后是否對網(wǎng)站內(nèi)容感興趣。當(dāng)用戶進(jìn)入網(wǎng)站上的頁面然后離開而沒有單擊網(wǎng)站上的另一頁面時，這稱為跳出率。這些指標(biāo)通常是針對特定網(wǎng)站的。SKU：庫存保有單位即庫存進(jìn)出計量的單位。SPU：商品信息聚合的最小單位。

3系統(tǒng)的需求分析3.1日志數(shù)據(jù)的獲取對于最終的不同分析模塊，需要不同的日志數(shù)據(jù)，并且需要分析每個模塊的日志數(shù)據(jù)。基本用戶信息是對用戶瀏覽行為信息的分析。瀏覽器信息分析和區(qū)域信息分析實際上是通過分析基本用戶信息并添加瀏覽器和區(qū)域的尺寸信息來執(zhí)行的。瀏覽器的window.navigator.userAgentnginx服務(wù)器可以收集本地信息，并將當(dāng)前URL和上一頁的URL添加到頁面查看事件中以進(jìn)行處理和分析。也就是說，頁面瀏覽事件可以滿足對這兩個模塊的分析。對于訂單信息分析，PC必須發(fā)送訂單生成的事件。要分析此模塊，您還需要一臺PC發(fā)送可定義為事件的新事件數(shù)據(jù)。您還需要設(shè)置一個開始事件來記錄新用戶的訪問。3.2用戶基本信息數(shù)據(jù)分析模塊用戶基本信息分析模塊從兩個主要角度分析和探索相關(guān)信息：用戶/訪問者和成員，例如新用戶，活動用戶，總用戶和新成員。正式成員，普通成員和會話分析等。以下是對各種用戶信息視角的分析，如圖3-1所示，用于主要功能分析的用例圖：圖3-1用戶基本信息分析3.3熱門商品的實時統(tǒng)計需求我們將實現(xiàn)一個“實時熱門商品”的需求，可以將“實時熱門商品”通常理解為：每隔5分鐘輸出最近一小時內(nèi)點擊最多的商品。這個需求我們可以大概分解成以下幾個步驟：首先，我們需要獲取業(yè)務(wù)時間戳。告訴FLINK框架給予業(yè)務(wù)時間做窗口。其次：過濾出平臺用戶點擊行為的數(shù)據(jù)，這個我們通常是在頁面進(jìn)行埋點來獲得的。第三：我們可以按準(zhǔn)確一小時為窗口大小，每隔五分鐘統(tǒng)計一次，做滑動窗口聚合。最后，我們按照每個時間窗口聚合，輸出每個窗口中點擊量靠前N名的商品。對于網(wǎng)站的每日點擊次數(shù)最多的商品，需要將其通過日志分析統(tǒng)計出來，為前端電商網(wǎng)站的熱門商品推薦模塊提供數(shù)據(jù)支持。3.4網(wǎng)站總瀏量的統(tǒng)計需求流量統(tǒng)計概念：是利用比較科學(xué)的計算方式，準(zhǔn)確的記錄來訪某一頁的訪客信息。通俗來說就是我們獲取一些我們需要的用戶信息，然后再進(jìn)行想要的統(tǒng)計分析的行為。網(wǎng)站流量統(tǒng)計是一種我們能夠準(zhǔn)確的、全面的分析訪問用戶的來源，方便網(wǎng)站管理人員能夠根據(jù)不同訪客的增加或減少修改網(wǎng)站的相關(guān)內(nèi)容，便于更好的提升網(wǎng)站的轉(zhuǎn)化率。提高網(wǎng)站的流量，例如：用戶喜歡瀏覽什么，我們就增加什么內(nèi)容，用戶幾乎沒有瀏覽過的，我們可以適當(dāng)?shù)臏p少這類內(nèi)容。我們?yōu)槭裁匆髁拷y(tǒng)計，從以下一個方面說明：第一：及時掌握用戶的需求，我們可以實時掌握網(wǎng)站的推廣效果，減少盲目性。第二：我們可以分析各種網(wǎng)絡(luò)營銷手段所取得的效果，能夠為制定和修正網(wǎng)絡(luò)營銷策略提供有力的依據(jù)。第三：通過對網(wǎng)站總流量的統(tǒng)計需求，我們可以分析網(wǎng)絡(luò)營銷的診斷，包括網(wǎng)站優(yōu)化狀況的診斷情況等等。通過對網(wǎng)站總瀏覽量的日志分析，可以得出當(dāng)前電商平臺的運營狀態(tài)，方便運營商和管理員針對不同的情況進(jìn)行項目策略的調(diào)整和規(guī)劃。部分指標(biāo)如圖3-2所示：圖3-2流量統(tǒng)計分析3.5市場營銷商業(yè)指標(biāo)統(tǒng)計分析需求伴隨這智能手機(jī)的用戶數(shù)日益增多，在如今的電商網(wǎng)站中越來越多的用戶來自于移動端，相對于通過傳統(tǒng)瀏覽器訪問的方式，手機(jī)APP成為了更多用戶訪問電商網(wǎng)站的首選。對于電子商務(wù)公司，他們通常通過各種渠道和來自這些渠道的統(tǒng)計信息來營銷其應(yīng)用程序（例如，其他網(wǎng)站上廣告鏈接的點擊次數(shù)，應(yīng)用程序下載次數(shù)）成為營銷的重要業(yè)務(wù)指標(biāo)。如圖3-3：圖3-3市場營銷統(tǒng)計3.6頁面廣告點擊量統(tǒng)計需求對每個用戶在瀏覽網(wǎng)站時候，通過日志的大數(shù)據(jù)分析，推送更多用戶喜好的同類型產(chǎn)品，有助于幫助用戶選擇，增加用戶對網(wǎng)站的好感度，并通過判斷用戶的頁面每個網(wǎng)站的點擊量，分析用戶更喜歡哪種類型的廣告，對商城的網(wǎng)站投放，商品推薦有更多的業(yè)務(wù)需求。用戶統(tǒng)計對我們網(wǎng)站的優(yōu)化有很大的作用，比如說我們在頁面中進(jìn)行埋點，統(tǒng)計用戶在當(dāng)前網(wǎng)站中停留了多長時間，點擊了哪些按鈕，或者是瀏覽了哪些數(shù)據(jù)，對于我們分析用戶行為有很大的幫助。比如說我們常用的神策數(shù)據(jù)埋點，它提供了從數(shù)據(jù)采集、建模、存儲、分析到只能應(yīng)用的全數(shù)據(jù)驅(qū)動解決方案，幫助我們驅(qū)動業(yè)務(wù)決策和產(chǎn)品智能化的優(yōu)化。3.7惡意登錄監(jiān)控需求惡意登錄網(wǎng)站：是指用戶短時間多次登錄網(wǎng)站，并且登錄失敗的情況，存在網(wǎng)站被人惡意攻擊可能，比熱ddos攻擊，如果是ddos攻擊則危害極大，這個攻擊的原理就是像我們的網(wǎng)站發(fā)送大量的數(shù)據(jù)包，占用大量的帶寬，損失極大。如果惡意攻擊，進(jìn)行程序報警。對于網(wǎng)站而言，用戶登錄并不是頻繁的業(yè)務(wù)操作。如果一個用戶短時間內(nèi)頻繁登錄失敗，就有可能是出現(xiàn)了程序的惡意攻擊，比如密碼暴力破解。因此我們考慮，應(yīng)該對用戶的登錄失敗動作進(jìn)行統(tǒng)計，具體來說，如果同一用戶（可以是不同IP）在2秒之內(nèi)連續(xù)兩次登錄失敗，就認(rèn)為存在惡意登錄的風(fēng)險，輸出相關(guān)的信息進(jìn)行報警提示。這是電商網(wǎng)站、也是幾乎所有網(wǎng)站風(fēng)控的基本一環(huán)。解決思路后端一般有兩個方案：第一種：對于同一個用戶（在我們的數(shù)據(jù)庫存在的數(shù)據(jù)）登錄狀態(tài)進(jìn)行常規(guī)統(tǒng)計，如果監(jiān)控在短時間內(nèi)進(jìn)行3次登錄失敗的情況下進(jìn)行報警。第二種是CEP方案：通過CEP定義“危險pattern”，實現(xiàn)數(shù)據(jù)的過濾檢出。前端解決方案是：在登錄頁面添加圖形驗證碼，如果圖形驗證碼驗證不通過，則不會請求后端接口，這樣大大減少了用戶頻繁的請求數(shù)據(jù)，對于攻擊也減少了，這種在前端應(yīng)用普遍。3.8訂單支付的實時監(jiān)控在電子商務(wù)網(wǎng)站上，訂單付款與營銷收入直接相關(guān)，在業(yè)務(wù)流程中非常重要。對于訂單，要適當(dāng)?shù)乜刂茦I(yè)務(wù)流程并增加用戶付款的意愿，網(wǎng)站一般會設(shè)置一個支付失效時間REF_Ref53552910\r\h[12]，超過一段時間不支付的訂單就會被取消。另外，對于訂單的支付，我們還應(yīng)該保證用戶支付100%的真確性，盡量不能出現(xiàn)支付錯誤的情況。訂單的實時監(jiān)控特別重要，在我們的電商平臺上，給我們最終創(chuàng)造收入和利潤的就是我們的用戶下單購買的重要環(huán)節(jié)，更直白來說，就是用戶在最終點擊支付并付款成功的時候，這是我們最重要的環(huán)節(jié)。用戶下定點的行為可以表明我們的用戶對商品的購買需求，但在現(xiàn)實中并不是用戶下訂單后立即支付，可能會延遲支付，或者用戶不進(jìn)行支付操作，所以我們?yōu)榱俗層脩粲蟹N緊迫感而把支付操作控制在15分鐘內(nèi)，在15分鐘內(nèi)給用戶進(jìn)行提醒，提高支付轉(zhuǎn)化率，同時也為了防范在用戶訂單支付的重要環(huán)節(jié)的安全風(fēng)險，電商網(wǎng)站通常會對用戶的訂單狀況進(jìn)行監(jiān)控，如果15分鐘未進(jìn)行最終支付，訂單就會被系統(tǒng)取消。4分析系統(tǒng)的設(shè)計與實現(xiàn)4.1系統(tǒng)數(shù)據(jù)表結(jié)構(gòu)的設(shè)計4.1.1源數(shù)據(jù)表的設(shè)計日志源表的實際，我最主要的是抓住最重要的一條，就是數(shù)據(jù)日志從產(chǎn)生到到達(dá)最終目標(biāo)期間的處理流程。一般來說，我們設(shè)計一個靈活可硬并且可擴(kuò)展的數(shù)，靈活配置的日志源庫，我們可以將日志源庫系統(tǒng)的劃分為四個大的部分，分別是：記錄器、過濾器、格式化器等四大部分其中概念分別是：記錄器：主要負(fù)責(zé)我們操作產(chǎn)生的日志數(shù)據(jù)的原始信息，例如：原始數(shù)據(jù)、過濾器、格式化器、記錄位置等信息。這些事情是我們考慮的一大重點，必須深思梳理后設(shè)計。過濾器：主要負(fù)責(zé)過濾我們不需要的日志信息，比如說重復(fù)的信息，用戶年齡等信息。格式化器：我們處理日志通常是需要要求按照我們的需求來獲得我們的相應(yīng)格式的信息，比如按照日期或點擊數(shù)量來分類，有格式化器來很好的找到我們需要的信息分類。輸出器：輸出器主要負(fù)責(zé)將我們進(jìn)行中的日志（一般經(jīng)過過濾器及格式化器精心處理過的數(shù)據(jù)）記錄到我們的最終需要的日志目的地（例如：輸出到我們需要的相應(yīng)文件中）通過將日志源庫系統(tǒng)的分為四個抽象的器皿，使它成為一個較為靈活并且可隨意擴(kuò)展的日志庫。比如你想實現(xiàn)從輸出到我們想要的文件和輸出到我們想要的TCP中這兩個功能，我們只需要分別實現(xiàn)這兩個輸出器的實例就可以得到我們想要的數(shù)據(jù)。另外我想說明一下一條日志的生命周期，對于我們設(shè)計數(shù)據(jù)庫也有很大的幫助，步驟如下：產(chǎn)生，經(jīng)過記錄器。記錄器需要獲取操作日志發(fā)生的時間，位置，線程信息等等信息，會有一個數(shù)據(jù)結(jié)構(gòu)去存儲你需要的信息，例如登錄需要獲得用戶的登錄名，用戶位置等等信息。經(jīng)過過濾器。過濾器存在大大方便了我們存儲數(shù)據(jù)的可用性，決定了是否過濾一些我們不需要的信息。經(jīng)過格式化器。格式化信息方便了我們過濾我們需要的信息，只要滿足條件，就繼續(xù)。到輸出器，例如輸出到用戶信息的文件中，我們只需要把信息寫到文件中就可以了。假如我們還實現(xiàn)了日志回滾的功能的話，我們在日志寫入文件后，還需要進(jìn)一步的判斷是否要觸發(fā)日志回滾的操作，如果滿足了回滾條件，則進(jìn)一步進(jìn)行日志回滾操作。下面是我日志源庫的設(shè)計：日志源表主要存儲用戶配置的日志信息，例如日志類型和日志路徑名。日志源路徑必須與日志收集模塊中的客戶相同。最終代理配置的日志路徑是相同的。當(dāng)Flink處理日志數(shù)據(jù)時，它會在數(shù)據(jù)庫中查詢?nèi)罩镜脑绰窂?。如果找到由Flink處理的日志源，但未進(jìn)行配置，則意味著Flink可以丟棄日志數(shù)據(jù)而不進(jìn)行處理。只有用戶設(shè)置的日志源才能進(jìn)入Flink實時分析模塊并參與計算，從而減少了不必要的資源占用。表3-1中顯示了日志源表結(jié)構(gòu)的關(guān)鍵列的設(shè)計（僅列出了關(guān)鍵列，但未列出全部）。4.1.2異常表設(shè)計異常表主要存儲用戶感興趣的日志異常信息(例如：用戶頻繁登錄網(wǎng)站等異常數(shù)據(jù))。用戶可能需要從前一天開始計算特定異常的趨勢圖。Flink實時計算異常數(shù)量。實時生成匯總數(shù)據(jù)并將其寫入MySQL時，用戶可以觀察一段時間內(nèi)異常的數(shù)量或頻率，并了解產(chǎn)品的穩(wěn)定性。例如，如果用戶未設(shè)置例外并出現(xiàn)在日志文件中，則日志文件由日志收集模塊收集并發(fā)送到Flink分析模塊。如果Flink模塊的檢查異常表中沒有配置異常，則Flink會將這種類型的日志標(biāo)記為未知異常。因此，如果用戶對某些異常日志感興趣，則應(yīng)在此表中對其進(jìn)行配置。表3-2中顯示了例外表中關(guān)鍵列的設(shè)計（僅列出了關(guān)鍵列，而不是全部列出）。表3-1日志源表設(shè)計中文名日志源表英文名logsource字段數(shù)據(jù)類型說明其他logsourceidint日志源idautoincrementlogsourcenamevarchar(100)日志名稱唯一hostnamevarchar(lOO)服務(wù)器域名聯(lián)合索引pathvarchar(255)路徑名聯(lián)合索引filepattemvarchar(255)文件名正則表達(dá)式聯(lián)合索引linestartregexvarchar(255)日志起始標(biāo)志linefilterkeywordvarchar(255)異常日志過濾關(guān)鍵字多個使用逗號分隔linetyperegexvarchar(255)異常類型匹配表達(dá)式多個使用逗號分隔statustinyint0：未監(jiān)控1：監(jiān)控中2：狀態(tài)異常3：已刪除4.1.3異常數(shù)據(jù)表設(shè)計異常數(shù)據(jù)表主要用于在用戶設(shè)置的采樣時間內(nèi)存儲用戶為特定日志源設(shè)置的特定異常號。例如，如果用戶配置日志源a，在例外表中指定相關(guān)的例外B，并且Flink的總采樣時間為30秒，則Flink計算模塊將在30秒內(nèi)計算來自日志源a的例外B的數(shù)量，并保存。結(jié)果對數(shù)據(jù)庫執(zhí)行此操作。表3-3顯示了異常數(shù)據(jù)表中關(guān)鍵字列的設(shè)計（僅列出了關(guān)鍵字列，而不是所有列）。4.1.4Nginx_access表設(shè)計Nginx.access訪問日志主要是系統(tǒng)對用戶訪問的響應(yīng)的某些特定指示。通過統(tǒng)計一定時間內(nèi)的響應(yīng)指標(biāo)值，可以創(chuàng)建趨勢圖來了解系統(tǒng)的響應(yīng)。Nginx_access日志包含特定于用戶的操作和系統(tǒng)響應(yīng)指示符，例如用戶單擊的URL，系統(tǒng)響應(yīng)時間，系統(tǒng)響應(yīng)狀態(tài)，用戶請求類型等。對此日志的摘要分析可以幫助您理解兩個方面。一個是系統(tǒng)級別，一個是系統(tǒng)級別，即系統(tǒng)在一表3-2異常表設(shè)計中文名異常表英文名exception字段數(shù)據(jù)類型說明其他exceptionidint異常idautoincrementlogsourceidint日志源id索引exceptiontypemd5varchar(100)異常類型的MD5索引exceptiontypetext(1000)異常類型exception_demotext(2000)出現(xiàn)該異常的一條完整日志實例表3-3異常數(shù)據(jù)表結(jié)構(gòu)設(shè)計中文名異常數(shù)據(jù)表英文名exceptiondata字段數(shù)據(jù)類型說明其他exceptiondataidbigint異常數(shù)據(jù)idautoincrementlogsourceidint日志源id索引sampletimeint釆樣時間戳，精度秒索引exceptionidint異常id索引exceptioncountint異常數(shù)量定時間內(nèi)是否響應(yīng)良好，錯誤的頻率，用戶TPS和其他數(shù)據(jù)，另一個是用戶級別。深度數(shù)據(jù)挖掘可以發(fā)現(xiàn)與用戶相關(guān)的行為習(xí)慣，例如用戶點擊次數(shù)最多的URL，并向用戶提供個性化建議。表3-4Nginxaccess表設(shè)計中文名Nginxaccess表英文名nginxaccess字段數(shù)據(jù)類型說明其他nidintNginxidautoincrementlogsourceidint日志源id聯(lián)合索引starttimetimestamp聚合開始時間聯(lián)合索引urlvarchar(255)url聯(lián)合索引totalcountintuid點擊的次數(shù)requesttimetotalint請求時間的總和requesttimemaxint最大的請求時間upstreamresponsetimetotalint響應(yīng)時間總和upstreamresponsetimemaxint最大的響應(yīng)時間okcountint非4**和5**狀態(tài)的總和error4countint狀態(tài)是4開頭的總和

5.系統(tǒng)總體架構(gòu)如圖5-1所示，整個系統(tǒng)架構(gòu)分為數(shù)據(jù)收集模塊，數(shù)據(jù)緩存模塊，數(shù)據(jù)清理，分析模塊，數(shù)據(jù)處理模塊和數(shù)據(jù)顯示模塊。數(shù)據(jù)采集模塊是單獨使用的。數(shù)據(jù)采集模塊分別使用JS-SDK和JAVA-SDK分別在前端的JS代碼中和后臺的JAVA代碼中設(shè)置埋點，當(dāng)用戶在網(wǎng)站上發(fā)送瀏覽行為時候，通過Nginx服務(wù)器，實時的將日志信息傳輸至數(shù)據(jù)分析服務(wù)器上，并存儲于本地的log文件中。然后使用Flume，將Flume的數(shù)據(jù)通過sink傳輸至kafka。使用Flink框架對Kafka寫入的磁盤數(shù)據(jù)進(jìn)行實時的云計算，并將統(tǒng)計分析得到的結(jié)果直接傳輸?shù)組YSQL數(shù)據(jù)中，通過前端的Echart等可視化模板進(jìn)行可視化的數(shù)據(jù)展示工作。圖5-1系統(tǒng)總體架構(gòu)圖5.1數(shù)據(jù)收集模塊實現(xiàn)我們在前端的JS代碼編寫中按照收集數(shù)據(jù)的不同分為不同的事件，設(shè)置pageview事件，Launch事件，chargeRequest事件。JS前端埋點的執(zhí)行流程如圖5-2：圖5-2通過各種事件從PC端發(fā)送的數(shù)據(jù)URL的格式如表5-1所示。URL后面的參數(shù)是我們收集的數(shù)據(jù)。表5-1最終分析模塊PC端jssdk事件用戶基本信息分析pageview事件瀏覽器信息分析地域信息分析外鏈數(shù)據(jù)分析用戶瀏覽深度分析訂單信息分析chargeRequest事件事件分析event事件launch事件啟動事件：當(dāng)用戶首次訪問網(wǎng)站時觸發(fā)此事件。它僅實現(xiàn)事件數(shù)據(jù)收集，而沒有提供用于外部調(diào)用的接口。頁面導(dǎo)航事件：當(dāng)用戶訪問頁面或刷新頁面時觸發(fā)此事件。程序員可以自動或手動調(diào)用此事件。chargeRequest事件：當(dāng)用戶下訂單時觸發(fā)此事件，應(yīng)從您的程序中調(diào)用該事件。事件：如果訪問者/用戶觸發(fā)了業(yè)務(wù)定義的事件，前端程序?qū)⒄{(diào)用此方法表中顯示了項目中使用的參數(shù)。表5-2參數(shù)名稱類型描述enstring事件名稱,eg:e_pvverstring版本號,eg:0.0.1plstring平臺,eg:websitesdkstringSdk類型,eg:jsb_rststring瀏覽器分辨率，eg:1800*678b_ievstring瀏覽器信息useragentu_udstring用戶/訪客唯一標(biāo)識符lstring客戶端語言u_midstring會員id，和業(yè)務(wù)系統(tǒng)一致u_sdstring會話idc_timestring客戶端時間p_urlstring當(dāng)前頁面的urlp_refstring上一個頁面的urlttstring當(dāng)前頁面的標(biāo)題castringEvent事件的Category名稱acstringEvent事件的action名稱kv_*stringEvent事件的自定義屬性dustringEvent事件的持續(xù)時間oidstring訂單idonstring訂單名稱cuastring支付金額cutstring支付貨幣類型ptstring支付方式Java后臺埋點執(zhí)行工作流；有些日志數(shù)據(jù)在前端不方便獲取，我們可以在后臺使用JAVA進(jìn)行日志的獲取，比如用戶的支付流程。圖5-3如圖5-3，本項目中在程序后臺會出發(fā)chargeSuccess事件，此事件的主要功能是將有關(guān)訂單成功的信息發(fā)送到nginx服務(wù)器。傳輸格式與PC端的傳輸方法相同，并且訪問相同的URL進(jìn)行數(shù)據(jù)傳輸。chargeSuccess事件：當(dāng)成員最終成功付款時將觸發(fā)此事件，應(yīng)從程序中調(diào)用該事件。chargeRefund事件：當(dāng)成員執(zhí)行退款操作且程序應(yīng)調(diào)用此事件時，將觸發(fā)此事件。最終將所有的日志數(shù)據(jù)實時的傳遞到云計算服務(wù)器的log日志中。5.2日志數(shù)據(jù)傳輸模塊的設(shè)計與實現(xiàn)首先需要啟動Zookeeper，默認(rèn)監(jiān)聽2181端口，然后啟動Kafka，默認(rèn)監(jiān)聽9092端口，為了接受Flume才寄過來的用戶行為日志信息，需要使用Kafka根據(jù)不同的項目創(chuàng)建主題。本系統(tǒng)分別創(chuàng)建auditLog主題，用于接收FlinkStreaming處理之后回傳給Kafka的總訪問量。后期的可視化模塊可直接對此Topic進(jìn)行數(shù)據(jù)獲取消費，結(jié)合頁面標(biāo)簽進(jìn)行實時訪問量的展示，region主題，用于接收linkStreaming處理之后回傳給Kafka的各省份總訂單量。后期的可視化模塊可直接對此Topic進(jìn)行數(shù)據(jù)獲取消費，結(jié)合Echarts進(jìn)行各地區(qū)實時購買量的展示。behavior主題，用于接收FlinkStreaming處理之后回傳給Kafka的用戶各類操作行為次數(shù)。后期的可視化模塊可直接對此Topic進(jìn)行數(shù)據(jù)獲取消費，結(jié)合Echarts進(jìn)行用戶行為操作實時統(tǒng)計的展示。編寫kafkaSink.flm連接配置文件，用于配置Flume作為Kafka的數(shù)據(jù)源，放于桌面。在文件中主要是定義了source、channel和sink，定義服務(wù)名a1，source定義類型為avro，端口號為4141；channel定義數(shù)據(jù)緩存類型為內(nèi)存，提升數(shù)據(jù)傳輸速度；sink類型定義為KafkaSink，配置好broker的信息和目標(biāo)topic。KafkaSink的配置文件如下所示。#定義一個服務(wù)名稱為a1，source，channel，sink分別為r1,c1,k1a1.sources=r1a1.channels=c1a1.sinks=k1#定義source，數(shù)據(jù)格式為avro，監(jiān)聽端口號為本機(jī)的4141端口a1.sources.r1.type=avroa1.sources.r1.bind=0.0.0.0a1.sources.r1.port=4141#定義channel，類型為內(nèi)存a1.channels.c1.type=memory#定義sink，k1的輸出類型為Kafka#此處僅為Kafka1.0.0版本配置內(nèi)容，新版kafka配置內(nèi)容有所修改a1.sinks.k1.type=org.apache.flume.sink.kafka.KafkaSinka1.sinks.k1.brokerList=localhost:9092a1.sinks.k1.topic=auditLoga1.sources.r1.channels=c1a1.sinks.k1.channel=c1使用編寫好的kafkaSink.flm文件啟動Flume，命令中的服務(wù)名為a1，需要與flm文件中一致。創(chuàng)建kakfaConsumer消費auditLog中的數(shù)據(jù)，用于判斷Flume與Kafka之間是否連通。創(chuàng)建好Kakfa的控制臺消費者之后，會出現(xiàn)如下圖所示的命令窗口顯示，等待數(shù)據(jù)進(jìn)入auditLog主題進(jìn)行消費。啟動Flume向avor-client發(fā)送采集數(shù)據(jù)，采集目標(biāo)文件為用戶行為日志源文件。啟動成功后，會通過內(nèi)置的傳輸端口進(jìn)行數(shù)據(jù)采集推送，如下圖所示。最終輸出結(jié)果如圖5-4所示圖5-4Kafka處理結(jié)果展示5.3數(shù)據(jù)處理模塊實現(xiàn)由于項目中的數(shù)據(jù)來源為Kafka，需要對獲取的數(shù)據(jù)進(jìn)行序列化。序列化方式是通過配置FlinkConf對象來實現(xiàn)的，而Flink在啟動時已經(jīng)默認(rèn)創(chuàng)建好sc對象，所以無法通過傳遞FlinkConf對象構(gòu)建sc對象。因此需要修改Flink文件夾中conf目錄下的flink-defaults.conf文件，配置啟動時默認(rèn)使用的序列化方式。因為conf目錄下只有flink-defaults.conf.template文件，所以需要復(fù)制模板文件再進(jìn)行修改。Flink中創(chuàng)建StreamingContext對象成功后，代碼塊下面會顯示相關(guān)信息，包括StreamingContext對象信息，連接的Kafka主題信息，Kafka中各個參數(shù)的詳細(xì)信息，創(chuàng)建Kafka數(shù)據(jù)源的Dstream。目前，創(chuàng)建連接Kafka數(shù)據(jù)源的Dstream有兩種方式，分別為createDstream和createDirectDstream，一般來說第二種常用于開發(fā)中，兩者的區(qū)別在各類文章中都有提及，學(xué)員們可自行學(xué)習(xí)。由于此項目中FlinkStreaming與Kafka的集成使用了0.10版本，而在0.8之后的版本，第一種創(chuàng)建Dstream的方式已經(jīng)被棄用了，所以只能使用第二種direct創(chuàng)建模式。數(shù)據(jù)預(yù)處理，需要先將數(shù)據(jù)流進(jìn)行簡單的map，將流中對象的值都取出。之后需要將原數(shù)據(jù)中某些字段進(jìn)行判斷賦值，以便于后期數(shù)據(jù)處理，如性別和年齡段字段，需要提前去除空值，以防出現(xiàn)異常。同時將得到的數(shù)據(jù)都封裝為一個個的用戶日志信息類的對象，形成一個個有機(jī)的整體，方便取值。啟動完成的FlinkStreaming程序，每隔3秒從Kafka的auditLog主題中獲取一遍數(shù)據(jù)進(jìn)行消費，并實時刷新打印在命令窗口中。獲取的數(shù)據(jù)都以UserBehavior對象的形式進(jìn)行打印。打印結(jié)果如圖5-5所示圖5-5數(shù)據(jù)輸出結(jié)果5.4前端的數(shù)據(jù)展示模塊實現(xiàn)前端數(shù)據(jù)展示的主要內(nèi)容為，加載主頁中的js文件時，創(chuàng)建Socket對象并向后臺發(fā)送請求，后臺接受到請求后，通過視圖函數(shù)調(diào)用回調(diào)函數(shù)，再通過回調(diào)函數(shù)中的請求將從Kafka中獲取到的數(shù)據(jù)發(fā)送到前端，然后使用echarts模板進(jìn)行前端的數(shù)據(jù)展示。在項目靜態(tài)資源/home/shiyanlou/Desktop/FlaskProject/static/js目錄下創(chuàng)建data_load.js文件。創(chuàng)建socket對象并初始化連接。連接中向后臺發(fā)送三個請求，分別是訪問量，用戶行為操作和地區(qū)購買力排行。在Flask中根據(jù)JavaScript中的請求編寫對應(yīng)的視圖函數(shù)，視圖函數(shù)中使用SocketIO的start_background_task函數(shù)新建一個線程，利用多線程處理業(yè)務(wù)。這樣便可以解決上個實驗中只有一個線程在打印的問題。在Flask中根據(jù)視圖函數(shù)中的需求編寫各功能的回調(diào)函數(shù)，對從各主題中獲取的數(shù)據(jù)進(jìn)行utf8編碼之后，將數(shù)據(jù)通過對應(yīng)的action發(fā)送到前端。主要分為總訪問量，地區(qū)購買排行和用戶行為三種回調(diào)函數(shù)。在JavaScript中根據(jù)Flask回調(diào)函數(shù)發(fā)來的請求進(jìn)行實現(xiàn)，將發(fā)送來的數(shù)據(jù)進(jìn)行處理，用于賦值給對象，變量或者頁面標(biāo)簽。以下JS代碼內(nèi)容都寫入data_load.js文件中。實現(xiàn)后臺總訪問量回調(diào)函數(shù)請求，將發(fā)送來的數(shù)據(jù)提取賦值給頁面標(biāo)簽。為了實現(xiàn)后臺用戶行為回調(diào)函數(shù)請求，創(chuàng)建用戶行為的json，將發(fā)送來的數(shù)據(jù)先分割賦值給對應(yīng)的變量，再將變量不斷刷新賦值給用戶行為json中的屬性，最終將對象數(shù)據(jù)賦值給頁面標(biāo)簽。實現(xiàn)后臺用戶行為回調(diào)函數(shù)請求，創(chuàng)建用戶行為的json，將發(fā)送來的數(shù)據(jù)先分割賦值給對應(yīng)的變量，再將變量不斷刷新賦值給用戶行為json中的屬性，最終將對象數(shù)據(jù)賦值給頁面標(biāo)簽。在JavaScript中對后臺視圖函數(shù)中的請求進(jìn)行實現(xiàn)（通過運行函數(shù)達(dá)到關(guān)閉請求的目的）。取到對應(yīng)的請求之后，進(jìn)行簡單日志輸出。然后開啟Flume進(jìn)行數(shù)據(jù)采集。使用SocketIO從Kafka中的behavior主題中獲取并發(fā)送到前端的數(shù)據(jù)，進(jìn)行簡單處理之后存放于json對象之中。創(chuàng)建兩個數(shù)組，分別用于存放json中每個元素的name以及value，為圖表繪制提供數(shù)據(jù)。調(diào)用用戶行為圖表繪制函數(shù)并創(chuàng)建Echarts圖表對象，使用setOption方法傳入數(shù)據(jù)。5.4.1Dashborad頁面展示如圖5-6，數(shù)據(jù)源通過Websocket傳送到前端頁面，總Dashboard頁面顯示有地區(qū)銷售趨勢直線圖，商家分布圖，商家熱銷排名，存儲和銷量分析等數(shù)據(jù)。圖5-6DashBorad頁面5.4.2地區(qū)銷量趨勢圖展示如圖5-7，通過點擊最大化標(biāo)簽，可以查看地區(qū)銷量趨勢大圖，從圖中可以看到最近幾個月地區(qū)銷量的趨勢情況，當(dāng)鼠標(biāo)在圖上移動時，可以橫向?qū)Ρ仍诋?dāng)前時間點，每個地區(qū)的銷售情況。圖5-7地區(qū)銷售趨勢頁面5.4.3熱銷商品分析圖展示如圖5-8，可以通過熱銷商品頁面對當(dāng)前商品類別的不同熱銷商品進(jìn)行分析，可以得到當(dāng)前種類銷售最熱門的商品。占比情況通過餅圖進(jìn)行展示，通過點擊左右兩個小三角，可以查看不同品類的產(chǎn)品占比。圖5-8地區(qū)銷售趨勢頁面5.4.4地區(qū)銷售排行頁面展示如圖5-9，地區(qū)銷售排行頁面，沒五秒刷新一次后臺數(shù)據(jù)，可以通過本頁面實時查看到地區(qū)