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

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

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

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

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

　　模型：定義后端數(shù)據(jù)源，并將它們作為通用的業(yè)務(wù)實體來表示

　　訪問和合并：跨幾個異構(gòu)數(shù)據(jù)源，實時聯(lián)合數(shù)據(jù)

　　剖析：分析和確認聯(lián)合數(shù)據(jù)存在的問題

　　轉(zhuǎn)換：對聯(lián)合數(shù)據(jù)運用高級的轉(zhuǎn)換機制，包括數(shù)據(jù)質(zhì)量

　　重復(fù)使用：針對任何應(yīng)用，迅速而順暢地改動同樣的虛擬視圖

　　移動或聯(lián)合：針對批量使用場合，重復(fù)使用虛擬視圖

　　擴展和執(zhí)行：充分利用優(yōu)化、緩存和模式，比如復(fù)制和ETL(抽取、轉(zhuǎn)換和加載)等

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

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

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

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

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

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

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

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

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