汽車網決策支持系統設計

董勤

摘要 汽車行業某垂直門戶網站（下稱汽車網）從2006年初開始上線到今天已經成功運營十多年，在全國各大城市均設有獨立的服務器和分站，主要提供汽車資訊、廣告、當地汽車報價、經銷商門店、車主投訴處理等功能。由于地區性差異，各分站發展到今天雖然界面形式上一致，但數據格式上卻各自演化無法統一，管理層無法及時得到準確的全局決策信息。為了徹底解決該問題，經調研決定在總部開發一套決策支持系統，集成各分站數據，讓管理層隨時都可以得到準確、及時的信息。該系統的成功實施提升了公司的決策效率，使高管們在第一時間掌控全國行業動態，及時調整廣告策略，給經銷商們提供符合市場的價格信息，企業也因此獲得了客戶的廣泛好評。

【關鍵詞】汽車網 決策支持系統 數據倉庫數據中心

1 引言

作為業內排名靠前的汽車行業垂直門戶，汽車網隨著業務的不斷發展，在全國主要大中城市均有分布式服務器集群。北京、上海、廣州、武漢、成都的客戶可以就近訪問電信或者網通甚至是其他更小規模服務商的網絡內的服務器，以便得到最好的網絡速度體驗，并且，隨著業務的飛速發展，用戶產生的內容和數據也越來越多，對存儲要求也越來越高，集中式的網站服務根本無法滿足全國各地用戶的多種需求，分布式網站的策略到現在依然有效，可以根據IP將用戶訪問分流到各地。但是這種策略對公司的高層領導來說也帶來了新問題，高層領導無法及時得到一個全局的數據視圖以準確掌控業務狀態，需要各分公司配合出各地報表，匯總到總裁辦公室合并為Excel，最后得到全局視圖。這種人工的方式費力，延遲，經常出錯，公司高層領導已經無法接受這種傳統模式，因此立項研發決策支持系統以徹底解決問題。

決策支持系統通常來講分為三部分：數據采集處理、數據存儲和數據展現。通常的做法是采購大型軟件公司的成熟方案，如IBM的DataStage，DB2，Portal系列;Oracle公司的Oracle DB，ApplicationServer，Form系列以及Microsoft公司的BI解決方案。這些方案的優點是成熟可靠，缺點也很明顯：不能靈活應對特殊場景，服務按小時計費價格昂貴。

汽車網選擇從開源軟件入手，以開源的Linux操作系統為核心，采用Java語言編寫數據采集與清洗軟件，使用Hadoop、Spark、Hbase作為分析處理和數據存儲服務器，并用G2框架為基礎開發個性化報表系統。最后同樣能夠達到一流商用BI方案的效果，并且可以針對自己的業務需求靈活快速地調整，而且開源軟件本身免費，取得了極佳的性價比。

2 需求分析

決策支持系統需要的數據種類繁多，比較典型的有以下幾種，其一是各種頁面的訪問量，廣告位曝光、點擊、報名轉化，從而分析廣告效果，以便進行動態調整廣告策略;其二是監控當地經銷商網店優惠活動及車型價格，采集分析其他重點汽車網站的報價信息進行對比，統計分析價格規律，從而讓管理層做出最優決策，以配置各地庫存數量及制定相關報價策略;其三是監控用戶輿論方向，對每一款車型的提問、回答，分析出當前用戶比較關注的焦點，從而做相關活動提高社區粘度;其四是收集車主投訴，匯總統計得出質量問題規律，對接車廠從而更好地服務于最終消費者。因此技術上需要每日從全國20多個分站抽取相關增量數據到總部數據中心，對處理好的數據進行分析和挖掘。

3 系統設計方案

傳統的決策支持系統分為ETL、DaraWarehouse、BI三部分;其中ETL部分一般采用IBM的SataStage工具來實現;數據中心主要采用NAS和IP SAN相結合的方式分別滿足共享文件存儲和數據存儲的功能，容量擴展主要依賴于磁盤陣列和磁帶庫;BI部分則采用水晶報表作為展現工具?？紤]到這么設計代價昂貴，尤其是數據中心部分的集中存儲方式擴展起來不是很方便，性能也難以保障，因此在汽車網的決策支持系統中，采用新的設計方式，如圖1所示。

如圖1所示，該設計主要采用了以開源框架Hadoop為基礎的分布式處理與存儲思想，規避了傳統收費軟件，使用相對廉價的PC服務器集群取代昂貴的專用磁盤陣列存儲設備，使得海量數據的處理存儲變得相對簡單、便宜。其中數據采集部分，使用kafla、flume等分布式組件遠程收集各分站的業務數據，匯總到總部數據中心，然后采用Spark Streaming對數據流進行實時處理，結果再以鍵值對的方式存入Hbase，對于需要進行多維分析的數據可以存入傳統的RDBMS中，也可以自己寫OLAP方法針對需求進行定制分析。

4 實施

4.1 數據采集與清洗

