数据科学与商业分析：挑战与解决方案

随着越来越多的公司发现数据科学和高级分析对其底线的重要性，文化冲突开始了。 这些快速增长的领域如何才能成为公司生态系统的一部分，尤其是对于已经存在十年或更长时间的成熟公司而言？

在基础架构方面，数据科学家和IT专业人员有着截然不同的需求。 在这里，我将列出其中一些要求，并讨论如何超越这些要求并一起发展。

部门观点

在公司内部启动数据科学计划时，最大的问题通常不是由技术本身引起的，而是由简单的错误沟通引起的。 部门间的误解会导致刚起步的数据科学团队与IT部门之间的纠缠不清。

为了解决这个问题，我们将研究两种观点并考虑他们的每种需求。 我们将从定义IT专业人员维护成功的工作流程所需的条件开始，然后我们将研究数据科学家为获得最大效率所需的条件。 最后，我们将找到共同点：如何使用它来实现健康的基础架构，以使双方都蓬勃发展。

它需要

让我们首先来看一下用于IT和软件开发的典型数据基础结构。

关于数据，任何IT部门都必须关注三个基本前提条件：

• 安全的数据
• 高效的数据
• 一致的数据

因此，许多IT部门都使用基于表的架构，并且经常使用SQL（结构化查询语言）或其变体之一。

此设置意味着有多种用途的表。 这些表中的每个表都是相互独立的，并用外键连接它们。 由于采用了这种设置，因此可以在考虑安全性的前提下快速，高效地执行查询。 这对于软件开发非常重要，在软件开发中，数据需要保持完整和可靠。

通过这种结构，与数据科学的需求相比，所需的硬件通常很少。 存储的数据定义明确，并且以可预测的速度发展。 几乎没有数据重复，查询过程减少了所需的处理资源量。

让我们看看数据科学有何不同。

数据科学需求

另一方面，数据科学具有不同的需求。 数据科学家需要数据自由移动，并且需要灵活地快速修改数据。 他们需要能够以非标准方式移动数据并一次处理大量数据。

使用高度结构化的数据库很难实现这些需求。 数据科学需要不同的基础架构，而是依赖于非结构化数据和无表模式。

当提到非结构化数据时，我们所谈论的是没有内在定义的数据。 直到由数据科学家确定形式之前，这都是模糊的。 对于大多数开发，每个字段都必须是已定义的类型，例如整数或字符串。 但是，对于数据科学而言，它与支持定义不明确的数据点有关。

无表模式为这种准混沌设置增加了更多的通用性，使所有信息都可以放在一个地方。 对于经常需要以创新和非结构化方式合并数据的数据科学家而言，此功能特别有用。 流行的选择包括NoSQL变体或允许多个维度的结构，例如OLAP多维数据集。

结果，数据科学所需的硬件通常更为坚固。 它将需要保留所使用的全部数据以及该数据的子集（尽管通常会分散在多个结构或服务中）。 随着大量数据的移动和聚合，硬件还可能需要大量的处理资源。

提炼需求为行动

考虑到这两组需求，我们现在可以看到错误传达是如何发生的。 让我们采用这些观点，并使用它们来定义我们正在寻找的变更以及如何进行变更。 将数据科学引入传统的IT环境时需要解决哪些问题？

简化数据处理

在传统的IT环境中，任何给定企业的数据库都可能遵循严格的结构，将表划分为适合特定需求的模型，使用适当的架构定义每条数据，并使用外键将它们捆绑在一起。 这使得查询数据的系统高效。 一些数据科学方法的探索性质可以将其推向极限。

当常见任务可能需要连接十二个或更多表时，基于表的结构的好处就不那么明显了。 解决此问题的一种流行方法是实现辅助NoSQL或多维数据库。 此辅助数据库使用常规ETL（提取，转换，加载）来保持其信息的最新性。 这增加了使用额外硬件或云服务的成本，但最大程度地减少了其他缺点。

请记住，在某些情况下，为数据科学添加单独的数据库比使用相同的数据库更经济（尤其是当复杂的许可问题开始发挥作用时）。

