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