spark + cassandra +postgres +codis 大數據方案

一、環境：

1.一、cassandra 集羣： 用於日誌數據存儲

1.二、spark集羣： 用戶後期的實時計算及批處理

1.三、codis 集羣： 用於緩存一些基本數據如IP歸屬地，IP經緯度等，當日志上來，對日誌進行補全

1.四、postgres數據庫： 一、用於存儲維度表 二、存儲統計結果

1.五、消息隊列 如：rabbitmq、apollo 或者kafka，用於接收產品日誌數據。當日志數據低於5000條/s時，能夠考慮使用rabbitmq。高於此值。建議換成apollo或者kafka。消息隊列不建議留太長時間的數據，建議保留時間：15天~1月

部署說明：

spark 和cassandra 採用一對一部署，以保證後期計算時的數據本地性

codis集羣：視具體狀況而定，建議很多於3組，每組2個節點

postgres：開啓自動vacuum

二、數據收集

日誌數據直接發送到消息隊列（能夠考慮在消息隊列前加上Nginx）。

三、數據補全與拆分 外加原始數據存儲

使用日誌數據時，咱們可能會有一些指望，好比，

A: 後期須要按區域進行產品統計，熱力圖。這時能夠將IP地址解析爲國家、省、市、和經緯度。

B: 日誌須要分發不一樣部門，日誌記錄須要惟一標識 如：添加長整型日期戳+進程標識

數據進行補全後，A：根據產品等拆分紅topic後，扔回隊列，供實時計算，B：並存儲一份到cassandra做爲原始數據，同時供離線計算

四、實時計算

spark streaming 根據須要，訂閱topic，進行實時計算

五、數據倉庫

根據實際業務，訂閱拆分後的topic，生成數據倉庫。維度表放在postgres中，事實表放在Cassandra中.

請注意如下幾點：

A、維度表

　　A1：採用Long做爲主鍵，以增快後期Join效率。

　　A2：同時爲避免過於頻繁讀寫關係數據庫，可使用codis緩存維度數據，設置ttl，如8小時。

B、事實數據，切忌放在關係數據庫中。過於頻繁的讀寫操做會對關係數據庫形成過大壓力。

C、若是精力、資源有限，能夠先對核心日誌類型作數據倉庫，好比，訂單。至於客戶點擊、瀏覽歷史能夠以後再作。

六、離線計算

6.1 spark 做業能夠讀取Cassandra中的原始數據，進行歷史數據的離線計算。詳見spark cassandra connector的使用

6.2 每日對事實表進行簡單聚合後，與維度表進行join，join後的數據另外存儲。供核心業務使用。

　　6.2.1 因爲每日join，恰好按日作了緩慢變化。若須要進行歷史統計能夠直接用。若須要按照最新維度信息對歷史數據進行統計，各個業務自行與維度表join

　　6.2.2 因爲事實表join個全部維度表，字段比較多。可是實際使用時，各個業務只會取其中的十個八個字段，甚至更少，此時，強烈建議使用列存儲，並啓用壓縮。

　　   建議使用parquet存儲（詳見：爲何咱們使用parquet），而不用rc或者orc file,緣由1:spark 原生支持parquet。緣由2：即便你用hive，hive也徹底支持parquet

七、計算結果

選擇計算結果的存儲位置,須要事先預估結果的記錄數。切勿只考慮一天，至少要考慮一年。以每一年3000W爲門坎，

若小於3000W，能夠考慮存儲到關係數據庫。

若大於3000W，須要使用NOSQL數據庫。您能夠選擇cassandra、hbase、mongodb等

八、結果展示

結果展示時，請考慮如下因素

數據導出：大數據的計算結果未必會是小數據，所以數據導出必定要分頁。在第7步選擇哪一種NOSQL，要先調研好分頁實現。

可視化展示：千里之堤，潰於蟻穴。數據已經計算出來了，必定要在展示上把數據的價值體現出來。能夠考慮使用折線圖、柱狀圖、餅圖、熱力圖、地圖等，推薦使用Echarts