混搭通常出现在时尚杂志上，街头混搭，伴随一些靓女帅锅照片，那是一种用不同风格的衣物服饰搭配起来，扮成“潮人”样子。以前google也推出一个应用，叫g oogle混搭，大致是让你可以用google公开的应用接口，比如web搜索、地图、翻译之类的，建立一种新的应用。曾经有个网站，提供搜索服务，给你一个框 子输入关键字，然后返回不同搜索引擎的结果，分栏显示。这也算是一种混搭。

因此，看起来混搭就是在现成基础上再创造。

BI界最近也吹起混搭风。

在这里，BI混搭强调了可以DIY式地创建自己的BI应用。这是个很好的主意，也许很多决策者不会去DIY，还是乐意用现成的工具，但对于一个高级分析者，也许 他需要构建这样的工具去将决策信息推送给决策者，而他又觉得现有的这些工具们总是有所欠缺，有的在数据管理上擅长，可在展现上很弱，有的在探索上很强，却在流程 控制上很弱...如果能够按照自己所需，将那些工具强强联合，那就好了。这也许就是混搭的效果。

这已经被视为未来的BI趋势，我很认同这点。其实，这多少跟我期望的决策市场有很大关系，当然，也面临同样的难题。

难题是——那些BI工具提供商是否将自己的工具开放了呢？恐怕不是，一般来说，BI工具都是各行其道的，自己的数据整合方式，自己的多维数据存储方式，各自的多 维概念甚至也不一样，对指标的定义也可能不尽相同，模型？也同样有各自的定义标准。想要组合这些工具，总得有个统一的标准吧。比如报表，可以很容易地将BO的报 表嵌入到我的混搭应用中，再从SPSS拉过来一个模型去做收入预测，从经分系统上拉过来一个指标监控仪表盘...但，不行，现在这些产品没法让你这么干。

虽然这些产品有些已经号称是面向服务的架构，但我想更大的问题是，目前并没有一种对分析服务的标准定义，而且让这些工具厂商都认同这些标准。也许在这个时代，大 家都想让自己的标准成为既成事实的标准。好吧，即便是你有标准也好啊，但现在很多产品你是无法脱离工具本身的环境，你没法去将各种小的功能拆分成一个个地使用。 分析服务有很多种，整合的数据、报表、多维分析、分析模型都算。就拿报表来说吧，如果我需要一张市场发展报表，知道在经营分析系统中有，如果能够直接用一个想网 页地址样的URL访问就能得到，那岂不就可以嵌入到另一个系统当中？

再举一个例子，比如现在我要做一个数据探索的工作，可出于安全考虑，无法让我访问数据仓库，SQL写的也不太熟。但数据仓库系统提供了一个接口，通过这个接口， 可以指定一些参数，返回数据集。并且另外还有个数据探索系统，他提供一个插件，这个插件可以根据输入的数据，自动地生成探索报告。于是，我就可以将这两个东西拉 到一起，将前者的输出当作后者的输入，最后得出一份报告。

这个场景看起来简单，细节还是挺复杂，首先你能将每种分析服务的输入输出定义清楚，统一起来。而且，还要考虑安全问题，比如报表这种东西，一个地址返回所有的数 据肯定不现实，还得根据访问者的权限返回限定的指标、数据。

决策市场就是想要定义每种分析服务，他侧重于分析需求的表达，以及分析服务能够满足这种分析需求上，建立一种供需关系的环境。BI混搭，侧重于应用，是相同想法 的另一种表达方法。

其实说起来就是统一数据标准, 开放api调用.  分析师线下做的大量工作之一, 恐怕也是在各种工具的数据格式之间做转换,
将一个工具的结果导入另一个工具中. 若有统一的标准, 即可系统自动化实现.

譬如PMML <http://www.dmg.org/products.html>这个项目, 就是为了让所有的模型一次建模, 多处使用.
这种是IT业界的趋势, 迟早之事.

---------------------------
http://www.4over7.com/

2009/11/6 Q <happys...@gmail.com>

统一的数据访问标准，类似早期提出的com/com+ ，或现在ado.net  通过统一的数据访
问入口，连接异构数据源。当然统一接口层动态调配负载，协调不同数据需求服务。

这个应该在新浪，雅虎 还有google 一大些网站的的“哈杜普”应用 架构有点类似
吧。

Python

MSN: shirly...@163.com

