2019独角兽企业重金招聘Python工程师标准>>>

数据平台架构跌代及研发

架构方案及版本跌代

统计版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实现，冗余和灵活性，维护开发成本大

阿里公测阶段需申请

统计+全文检索版（为一检索功能投入太大）

日志服务+OTS（没这东西据查，日志搜索一个是周期限制历史数据没有不是全量，二是只简单手动配置索引，需现加Keywords）

阿里不支持ES是opensearch服务（对决解析后的oss，页面级设置即可生成日志分词索引）

ES自搭。。。

架构改动：

解析及处理后结果偏向存oss或hadoop或自有分步索引格式

全文检索上做统计，要做中间桥接匹配，如检索出的记录，用id列在spark rdd中做filter 或是nosql中in(ids,,,)

其它类似redis 或mongo

数仓DW,集市DM,OLAP,BI完整版(大工程，针对多仓库多系统多行业)

据阿里云EMR快速搭建数据平台（二）