英语原文共 7 页，剩余内容已隐藏，支付完成后下载完整资料
文献翻译
通过数据库系统管理大数据分析工作流程
摘要——大数据分析工作流程漫长而复杂，许多程序，工具和脚本交互在一起。通常在现代组织形式中有相当数量的在数据库之外执行大数据分析处理的系统，这会在管理和处理大数据分析工作流程时带来许多问题。大多情况下数据预处理是大数据分析工作流程中最耗时的任务，在这项工作中，我们坚持预处理、计算模型的想法并在数据库系统内对数据集进行评分。此外，我们还讨论有关的建议和经验，通过推进数据预处理（即数据清洁、聚合和列转换）到数据库系统中来改进大数据工作流程。在转换和准备数据集以改进大数据分析工作流程的过程中，我们提出了一个关于现实问题和通用解决方法的讨论作为基于现实生活中的大数据分析项目经验的案例研究，比较了在数据库系统内部和外部运行大数据分析工作流程之间的优点和缺点。突出强调了与外部处理相比，大数据分析工作流中的哪些任务在数据库系统处理时更容易管理，速度更快。
- 引言
在一个由数据库系统管理的现代组织事务处理和数据仓储中，大数据分析项目则是另外一回事。尽管大多数现有的数据库系统提供了数据挖掘功能，但许多统计任务却通常在数据库系统之外执行。这是由于复杂的统计工具和库的存在而统计分析师又缺乏编写正确和有效的SQL查询的专业知识——有限数据库系统中的统计算法和技术（相对于统计包）和遗留代码丰度（一般公调谐并难以在不同的语言来重写）等导致的。在这种情况下，用户利用数据库系统只是通过临时SQL查询来提取数据。导出大表后，根据当前的任务汇总进一步转换大表，但却不在数据库系统中。最后，当数据集具有所需的变量（特征）时，将统计模型进行计算，解释和调整。一般来说，用于分析的预处理数据是最耗时的任务，因为它需要清理，连接，聚合和转换文件、表格以获得适用于立方体或机器学习的“分析”数据集处理。不幸的是，在这样的环境中，在数据库系统之外操纵数据集会产生许多数据管理问题：数据集必须在每次更改时重新创建和重新导出；需要将模型导回到数据库系统，然后部署；不同的用户可能在其自己的计算机中具有相同数据集的不一致版本，则安全性会受到影响。因此，我们坚持这个论点，即在数据库系统内转换数据集和计算统计模型更好。 我们提供的证据表明这种方法改善了大数据分析工作流程的管理和处理。我们认为以数据库系统为中心的大数据分析工作流对于大型组织来说是一种很有前途的处理方法。在这项工作中报告的经验是基于第一作者作为一家主要DBMS公司的开发人员和顾问参与其中的分析项目。根据大数据分析项目的经验，我们已经意识到统计分析师不能编写正确和高效的SQL代码来从数据库系统提取数据，或者为了处理大数据分析任务而转换他们的数据集。 为了克服这些限制，统计分析师使用大数据分析工具，统计软件，数据挖掘软件包来操纵和转换他们的数据集。因此，用户最终创建了一系列将数据转换和统计建模任务混合在一起的复杂程序。在典型的大数据分析工作流程中，大部分开发（编程）工作都花费在转换数据集上——这是本文研究的主要方面，数据集代表了大数据分析工作流程的核心要素：所有数据转换和建模任务都必须适用于整个数据集。我们提供完整的数据库系统内部运行工作流的证据以改进工作流管理并加速工作流处理。文章的结构安排如下：第二部分提供了最常见的大数据分析工作流的规范；第三节讨论了在数据库系统内准备和转换数据集时的实际问题和解决方案，对比了数据库系统内外的处理工作流程；第四部分比较了在数据库系统内部处理大数据分析工作流程以及外部利用外部数据挖掘工具的优势和时间表现，这种比较是基于实际数据挖掘项目的经验；第五部分讨论相关工作； 第六部分介绍未来工作的结论和研究问题。
- 大数据分析工作流程
考虑大数据分析的工作流程，其中任务i必须在任务i 1之前完成。进程大多是从任务到任务的顺序，但是从任务i返回任务1是可行的，因为数据挖掘是迭代过程。
让我们区分一下两个互补的大数据分析工作流程：（1）计算统计模型; （2）基于模型评分数据集。一般而言，统计模型是在新的数据集上计算出来的，而模型是在得到很好的理解并产生了可接受的数据挖掘后才进行的评分。
用于计算模型的典型大数据分析工作流程由以下主要任务组成（该基本工作流程可以根据用户的知识和重点而变化）：
- 数据预处理：构建用于分析的数据集（选择记录，非规范化和聚合）
- 探索性分析（描述性统计，OLAP）
- 计算统计模型
- 调整模型：添加，修改数据集属性，特征/变量选择，训练/测试
- 基于选定特征和最佳模型创建评分脚本
这个建模工作流程通常是线性的（任务i在任务i 1之前执行的任务），但通常有循环。这是因为有很多迭代构建数据集，分析之前的可变行为并计算模型，从而可以获得可接受的结果。最初，工作流的瓶颈是数据预处理。之后当数据挖掘项目演变为大多数工作流时，处理过程就变为了测试和调整所需的模型。大部分情况下数据库系统会执行一些非规范化和聚合，但通常是在数据库系统之外执行大多数转换。当需要添加或修改功能时，需要重新计算查询，返回到任务1。因此只有工作流的第一个任务的一部分在数据库系统内完成计算; 工作流程的剩余阶段计算则是通过外部的数据挖掘工具。
我们考虑的第二个工作流程实际上是部署一个包含到达（新）数据的模型，这项任务被称为评分。由于最好的特征和最好的模型已经知道，所以通常在数据库系统内进行处理。评分工作流程是线性和非迭代的：进程从任务1开始，任务i在任务i 1之前执行，以最后一个任务结束。
在评分工作流程中，任务如下：
- 数据预处理：为评分构建数据集（选择记录，计算最佳特征）。
2）在测试数据集上部署模型（例如预测类别或目标值），将每条记录的模型输出作为新的表格或视图存储在数据库系统中。
3）评估查询并生成关于与源表连接的评分数据集的总结报告。通过将数据追溯回数据库系统中的源表来解释模型。构建数据集往往是两个工作流程中最重要的任务，因为它需要从许多源表中收集数据。
在这项工作中，我们落实了在数据库系统内预处理大数据的想法。但只有当原始数据来源于数据仓库时，这种方法才有意义；也就是说，我们没有解决将外部数据集的处理迁移到数据库系统的问题。
- 编写数据集的任务
我们来讨论改善大数据分析工作流程中数据处理阶段的问题和建议。我们的主要动机是为了绕过使用外部工具进行数据预处理，并且使用SQL语言来代替。
- 在数据库系统外部处理大数据分析工作流的原因
一般来说，主要原因是具有现实背景的：用户不希望翻译现有的外部工具代码。通常这样的代码已经存在了很长时间（传统程序），被广泛的使用（存在很多程序）并且调试和调整。因此，在给定相关风险的情况下，用户不愿意用不同的语言重写它。第二个原因是由于与复杂的统计软件包相比，数据库系统提供了基本的统计功能， 尽管多年来这种差距一直在缩小。 如前所述，在数据挖掘环境中，大多数用户时间花费在了准备用于分析目的的数据集上。我们讨论了当表被操纵并转换为准备数据挖掘和统计分析的数据集的情况等最重要的数据库问题。
- 主要数据预处理任务
我们考虑三大任务：
1）选择记录进行分析（过滤）
2）非规范化（包括数学转换）
3）聚合
选择记录进行分析：在不同的表中选择可以在几个阶段完成的行， 这样的过滤是为了丢弃异常值，丢弃具有重大缺失信息内容（包括参考完整性）的记录，以丢弃对模型的潜在贡献没有提供洞察力或其特征值得单独分析的记录集合的记录。众所周知，推送选择是加速SPJ（select-projectjoin）查询的基本策略，但不适用于多个查询。通常使用的解决方案是在一个数据集上尽可能多地执行过滤。这使得代码维护更容易，并且查询优化器能够尽可能多地利用过滤谓词。通常对于数据挖掘任务，有必要根据日期范围从数据库中最大的一个表中选择一组记录，这个选择需要很慢的在整个表上扫描。当存在基于日期的二级索引时，选择行的效率更高，但并不总是可用。以上的根本问题在于这样的事务处理表比数据库中的其他表大得多。 例如，此时间窗口定义了一组活动客户或具有近期活动的银行账户，此问题的常见解决方案包括创建实体化视图（避免在大型表上进行联合重新计算）和精简表，以及分析对象（记录，产品等）的主键，以充当进一步的数据准备任务中的过滤器。非规范化通常需要从多个表中收集数据并将数据元素存储在一个位置并通过在线事务处理（OLTP）数据库系统更新规范化表；规范化使得事务处理更快，并且ACID语义更容易得到确保，从规范化表中检索几条记录的查询也相对较快。另一方面，对数据库的分析则正好相反：需要大量的记录并且这些记录需要从许多表中收集信息。这种处理通常涉及复杂的涉及连接和聚合的查询。
因此为了分析目的，规范化可以有效地构建数据集。一个解决方案是保留一些可以构建专用表的关键非规范化表。 一般来说，这些表不能动态维护，因为它们涉及大表的连接计算。 因此，需要定期重新创建为批处理过程下面显示的查询构建了一个非规范化的表格，从中可以计算出几个聚合（例如类似于多维数据集查询）：
SELECT
customer_id
,customer_name
,product.product_id
,product_name
,department.department_id
,department_name
FROM sales
JOIN product
ON sales.product_id=product.product_id
JOIN department
ON product.department_id
=department.department_id;
出于分析目的，最好使用尽可能多的数据，这有很多原因——当处理大量数据时，统计模型更加可靠，更容易处理缺失的信息，偏离分布，发现异常值等。在一个大型数据库中，来自规范化数据库的表与来自过去用于分析目的的表连接，可能致使某些表中的外键与无法找到的记录连接。也就是说，自然连接可能会丢失有用的记录。这个问题的最终结果是结果数据集不包含所有潜在对象（例如记录，产品）。解决方案是定义一个无限数据集，其中包含使用所有表的联合收集的所有对象，然后使用此表作为基本表来执行外部联接。为了简单和优雅，首选左外连接 并在数据准备过程中遍历传播，保证记录的完整性。通常这种左外连接在连接条件上具有“星形”形式，其中主表的主键与其他表的主键保持连接，而不是与链接条件连接（表T1的FK为 与表T2的PK连接，表T2的FK与T3的PK连接，等等）。下面的查询计算从单个数据集构建的全局数据集， 通知数据集可能相互重叠也可能不重叠。
SELECT
,record_id
,T1.A1
,T2.A2
..
,Tk.Ak
FROM T_0
LEFT JOIN T1 ON T_0.record_id= T1.record_id
LEFT JOIN T2 ON T_0.record_id= T2.record_id
..
LEFT JOIN Tk ON T_0.record_id= Tk.record_id；
聚合：
大多数数据挖掘任务都不容易从数据库中获得维度（变量）。 这些维度通常需要在多个粒度级别进行计算聚合。这是因为统计或机器学习技术所需的大多数列需要度量（或度量），这些度量或度量用SQL计算得出。 然而粒度级别不是分层的（如多维数据集或OLAP [4]），因此必须使用单独的汇总表（例如，零售数据库中的产品或客户进行汇总）。一个简单的优化就是在可能的情况下在同一个语句中利用相同的分组语句计算尽可能多的维度。 通常对于统计分析师来说，最好尽可能多地创建变量（维度），以便隔离那些可以帮助建立更准确模型的变量。之后汇总往往会创建包含数百个列的表，这会使查询处理变慢。 然而，大多数现有的统计和机器学习技术被设计为执行可变（特征）选择，其中许多列最终被丢弃。从事务表导出维度的典型查询如下：
SELECT
customer_id
,count(*) AS cntItems
,sum(salesAmt) AS totalSales
,sum(case when salesAmtlt;0 then 1 end)
AS cntReturns
FROM sales
GROUP BY customer_id;
交易表通常具有两个或更多级别的细节并且在主键中共享一些列。 典型的例子是商店交易表，其中包含单个项目以及支付的项目总金额和总金额。 这意味着很多时候不可能仅从一个表执行统计分析。每个级别都可能有独特的信息。因此，需要将同样大的651个表彼此连接，然后根据当前的数据挖掘任务，在适当的粒度级别进行聚合。 一般来说，这样的查询通过索引它们公共列上的两个表来优化，以便可以使用散列连接。
结合非规范化和聚合：
多个主键：当存在多个主键时，最后一个方面正在考虑聚集和非规范化相互作用。在大型数据库中，不同的表子集具有不同的主键。 换句话说，这些表格彼此不兼容以执行进一步的聚合。关键问题是，在某些时候，必须对具有不同主键的大表进行连接和汇总。但因为索引涉及大基数的外键，所以加入操作将会很慢。两种解决方案很常见：在最大表的替代主键上创建二级索引，或者创建一个具有两个主键的非规格化表，以启用快速联接处理。
例如，考虑银行中的数据挖掘项目，需要通
全文共6051字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[17409]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