简化数据扩展

这个特定的问题涵盖了两个不匹配的问题：

1. 定期增加程序数据
2. 对非结构化数据类型的需求

在传统的IT中，数据库的大小可以很好地定义，既可以保持不变，也可以以适度的速度增长。 当将数据库用于数据科学时，这种增长可能是指数级的。 每天（或更多）添加千兆字节的数据是很常见的。 鉴于此类数据的巨大规模，企业将需要纳入一项计划以扩展内部架构或使用适当的云解决方案。

至于非结构化数据，根据您的特定用途，它可能会占用大量的存储和处理能力资源。 因此，将其全部保留在可能用于其他目的的数据库中通常效率不高。 该解决方案通常类似于缩放。 我们要么需要一个计划来扩展我们的内部架构以满足这些需求，要么我们必须找到一个合适的云解决方案。

资源使用

我们将讨论的最后一个主要区别是资源的使用。 对于IT而言，资源的使用通常是高效的，定义明确且一致的。 如果数据库为电子商务站点提供动力，则存在已知约束。 IT专业人员将大致了解在给定的时间段内将有多少用户，因此他们可以根据每个用户需要多少信息来计划其硬件配置。

使用传统的IT基础结构，如果一个项目仅使用少量表中的几百行，就不会遇到任何问题。 但是，一个需要两打表中的每一行的项目很快就会成为问题。 在数据科学中，处理和存储方面的需求因项目而异，并且这种不可预测性可能难以支持。

在传统的IT中，资源可能会与其他各方共享，这些各方可能是现场生产站点或内部开发团队。 这里的风险是，运行大型数据科学项目可能会在一段时间内将其他用户拒之门外。 另一个风险是拥有数据库的服务器可能无法处理必要的大量处理。 从15个表中调用200,000行，并要求在顶部进行数据聚合成为一个问题。 在服务器通常可以处理大约1000个并发用户的服务器上，如此庞大的查询量可能会非常繁重。

理想的解决方案归结为云处理。 这解决了两个关键因素。 首先是它允许查询性能远离任何重要数据库。 第二个是它提供了可以适合每个项目的扩展资源。

那么两者的最终要求清单是什么？

现在我们已经深入讨论了需求，让我们总结一下。 IT和数据科学部门需要以下条件才能取得长期成功：

• 一个单独的数据库，以减少对其他利益相关者的影响
• 扩展存储解决方案以适应数据变化
• 适应不同项目类型的缩放处理解决方案
• 一个非结构化的数据库，可提供高效的检索和存储高度变化的数据的功能

建立数据科学案例

让我们将所有内容分解为规格，以便我们可以制定出互惠互利的解决方案。 现在，我们来看看如何定义组织所需的特定资源：

研究规格

从IT方面来看，创建必要的基础结构需要三个主要定义。 这些是：

1. 数据量
2. 需要处理到什么程度
3. 数据如何到达存储解决方案

这是确定每个方法的方法。

数据存储需求

这一切都始于所需的初始数据大小和估计的正在进行的数据添加。

为了满足您的初始数据需求，请使用当前数据库的已定义大小。 现在减去在数据科学项目中不需要的任何列或表。 取这个数字并添加您将要介绍的任何新来源的数据大小。 新来源可能包括Google Analytics（分析）数据或来自销售点系统的信息。 这个总数将是我们希望获得的数据存储。

尽管最初的存储需求非常有用，但您仍将不得不考虑持续的数据需求，因为随着时间的流逝，您可能会向数据库中添加更多信息。 要查找此信息，您可以从当前可用数据中计算出每天添加的数据。 查看过去30天内已添加到数据库中的信息量，然后将其除以30。然后对将要使用的每个信息源重复此操作，并将其添加在一起。

尽管这并不精确，但是有一个古老的开发原则，您应该将估计数字加倍，我们将在这里使用它。 为什么？ 我们要考虑可能影响您数据存储需求的不可预测的更改，例如公司增长，每个项目的需求或仅是一般区域。

