从日志到数据仓库的涉及到问题
一 系统层面数据仓库的源数据比较多，可能是从其他的业务数据库中取出来，也可能是其他的业务配置文件，也可能是不规整的原始日志，但总体的思路逃不出一下几点【过程】:
1.数据源的抓取【其他的业务数据库数据，其他的业务配置文件，不规整的原始日志等等】
2.数据源的格式化【过滤非法数据，格式化成能够装载的文本或者SQL】
3. 装载到数据库
4. ＳＱＬ方式生成模型表,业务表,dimension表
5. 生成fact
6.根据dimension 和 fact 配合前端显示了
第4,5到了SQL层，基本上比较好控制了, 重点是前面3步:
如果hard coding , 那么如何让这三步自动化，同时具有扩展性？ 个人认为，必须要理清楚数据源的来源，方式，在这个前提下，基本框架可以定下来，留下必要的扩展接口就可以了
那么剩下的工作就是数据流的监控了和修补的自动化处理了
二 服务器层面
系统部署在N台服务器上,N>=1
如果服务器资源不是问题，服务器根据功能角色分到不同的独立服务器，机器冗余备份做完善些， 需要充分考虑到计算节点如果当了，该怎么处理，
系统在多台机器上，这些机器的通信借口如何定义？
数据的备份策略:这个就跟业务有关系了，日志是用什么手段压缩？存放多长时间？DB用什么手段备份，备份多长时间？
这个可能是笔者考虑到的问题，可能不够全面，楼下的补充。。 日志表的解析，主要还得看业务系统自己的解析对应表了:mrgreen:
不过日志分析是所有分析中最有意思的，因为它没有具体变化多端的数据格式，也没复杂的业务关系字段，所有业务都在同样的字段里记录中，等待你的规整和挖掘。 日志表的解析，主要还得看业务系统自己的解析对应表了:mrgreen:
不过日志分析是所有分析中最有意思的，因为它没有具体变化多端的数据格式，也没复杂的业务关系字段，所有业务都在同样的字段里记录中，等待你的规整和挖掘。
页:
[1]