今天起床刷牙时脑子突然冒出来，虽然现在不搞这块但好的东西应该记录下来
1.瓶颈存在优化
a) 将分析时间打散
b) 每次数据入库/数据收集时立刻分析
c) 将变更的结果存储入库
d) 将结果缓存起来,查询时优先查缓存 -> 数据仓库 -> 创建数据实例
e) 新统计任务补过去数据时，在CPU 低峰期异步执行
f) 将分析过的数据设置已分析标志，防重复处理 如加版本号匹配过滤
2.数据来源(无论何种方式,应尽量给每条数据加分析标志)
a) 推送
b) 数据库
c) 本地文件
d) 网络拉取数据
设计流程已有，这只是简单的处理业务分析，已经满足大多公司业务需求。
我个人是比较倾向配置大于约定的，为什么？
当业务逻辑很复杂时，用配置来简化逻辑会节省大量的工作量这就是LINUX 设计精髓
甚至可以做到加一条配置记录相当加一个功能，连一行代码都不会写
|
任务标识 |
任务名称 |
共享任务标识 |
父任务标识 |
异步执行表达式 |
key逻辑 |
init逻辑 |
reduce逻辑 |
|
1 |
测试1 |
test1 |
|
|
return getString(source,"date"); |
return {"date": key,a:0,b:0}; |
ret.a+=getInt(source,"a"); |
|
2 |
测试2 |
test1 |
|
|
return getString(source,"date"); |
return {"date": key,a:0,b:0}; |
ret.b+=getInt(source,"b"); |
|
3 |
测试3 |
test2 |
test1 |
|
return getString(source,"date"); |
return {"date": key,c:0}; |
ret.c+=getInt(source,"a"); |
Mr 算法由于其特性，决定他关联分析不了，所有出现父任务设计
以数据驱动工作方式比逻辑驱动方式更直观，但两者相结合效果更佳.
于2015-6-15 完
原文：http://www.cnblogs.com/solq/p/4576590.html