现在定义了该数字，然后将其乘以365。这就是您预计的一年数据增长，将其与初始数量相加后，将确定您应该获得多少存储空间。

处理资源需求

与数据存储需求不同，要精确计算处理需求要困难得多。 这里的主要目标是确定您是要对查询还是对本地计算机（或云实例）进行繁重的工作。 在此请记住，当我谈论本地计算机时，并不是指您通常使用的计算机，您可能需要某种优化的工作站才能进行更密集的计算。

为了做出选择，这有助于考虑您可能在明年运行的最大的数据科学项目。 您的数据解决方案能否处理该大小的查询，而不会成为所有其他涉众无法访问的查询？ 如果可以，那么您无需任何其他资源就可以了。 如果没有，那么您将需要计划获得适当大小的工作站或扩展云实例。

ETL（提取，转换，加载）过程

在决定存储和处理数据的位置之后，下一个决定就是方法。 创建ETL流程将使您的数据科学数据库保持有序和更新，并防止其使用其他地方的不必要资源。

这是您的ETL文档中应包含的内容：

• 任何应执行的备份程序
• 数据将来自何处以及它将何处去
• 应移动的确切尺寸
• 转移应该多久发生一次
• 传输是否需要完成（重写整个数据库）还是可以累加的（仅转移新内容）

准备解决方案

掌握了所有数据点之后，就该选择解决方案了。 这一部分需要进行一些研究，并且在很大程度上取决于您的特定需求，因为从表面上看，它们往往具有很多相似之处。

三个最大的云解决方案-Amazon Web Services（AWS），Google Cloud Platform（GCP）和Microsoft Azure-提供了一些最优惠的价格和功能。 这三者的成本相对相似，尽管AWS的计算成本明显更高（由于其单点定价结构）。

除价格外，每个都提供可伸缩的数据存储并添加处理实例的能力，尽管每个都以不同的名称调用其“实例”。 在研究将哪些用于自己的基础结构时，请考虑到您将最充分利用哪些类型的项目，因为这可能会改变每个人的定价和功能集的价值。

但是，许多公司只是选择与他们现有技术堆栈相符的方法。

您可能还想在内部建立自己的基础架构，尽管这要复杂得多，而且并非出于胆小。

顺利实施的其他技巧

连续执行所有任务，就可以开始执行了！ 为了提供帮助，这里有一些来之不易的技巧，它们使您的项目从推销到执行都变得更加容易。

测试您的ETL流程

当您首次将ETL流程放在一起时，不要一次全部测试整个过程！ 如果出现错误或需要多次尝试该过程，这可能会给您的资源造成严重压力，并大幅增加云成本。

取而代之的是，最好首先只使用原始表的前100行左右运行您的流程。 然后，请在知道可以使用的情况下运行完整传输。

也测试您的查询

对于在云实例上运行的任何大型查询也是如此。 在系统上犯一个错误，要提取数百万个数据要比仅输入几个错误要困难得多，尤其是在按GB付费时。

创建仓储备份策略

大多数云运营商都将此功能作为功能，因此您不必担心它。 您的团队仍应讨论他们是否愿意创建自己的常规数据备份，或者在需要时重建数据是否更有效。

安全和隐私问题

将客户数据转移到云中时，请确保所有相关人员都知道您公司的数据治理策略，以防止将来出现问题。 这也可以帮助您节省存储在云中的数据量。

ETL期间的尺寸命名

从基于表的数据库到非结构化数据库执行ETL时，请注意命名过程。 如果名称只是批发转让，那么您可能会从不同的表中获得许多共享相同名称的字段。 首先解决此问题的一种简单方法是在非结构化数据库中将新维度命名为{oldtablename}_{columnname} ，然后从那里重命名。

让电动机运转！

现在，您可以计划分析和数据科学基础架构的基础。 在定义了许多关键问题和答案之后，实施和获得管理层支持的过程应该更加顺利。

很难为您自己的公司提供答案？ 我是否掩饰了重要的事情？ 在评论中让我知道！

翻译自: https://code.tutsplus.com/articles/data-science-and-analytics-for-business-challenges-and-solutions--cms-31865