人工智能-智能創意平台架構成長之路(三)--機器學習算法工程服務化
人工智能-智能創意平台架構成長之路(四)-豐富多彩的banner圖生成解密第一部分（對標阿里鹿班的設計）
人工智能-智能創意平台架構成長之路(一)--長篇開篇 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中做離線分析。
未完待續