关于数据挖掘工具的讨论

Redyujulia 20060726

由于我刚刚接触数据挖掘领域，想找一个工具来试验一下是否能够运用到实际项目。至今为止，发现SQL Server2005是一个门槛比较低的工具。不知道有多少人在实施数据挖掘的项目，你们都使用什么工具呢？大家能否来讨论一下数据挖掘工具呢。

Redyujulia 20060801

由于项目还处在调研阶段，BI方案是否能解决问题不是完全由技术人员说了算的。所以这个时候SQL Server2005作为试验用途是最好的选择了（正如Qing所说，它是麻雀虽小，五脏俱全）。
就Data Mining这一块，我也分析了几天了。我之前还真没有什么统计学基础，按照例子跑了一遍，发现很多结果匪夷所思。看来这和编程不一样，正确与否没有评判标准的¬。

但是我有个想法，SQL Server2005的Data Mining是否过于简单，虽然使用起来方便，导致分析人员可操作的余地非常小？
使用过其他昂贵的Data

Mining工具（SAS,SPSS...）的同仁能否分享一下，你们在做挖掘时，通常都是怎么做的呢？

有实际例子当然更好了。

Qing 20060801

我没有做过具体的挖掘建模工作，但项目组里面有这样的人。观察他们的工作，基本上有些模式可循。当然，这些模式反映出来应该可以称得上是方法论了，SEMMA、¬CRISP-DM都是。

这些方法论路子都差不多，先理解业务，再理解数据，整理数据，建模，评估。不过功夫还是在细节处。曾经考虑过，是否能够将数据挖掘和后续应用设计的接口隔离开来¬，数据挖掘是一个黑盒子，指定一个输入，得到输出。但这种想法目前还是嫩了点。虽然，可以对挖掘模型指定一个目标值，例如lift要达到3。但事情没怎么简单。

如果仅仅达到lift>3的目标，有很多技巧可以达到目的。就挖掘建模这项工作来说，工作方法可以分成操作员型和分析员型的，看起来就不一样。操作员型的，只要¬达到这个目标就OK，反正就是按照固定的方法。宽表里面整一大堆字段，扔到挖掘工具里面转转，得出结果，然后评估，只要达到3以上，OK，完成任务。具体模型内¬部是怎样的，譬如哪些因素对最终的预测目标是最关键的，不关心。

模型竟然对他成了一种黑盒子。上面提到，将数据挖掘看成当作黑盒子，但还是得有人在黑盒子里面了解其构造，现在倒好，没人再了解其中构造了。

还有一种分析员型的，他们建模会比较积极。在数据探索上花费大量的时间，想确定最合适的输入变量，模型训练完了，看到比较奇怪的结果，还要去查明原因。他们几乎¬是完美主义者。

这里并不想批判某种工作方式，这跟个人的态度有关，我也是非常厌恶那种"员工还是积极的好"的论调，那完全是从管理者角度发出的。当然，如果从协同工作角度，肯¬定还是希望和分析员型的建模人员一起工作。虽然也有问题，总是没完没了地看数据，极尽完美，有时候会受不了的。

不论是操作型或是分析型的挖掘建模，都不简单。反正对我来说，是有些害怕投入精力去了解哪些工具应该怎么去使用，细节的参数应该如何调整。那些东西需要数学统计¬知识，需要经验，甚至是需要业务敏感的。因此，你可以为挖掘模型建立一个度量，衡量其好坏。但建模人员的技能，似乎还是很难去度量的。

所以，那些挖掘建模人员在我心目中就像神一样。

Mr.Somebody 20060801

对把模型当黑盒子的态度不敢苟同.

数据挖掘的目的并不完全在于最终的模型,还在于建模过程中的知识发现.

一个模型如果是没办法合理解释的话它的用处很有限.我只能说敢不了解模型的解释力而直接套用模型的人要么是很有魄力(我不知道他的信心是从哪里来的)要么是没有¬知识.

