英语原文共 7 页，剩余内容已隐藏，支付完成后下载完整资料
使用数据库系统管理大数据分析的工作流程
摘要
在大量工程，工具以及脚本交互的情况下，大数据分析的工作流程冗长而复杂。一般来说，在现代组织中，数据库系统之外存在着大量大数据分析处理过程，这产生了许多关于管理和处理大数据分析工作流程的问题。一般来说，数据预处理是大数据分析工作流程中最耗时的任务。在这项工作中，我们始终保持着数据库系统中预处理，计算模型和评分数据集的想法。此外，我们通过将数据预处理（即数据清理，聚合和列转换）推送到数据库系统中，讨论改进大数据分析工作流程的建议和经验。在转换和准备数据集以改进大数据分析工作流程时，我们将讨论实际问题和常见解决方案。作为案例研究验证，根据现实生活中的大数据分析项目的经验，我们比较了在数据库系统内外运行大数据分析工作流程的优缺点。与外部处理相比，我们强调大数据分析工作流程中的哪些任务在数据库系统处理时更容易管理和更快速。
介绍
在现代组织中，事务处理和数据仓库由数据库系统管理。另一方面，大数据分析项目是一个不同的情节。尽管现有数据挖掘技术以及大多数数据库系统提供的功能，许多统计任务仍在数据库系统之外执行。这是由于复杂的统计工具和库缺乏统计分析师的专业知识来编写正确和高效的SQL查询，数据库系统中的一些有限的统计算法和技术（与统计软件包相比）以及丰富的遗留代码（通常调整良好，难以用不同的语言重写）。在这种情况下，用户利用数据库系统只是通过特殊SQL查询提取数据。一旦导出了大表，它们将根据当前的任务，在数据库系统之外进行汇总和进一步转换。最后，当数据集具有所需的变量（特征）时，计算，解释和调整统计模型。总的来说，预处理用于分析的数据是最耗时的任务，因为它需要清理，加入，聚合和转换文件和表以获得适用于立方体或机器学习的“分析”数据集处理。不幸的是，在这样的环境中操纵数据库系统之外的数据集会创建许多数据管理问题：必须在每次发生变化时重新创建和重新导出数据集，模型需要被导入到数据库系统中，然后被部署，不同的用户可能在自己的计算机中具有相同数据集的不一致版本，安全性受到损害。因此，我们捍卫最好在数据库系统中转换数据集和计算统计模型的论文。我们提供证据，这种方法可以改善大数据分析工作流程的管理和处理。我们认为以数据库系统为中心的大数据分析工作流是大型组织的有前途的处理方法。
在这项工作中所反映的经验，是基于第一作者作为DBMS公司主要的开发人员和顾问参加的分析项目。根据大数据分析项目的经验，我们已经意识到，统计分析师无法编写正确和高效的SQL代码来从数据库系统中提取数据，或者将其数据集转换为手头的大数据分析任务。为了克服这些限制，统计分析师使用大数据分析工具，统计软件，数据挖掘软件包来操纵和转换其数据集。因此，用户最终将创建一个复杂的程序集合，将数据转换和统计建模任务混合在一起。在典型的大数据分析工作流程中，大部分开发（编程）工作用于转换数据集：这是本文研究的主要方面。数据集表示大数据分析工作流程中的核心要素：所有数据转换和建模任务都必须在整个数据集上工作。我们提供完整运行数据库系统内工作流程的保证，改进工作流管理和加速工作流处理。
文章的结构安排如下。 第二部分提供了常见的大数据分析工作流程的规范。 第三部分讨论在数据库系统中准备和转换数据集时的实际问题和解决方案。 我们对比数据库系统内外的工作处理流程。 第四节比较了在数据库系统内处理大数据分析工作流程的优势和时间性能，并利用外部数据挖掘工具进行了外部利用。 这种比较是基于现实生活中数据挖掘项目的经验。 第五节讨论相关工作。 第六节介绍了未来工作的结论和研究问题。
大数据分析工作流程
我们认为大数据分析工作流程中，任务i必须在任务i 1之前完成。 处理顺序大多是从一个任务到另一个任务，但是从任务I循环处理至任务1是可行的，因为数据挖掘是一个迭代过程。 我们区分两个互补的大数据分析工作流程：（1）计算统计模型; （2）基于模型评分数据集。 一般来说，统计模型是在一个新的数据集上进行计算的，而在模型被很好地理解并且已经产生可接受的数据挖掘之后进行评分。
计算模型的典型大数据分析工作流程包括以下主要任务（此基本工作流程可能会因用户的知识和焦点而异）：
1）数据预处理：构建用于分析的数据集（选择记录，非规范化和聚合）
2）探索性分析（描述性统计）
3）计算统计模型
4）调试模型：添加，修改数据集属性，特征/变量选择，列车/测试模型
5）根据所选功能和最佳模型创建评分脚本
这个建模工作流往往是线性的（任务i在任务i 1前面执行 ），但通常它有循环。这是因为建立数据集有很多次迭代，可以分析变量行为和计算模型，并且可以获得可接受的结果。最初工作流的瓶颈是数据预处理。后来，当数据挖掘项目发展时，大多数工作流程处理正在测试和调整所需的模型。一般来说，数据库系统执行一些非规范化和聚合，但是在数据库系统之外执行大多数转换是常见的。当需要添加或修改特征时，需要重新计算查询，返回到任务1.因此，仅在数据库系统内计算工作流的第一个任务的一部分;使用外部数据挖掘工具计算工作流的剩余阶段。
我们考虑的第二个工作流程实际上是部署一个带传达数据的模型。这个任务叫做得分。由于最好的功能和最好的模型是已知的，所以通常在数据库系统中进行处理。评分工作流是线性和非迭代的：处理从任务1开始，任务i在任务i 1之前执行，以最后一个任务作为结束。在评分工作流程中，任务如下：
1）数据预处理：构建数据集进行评分（选择记录，计算最佳特征）。
2）在测试数据集（例如预测类或目标值）上部署模型，将每个记录的模型输出存储为数据库系统中的新表或视图。
3）评估查询并生成与源表连接的评分数据集的摘要报告。 通过将数据追溯回数据库系统中的源表来解释模型。
构建数据集往往是两个工作流程中最重要的任务，因为它需要从许多源表收集数据。 在这项工作中，我们捍卫了在数据库系统中预处理大数据的想法。 只有当原始数据来自数据仓库时，此方法才有意义。 也就是说，我们不解决将外部数据集的处理迁移到数据库系统中的问题。
任务要准备数据集
我们讨论在大数据分析工作流程中改进数据处理阶段的问题和建议。 我们的主要动机是绕过使用外部工具来执行数据预处理，而不是使用SQL语言。
A.处理大数据分析工作流的原因数据库系统之外
一般来说，主要原因是实用的：用户不想翻译现有的外部工具代码。 通常这样的代码已经存在很长一段时间（传统程序），它是广泛的（存在许多程序），并且已被调试和调整。 因此，给予相关风险，用户不愿意用不同的语言重写它。 第二个抱怨是，与复杂的统计软件包相比，一般来说，数据库系统提供了基本的统计功能。 然而，这些差距在多年来一直在缩小。 如前所述，在数据挖掘环境中，大多数用户时间用于准备用于分析目的的数据集。 我们讨论一些最重要的数据库问题，当表被操纵和转换以准备一个数据集进行数据挖掘或统计分析。
B.主要数据预处理任务
我们考虑三个主要任务：
1）选择记录进行分析（过滤）
2）非规范化（包括数学转换）
3）聚合
选择分析记录：行的选择可以在不同的表中的几个阶段完成。这样的过滤是为了丢弃异常值，丢弃具有重要缺失信息内容（包括引用完整性[14]）的记录，以丢弃其对模型的潜在贡献不提供其特征值得分开分析的特征或集合的记录。众所周知，推送选择是加速SPJ（select-projectjoin）查询的基本策略，但并不直接应用于多个查询。我们使用的一个常见解决方案是在一个数据集上执行尽可能多的过滤。这使得代码维护变得更简单，查询优化器能够尽可能地利用过滤谓词。
通常，对于数据挖掘任务，有必要根据日期范围从数据库中的最大表之一中选择一组记录。一般来说，这个选择需要扫描整个表格，这是很慢的。当基于日期存在辅助索引时，选择行更有效，但并不总是可用。基本的问题是这样的事务表比数据库中的其他表大得多。例如，此时间窗口定义了一组具有最近活动的活跃客户或银行帐户。此问题的常见解决方案包括创建物化视图（避免在大型表上重新计算连接重新计算），以及倾斜表与被分析对象（记录，产品等）的主键作为进一步的数据准备任务中的过滤器。
非规范化：一般来说，有必要从许多表收集数据，并将数据元素存储在一个地方。众所周知，在线交易处理（OLTP）数据库系统更新归一化表。规范化使事务处理更快，ACID [4]语义更容易确保。从标准化表中检索一些记录的查询相对较快。另一方面，对数据库的分析恰恰相反：需要大量记录，这些记录从许多表中收集信息。这种处理通常涉及涉及连接和聚合的复杂查询。因此，归一化工作可以有效地构建用于分析目的的数据集。一个解决方案是保留几个关键的非规范化表，从中可以构建专门的表。一般来说，这样的表不能被动态地维护，因为它们涉及具有大表的连接计算。因此，它们定期重新创建为批处理。下面显示的查询构建一个非规范化表，从中可以计算出几个聚合（例如，类似于多维数据集查询）。
为了分析目的，总是最好使用尽可能多的数据。这有很强的理由。统计模型更可靠，当手头有大量数据时，更容易处理丢失的信息，倾斜的分布，发现异常值等。在具有来自与用于分析目的使用的表连接的归一化数据库的表中的大型数据库中，可能涉及与某些表中可能找不到外键的记录的连接。也就是说，自然连接可能会丢弃潜在有用的记录。这个问题的最终效果是结果数据集不包括所有潜在对象（例如记录，产品）。解决方案是定义一个Universe数据集，其中包含从所有表中收集的所有对象，然后使用此表作为基础表来执行外部连接。为了简单而优雅，左外连接是首选。然后在外部连接中传播数据准备中的各处，并保证记录的完整性。通常，这种左外连接在连接条件上具有“星形”形式，其中主表的主键与其他表的主键保持连接，而不是连接它们与链接条件（表T1的FK加入表T2的PK，表T2的FK与T3的PK连接，等等）。下面的查询计算从各个数据集构建的全局数据集。通知数据集可能彼此重叠或不重叠。
聚合：不幸的是，大多数数据挖掘任务需要数据库中不容易获得的维度（变量）。这样的维度通常需要在几个粒度级别进行计算聚合。这是因为统计学习或机器学习技术所需的大多数列需要度量（或度量），它们作为用SQL计算的总和或计数。不幸的是，粒度级别不是分级的（如多维数据集或OLAP [4]）使得使用单独的摘要表（例如，零售数据库中的产品或客户的汇总）。一个简单的优化是在可能的情况下，在同一个语句中使用相同的group-by子句来计算尽可能多的维度。一般来说，对于统计分析师来说，最好创建尽可能多的变量（维度），以便隔离那些可以帮助构建更准确的模型的变量（维度）。那么总结趋向于创建具有数百列的表，这使查询处理速度更慢。然而，大多数最新的统计和机器学习技术被设计为执行可变（特征）选择[7]，[10]，并且这些列中的许多最终被丢弃。
事务表通常具有两个甚至更多的细节级别，在其主键中共享一些列。 典型的例子是商品交易表，其中包含单个商品和商品总数及总金额。 这意味着很多时候，不可能仅从一个表中进行统计分析。 在每个级别可能有独特的信息。 所以这么大
表需要彼此连接，然后根据当前的数据挖掘任务在适当的粒度级别进行聚合。 通常，通过在其公共列上对两个表进行索引来优化这些查询，以便可以使用哈希连接。
结合非规范化和聚合：多个主键：最后一个方面是考虑聚合和非规范化，当有多个主键时，它们在一起进行交互。在一个大型数据库中，不同的表格子集有不同的主键。换句话说，这样的表彼此不兼容以进行进一步的聚合。关键问题是，在某些情况下，必须连接和汇总具有不同主键的大表。加入操作会很慢，因为索引涉及大量基数的外键。两个解决方案是常见的：在最大表的替代主键上创建一个辅助索引，或创建一个具有两个主键的非规范化表，以启用快速连接处理。
例如，考虑一个银行的数据挖掘项目，需要根据客户ID进行分析，但也需要帐号。一个客户可能有多个帐户。帐户可能有多个帐户持有人。鉴于他们的规模，加入和操纵这些表格是具有挑战性的。
C.工作流处理
依赖SQL语句：数据转换脚本是一个长序列的SELECT语句。它们的依赖是复杂的，尽管存在由创建用于分析的临时表和数据集的顺序定义的部分顺序。要调试SQL代码，创建具有多个查询块的单个查询是一个坏主意。换句话说，这样的SQL语句不适合查询优化器，因为它们是分开的，除非它可以跟踪查询的历史使用模式。一个常见的解决方案是创建可由多个语句共享的中间表。这些中间表通常具有以后可以在适当的粒度级别聚合的列。
计算机资源使用：此方面包括磁盘和CPU的使用，第二个是更有价值的资源。这个问题由于大多数数据挖掘任务在整个数据集或其大的子集上工作的事实而变得复杂化。在高峰使用时间运行数据准备任务的活动数据库环境中，可能会降低性能，因为一般来说，读取大型表并创建大型表。因此，有必要使用工作负载管理工具来优化多个用户的查询。一般来说，解决方案是使数据准备任务比交互式用户的查询优先级低。在长期战略中，最好围绕常用数据集组织数据挖掘项目，但鉴于分析的数学性质和数据集中变量（维度）的不断变化的性质，这一目标难以达成。
比较视图和临时表：视图提供对存储和索引的有限控制。创建临时表可能会更好，特别是在汇总中使用了许多主键时。但是，当插入新记录或创建新的变量（维））时，磁盘空间使用率会快速增长，并且需要刷新这些表/视图。
评分：尽管使用统计软件包和数据挖掘工具在数据库系统之外构建了许多模型，但最终必须将该模型应用于数据库系统[6]。当数据量不大时，可以在外部执行模型部署：导出数据集，应用模型和构建报告可以在不到几分钟内完成。然而，随着数据量的增加，数据库系统的导出数据成为瓶颈。当有必要将统计数字与数据库中的原始表相关联时，这个问题与结果解释相结合。因此，通常在外部构建模型，经常基于样本，然后一旦获得可接受的模型，则将其导入到数据
全文共10477字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[142686]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
