【51CTO 5月4號外電】沒錯，數據虛擬化絕對與敏捷性有關。我們在前一篇文章(http://virtualization.sys-con.com/node/2215562)中從不同角度探討了這個話題。這里的敏捷性是指，縮短交付業務用戶需要和信任的新的關鍵數據和報表的時間。這還牽涉面對底層數據源出現的變化，可以靈活應變的架構，又不會影響使用數據的應用程序。關鍵在于以正確的方式進行數據虛擬化，那樣你能夠在短短幾天內，而不是幾個月內交付新的關鍵數據和報告。

　　不過，生產力方面又如何?圍繞敏捷性的討論不可能、也絕對不能將生產力排除在外。因而，生產力與敏捷性休戚相關。無論生產力指的是制造商品或完成工作的速度，還是衡量生產效率的指標，歸根到底是順利而高效地開展工作。這就引發了關于生產效率的一場更深入的探討。不過，看起來有人忘了談論這個話題，不是嗎?

　　據數據倉庫研究所(TDWI)在2011年發布的《商業智能基準測試報告》(http://tdwi.org/research/2011/09/2011-tdwi-bi-benchmark-report.aspx)顯示，“對商業智能/數據倉庫團隊而言，開發和測試是最主要的活動，表明了構建和擴展商業智能系統的工作在整個行業正在進行中。開發團隊所花的時間中近53%用于開發和測試，其次26%用于維護和變更管理。”既然絕大多數的時間用于開發和測試，既然追求商業智能方面的敏捷性是最終目標，那么提高生產力不是絕對很重要嗎?

　　我認為，當以弗所的赫拉克利特(Heraclitus of Ephesus)說“隱藏的關系比明顯的關系更強勁”時，他談論的是數據虛擬化方面的生產力。這絕對是一種隱藏的關系。不過，生產力常常被人無視。倒不是由于生產力不重要，而是由于基于數據聯合的數據虛擬化根源于SQL或XQuery。我們都知道，由于手工編程、有限的重復使用以及不必要的工作，生產力完全被拋之腦后。

　　不妨看看生產力在數據虛擬化項目中到底處于怎樣的地位。數據虛擬化項目涉及一系列獨立的步驟，包括從定義數據模型，直到部署經過優化的解決方案。就像一件藝術品那樣，每個步驟能夠以不同的方式來對待——可能令人痛苦不堪，也可能運用支持生產力的***實踐。行業架構師在下面描述了數據虛擬化項目的典型的生命周期。如果質疑每一個步驟如何開展，我們就能明白這些步驟給生產力帶來的影響：

　　模型：定義后端數據源，并將它們作為通用的業務實體來表示

　　訪問和合并：跨幾個異構數據源，實時聯合數據

　　剖析：分析和確認聯合數據存在的問題

　　轉換：對聯合數據運用高級的轉換機制，包括數據質量

　　重復使用：針對任何應用，迅速而順暢地改動同樣的虛擬視圖

　　移動或聯合：針對批量使用場合，重復使用虛擬視圖

　　擴展和執行：充分利用優化、緩存和模式，比如復制和ETL(抽取、轉換和加載)等

　　不妨從模型開始說起。這里要提出的問題是：有沒有現成的數據模型?如果有，是否很容易導入數據模型?這意味著，你必須能夠通過現成的眾多建模工具與模型進行交互。如果沒有現成的數據模型，要是你需要從頭開始搞起，就必須能夠借助一種元數據驅動的圖形化方法，開始創建邏輯數據模型。這對業務用戶來說應該輕車熟路，因為業務用戶對數據最熟悉。是吧?

　　接下來，不妨考慮訪問和合并。沒錯，這是數據聯合的范疇。其目的在于使許多數據源如同一個數據源。不過，我在討論為什么只有一技之長不管用時，提到了弗雷斯特研究公司最近撰寫的一篇博文(詳見http://blogs.forrester.com/boris_evelson/11-11-15-top_10_business_intelligence_predictions_for_2012)。該博文表示，傳統的商業智能方法常常不盡如人意，原因是商業智能并沒有充分授權予信息型員工，這些員工仍然在很大程度上依賴IT部門。我們不妨提出這個問題：在沒有IT部門幫助的情況下，業務用戶也能直接訪問和合并不同數據嗎?

　　你對來自幾個異構數據源的數據進行了聯合后，是不是說大功告成了?錯了!這只能說基于數據聯合的數據虛擬化完成了。按道理講，想以正確的方式進行數據虛擬化，工作還得繼續。同樣這些業務用戶(不是IT用戶)現在不僅能夠分析數據源，還能夠分析集成邏輯——無論集成邏輯是數據源、嵌入轉換還是虛擬目標。而這其實是對聯合數據進行剖析——這意味著沒有試運行，沒有進一步的處理。

　　接下來就是，一旦業務用戶發現了數據不一致或不正確的地方，自然要采取的合理的后續步驟。沒錯，我們必須針對聯合數據運用高級的轉換邏輯(包括數據質量和數據屏蔽)。這時候，你必須問一下有沒有現成的預制庫，以便你很容易在你的畫布(canvas)中使用。我認為，我們都認識到，這意味著沒必要為這類邏輯手工編程，而此舉顯然會限制任何重復使用。

　　你已定義了數據模型，聯合了數據，實時剖析了聯合數據，而且動態運用了高級轉換機制，這一切都是在沒有IT部門幫助的情況下完成的。沒錯，必要的話，可以尋求一些技術幫助，開發新的轉換機制。但是務必要以一種圖形化、元數據驅動的方式來開發，那樣業務用戶和IT用戶能夠立即運用基于角色的工具進行合作。問一下虛擬視圖是不是拿來后，你只要點擊幾下，就可以重復使用了。查看一下是否只需處理幾個可重復使用的對象，而不是處理成千上萬行SQL代碼。

　　我們已討論了虛擬化數據集成涉及的幾個步驟。沒錯，沒有實際的數據遷移;沒錯，這很神奇。不過，要問一下：如果你出于遵守法規的考慮需要對數據進行持久化處理，你能做什么。或者，當數據容量超出經過優化的、可擴展的數據虛擬化解決方案的處理能力時，要求還能進行批量處理的靈活性。絕對不要靠另一個工具來處理問題。要問一下，能不能使用同一個解決方案在虛擬模型和物理模型之間進行切換。

　　***，當你準備部署虛擬視圖時，一個合理的問題肯定與性能有關。畢竟，我們談論的是在虛擬模式下運營。進行一番優化，弄清楚緩存方面的情況。要深入查明引擎是如何構建的。引擎是不是基于一種可靠的、成熟的、可擴展的數據集成平臺?還是它只能進行數據聯合，又存在種種限制?此外，別忘了問一下同一個解決方案是不是充分利用了變更數據捕獲和復制模式。

　　如果解決方案能支持上面討論的整個數據虛擬化生命周期，你可能距離生產力和敏捷性兼而有之的理想境界不遠了。不過，關鍵在于要敢于提出尖銳的問題：因為每一個步驟不僅讓過程縮短了數周，還幫助用戶提高了效率。這開始聽起來像是杜絕了整個過程中的等待和浪費，就像《精益集成》(Lean Integration)(http://www.integrationfactory.com/)這本書里面詳細介紹的那樣。我們兜了個大圈，回到了原處。不過我認為，我們很可能已成功地將生產力從被人無視的境地中挽救出來。

　　譯文來源： http://virtualization.sys-con.com/node/2236825