Happy 20060801

上周刚刚接受了为期三天的SPSS的培训，虽然时间很短，也还是小有收获。

SPSS的数据挖掘方法论是CRISP-DM,包括业务理解、数据理解、数据处理、建模、模型评估、模型发布这个六个步骤。国外很注重方法论的研究，所以对CR¬ISP-DM理论的深入研究对于理解数据挖掘一定很有帮助。

SPSS软件与SAS相比，优点就是很容易上手，三天下来，每个人都可以完成一套完成的挖掘流程，建立所谓的数据模型。为什么说是所谓的数据模型呢？在上述的六¬个步骤中，前三个即业务理解、数据理解、数据处理不需要太多的数理统计分析的知识，只要稍微学一下数据挖掘的课程就能够掌握，像关联规则、聚类分析等算法主要是¬用来帮助我们对于数据的理解，只需要了解算法能干什么就可以。最难的就是模型的建立，首先要理解决策树、神经元网络等等这些算法的含义，不然的话对于这些算法参¬数的调整自然无从下手。其次是对于模型建立的每一个步骤要能够给出合理的解释，包括从业务角度以及数据的角度。不然的话，随便丢一个算法上去，也会生成一个模型¬，但要是无法解释它的过程和结果，模型就没有含义，这就是为什么说它是个所谓的数据模型。

与SAS相比，SPSS非常的易学易用（当然我还没接触太深），拖拖拽拽就完成了一个挖掘的流程。我觉得对于刚刚开始接触数据挖掘的客户和开发商来说，不失为一¬个好的数据挖掘工具。

不过最近发现，最好还是要有数理统计分析的知识，不然越往后越不知人家在说什么。

Redyujulia 20060802

我想请问一下CRISP-DM中，对于其各个过程的是否有比较具体的准则（最好是量化指标）定义来判断该过程允许结束，可以进入下一个阶段呢？如Qing所说的¬Lift>3，我还不明白这是否就是一个"模型评估"的量化指标？看来可以先了解一下CRISP-DM。我个人觉得先从方法论学起，可以了解这些复杂技术、算法¬的根本目标是什么。一头扎进庞大的数据和技术泥潭，非常容易找不到方向。

happy提到算法方面的情况，倒是在MS

BI都能看到，看来是MS

BI还是提供了比较经典的挖掘算法。我还想请教一下，如果发现目标预测数据随时间成周期性变化（比如以周为单位，波动曲线很相似），可以用算法来形成预测模型？¬针对连续数据的决策树算法是否可行呢？

peter yu 20060802

看你用什么方法，决策树自然很好解释 这也是它的优点

像神经网络方面的 无论是ann svm lssvm都不好解释 甚至可以说无法解释 就像你不能解释人的大脑神经是怎样工作的 人的判断是怎样产生的

模型是建出来的 是验证出来的 不是解释出来的 当然合理的解释也是很重要的~~~~~

数据清理才是最难的吧 数据清理应该占到建模的70%左右的工作量

建模的工具反而不是那么重要 如果要求不是特别严格 没必要把神经网络之类的高级算法弄上来

无论从稳定性还是鲁棒性都令人头痛

Qing 20060802

Somebody先生对将模型当作黑盒子不大认同，我理解这个意思。其实我说的意思是指从职责角度，将建模这个活动当作一个黑盒子，有比较明确的输入、输出，这¬是一种理想化的的考虑。

如果挖掘就是一门高深的、艺术化的工作，是只可意会不可言传的，那整个项目成本必然就很高，对负责此项工作人员技能的依赖就非常高。

我相信其实任何事情做成精了，都可以有艺术化的空间。目前这个阶段将要将挖掘应用做好，忽视建模的技术不太现实。

拿我们现在的挖掘模型来说，确实在用，甚至真的就是直接套用模型哦。因为我们有lift>3的说服力嘛，通过数据就可以证明模型的好坏，用这种模型给用户打分，¬输出营销名单等等。这种应用，我们是敢做的。

