spark + cassandra +postgres +codis 大数据方案
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