数据挖掘项目实施过程概述.doc
《数据挖掘项目实施过程概述.doc》由会员分享，可在线阅读，更多相关《数据挖掘项目实施过程概述.doc（33页珍藏版）》请在冰点文库上搜索。
数据挖掘项目实施过程概述
二零一一年八月
目录
1. 业务理解 4
1.1 确定业务目标 4
1.1.1 编写业务背景资料 4
1.1.2 定义业务目标 6
1.1.3 业务成功标准 6
1.2 评估情况 7
1.2.1 资源清单 7
1.2.2 要求、假设和约束 8
1.2.3 风险和费用 9
1.2.4 术语 9
1.2.5 成本/收益分析 10
1.3 确定数据挖掘目标 10
1.3.1 数据挖掘目标 11
1.3.2 数据挖掘成功标准 11
1.4 制定工程计划 12
2. 数据理解 12
2.1 收集初始数据 12
2.2 描述数据 14
2.2.1 编写数据说明报告 14
2.3 探索数据 15
2.3.1 编写数据探索报告 15
2.4 验证数据质量 16
2.4.1 编写数据质量报告 16
3. 数据准备 17
3.1 选择数据 18
3.1.1 包括或排除数据 18
3.2 清理数据 19
3.2.1 编写数据清理报告 19
3.3 构建新数据 20
3.4 集成数据 20
3.4.1 格式化数据 21
4. 建模 21
4.1 选择建模技术 22
4.1.1 选择正确的建模技术 22
4.1.2 建模假设 23
4.2 生成测试设计 23
4.2.1 编写测试设计 24
4.2.2 电子商务零售业示例-测试设计 24
4.3 构建模型 24
4.3.1 参数设置 25
4.3.2 运行模型 25
4.4 评估模型 26
4.4.1 综合模型评估 26
4.4.2 跟踪已修正的参数 27
5. 评估 27
5.1 评估结果 28
5.2 审核过程 28
5.3 确定后续步骤 29
6. 部署 30
6.1 制定部署计划 30
6.2 计划监视和维护 31
6.3 生成最终报告 32
6.3.1 准备最终演示 32
6.4 执行最终工程审核 33
1.业务理解
在开始工作之前，需要首先探讨一下我们期望通过数据挖掘获得什么。
尽可能多地一些重要业务人员参与此类讨论，并将结果记录下来。
了解进行数据挖掘的业务原因有助于确保在花费宝贵的资源之前所有人都达成一致意见。
并对期望结论有一致的认识。
1.1确定业务目标
第一个任务是尽可能多地了解数据挖掘的业务目标。
通过详细说明问题、目标和资源，可以将今后的风险降至最低。
包括：
• 开始收集有关当前业务情况的背景信息。
• 记录下由关键决策者决定的具体业务目标。
• 一致同意用于确定从业务角度判定数据挖掘成功与否的标准。
1.1.1编写业务背景资料
理解组织的业务情况有助于了解在以下这些方面需要解决什么问题：
• 可用资源（人力资源和物资）
• 问题
• 目标
将需要对当前商业情况进行一些研究，以便找到对影响数据挖掘项目结果的那些问题的正确答案。
Ø确定组织结构
• 建立组织结构图来说明企业分公司、部门和项目团队的结构。
确保包含管理者的名字和职责。
• 识别组织中的关键个人。
• 识别将提供财务支持和/或领域专门知识的内部负责人。
• 确定是否存在指导委员会并制作一份成员列表。
• 识别将受到数据挖掘项目影响的业务单位。
Ø说明存在问题的领域
• 识别存在问题的领域，例如市场营销、客户服务或业务发展。
• 使用常规术语来描述问题。
• 阐明项目的先决条件。
项目背后的动机。
企业是否已经在使用数据挖掘。
• 检查业务团队内数据挖掘项目的状态。
• 准备有关的组织进行数据挖掘的信息演示文稿。
Ø说明当前的解决方案
• 说明当前用于解决业务问题的所有解决方案。
• 说明当前解决方案的优点和缺点。
此外，指出这个解决方案在组织内的接受程度。
1.1.2定义业务目标
作为的研究和会议的结果，应该拟定一个主要具体目标，并得到项目负责人和受结果影响的其他业务单位的一致同意。
这个目标将最终从模糊的概念，例如“减少客户流失”转变为可以指导进行分析的具体数据挖掘目标。
确定以下内容：
• 需要使用数据挖掘解决的问题。
• 准确地指出所有业务问题。
• 确定其他业务要求。
• 使用业务术语和指标指定如“预期收益率提高”“高价值客户流失减少10%”。
1.1.3业务成功标准
目前的目标可能很清晰，但如何衡量是否已经达到该目标。
在继续推进之前，定义数据挖掘项目的业务成功特征很重要。
成功标准分为两类：
• 客观标准。
这些标准很简单，如审核准确度或商定的流失率减少值具体提高了多少。
• 主观标准。
主观标准（如“发现一组有效解决方案”）比较难于确定，但你们可以商定由谁进行最终决策。
• 尽可能准确地记录此项目的成功标准。
• 确保每个业务目标都有相关的成功标准。
• 调整决定者的主观成功衡量标准使其一致。
如果可能，记录下客户的期望值。
1.2评估情况
有了一个明确指定的目标，下面应该评估处当前的状况。
这一步骤需要获得以下信息，例如：
• 什么类型的数据可供分析；
• 是否具有完成此项目所需的人力资源；
• 所涉及的最大风险因素是什么；
• 对于这些风险，是否具有相应的应急计划；
1.2.1资源清单
获取准确的资源清单是必不可少的步骤。
通过实际查看硬件、数据源和人力资源问题，可以节省很多时间以及避免很多问题。
Ø调查硬件资源
需要哪些硬件资源支持挖掘。
Ø识别数据源和知识存储
• 哪些数据源可用于数据挖掘。
记录数据类型和数据格式。
• 采用什么方式存储数据。
是否可以对数据仓库或操作数据库进行实时访问。
• 是否计划购买外部数据。
• 是否存在任何让无法访问所需数据的安全问题。
Ø识别人力资源
• 是否能找到业务和数据专家。
• 是否确定数据库管理员以及可能会需要的其他技术支持人员。
在阶段报告中应包含一个联系人和资源列表。
1.2.2要求、假设和约束
如果真实地评估了项目的负载情况，获得回报的可能性就更大。
尽可能清楚地阐明这些利害关系，这将有助于预防未来出现问题。
Ø确定要求
最基本的要求就是之前讨论过的业务目标，但需要考虑下面这些问题：
• 对于数据或项目结果，是否存在安全或法律方面的限制。
• 是否所有人都已对项目计划要求达成共识。
• 是否存在任何对结果部署的要求（例如，发布到网上或将得分读取到数据库中）。
Ø说明假设
• 是否存在可能影响项目的经济因素（例如，咨询费或竞争产品）。
• 是否存在对数据质量的假设。
• 工程负责人/管理团队期望采用什么方式查看结果。
换句话说，他们是希望了解模型本身，还是只想看到结果。
Ø验证约束
• 是否具有数据访问所需的所有密码。
• 是否验证过所有对数据使用的法律约束。
• 所有财务约束是否都在工程的预算内。
1.2.3风险和费用
考虑工程进行中可能会遇到的风险是一种明智的做法。
风险的类型包括：
• 计划（如果工程花费的时间比预期时间长怎么办。
）
• 财务（如果工程负责人遇到预算问题怎么办。
）
• 数据（如果数据质量较差或者范围过窄怎么办。
）
• 结果（如果初期结果达不到预期怎么办。
）
当考虑了各种风险之后，制定一个应急计划以帮助避免失败：
• 记录下每种可能遇到的风险。
• 记录每种风险的相应应急计划。
1.2.4术语
为了确保业务和数据挖掘团队“说同一种语言”，应该考虑为技术术语和需要解释的专门用语编写一个词汇表。
例如，如果“流失”对于的业务具有特殊且独特的意思，就值得为了整个团队的利益对其进行明确说明。
同样，团队还会受益于对收益图的使用说明。
Ø任务列表
• 在表中记录术语或团队成员容易混淆的行话。
包括业务和数据挖掘术语。
• 考虑在公司内部网或其他工程文档中发布此列表。
1.2.5成本/收益分析
这一步回答问题，数据挖掘的底线是什么。
作为最终评估的一部分，将工程成本和潜在的成功收益进行比较非常重要。
将下列估计成本包括在的分析中：
• 数据收集和使用的任何外部数据
• 结果部署
• 运营成本
然后，考虑下列收益：
• 要达到的主要目标
• 其他通过数据探索获得的深入见解
• 因深刻理解数据而可能获得的收益
1.3确定数据挖掘目标
已经明确了业务目标，应该将其转换为数据挖掘实体。
例如，“减少流失”的业务目标可以转换为包含下列信息的数据挖掘目标：
• 基于最近的采购数据识别高价值客户
• 使用可用的客户数据构建一个模型，用于预测每个客户的流失可能性
• 基于流失倾向和客户价值为每个客户指定等级
这些数据挖掘目标可以随即被企业用于减少最有价值客户的流失。
业务和技术必须紧密配合才能获得有效的数据挖掘。
1.3.1数据挖掘目标
• 描述数据挖掘问题的类型，如聚类、预测或分类。
• 使用具体的时间单位记录技术目标，例如预测在三个月内有效。
• 如果可能，为所需结果提供实际的数字，例如为80%的现有客户生成流失得分。
1.3.2数据挖掘成功标准
必须使用技术术语来定义成功，以便随时了解数据挖掘工作的进度。
使用之前确定的数据挖掘目标来明确说明成功的基准。
。
• 描述模型评估（例如，准确度、性能等）的方法。
• 定义评估成功的基准。
提供具体的数字。
• 尽可能详细地定义主观衡量标准，并确定成功的决定者。
• 考虑成功部署模型结果是否算是数据挖掘成功的一部分。
立即开始对部署进行计划。
1.4制定工程计划
工程计划是适用于所有数据挖掘工作的主要文档。
如果计划制定得好，它可以为每个工程相关人员提供各个数据挖掘阶段的目标、资源、风险以及计划等信息。
可能希望在公司内部网中发布此计划，同时发布这个阶段收集到的所有文档。
创建计划时，确保已经解决了下面这些问题：
• 是否已经和所涉及的每个人讨论了工程任务和提议的计划。
• 是否所有阶段或任务都包含估计的时间。
• 是否包含了部署结果或业务解决方案所需的工作量和资源。
• 计划中是否突出显示了决策点和审核求。
• 是否已经标记出通常会发生多个迭代的阶段，例如建模阶段。
2.数据理解
数据理解阶段包含深入了解可用于挖掘的数据。
此步骤是在下一个阶段（数据准备）中避免意外问题发生的关键，这个后续阶段通常是工程中耗时最长的部分。
数据理解包含使用工具，通过组织的表格和图形访问数据以及探索数据。
在这一阶段中，可以确定数据的质量并在工程文档中描述这些步骤的结果。
2.1收集初始数据
此时已作好访问数据的准备。
数据来自各种不同的数据源，例如：
• 现有数据。
这包括大量不同的数据，例如交易数据、调查数据、Web日志等。
考虑现有数据是否足以满足的需要。
• 购买的数据。
是否使用补充性数据，如果没有，考虑是否需要使用此类数据。
• 其他数据。
如果上面的数据源并不能满足的需求，可能需要开展调查或开始进行其他跟踪以便补充现有的数据存储。
Ø查看数据然后考虑以下问题。
确保记录下发现的问题。
• 数据库中的哪些属性（列）看起来最有用。
• 哪些属性看起来并不相关，可以排除在外。
• 要想得出概括的结论或者做出准确的预测，现有数据是否足够。
• 所选的建模方法是否存在过多属性。
• 是否要合并不同的数据源。
如果要合并，是否存在合并时会引发问题的区域。
• 是否考虑过如何处理各个数据源中的缺失值。
Ø编写数据收集报告
使用上述步骤中收集的材料，可以开始编写数据收集报告。
一旦完成，可将此报告添加到工程Web站点或向工程团队发布。
它也可以与后续步骤中准备的报告组合在一起，如数据说明、探索和质量验证。
这些报告将在整个数据准备阶段指导的工作。
2.2描述数据
可以采用多种方式对数据进行描述，但是大多数描述都将重点放在数据的数量和质量上，即可提供多少数据以及这些数据的具体情况。
以下列出了描述数据时需要用到的一些关键内容。
• 数据的数量。
对于大多数建模技术，数据大小都具有相关的协定。
大型数据集可以生成更准确的模型，但它们也会增加处理时间。
考虑是否可以使用数据的一个子集。
当为最终报告记录信息时，确保包括所有数据集的大小统计数据量，并且记住在描述数据时考虑记录和字段（属性）的数量。
• 值类型。
数据可以采用多种格式，例如数字、类别（字符串）或布尔值（true/false）。
注意值类型可以防止在后面的建模阶段出现问题。
• 编码方案。
数据库中的值常用于表示特征，如性别或产品类型。
例如，一个数据集可以使用M和F来表示男性和女性，此外也可以使用数字值1和2表示。
注意数据报告中的那些冲突的方案。
2.2.1编写数据说明报告
要有效地推进的数据挖掘工程，考虑使用下列度量标准生成准确数据说明报告的值：
Ø数据数量
• 数据的格式是什么。
• 指定用于捕获数据的方法，例如，ODBC。
• 数据库有多大（使用行数和列数描述）。
Ø数据质量
• 数据是否包含与业务问题相关的特征。
• 所呈现的是什么数据类型（符号、数字等）。
• 是否为关键属性计算了基本统计数据。
这些数据为业务问题提供了哪些深入的见解。
• 是否能够为相关的属性设置优先级。
如果不能，业务分析师是否可以提供进一步的见解。
2.3探索数据
使用工具中的表格、图表和其他可视化工具来探索数据。
此类分析可以帮助解决在业务理解阶段构建的数据挖掘目标。
它们还可以帮助用于设定假设以及制定将在数据准备阶段进行的数据转换任务。
2.3.1编写数据探索报告
当创建图形并对可用数据进行统计时，应该开始设定数据如何才能解决技术和业务目标的假设。
记录发现的问题以便将其包含在数据探索报告中。
确定以下内容：
• 对数据设定了什么类型的假设。
• 哪些属性看起来对于进一步的分析有用。
• 探索是否揭示了新的数据特征。
• 这些探索怎样改变了的初始假设。
• 是否能标识特定的数据子集以供过后使用。
• 再次查看一下的数据挖掘计划。
此次探索是否更改了目标。
2.4验证数据质量
数据几乎没有完美的。
事实上，大多数数据都包含代码错误、缺失值或其他类型的不一致现象。
一种可避免可能出现缺陷的方法是在建模前对可用数据进行全面的质量分析。
• 缺失数据包括空值或编码为无应答的值（例如$null$、?
或999）。
• 数据错误通常是在输入数据时造成的排字错误。
• 度量标准错误包括正确输入但却基于不正确的度量方案的数据。
• 编码不一致通常包含非标准度量单位或不一致的值，例如同时使用M和male表示性别。
• 无效的元数据包含字段的表面意思和字段名称或定义中陈述的意思不匹配。
确保记录下此类质量问题。
2.4.1编写数据质量报告
数据存在多种类型的数据质量问题。
考虑下列质量问题并规划解决方案。
将所有答复记录在数据质量报告中。
• 有没有找到任何缺失属性和空字段。
如果找到了，此类缺失值是否暗含什么意思。
• 是否存在可能会在后面的合并或转换的过程中导致问题的拼写前后不一致的情况。
• 是否探索了偏差值以确定它们是“无效数据”还是值得进一步分析的现象。
• 是否对值执行了真实性检查。
记录下所有明显的冲突（例如青少年具有高收入）。
• 是否考虑过将那些对的假设没有任何影响的数据排除在外。
• 数据是否存储在平面文件中。
如果是，这些文件中的定界符是否一致。
每条记录是否都包含相同数量的字段。
3.数据准备
数据准备是数据挖掘最重要的阶段之一，通常需要花费大量的时间。
据估计，实际的数据准备工作通常占50-70%的工程时间和工作量。
在前期的业务理解和数据理解阶段投入足够的精力可以将对这一阶段的投入降至最低，但仍需花费大量的精力为挖掘准备和打包数据。
取决于的组织及组织目标，数据准备通常包含以下任务：
• 合并数据集和/或记录
• 选择数据子集样本
• 汇总记录
• 导出新的属性
• 排序数据以便建模
• 删除或替换空值或缺失值
• 分为训练数据集和测试数据集
3.1选择数据
基于在前面的阶段执行的初始数据收集，可以开始选择与的数据挖掘目标相关的数据。
通常，有以下两种选择数据的方式：
• 选择项目（行）包含各种决策的制定，例如要包含哪些帐户、产品或客户。
• 选择属性或特征（列）包含有关使用哪些特征的决策制定，如交易金额或家庭收入。
3.1.1包括或排除数据
在决定要包括或排除哪些数据子集的时候，确保记录下做出这些决定的根本原因。
• 某个给定的属性是否与的数据挖掘目标相关。
• 某个特定数据集或属性的质量是否会导致的结果无效。
• 是否能对此类数据进行数据挽救。
• 对于使用某些特定字段，如性别或种族是否存在任何限制。
在此阶段所作的决定是否与在数据理解阶段所作的假设不同。
如果不同，确保在工程报告中记录下的原因。
3.2清理数据
清理数据包括深入了解选择包含在分析中的数据存在的问题。
可以通过记录和字段操作节点来清理数据。
数据问题
可能的解决方案
缺失数据
排除行或特征。
或者，使用估计值填充空值。
数据错误
通过逻辑关系手动发现错误并进行替换。
或者，排除特征。
编码不一致
决定使用其中一种编码方案，然后转换及替换相应的值。
缺失或无效的元数据
手动检测可疑字段并追踪其正确的意思。
在数据理解阶段准备的数据质量报告包含的数据的特定问题类型的详细信息。
3.2.1编写数据清理报告
报告的数据清理成果对于跟踪数据的更改是必不可少的步骤。
轻松掌握工作的详细信息将有助于将来的数据挖掘工程。
编写报告时应对以下问题进行考虑：
• 数据中产生了哪些类型的无用数据。
• 使用什么方法删除这些无用数据。
哪些技术获得了成功。
• 是否存在无法挽救的情况或属性。
确保记录因无用数据而排除的数据。
3.3构建新数据
经常会遇到需要构建新数据的情况。
有以下两种构建新数据的方式：
• 导出属性（列或特征）
• 生成记录（行）
3.4集成数据
同一组业务问题具有多个数据源的情况很多见。
例如，可以访问同一组客户的抵押贷款数据以及购买的人口统计数据。
合并数据的基本方法有以下两种：
• 合并数据，涉及合并两个具有相似记录但不同属性的数据集。
这些数据通过各记录的相同关键标识符（例如客户ID）合并。
生成的数据将会增加一些列或特征。
• 追加数据，涉及集成两个或多个具有相似属性但不同记录的数据集。
数据基于相似字段（例如产品名称或合同时长）集成。
如果没有花费足够的时间开发和理解的数据，集成数据将会变得很复杂。
更多地思考一下那些看上去与数据挖掘目标关系最大的项目和属性，然后开始集成的数据。
• 使用合并或追加，集成那些认为对于建模有用的数据集。
• 考虑在建模之前保存生成的输出。
• 合并之后，可以通过汇总值简化数据。
汇总表示通过总结多条记录和/或表中的信息计算出新值。
• 此外，也可能需要生成一些新记录（例如多年联合退税的平均减免额）。
3.4.1格式化数据
作为建模前的最后一个步骤，检查某些特定技术是否需要数据具有特定格式或顺序很有用。
例如，某种序列算法要求数据在运行模型前预先排序的情况很常见。
即使模型可以执行排序操作，但是在建模前使用排序节点可以节省处理时间。
格式化数据时考虑下列问题：
• 计划使用哪些模型。
• 这些模型是否需要特定的数据格式或顺序。
4.建模
这是的努力工作开始有所回报的阶段。
此时这些结果开始表现在业务理解阶段呈现的业务问题。
建模时通常会执行多次迭代。
通常，数据挖掘人员会使用默认参数运行多个模型，然后再对这些参数进行微调或回到数据准备阶段以便执行所选模型所需的操作。
仅使用一个模型且仅执行一次就能圆满地解答组织的数据挖掘问题，这样的情况几乎不存在。
这就是数据挖掘如此有趣的原因，可以使用多种方法来考虑某个已知的问题。
4.1选择建模技术
尽管可能已经知道哪种类型的建模方式最能满足组织的需要，但现在应该做出有关使用哪些建模方式的正式决定。
通常，将会基于下列因素确定最适用的模型：
• 可用于挖掘的数据类型。
例如，感兴趣的字段是否为分类（符号型）。
• 数据挖掘目标。
是否只想获取有关交易数据存储的深入见解并挖掘出令客户感兴趣的购买模式。
或者是否需要生成一个得分，例如用于表明拖欠学生贷款的倾向。
• 具体的建模要求。
模型是否要求使用特定的数据大小或类型。
是否需要一个具有易于演示的结果的模型。
4.1.1选择正确的建模技术
通常，数据挖掘人员使用多种技术从多个不同方向处理问题。
当决定要使用哪种（些）模型之后，考虑以下的问题是否会影响的选择：
• 此模型是否需要将数据分为测试集和训练集。
• 是否具有足够的数据为给定的模型生成可靠的结果。
• 此模型是否需要特定的数据质量级别。
的当前数据是否达到这一级别。
• 的数据是不是适用于此特定模型的恰当类型（例如适用于GRI的符号输出字段）。
如果不是，是否可以使用数据操控类节点进行必要的转换。
4.1.2建模假设
当开始缩小建模工具的选择范围时，记录下决策制定过程。
记录下所有为了达到模型的要求而设定的数据假设以及为此而执行的数据操作。
例如，Logistic回归和神经网络节点都要求其数据类型在执行前经过完全实例化（数据类型已知）。
这就意味着将需要在流中添加一个类型节点并执行该节点以便在构建和运行模型前全面运行数据。
与之相似，预测模型（例如GRI或C5.0）可以受益于在预测不常发生事件的规则时重新平衡数据。
当进行此类预测时，通过在流中插入一个平衡节点并在模型中增加平衡性更强的子集通常可以获得更好的结果。
4.2生成测试设计
作为实际构建模型之前的最后一个步骤，应该再次考虑要采用什么方式对模型的结果进行测试。
生成一个全面的测试设计操作包含两个部分：
• 描述模型的“优异性”标准
• 定义将要对其测试这些标准的数据
模型的优异性可以通过多种方法度量。
对于监督式模型，例如C5.0、GRI和C&RT，优异性的度量方法通常是估计特定模型的错误率。
对于非监督式模型，例如Kohonen聚类网络，度量方法可以包括易于解释、部署或所需处理时间等标准。
模型构建操作是一个迭代的过程。
这意味着通常需要测试多个模型的结果才能决定使用和部署哪些模型。
4.2.1编写测试设计
测试设计就是将用于测试生成的模型的步骤说明。
因为建模是一个迭代过程，因此知道何时应该停止调整参数以及尝试另一种方法或模型非常重要。
4.2.1.1任务列表
当创建测试设计时，考虑以下问题：
• 将使用什么数据测试模型。
是否已将数据分为训练/测试集。
（这是在建模时常会使用的方法。
）
• 要怎样度量监督式模型是否成功（例如C5.0和GRI）。
• 要如何度量非监督式模型是否成功（例如Kohonen聚类网络）。
• 愿意在尝试另一种模型类型前使用调整的设置重新运行多少次模型。
4.2.2电子商务零售业示例-测试设计
4.3构建模型
大多数数据挖掘人员通常都会在部署或集成模型之前构建多个模型，然后再比较它们的结果。
为了跟踪处理多个模型的过程，确保记录下每个模型所使用的设置和数据。
这可以在与其他人讨论这些结果时提供帮助，并且还可以在需要时重新跟踪的步骤。
在模型构建过程的最后阶段，将获得三类将在数据挖掘决策时使用的信息：
• 参数设置包括记录的生成最佳结果的参数。
• 生成的实际模型。
• 模型结果说明，包括在执行模型并探索其结果时发生的性能和数据问题。
4.3.1参数设置
大多数建模技术都具
升级会员 