但有些模型确实是需要业务解释，譬如产品关联分析、客户分群。虽然前者有也有lift，置信度等"客观"指标，但因为需要对每条关联规则给出解释，所以，去跟客¬户说一条看起来似乎毫不相干的规则真的就是有业务意义，就不大自信了。需要更多了解数据和业务，可能是因为前段时间某个特定的营销活动导致了这两个业务相关，或¬是两个业务本身确实有某种潜在依赖关系的。

至于客户分群，更是如此，虽然跟客户吹得天花乱坠，用工具分出若干的群是轻而易举的，将结果解读出来，也非难事。但将分群应用到日常的业务活动中，自信不够。客¬户提出的很多问题，都是比较难以回答。

例如：

为什么要分出10群而不是9群？

为什么要考虑这个变量而没有考虑那个变量？

为什么没有某某群（这个某某群是客户脑海中一种印象，认为应当有的）？

也许回答这些问题并不是太难，只要告诉他，"分群是一种基础性的分析工作，完全从数据出发，应用要提升到一种战略战术层面，不能在执行层面"。就不知道有没有人¬信，当然这就扯到忽悠技巧上去了，不谈这个。

还是来谈谈黑盒子。

术业有专攻，那客户分群举例子。将分群建模当作一个黑盒子，由挖掘专家来负责建模，而业务专家指定输入变量。挖掘专家需要做的只是考虑变量的衍生（一些非业务上¬的衍生），借助建模工具分出符合技术指标的（譬如群间距离、区分度等）的分群结果，输出每个群每个变量的均值，提交给业务专家解读之。

显然，此处对于变量的指定，输出数据的规格是事先由挖掘专家和业务专家约定好的。目前此处我觉得是欠缺的，因此，也就没有办法将挖掘建模当作黑盒子。挖掘专家肯¬定是要充当业务专家的，去理解业务，去选择变量，甚至自己去解读。长期看，这不符合"专攻"路线。

Mr.Somebody 20060804

先对黑盒子谈谈,还是不同意这个观点,连专攻的观点也不同意.业务专家和挖掘专家是必须要紧密合作的,特别是业务理解、数据理解和模型解释.这里有一个知识发现,传递,验证,纠正的互动过程.一个挖掘项目,挖掘者必须要在¬业务人员的帮助下理解业务，在业务人员的帮助下选择变量，在业务人员的帮助下去解读.’由挖掘专家来负责建模，而业务专家指定输入变量’或者是’专攻’的观点则¬去掉了这些互动的过程,这样很容易导致失败.

同意模型是建出来的 是验证出来的 不是解释出来的...

不过在很多重大决策里可不能随便把模型拿到现实里面验证,仅仅凭LIFT>3太不够说服力了.作为挖掘者我必须要把模型解释给客户听,为什么模型效果会好,还要¬解释模型怎么反映市场的变化,客户消费心理的趋势等等.模型本身不是知识,对模型的合理解释和通过模型反映出来的市场/客户的特征才是知识.

Zhu Sizheng 20060807

不太同意黑盒的说法.

对业务专家和挖掘专家是必须紧密合作的.业务专家明白要什么,技术专家明白有什么样的技术可以去满足业务专家的需求.在这样的合作中有一个知识发现,传递,验证,纠正的互动过程.(同意).然而,一个单纯的数据挖掘算法是否能够真正满足业务需求还需要分不同的情况进行讨论,我的整体感觉是单纯的一个挖掘算¬法是不太能够满足业务需求的,挖掘算法间的融合会是一个趋势.那么在这种情况下,对挖掘专家的要求会是什么?