发件人: ttnn@googlegroups.com [mailto:ttnn@googlegroups.com] 代表 eTsir
发送时间: 2009年11月6日 16:51
收件人: ttnn@googlegroups.com
主题: Re: 什么是BI混搭

其实说起来就是统一数据标准, 开放api调用.  分析师线下做的大量工作之一, 恐怕也
是在各种工具的数据格式之间做转换, 将一个工具的结果导入另一个工具中. 若有统一
的标准, 即可系统自动化实现.

譬如PMML <http://www.dmg.org/products.html> 这个项目, 就是为了让所有的模型一
次建模, 多处使用. 这种是IT业界的趋势, 迟早之事.

---------------------------
http://www.4over7.com/

2009/11/6 Q <happys...@gmail.com>

混搭通常出现在时尚杂志上，街头混搭，伴随一些靓女帅锅照片，那是一种用不同风格
的衣物服饰搭配起来，扮成"潮人"样子。以前google也推出一个应用，叫google混搭，
大致是让你可以用google公开的应用接口，比如web搜索、地图、翻译之类的，建立一
种新的应用。曾经有个网站，提供搜索服务，给你一个框子输入关键字，然后返回不同
搜索引擎的结果，分栏显示。这也算是一种混搭。

因此，看起来混搭就是在现成基础上再创造。

BI界最近也吹起混搭风。

在这里，BI混搭强调了可以DIY式地创建自己的BI应用。这是个很好的主意，也许很多
决策者不会去DIY，还是乐意用现成的工具，但对于一个高级分析者，也许他需要构建
这样的工具去将决策信息推送给决策者，而他又觉得现有的这些工具们总是有所欠缺，
有的在数据管理上擅长，可在展现上很弱，有的在探索上很强，却在流程控制上很
弱...如果能够按照自己所需，将那些工具强强联合，那就好了。这也许就是混搭的效
果。

这已经被视为未来的BI趋势，我很认同这点。其实，这多少跟我期望的决策市场有很大
关系，当然，也面临同样的难题。

难题是----那些BI工具提供商是否将自己的工具开放了呢？恐怕不是，一般来说，BI工
具都是各行其道的，自己的数据整合方式，自己的多维数据存储方式，各自的多维概念
甚至也不一样，对指标的定义也可能不尽相同，模型？也同样有各自的定义标准。想要
组合这些工具，总得有个统一的标准吧。比如报表，可以很容易地将BO的报表嵌入到我
的混搭应用中，再从SPSS拉过来一个模型去做收入预测，从经分系统上拉过来一个指标
监控仪表盘...但，不行，现在这些产品没法让你这么干。

虽然这些产品有些已经号称是面向服务的架构，但我想更大的问题是，目前并没有一种
对分析服务的标准定义，而且让这些工具厂商都认同这些标准。也许在这个时代，大家
都想让自己的标准成为既成事实的标准。好吧，即便是你有标准也好啊，但现在很多产
品你是无法脱离工具本身的环境，你没法去将各种小的功能拆分成一个个地使用。分析
服务有很多种，整合的数据、报表、多维分析、分析模型都算。就拿报表来说吧，如果
我需要一张市场发展报表，知道在经营分析系统中有，如果能够直接用一个想网页地址
样的URL访问就能得到，那岂不就可以嵌入到另一个系统当中？

再举一个例子，比如现在我要做一个数据探索的工作，可出于安全考虑，无法让我访问
数据仓库，SQL写的也不太熟。但数据仓库系统提供了一个接口，通过这个接口，可以
指定一些参数，返回数据集。并且另外还有个数据探索系统，他提供一个插件，这个插
件可以根据输入的数据，自动地生成探索报告。于是，我就可以将这两个东西拉到一
起，将前者的输出当作后者的输入，最后得出一份报告。

这个场景看起来简单，细节还是挺复杂，首先你能将每种分析服务的输入输出定义清
楚，统一起来。而且，还要考虑安全问题，比如报表这种东西，一个地址返回所有的数
据肯定不现实，还得根据访问者的权限返回限定的指标、数据。

决策市场就是想要定义每种分析服务，他侧重于分析需求的表达，以及分析服务能够满
足这种分析需求上，建立一种供需关系的环境。BI混搭，侧重于应用，是相同想法的另
一种表达方法。

On 11月6日, 下午5时09分, "python" <pytho...@gmail.com> wrote: