关于数据挖掘的输入数据格式转换等问题请教

来TTNN快一年了,跟我接触BI的时间差不多,后学不才,希望大家多多指教.这几天世界杯,大家肯定熬夜不少,发文也见少了.呵呵,小弟就提个问题,大家来议议吧:)

我所在实验室有一款自己开发的数据挖掘软件XMiner.它的设计理念是基于数据仓库之上提供数据挖 掘功能.为此,XMiner实现了一个简单的数据仓库平台,虽简单却五脏俱全,包括有数据仓库管理,ETL处理,OLAP分析.在数据仓库之上,实现了一个数据挖掘平台,挖掘算法以DLL的形式注册,可以不断扩展. 数据仓库和数据挖掘两个平台都由一个元数据服务程序提 供服务,如访问数据库,执行SQL语句等等.XMiner有一个元数据库,元数据库包括了数据仓库的数据源,主题等信息,ETL处理的转换函数,任务参数等信息,OLAP的CUBE,维度等信息,以及数据挖掘的算法,挖掘任务参数等信息.

总之, XMiner的设计架构包括五个部分(如图1所示,若看不见请看附件)，分别是元数据服务、数据仓库管理、E TL、OLAP以及数据挖掘模块。

在元数据服务的支持和调度下，各部分之间的耦合是相当紧密的。

XMiner最大的特点是扩展了元数据的作用范围，用元数据描述和管理整个系统的数据和环境，不仅包括数据仓库平台中的数据，并且包括数据挖掘工具中的任务模型。这样，元数据居于整个系统的核心地位，统一管理数据仓库和数据挖掘工具，并控制整个数据挖掘流程，包括数据准备、挖掘、表述以及评价，使数据和数据挖掘任务有机地结合在一起；

但一些来实验室访问的国内外专家学者看过我们的演示之后,提了一些意见.比如说,数据挖掘与自己实现的数据仓库平台紧密耦合,那么别人要使用你的数据挖掘功能就必须把数据迁移到你的数据仓库环境.有几个原因是阻碍因素,一是很多情况下,数据迁移代价不菲;二是你的数据仓库过于简单,不能支持大规模的数据量,用户无法使用(老实说,我们的数据仓库部分还只能算实验室产品,不够工业强度).三是听说有些公司如SAS就提供了专门的数据挖掘模块,可以与其它数据仓库结合.

坦白说,听了这些质疑,我心里也有些赞同.XMiner应该可以分成数据仓库与数据挖掘两个独立的系统,想办法实现可扩展,松耦合的接口,这样会更加实用,两个系统的开发也不会互相牵制. 用户可以只使用我们的数据挖掘系统而用其它的数据仓库或其它系统,而不必非要再捆绑使用我们的数据仓库系统.不知道大伙对这个问题有什么高见?

还有一个问题,现在XMiner数据挖掘算法的数据输入是以关系表的结构化数据形式,但问题是每个算法要求的数据输入格式(表的字段,类型,结构等)都是不一样的,要使用一个挖掘算法就要输入该算法要求的数据表格式,若不满足就要针对它要求的数据格式进行转换.

我的问题是:这个数据格式转换工作是挖掘算法来做,还是由用户利用ETL或其它数据预处理程序进行人工参与的转换?

我的一点想法是要由挖掘算法来做,算法不可能对各种各样的表分别有一个对应的转换接口,算法最好把它要求的数据格式用一种形式进行定义,比如XML,每个算法可以有一个数据预处理器,数据预处理器把输入的各种不同格式的表转换成XML格式再进行处理,处理结果为算法要求的数据格式,可以是关系表或文本文件等;若实在不能转换,则提示输入的数据表不能转换.

这样做的原因是关系表对数据的描述能力较低,可以借助XML强大的数据描述能力来规整输入数据. 不知道可行不? 各位的实践经验较为丰富,能否说说其它数据挖掘软件如SAS,SPSS在这个问题上是怎么处理的?

欢迎大家批评指正!

Innovate 20060615

比较有想法,
确实人家提出的问题会致使你们的产品无法商业化.
而且从他们的评价看, 你们的优势是数据挖掘,
不是数据仓库, 所以我觉得还是转于数据挖掘地好.

至于挖掘处理过程, 我也不清楚,
我只是听说SAS需要的是平面的数据,
数据仓库系统只需要为它准备一个大表,
既含有事实表数据, 又含有各个维的信息,
至于后面怎么处理, 我也不清楚了.

ChenMing 20060616

innovate511的建议很好,
把数据挖掘和数据仓库分开做,把注意力集中在数据挖掘上面会有更大的应用面.现在的问题是把XMiner中两者之间的紧耦合关系拆开,对数据挖掘数据输入接口予以规整,不知道XML是不是合适的格式?

另外,不知道现在BI项目中有无数据挖掘部分?占多少?主要使用哪些功能?数据挖掘以后的发展前景如何?

PS:我一个博士师兄在Teradata,做的都是数据仓库项目,数据挖掘的部分很少,有也只是用到决策树分析.刚结束一个大项目,现在挺清闲,他准备换个环境了.

小弟以后也许就在数据挖掘的路上走下去了,不知道这条路以后有多宽,有多长... 有些迷茫啊

Jerome 20060618

说实话，看了你对XMiner的介绍，感觉很模糊，不能确定你们的对自己的定位是什么？是数据挖掘软件产品？是数据挖掘应用产品？还是一套DW/BI解决方案？

如果你们定位数据挖掘软件产品的话，可以参考innovate511的建议，放弃数据仓库，专注于数据挖掘。进一步，对于数据挖掘需要的数据的格式转化和数据挖掘也可以分成两个产品，或者只关注于数据挖掘软件产品。对于数据挖掘软件来说，需要定义自己的数据格式，由另外的人员和工具来进行数据准备，而你们应该更关注于数据挖掘的算法的准确度和效率。