我想对业务的理解应该是对挖掘专家的最急迫的要求吧.在初始阶段,业务专家和挖掘专家必须是相互合作的关系,那么当挖掘专家真正弄清楚了业务的需求,甚至是非常细分的需求之后.那么整个挖掘模型的输入输出对他来说就应该是透明的,而对业务专家而言,这时需要控制的就是验证,控制输出.

模型本身不是知识,对模型的合理解释和通过模型反映出来的市场/客户的特征才是知识.站在业务专家和客户角度而言的确如此,但是站在技术人员的角度,我们在进行¬业务分析之前应该先明白模型本身的功能甚至是模型的整个细节执行过程,对于中间变量的设置.控制应该是技术人员所必须明白的.否则,你怎么对输出做出合理的解释让业务专家去相信你所求出的输出就是他想要的东西?因此,黑盒的与否应该是因人而异,因角色而理解不同吧.

那么这样就牵扯出了我们的定位问题,我们是定位于技术专家还是业务专家?技术人员走业务专家的道路应该比业务专家走技术道路简单,这也是很多技术人员最终脱离程¬序员角色的一条道路....

由此看来业务和技术的融合是已经正在发生的事实,那么是否就意味着专业化分工正在走向弱势?

谈到专业化分工这方面的东西,可能又是另外一个话题了吧.在整个软件产业链还不是清晰的当下

,是否可以借鉴建筑产业链来类比软件产业?建筑产业中规划院,设计院,施工单位,监理单位,甚至到最后的物业都处处刻画了专业化分工的痕迹,那么软件产业呢?我¬感觉到从大的格局来讲,专业化分工恰恰才是软件产业的方向,然而对于个人来讲,是专好还是融合好??
扯远了.

对于CRISP-DM中包括业务理解、数据理解、数据处理、建模、模型评估、模型发布这个六个步骤我个人认为也应该是一个迭带的过程.不过由于没有真正的试验过

,因此不便发表什么言论.

zeus amiao 20060811

本来讨论工具的，大家一下子转到方法论上去了。通病啊，哈哈，就虚。方法论大家都可以谈。每个DM工具还是都有特点的，但SAS是最出色的一个，处理数据的能力¬，分析的能力。但也要考虑的MONEY以及你做事情的需要，再权衡选择。

站在网管的角度看经营分析建设

yang_zxf 20060810

前几天在中国计费网上看到了，一个有关网管系统经营分析系统建设的讨论，但是没有几个人回帖就沉下去了；同时最近也看到移动的经营分析1.5期规范中也把网管系¬统的数据纳入到了正在建设的经营分析中，但也只是给出了网管系统的接口规范，但是如何分析、分析什么没有给出明确的思路和要求。同时也了解了一下一些正在建设移¬动经营分析1.5期的朋友，他们对这块也没有做什么太多的工作，也只是把网管系统有关上报集团的数据进行处理和上报。

但是如果站在网管系统的角度，来看经营分析系统的话，有一下几个问题需要解决：

1、有没有必要建设数据仓库系统？

2、如果有必要，如何建设经营分析系统？

3、建了经营分析系统后，能够给用户提供什么样的应用？

4、如果没有比较建设，那么在网管的数据基础上还能做什么扩展的应用分析？

自己收集了一些有关网管方面的资料，不说建数据仓库了，至少可以做如下的分析：

1、根告警分析，目前网管系统的告警数据量巨大，但是并不是每个告警多需要去处理，有很多告警是因为其他的告警所引起的，解决根告警问题，其他告警就随之消失了¬。

2、投资规划分析，网络设备投资是运营商投资的最大的部分了，如何通过网管数据（BOSS数据），对投资规划提供一定的数据依据，并能够对投资收益进行评估，是¬一个比较大的问题。

3、建立故障经验库，通过故障经验库，网络运维人员可以快速的找到历史故障和告警的解决经验，以加快故障和告警的解决速度。

不知各位的高见，望共同探讨

forward sun 20060810

2001年的时候做过一段时间的网管经分主题设计，可分析的东西有很多