汽車網各種業務數據，如各分站經銷商的報價數據，各車型的用戶口碑，各地用戶的投訴與評論，各分站的汽車專業文章及廣告位，閱讀量、點擊量等均需要及時傳送匯總到數據中心。這個過程分為數據抽取、數據清洗、數據傳送三個環節。首先各分站的分布式數據抽取工作并不容易，如果直接連接到各地生產庫上，可能會影響性能，因此對于數據庫類型的數據源，各分站先做主備模式，只需要連接到備機上根據時間抽取增量數據再通過kafka隊列傳輸到總部數據中心;對于日志文件，則采取先集中備份到日志轉發機，再采用消息隊列kafka傳輸到總部數據中心;fiume管道對HDFS格式的文件傳輸比較友好，專門用來傳輸這類格式的數據。這些數據在進入隊列或者管道之前進行統一的格式轉換，即完成數據清洗工作。數據傳輸任務設置在每天夜間定時完成，最后匯總到數據中心，由Spark Streaming進行實時分析、處理、分類，最后存到Hbase數據倉庫，也有少量存入Mysql數據庫中。

4.2 數據分析與處理

Spark Streaming從消息隊列中獲取數據流，并按照時間分塊，轉化為rdd，然后通過滑動窗口對數據進行實時的統計分析計算。Spark Streaming中提供了很多封裝好了的簡單易用的算子，例如map，flatMap，filter，sort，reduceByKey，collect等，通過這些算子的組合，可以完成不同的計算需求。這些算子會創建很多map/reduce子任務，分發到不同的集群子節點，進行分布式運算。例如要統計10分鐘內多款車型詳情頁面的閱讀次數，則可以采用10分鐘作為滑動窗口的大小，而滑動頻率決定了觸發計算任務的頻率，需要根據實際的數據量、集群的算力、實時性等統一考慮，設置適當的窗口滑動頻率可以讓集群運行更加穩定;計算的過程如下：從日志中篩選出這幾款車型的訪問記錄（filter算子），然后轉換為鍵值對（url，1），最后通過reduceByKey統計出每款車型的總訪問量。在處理更復雜的情況時，還需要從數據中抽取出重要的數據字段（主要通過正則匹配來實現），然后轉換為對象實例，方便后續的處理;在計算的過程中，有的時候還可以把需要重復使用的數據緩存起來，后續就會直接使用cache，而不是重新計算，這可以極大地提高計算速度。

4.3 多維分析與報表展現

Hbase本身是key-value存儲格式，適合海量存儲，但對于復雜的多維分析運算需要額外編寫程序，另外還可以借助傳統的RDBMS來實現。在汽車網廣告分析模塊中，利用開源的Mysql作為補充進行報表運算。多維分析的表結構設計與普通的事務處理表結構設計并不相同，它更多的傾向于數據分析，要求從多個維度考察度量指標，比方說在廣告點擊量分析數據倉庫，記錄了每個廣告的曝光量點擊量，這個廣告發布在哪個位置，哪天發布的。多維數據庫由事實表和維度表組成，其中事實表由維度和度量組成，度量是廣告的點擊量和曝光量，維度是時間、位置、廣告。有了這樣一個多維數據庫記錄歷史到今天的廣告數據，很容易鉆取（drill down）和上卷（roll up）來分析廣告效果。以前靠人工收集數據，EXCEL匯總的模式，已經被高度自動化的數據抽取、清洗、分析、匯總、生成報表的流程取代，延遲從以前的好幾天變成現在的幾小時，報表數據精確無誤，高層能隨時查看最新動態，對用戶關心的汽車投訴問題、行情信息、銷售量、熱銷和滯銷車型了如指掌。另外也不需要采購昂貴的水晶報表軟件來完成這項工作，開源引擎G2是一個非常好的工具，被深度應用于汽車網的報表展現中。

5 結論

決策支持系統的數據采集模塊分布在全國多個分站，在帶寬充足的前提下和總部數據中心的通信穩定可靠，項目成功運行半年多充分證實最初的設計正確可行。

數據流實時分析處理部分，快速高效，超過預期。實踐證明采用Spark Streaming在內存中實時處理的效果要優于先將數據存入HDFS攢到一定量再進行批處理的方式。

自動化報表程序快速高效，準確率高。高管隨時掌握全國各分公司業務的最新動態，準確抓住業務的敏感點，及時調整市場策略實現效益最大化，充分體現了數據的價值。

參考文獻

[1]姚雄飛，覃海生，多品牌汽車銷售集團的業務決策支持系統的架構設計[J].電腦編程技巧與維護，2016.

[2]莊玉良，賀超.基于物聯網的汽車業再制造信息采集與決策支持系統研究[J]，物流技術，2016 （06）.

[3]張若儒，基于HBase的OLAP多維數據聚集計算[J].東南大學，2012.

[4]尹國明，汽車維修故障診斷智能決策支持系統的研究[J].中國新技術新產品， 2013（23）.

[5]楊春瑩，杜小芳，王維.汽車企業訂單生產決策支持系統[J]，汽車工程師，2011 （10）.

[6]楊艷霞，于海平.基于數據倉庫的汽車配件銷售決策支持系統[J].計算機與數字工程，2010 （07）.