1、環境：
1.1、cassandra 集群： 用於日志數據存儲
1.2、spark集群： 用戶后期的實時計算及批處理
1.3、codis 集群： 用於緩存一些基本數據如IP歸屬地，IP經緯度等，當日志上來，對日志進行補全
1.4、postgres數據庫： 1、用於存儲維度表 2、存儲統計結果
1.5、消息隊列 如：rabbitmq、apollo 或者kafka，用於接收產品日志數據。當日志數據低於5000條/s時，可以考慮使用rabbitmq。高於此值。建議換成apollo或者kafka。消息隊列不建議留太長時間的數據，建議保留時間：15天~1月
部署說明：
spark 和cassandra 采用一對一部署，以保證后期計算時的數據本地性
codis集群：視具體情況而定，建議不少於3組，每組2個節點
postgres：開啟自動vacuum
2、數據收集
日志數據直接發送到消息隊列（可以考慮在消息隊列前加上Nginx）。
3、數據補全與拆分 外加原始數據存儲
使用日志數據時，我們可能會有一些期望，比如，
A: 后期需要按區域進行產品統計，熱力圖。這時可以將IP地址解析為國家、省、市、和經緯度。
B: 日志需要分發不同部門，日志記錄需要唯一標識 如：添加長整型日期戳+進程標識
數據進行補全后，A：根據產品等拆分成topic后，扔回隊列，供實時計算，B：並存儲一份到cassandra作為原始數據，同時供離線計算
4、實時計算
spark streaming 根據需要，訂閱topic，進行實時計算
5、數據倉庫
根據實際業務，訂閱拆分后的topic，生成數據倉庫。維度表放在postgres中，事實表放在Cassandra中.
請注意以下幾點：
A、維度表
A1：采用Long作為主鍵，以增快后期Join效率。
A2：同時為避免過於頻繁讀寫關系數據庫，可以使用codis緩存維度數據，設置ttl，如8小時。
B、事實數據，切忌放在關系數據庫中。過於頻繁的讀寫操作會對關系數據庫造成過大壓力。
C、如果精力、資源有限，可以先對核心日志類型做數據倉庫，比如，訂單。至於客戶點擊、瀏覽歷史可以之后再做。
6、離線計算
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
7、計算結果
選擇計算結果的存儲位置,需要事先預估結果的記錄數。切勿只考慮一天，至少要考慮一年。以每年3000W為門坎，
若小於3000W，可以考慮存儲到關系數據庫。
若大於3000W，需要使用NOSQL數據庫。您可以選擇cassandra、hbase、mongodb等
8、結果展現
結果展現時，請考慮以下因素
數據導出：大數據的計算結果未必會是小數據，因此數據導出一定要分頁。在第7步選擇哪種NOSQL，要先調研好分頁實現。
可視化展現：千里之堤，潰於蟻穴。數據已經計算出來了，一定要在展現上把數據的價值體現出來。可以考慮使用折線圖、柱狀圖、餅圖、熱力圖、地圖等，推薦使用Echarts