從日志到數(shù)據(jù)倉庫的涉及到問題

hunter_search

一 系統(tǒng)層面
數(shù)據(jù)倉庫的源數(shù)據(jù)比較多，可能是從其他的業(yè)務數(shù)據(jù)庫中取出來，也可能是其他的業(yè)務配置文件，也可能是不規(guī)整的原始日志，但總體的思路逃不出一下幾點【過程】:

1.數(shù)據(jù)源的抓取【其他的業(yè)務數(shù)據(jù)庫數(shù)據(jù)，其他的業(yè)務配置文件，不規(guī)整的原始日志等等】

2.數(shù)據(jù)源的格式化【過濾非法數(shù)據(jù)，格式化成能夠裝載的文本或者SQL】

3. 裝載到數(shù)據(jù)庫

4. ＳＱＬ方式生成模型表,業(yè)務表,dimension表

5. 生成fact

6.根據(jù)dimension 和 fact 配合前端顯示了


第4,5到了SQL層，基本上比較好控制了, 重點是前面3步:
        如果hard coding , 那么如何讓這三步自動化，同時具有擴展性？ 個人認為，必須要理清楚數(shù)據(jù)源的來源，方式，在這個前提下，基本框架可以定下來，留下必要的擴展接口就可以了

那么剩下的工作就是數(shù)據(jù)流的監(jiān)控了和修補的自動化處理了



二 服務器層面
   系統(tǒng)部署在N臺服務器上,N>=1
   如果服務器資源不是問題，服務器根據(jù)功能角色分到不同的獨立服務器，機器冗余備份做完善些， 需要充分考慮到計算節(jié)點如果當了，該怎么處理，
   系統(tǒng)在多臺機器上，這些機器的通信借口如何定義？
   數(shù)據(jù)的備份策略:這個就跟業(yè)務有關系了，日志是用什么手段壓縮？存放多長時間？DB用什么手段備份，備份多長時間？


這個可能是筆者考慮到的問題，可能不夠全面，樓下的補充。。

innovate511

日志表的解析，主要還得看業(yè)務系統(tǒng)自己的解析對應表了

不過日志分析是所有分析中最有意思的，因為它沒有具體變化多端的數(shù)據(jù)格式，也沒復雜的業(yè)務關系字段，所有業(yè)務都在同樣的字段里記錄中，等待你的規(guī)整和挖掘。

innovate511

日志表的解析，主要還得看業(yè)務系統(tǒng)自己的解析對應表了

不過日志分析是所有分析中最有意思的，因為它沒有具體變化多端的數(shù)據(jù)格式，也沒復雜的業(yè)務關系字段，所有業(yè)務都在同樣的字段里記錄中，等待你的規(guī)整和挖掘。