搭建沟通BI与SOA的桥梁

搭建沟通BI与SOA的桥梁2010-02-06 infoq Arnon Rotem-Gal-Oz简介

我们都知道商业智能（Business Intelligence，BI）能给组织带来许多优势。通过整理、聚集和分析数据，BI能帮助我们洞悉组织内正在发生的事情，以及将要发生的事情。BI让我们识别出组织前进的方向或者应该前进的方向。BI的过程通常从提取、转换和加载数据（Extract、Transform、Load，ETL）开始。一般来说，ETL是数据仓库（Data Warehouse）中的一个过程，其中包括：

从外部和内部数据源提取数据。

转换数据以符合业务的需要。

将转换后的数据加载到数据仓库（或者数据集市，Data Mart）

基本上，我们要达到BI的圆满境界，“只”需要一样东西：数据。BI需要隐藏在组织系统中的数据。

走进SOA

在过去的数年间，我们已经看到了面向服务架构（Service-Oriented Architecture，SOA）在IT架构前沿的进步。随着夸大的宣传渐渐平息，而各个组织逐渐完成向SOA的过渡，突然之间人们发现BI所需的数据被分散到了各个服务之中，被隐藏到了各种接口契约之后。

请看图1所示的SOA组件（来自我的论文《到底什么是SOA？》），我们可以看到除了最主要的组件——服务——之外，SOA还有若干与服务接口相关的其它组件：

契约，服务所实现的契约

端点，与服务建立联系的所在

消息，在服务与其用户之间来回传递的消息

策略，服务遵循的策略

用户，与服务交互的用户

这些组件，以及SOA的“共享数据定义（Scheme）而非数据”和“服务应当是自治的”等信条，都告诉我们SOA对其接口的重视。正是通过这种对严密定义的接口通信的强调，给SOA在松耦合、灵活性和敏捷性等方面带来了技术和业务上的优势。

图1：SOA组件及其关系

一方面BI着力在对数据的深入理解，另一方面SOA着力在将内部数据隔离到接口之后，目标冲突是真实存在的。正如Pat Helland在《外部数据vs.内部数据》中所说，服务的内部数据绝不应该暴露到服务的外部，而这些数据正是BI所需要的。正是出于这个原因，根据最近Ventana Research 进行的一项调查（由Dan Everett在Dr. Dobb"s Journal上发表），只有1/3的调查对象认为他们的内部IT人员有知识和能力去实现BI服务，这个结果并不令我们感到惊讶。

我们似乎面对两个选项：要么直接获得数据而无视某些SOA原则（比如“共享数据定义而非数据”），要么遵循眼前的接口契约而盲目地期望BI能获得足够的数据。（第三个选项则跟第一个选项等效，我稍后会讨论到，即创建特定于BI需要的契约。）

直接获取数据，或者……

第一个选项是直接获取BI所需的数据，其过程则按照过去已经充分证明有效的ETL。

SOA给ETL带来了一点挑战，你必须从许多分散的位置（服务）将数据集中起来。不过，从多个资源中汇集数据对BI或者ETL来说都不是什么新问题。大企业中已经存在许多数据源：ERP、CRM、分散在各个部门的数据竖井（data silos），诸如此类。有了SOA，ETL反而可能更容易，如果考虑到SOA承诺把企业数据编织成高内聚的组织结构，而不是意大利面条式的点对点集成。（请注意“承诺”这个词，事实上要达到高内聚的服务组织结构不是一件容易的事。不过这是题外话了，这个问题要用另一篇文章甚至一本书才能解释清楚。）

前面我已经说过，ETL已经很成熟，也已经被证明是成功构建BI解决方案的基础。然而，使用ETL基本上就意味着抹杀大部分当初让我们追寻SOA的那些好处。在SOA史前时代，我们面对的主要问题（在许多组织中这个问题仍然存在）之一是，企业系统的意大利面条式集成。请考虑图2所示的情形。由于历史的原因，每个部门都建立了自己的系统。随着新的业务需求的显现，其结果就是一堆各自为营的、条块分割的系统。然后，当系统间需要共享数据时，就加入新的点对点的接口来解决系统集成的需要。随着人们使用系统，他们发现自己需要另一个系统的数据，结果又是一个点对点的集成。图2展示了四种类型的点对点集成：ETL（提取、转换和加载），这是一种数据库间的关系；线上集成和基于文件的集成，两者都是应用间的关系；到数据库的直接连接，这是应用到数据库的关系。这里列举的关系并不完整；还存在更多的关系类型，如复制（replication）、基于消息的关系等等，都没有在图2中表示出来。

最终的结果就是意大利面条式的系统。对一个系统的改动会波及到其他系统，其结果是不可预测的。SOA强调通用的接口和自治性就是为了解决这些问题。

图2：典型的意大利面条式企业系统集成