数据平台架构跌代及研发
架构方案及版本跌代
统计版0.0.1
spark+redis+oss+sls相关接口测试用例和分析环境都已打通
解析后内容，缓存内容，数据检查点：内存和本地或hadoop临时文件
持续更新状态或数据累加汇总结果直接记redis
常用中间结果数据集考虑存oss（redis备选简单集存储，因数据链接资源问题，不适用直接在nosql上做跌代计算），如新老访客标识等
redis存储KEY(暂定):domain-prduct-model-指标[-维度1|维度2-周期-其它]
如：twotiger访问统计 站点概要 当天北京小时级ip分步的前十个IP twotiger.com-siteStatistics-siteSummary-ip-timeDim=today|regionalDim=110000-h-top10
维度表存储
mysql
阿里统一了hive元数据库（统一了不给root权限，不在emr,可能不能手动增改，总之不灵活，如是业务性质维度也不太安全）
自建rds 库保存管理维护元数据
emr中master节点有一本地mysql，先把维度表暂放至test库，以后在迁移
oss文件
hbase
其它nosql
统计+检索（当前需求基本满足）
nosql为主的集群，如mogo，解决关系型百万级以上读写常用统计困难问题
优点：以业务方案统一，简单直接成熟易操作开发维护投入成本低，常用检索统计需求均可满足，除nosql分步式存储访问优势，
还能运用spark给业务查询统计带来分步式计算的优势，如百万级记录统计，从db的30s到nosql的10s内到spark的秒级
劣势：
1.正则检索并不能发挥nosql内存索引优化，不支持Join,区分大小写，内存翻倍增长，分片均衡拷备延迟，锁管理等 2.日志容量增长是业务数据的倍数，可能很快到达nosql边界，出现丢数据，无端故障等不稳定状况， 需实际测试，nosql集群的边界和日志的增长合理估算周期和投入
针对版本一架构的改动：
缓存及数据检查点不变
解析后内容或数据处理后结果直接进mongo
mongo3.2以上，shard分片加replcat set,ssd缓存或全硬盘 2核 4G集群版（据数据增长扩容shard；目前rds都可以改配置有几次停屯，升级拷备不影响使用时间）
10万全表扫描？秒，百万？ 秒
单实例存储量估计?W，内存使用估计？G,监控指标？%备增节点或做相应优化
阿里官方性能指标：单分片（shard）最大支持25600的IOPS，最大存储2T数据，单分片最大可承载近 10万 QPS 的应用压力；且Sharding模式支持水平无限扩展
个别慢查询优化方案：独立connection或hbase中做预查询存储优化
持续状态和汇总统计结果值可以用redis也可以合到mongo另一独立connection
常用中间结果集类似oss主为，mongo或redis备选
升级版，mongo极限后迁致hbase，量上解决了，但检索开发及性能由自己设计，维护成本没有优势
十万条全表查询秒级，百万在5-8秒
有rowkey过虑功能，社区支持勾子函数实现二级索引
全文检索还是另借lucence等实现
适合场景：
结构化(单纯的、海量的key value)或半结构化的非关系型的数据，大规模写入(注意适时禁用auto split)、扫库的业务
不适宜:
1.随机读取:整block加载到内存，二分查找，缓存不断重建修改 2.灵活查询则需要自己构建二级索引，甚至重复数据建立不同的查询key实现，冗余和灵活性，维护开发成本大
扫一扫
887
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
