蘇寧人工智能研發(fā)中心智能創(chuàng)意平臺架構成長之路(一)--長篇開篇
<https://www.cnblogs.com/laoqing/p/11326132.html>
?https://www.cnblogs.com/laoqing/p/11326132.html? ?我們接著第一篇繼續(xù)。

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

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

?

在第二輪迭代完成后，第三輪迭代中，我們就開始做平臺的數(shù)據(jù)分析了，這里我們以工作臺數(shù)據(jù)分析為例，講解平臺如何采用大數(shù)據(jù)的方式來進行數(shù)據(jù)分析。



工作臺中，需要做數(shù)據(jù)分析，比如平臺合成出來的banner圖被用戶的點擊次數(shù)，banner圖合成出來后，被用戶下載的數(shù)據(jù)，工作臺中的PV/UV情況等。


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

1）、亞秒級的OLAP查詢分析，Druid采用了列式存儲、倒排索引、位圖索引等關鍵技術，能夠在亞秒級別內完成海量數(shù)據(jù)的過濾、聚合以及多維分析等操作。

2）、實時流數(shù)據(jù)分析，區(qū)別于傳統(tǒng)分析型數(shù)據(jù)庫采用的批量導入數(shù)據(jù)進行分析的方式，Druid提供了實時流數(shù)據(jù)分析，采用LSM(Long structure
merge)-Tree結構使Druid擁有極高的實時寫入性能；同時實現(xiàn)了實時數(shù)據(jù)在亞秒級內的可視化。

3）、豐富的數(shù)據(jù)分析功能。針對不同用戶群體，Druid提供了友好的可視化界面、類SQL查詢語言以及REST 查詢接口


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

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



1、 在頁面中，我們用采集插件做了數(shù)據(jù)埋點采集，數(shù)據(jù)采集通過數(shù)據(jù)采集服務丟入到kafka中。

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

3、 在kafka中，我們創(chuàng)建了兩個消費組，一個用于小時消費處理，一個用于分鐘消費處理。



4、 在平臺設計時，每張banner圖都有一個唯一的bannerId和url，在數(shù)據(jù)聚合處理操作時，bannerId
就成了唯一的標志，按照bannerId進行分鐘級的聚合處理和小時級的聚合處理。

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



6、 數(shù)據(jù)報表在查詢時，就可以按照1個月以內查詢分鐘表，1個月以外的查詢小時表。




上面講的工作臺中數(shù)據(jù)分析的場景，另外我們還有接口合成banner圖的數(shù)據(jù)也是需要分析。在第二輪迭代時，接口請求合成的banner圖的結果數(shù)據(jù)我們同時入了hbase和mysql兩張表，上文中已經說過入hbase中的數(shù)據(jù)是供用戶做接口合成結果查詢的。入mysql中當時是準備用作數(shù)據(jù)分析的（因為第二輪時，調用量還不夠大，所以那個時候還未采用大數(shù)據(jù)方案），如下圖



在第三輪的接口迭代中，我們將架構進行了優(yōu)化，以適應每天千萬級的接口合成調用，不然mysql數(shù)據(jù)庫會成為最終的瓶頸，如下圖



我們將入mysql的那份數(shù)據(jù)改成寫到kafka中，然后kafka的數(shù)據(jù)可以做實時分析，也可以將kafka的數(shù)據(jù)進入到hive中做離線分析。

未完待續(xù)

?

• ? 上一篇：使用Junit測試一個 spring靜態(tài)工廠實例化bean 的例子，所有代碼都沒有問題，但是出現(xiàn)java.lang.IllegalArgumentException異常
• ? 下一篇：Powered by .NET Core 進展：驗證高并發(fā)性能問題嫌疑犯 docker swarm