蘇寧人工智慧研發中心智慧創意平臺架構成長之路(一)--長篇開篇 https://www.cnblogs.com/laoqing/p/11326132.html   我們接著第一篇繼續。

(這是第二篇大資料架構篇，成長之路序列會包含多篇，筆者作為這個平臺的架構兼技術經理，充分講述其中的迭代心酸之路以及中間遇到的問題和解決方案)

宣告：文章不涉及公司內部技術資料的外洩，涉及的圖片都是重畫的簡易架構圖，主要通過架構的演進，講述分享技術的迭代之路和過程。

在第二輪迭代完成後，第三輪迭代中，我們就開始做平臺的資料分析了，這裡我們以工作臺資料分析為例，講解平臺如何採用大資料的方式來進行資料分析。

工作臺中，需要做資料分析，比如平臺合成出來的banner圖被使用者的點選次數，banner圖合成出來後，被使用者下載的資料，工作臺中的PV/UV情況等。

在此輪設計中，我們直接用的大資料解決方案，並沒有在一開始使用關係型資料來做這樣的資料分析統計，架構方案如下，我們選用了Druid來做資料儲存，以OLAP的方式來做資料分析，Druid.io(以下簡稱Druid)是面向海量資料的、用於實時查詢與分析的OLAP儲存系統。Druid的四大關鍵特性總結如下:

1）、亞秒級的OLAP查詢分析，Druid採用了列式儲存、倒排索引、點陣圖索引等關鍵技術，能夠在亞秒級別內完成海量資料的過濾、聚合以及多維分析等操作。

2）、實時流資料分析，區別於傳統分析型資料庫採用的批量匯入資料進行分析的方式，Druid提供了實時流資料分析，採用LSM(Long structure merge)-Tree結構使Druid擁有極高的實時寫入效能；同時實現了實時資料在亞秒級內的視覺化。

3）、豐富的資料分析功能。針對不同使用者群體，Druid提供了友好的視覺化介面、類SQL查詢語言以及REST 查詢介面

4）、高可用性與高可拓展性。Druid採用分散式、SN(share-nothing)架構，管理類節點可配置HA，工作節點功能單一，不相互依賴，這些特性都使得Druid叢集在管理、容錯、災備、擴容等方面變得十分簡單。

關於druid的介紹，可以參考https://www.jianshu.com/p/0a614455a964 這篇文章。

1、 在頁面中，我們用採集外掛做了資料埋點採集，資料採集通過資料採集服務丟入到kafka中。

2、 我們在druid中設計了兩張表，資料的粒度精確到分鐘時間段，也就是有分鐘表和小時表兩張。分鐘表資料量可能會比較大，所以我們只會保留1個月內的分鐘表資料，小時表的資料會長期儲存。

3、 在kafka中，我們建立了兩個消費組，一個用於小時消費處理，一個用於分鐘消費處理。

4、 在平臺設計時，每張banner圖都有一個唯一的bannerId和url，在資料聚合處理操作時，bannerId 就成了唯一的標誌，按照bannerId進行分鐘級的聚合處理和小時級的聚合處理。

5、 小時級的聚合處理也可以考慮使用hive，處理的方案如下，由於分鐘表的資料會儲存1個月，所以1個月內的查詢其實都是直接查詢分鐘表，1個月以外的資料才會查詢小時表。所以儘管此種方案可能會存在資料採集延遲的情況，但是也不會延遲1個月之久，所以可以通過定時任務來處理，定時任務可以在第二天處理前一天的資料。

6、 資料報表在查詢時，就可以按照1個月以內查詢分鐘表，1個月以外的查詢小時表。

上面講的工作臺中資料分析的場景，另外我們還有介面合成banner圖的資料也是需要分析。在第二輪迭代時，介面請求合成的banner圖的結果資料我們同時入了hbase和mysql兩張表，上文中已經說過入hbase中的資料是供使用者做介面合成結果查詢的。入mysql中當時是準備用作資料分析的（因為第二輪時，呼叫量還不夠大，所以那個時候還未採用大資料方案），如下圖

在第三輪的介面迭代中，我們將架構進行了優化，以適應每天千萬級的介面合成呼叫，不然mysql資料庫會成為最終的瓶頸，如下圖

我們將入mysql的那份資料改成寫到kafka中，然後kafka的資料可以做實時分析，也可以將kafka的資料進入到hive中做離線分析。

未完待續

&n