【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