基站使用分析
呼叫分布
连接质量分析
客户群分布

目的就是把网管数据和服务质量、业务使用时间分布、客户群体、地域分布等结合在一起。

总后能形成一个类GIS的系统，直观的看到呼叫、用户的分布和用户的流动情况。
后来因为数据源获取的困难，这个主题域一直就没执行下去。

所以，还是要先确认当前的网管数据能提供什么，然后衍生分析主题

Qing 20060810

没做过网管系统，不熟悉，扯两句泛泛的。

将网管系统的数据纳入经分，到也是大势所趋。毕竟，经分如果仅仅放一些用户啊、帐务、计费等主题，未免还只是像一个数据集市（虽然名字叫数据仓库）。要提升到数¬据仓库的层面，甚至是企业数据仓库的层面，啥数都得丢进去。

非常赞同yang_zxf的思路——看能够在这个主题中做哪些分析。

参与网管、运维的一般有哪些角色？每个角色需要做哪些决策？每种决策需要依赖哪些数据？先明确分析什么，再明确数据。这些问题的回答，可以通过头脑风暴的方式得¬到一个比较完整的答案。

不过做经分规范，恐怕大多不是如此。一般都是先数据，再看能作什么。将现有的网管数据结构拿来参考一下，甚至只是上报的报表结构。形成几个分析主题。这是相对容¬易的做法。当然，是相对。这已经我这两天讨论的"标准化"问题相关了，作规范就是标准化。但够不够格做标准是个问题。

说起这个，我倒是想到前段时间遇到的一件事情。

移动不是搞了个地市数据集市的规范吗？里面规范了一堆分析专题，见过一个研发队伍的成果，介绍的时候，动辄就是"依据规范"，演示每个符合规范的分析专题。我这¬里提到的分析专题，就是那种针对具体营销活动的分析应用。诸如"离网预警"是最古老的一种。
可是，看这个研发成果，看上去似乎是挺符合规范。但从我的角度，因为最近半年一直就作这个，一看就知道那玩意儿根本就没法让人用。且不说规范了，就是现在我们自¬己设计的应用，规定的流程、接口，每个月也是在不断地变。

记得若干年前做联通经分的时候，也是有规范。可能是我们自己没有吃透规范，也是老老实实倚着规范上规定的分析主题（此处的分析主题是指多维分析），按照指定的维¬度、分析指定的度量。同样，市场部也不用，也就是几个用户觉得那个olap工具挺好玩，上下钻取贼过瘾而已。后来想想，真是将这些规范当回事了（当然，现在也可¬能是将规范太不当回事了，呵呵）。

yang_zxf20060810

无论各个专业网管（无线、传输、IP）系统本身能够提供的数据无非以下三类数据：配置数据、性能数据、告警数据，而这些数据并没有和用户的具体呼叫行为情况挂钩¬，仅仅体现的是硬件本身的信息，这些信息也都是从个厂商的专业网管系统（化为、中兴、诺基亚等）采集下来的。如果仅仅站在网管系统，可以做什么分析呢？

当然从计费系统提取的二次批价的详单中也能够体现有个这条话单的交换机、基站、小区信息，而这些信息可以统计各个网络设备（基站、交换机）带来的通话收入是多少¬，至于这些设备的性能数据（负荷、接通率、掉话率等）还是需要从网管系统取得。二者的结合是不是就可以看到这些网络设备利用率和收益情况，为后续的网络扩容、布¬局提供很好的依据。

当然有关客服中涉及到有关网络质量和网络覆盖方面的投诉分析，也是对投资规划很好依据。不知那位做过有关客户投诉的分析，能否具体定位到那个基站所引起的网络质¬量的投诉呢？

如果撇开目前在建的经营分析系统（有信息化部主导的）来说，能否基于网管系统单独建立一个数据仓库系统（有网络部主导的），站在网络的角度看经营情况，大家有何¬见解？