像SAS、SPSS等（其实它们的范围要远大于数据挖掘），他们除了最核心的算法比较强以外还有两个很突出的特点，一个是都支持各种的形式的数据源，另一个是它们提供开发的接口。

同样，如果你们定位为数据挖掘软件产品的话，你们除了在数据挖掘算法外还需要做到两个事情，一个是提供API接口，这个是必须的，最好J2EE的C的都提供，让我们这些做应用的可以方便的将你们的算法嵌入我们的应用中。另一个是提供图形的使用方法，像SAS等可以连接各式的数据源（XML是一定要支持的），这样可以让数据分析人员使用你们的产品进行分析。如果你们更强的话，可以再提供开发工具，提供应用服务器，提供行业解决方案。

如果你们定位为数据挖掘应用的话，需要进入某些行业。仍然需要定义好自己的数据格式，很多国外的分析软件产品公司都是这样做的。在实施时，在国内找合作伙伴，把最麻烦的数据清理和格式转化工作分出去，因为这部分不同的企业有不同的情况，很难做成产品。而实施过程中，他们的产品基本不需开发，只要进行配置就可以使用。

如果你们定位为DW/BI解决方案的话，你们要走的路还很长。

--另外,不知道现在BI项目中有无数据挖掘部分?占多少?主要使用哪些功能?数据挖掘以后的发展前景如何?
目前国内的BI项目中，个人感觉数据挖掘只能算是起步，要走的路还很长。

--小弟以后也许就在数据挖掘的路上走下去了,不知道这条路以后有多宽,有多长...有些迷茫。

关于这个问题，个人觉得数据挖掘是一个不错的方向，和其他大多数方向一样有两种选择，一种是做理论和算法，另一种是做应用。做算法的需要更深的数学功底，建议出国深造；做应用的其实只需要理解数据挖掘常用算法的大致思路和常用参数的含义即可，甚至不懂也能使用，而对行业的理解可能更重要一些。

刘庆 20060619

世界杯是没看的，倒是休了两天假，因此没有发什么文。

对于XMiner的体系结构，我和Innovate和Jerome是同样的感觉，认为不够专注。数据仓库和数据挖掘未来肯定是两个方向，数据仓库讲究的是对数据的管理、处理；数据挖掘讲究是从数据中弄点什么东西出来。甚至，还会更加细分，例如jerome所说的数据挖掘会分成理论和应用这两块。像那种体系结构丰富，啥也不缺的，是大款们玩的玩意儿。例如SAS、MS、BO等，他们的目标是整体解决方案提供商，因此希望将BI相关的，DW、DM、ETL都给包了。可就算是他们，也不会是自己去从头开发，大多也选择并购的方式，将他人成熟的东西纳入自己的体系当中。

所以，XMiner，名字中透着是挖掘，可里面还有Cube之类的东东，真是有些奇怪。而ming提到的在数据接口到算法输入之间，还有个规范化的操作，是否用XML是个不错的形式。我认为这个问题本身并不太恰当。

是否采用XML，的确是一种方式选择。所提到的关系表对数据描述能力弱，我有些不太明白。但猜测是指元数据记录地不丰富吧。其实就是元数据呗，从不固定字段、类型的表到统一的算法数据格式，得有个东西来描述他们的对应关系，这不就是元数据嘛？用关系表怎么就不能表示了呢？使用XML的好处，恐怕是在交换起来方便，从一种数据库，到另一种，另一个地方的数据库，还可以用。

再来说说数据挖掘应用的情况。

现在国内大多项目并没有到分工非常细分的阶段。我现在做的工作是数据挖掘中"应用"这块。对于算法，我是不敢碰的，一来数学底子不太好，看着那些算法头晕；二来，觉得这也不是自己未来方向。故此，很少去关注算法之类的东东。而应用这块，就是位于挖掘模型和市场策略的中间地带。应用的好坏，当然跟模型，跟数据有很大关系，但现在，数据、模型、应用之间的职责并没有划分得十分清楚，因此，自己也经常会关注其他环节，例如数据质量的问题。

那现在有多少项目已经开展数据挖掘工作了呢？我觉得不少，至少在移动、联通领域，已经在进行了吧。客户细分只是一种应用目的不太明确的挖掘模型，其实这两年，做客户流失预警，用挖掘模型的多得很。其他的还有诸如产品关联分析之类的。

显然，目前处于一种非常初级的阶段。从客户、集成商各方，都能够发现一种现象。将数据挖掘看作是一种标志，似乎买了挖掘工具，就得搞出多少模型出来。因此，有些是不敢上数据挖掘，有些是上了数据挖掘以后，啥都想用一个模型来分析。遇到一个问题，大家似乎都不动脑子了，"建一个模型吧。"。其实在我看来，数据挖掘也仅仅是一种数据分析的手段。可平常很多需要"分析"的工作，通过统计、运筹的一些知识，配合人们的人工智能，甚至能够解决的更好。但往往事物在发展的初级阶段就是如此，要不全有，要不全无。

谈到这里，我对jerome将数据挖掘分成理论和应用也有些想法了。搞挖掘，理论是那些算法。而什么算法解决什么类型的业务问题，可以将这个工作称为是"应用"。但如果将这项工作定位成此，似乎还是有些不对劲。因为这还是涉及到上面谈的两种"应用"方式，是从理论、从模型，推出应用？还是从客户的业务问题来设计应用？而后者的应用设计者，其实就不应该只局限于数据挖掘的手段。