云ETL

[Qing]

将BI当作服务已经越来越成为流行风尚的时候，我们再来看看这其中的一些进展。这个话题里面包括了一些关键词，On-Demand，SaaS，SOA，云计算，web service...这个世界很奇怪。当你觉得这个世界毫无悬念地走向一个方向，但一个看着像是相反方向的东西也同样是潮流。比如未来的pc将会被网络取代，客户端可以不用任何东西。可是adobe出来一个AIR，鼓吹富客户端的web应用，这事儿整的。真是让人看不懂。也许只能用中国古话来形容，合久必分，分久必合。

 

以前介绍过有人将数据仓库当作一种服务，加到云计算体系里。那是vertica跟amazon的故事。但还不止这些，最近有一家开源的数据整合软件，SnapLogic，也跟amazon发生了故事。在后者的云计算框架中，加入了ETL的东西。请看：

http://ttnn.appspot.com/read?i=agR0dG5ucg8LEghOZXdzSXRlbRjcCgw&u=http%3A//news.google.com/news/url%3Fsa%3DT%26ct%3Dus/7-0%26fd%3DR%26url%3Dhttp%3A//www.informationweek.com/blog/main/archives/2008/07/new_data_integr.html%26cid%3D1226491391%26ei%3DZxN0SOadJJvI8ATJ6eWQCQ%26usg%3DAFQjCNGau3uA0iDdsuSCjtRvBDrLg15BRQ

 

为什么都是amazon的故事？

 

可以看到他的路线，显示数据仓库，将一种列式存储的数据库拉进来，接着是etl工具，接着呢？也许会将报表、olap、挖掘的工具拉进去，按照前面他的模式，不大可能是那些很独立比较成熟的工具，而是会选取一些开放性，本身就是基于面向服务架构的工具，如果有人熟悉各种工具的架构的话，可能能够猜到接下去还会有什么样的合作曝光。

 

来看看snaplogic这个工具有什么特别的地方。他提供的功能主要是设计工具、元数据库、引擎，还有一系列跟数据源的读取器。设计工具么，就是那种拖来拖去的，将各个部件组合串联或并联，或先或后的流程可视化管理。元数据库，大多存放源、目标、转换逻辑等规则，应该也是在远程存储的，引擎，也就是实现数据从源到目标的流动，必定也是在云计算基础设施上运行的。数据源读取器，恐怕更多是针对成熟应用数据源，比如oracle的erp、salesforce、apache的log等等。如图是其架构：

这种架构对处理大数据量的情况当然是不太适合，通过http协议来交换数据，还要用xml的格式来组装这些数据。但要注意到目前已经将自己业务系统外包出来的企业来说，他们的数据不会太大。灵活性，开放性是更加重要的。有了这个玩意儿，至少理论上amazon的用户就可以将它们存放在业务系统里面数据噌蹭塞到vertica数据库里面，再来，就可以做数据分析和展现。我想，那些数据源暂时还只能来自托管在amazon那里的应用吧。虽然从架构上，snaplogic基于了一种叫做REST风格的架构，将所有的数据服务当作统一资源标识（URI），但外部的应用恐怕暂不会将自己的数据当作资源发布，但也许这种日子也不远了。

[Qing]

上次谈到SnapLogic的分布式ETL产品时，提到他使用一种叫做REST的风格，有人愿意叫他作为风格，或者叫他做思想，我想这些词都不会给你一个很明确的概念。但只要明白，这不是一种语言，也不是一种具体技术工具。我是第一次看到这个名词，于是找了几篇介绍看看，结果还是似懂非懂。后来看snaplogic的demo，稍微有点感性认识。但在这里之所以说这种技术，还是因为他可能是一种适合于BI的底层技术。据说，他的强项就在于数据服务。

 

他的基本思想，是所有的服务通过统一资源标识（URI），他将所有的服务都当作"资源"看待，通过类似于http://host.com/product/type的形式来访问特定类型的产品数据。当然，这个URI的形式得由应用设计者来规范，道理是如此的。这样看，似乎只是用一种方式可以对数据进行命名而已，但我想这点很重要。在很久以前，我曾经想过应该存在一种"数据块"的东西，他比记录的粒度要粗，而比一个表的粒度要细。比如"某个部门的员工"，这就是一个数据块。它是可以被命名的，因为只有没命名，才容易被管理，被跟踪。这里，URI就是对数据块的命名。

 

为什么叫做REST？从他的全称，叫做表述性状态转移（REpresentaional State Transfer），你能看出什么来么？我没看出什么，只是觉得有些晕。这真是一个很难听且很难理解的名字，虽然简写的名词很酷，休息一会儿。

 

我写这篇文章的目的也算是帮助自己来理解一些这个概念。REST通常是跟web service联系在一起的，显然，他的URI风格非常适合将很多服务、数据分散在不同的主机，而这也跟我们现在的数据状况类似，分散在不同的地方。主要你将自己的数据通过URI暴露出来，就能够被其他人访问，其他人通过REST风格的访问可以对数据进行增加、删除和修改。当然，将数据整合起来，形成一个新的数据资源，也就是数据仓库，当然也是其中一种用途。那将是个开放的世界，所有的资源可以互联互通，遵循一些公共的标准来访问（HTTP）。

 

BI的服务，跟数据密切相干，不论是ETL，还是分析，还是可视化，都需要访问数据。基于这样的架构风格，我们可以将数据当成一种资源存在，一张报表所需要的数据，用一个URI指定，一个趋势图所需数据，由一个URI指定。而可视化的功能被当作一种公共的服务，也同样被某个URI指定。于是，将两者绑定起来，就能实现一张报表，或是进行OLAP分析。但好处是实现了数据、展现的分离，这是基本的面向服务架构的思想，而REST则提供了一种进一步的手段。

 

但对于REST为什么叫做这个名字，我还是百思不得其解。也许还得看看资料，这个名词是2000年的时候，一个叫做Roy Thomas Fielding的大哥整出来的，有一篇创名论文，也被翻译成了中文，大家瞅瞅，http://www.redsaga.com/opendoc/REST_cn.pdf。相信这对学习了解网络时代的应用架构是一份非常好的资料，谁要是细看了，也来分享一下心得吧。

 

2008/7/11 Qing <happ...@gmail.com>:

...从架构上，snaplogic基于了一种叫做REST风格的架构，将所有的数据服务当作统一资源标识（URI）...

[xichen...@gmail.com]

REST是跟web service 和SOA联系起来的，Master Data management又跟SOA有联系。前几才发现原来Master Data management是SAP提出的 而且很久了

在08-7-14，Qing <happ...@gmail.com> 写道：