从日志到数据仓库的涉及到问题

hunter_search

一 系统层面
数据仓库的源数据比较多，可能是从其他的业务数据库中取出来，也可能是其他的业务配置文件，也可能是不规整的原始日志，但总体的思路逃不出一下几点【过程】:

1.数据源的抓取【其他的业务数据库数据，其他的业务配置文件，不规整的原始日志等等】

2.数据源的格式化【过滤非法数据，格式化成能够装载的文本或者SQL】

3. 装载到数据库

4. ＳＱＬ方式生成模型表,业务表,dimension表

5. 生成fact

6.根据dimension 和 fact 配合前端显示了


第4,5到了SQL层，基本上比较好控制了, 重点是前面3步:
        如果hard coding , 那么如何让这三步自动化，同时具有扩展性？ 个人认为，必须要理清楚数据源的来源，方式，在这个前提下，基本框架可以定下来，留下必要的扩展接口就可以了

那么剩下的工作就是数据流的监控了和修补的自动化处理了



二 服务器层面
   系统部署在N台服务器上,N>=1
   如果服务器资源不是问题，服务器根据功能角色分到不同的独立服务器，机器冗余备份做完善些， 需要充分考虑到计算节点如果当了，该怎么处理，
   系统在多台机器上，这些机器的通信借口如何定义？
   数据的备份策略:这个就跟业务有关系了，日志是用什么手段压缩？存放多长时间？DB用什么手段备份，备份多长时间？


这个可能是笔者考虑到的问题，可能不够全面，楼下的补充。。

innovate511

日志表的解析，主要还得看业务系统自己的解析对应表了

不过日志分析是所有分析中最有意思的，因为它没有具体变化多端的数据格式，也没复杂的业务关系字段，所有业务都在同样的字段里记录中，等待你的规整和挖掘。

innovate511

日志表的解析，主要还得看业务系统自己的解析对应表了

不过日志分析是所有分析中最有意思的，因为它没有具体变化多端的数据格式，也没复杂的业务关系字段，所有业务都在同样的字段里记录中，等待你的规整和挖掘。