多源数据整合解决方案
在整合来自多个来源的数据时，互联网上对要考虑的事情的搜索数量胜过对后续数据分析的查询
数据驱动的启示就像真相血清，立即发现需要改变、纠正或消除的每一件小事。这就是为什么当获得这种有价值的定量反馈的方式变成一个沼泽，充满了不同格式和结构的互不关联的数字时，它会如此令人沮丧，使你的业务陷入困境，在你达到本质之前错过数百个机会。毫不奇怪，在整合来自多个来源的数据时，互联网上对要考虑的事情的搜索数量胜过对后续数据分析的查询。然而，由于这个话题很广泛，找到的答案往往倾向于更深入地研究矛盾，并进一步混淆好奇的研究人员。
数据集成的概念
第一个问题因其独创性而令人兴奋：一个人需要了解哪些数据集成才能从一开始就为流程定下正确的基调？
数据集成意味着组合和构建与来自多个来源的数据相关的数据或元数据，目的是以一种使我们能够有效地利用它来解决特定任务和查询的方式聚合信息。
有时没有必要将大量数据从第三方数据源 提取到我们的存储库中。元数据可能只是完美的。我的意思是，我们可以告诉我们的存储库存在某些数据，它的位置，并给出如何处理它的说明。
它真的可以让一切变得不同。例如，我曾经有一个项目，我必须复制 2 PB 的数据，这实际上需要长达四天的时间。这在宇宙的时间轴上并不是什么大问题，但就任何业务而言——一个非常有形的停机时间。
为什么数据集成很重要
在我们进入实践方面之前，我们想问：数据集成是否值得所有的精力和时间？
这里没有必要唠叨，因为答案很明显——数据集成非常重要。大多数情况下，不同任务的数据存储在一个公司内具有不同访问机制的不同存储库中。例如，某些数据很少被访问，因此我们将其保存在专为长期数据存储而设计的数据仓库中。虽然有些数据中毫秒的响应很重要，但显然，我们以不同的访问模式将其保存在存储中。
但事情是这样的：许多业务问题往往会意外出现，需要及时解决。这就是为什么始终拥有触手可及的各种来源的完整数据集如此重要的原因。只有这样，您才能始终全面了解您的业务中正在发生的事情。
了解不同的数据源
说到您提到的数据源，哪些是最常见的？
有了大量的自定义选项，数据源的变体实际上是无穷无尽的。但是，如果我们谈论的是最受欢迎的，我会挑出这三个主要来源：
当您与第三方数据提供商交互时，会出现对数据的 API 访问。
关系数据库是一种使用表以结构化方式组织和存储数据的方法。尽管它们已经被积极使用了大约 40 年，但它们在它们的利基市场中仍然相当不错，并且在动态连接来自不同表的数据方面无与伦比。
对象存储或文件存储库（如 Amazon S3、Google Bucket 或 Azure）基本上是虚拟的无限存储空间，您可以在其中收集具有唯一 ID 的文件，并使用各自的 ID 快速检索/读取它们。从这些存储系统检索数据与从关系数据库检索数据一样普遍。
虽然我们仍在研究这个问题，但出现了另一个问题：企业不会屈服于新趋势并从旧的关系数据库迁移到云吗？
如今，在互联网智慧的指导下，许多企业真正相信云解决方案、NoSQL、大数据等对他们来说将更加有利，并要求进行此类更改，根据我自己的经验，这些更改仅在大约一半的情况下是合理的。
内部和外部数据源
来自不同来源的数据通常分为外部和内部。这种划分有多重要，谁从中受益？
内部可能包括公司的数据仓库、数据湖和日志，而外部示例包括 API、Web 抓取和公共数据集。
该部门更多地与如何组织对数据的访问有关。如果是内部数据，我们可以随时使用它。如果是外部的，我们需要订阅。
对于数据分析师来说，数据的原始来源没有太大意义。无论是来自YouTube还是任何其他来源的数据，分析师通常都以标准化的方式与之交互。
另一方面，负责从YouTube中提取数据的工程师需要了解来源。但问题是，从YouTube视频中抓取数据的过程本身也属于数据集成的概念。
数据集成的关键技术
让我们转到关键要素 — 哪些主要的数据集成技术值得考虑？
假设我们的数据存储在日志中。如果我们想从那里的大量文件中提取有用的信息来计算和分析每天的唯一用户数量怎么办？
我将从效率最低的方法开始 — 解析日志中的所有条目并提取必要的信息。为什么效率低下？每次将来我们遇到类似的任务（例如，计算每个用户会话的平均时间），我们都需要重新做已经完成的工作。
在这种情况下，哪些数据处理方法可以提供帮助？我们有两个主要选择：
ETL（提取，转换，加载），它允许您读取一次原始文件并以我们感兴趣的方式在那里构建数据。例如，在日志的情况下 — 如果我们有文本，我们可以将其划分为列或不同的字段，并且已经以转换的形式，有效地处理每条记录中的特定字段，从而节省大量查询完成时间。
ELT（提取、加载、转换），具有与 ETL 相同的本质，但操作顺序不同。这种数据操作技术刚刚用于我当前的一个项目，并且以这种方式工作：当发生事件时，例如用户注册或课程购买，它会以原始数据的形式发送到特殊的 Amazon RedShift 表（来自 Amazon 的数据存储库）。然后，此原始数据经过特定处理，并保存在准备处理的表中。
哪种方法，ETL 或 ELT，应该是企业的首选？
根据我的经验，我可以说 ETL 更常用于处理数据湖，而 ELT 与数据仓库相关联。但是，这一切都主要归结为您正在使用的技术。
集成来自各种数据源的方案
现在让我们更深入地了解动手过程。企业从一开始就需要考虑什么，以使数据集成尽可能高效？
为了让您更好地了解情况，让我们首先看一个常见但非常不切实际的数据集成方法的示例，该方法最初进展不顺利。
想象一下，一些“N”公司将部分数据存储在关系数据库中，一些存储在基于云的存储中，如Amazon S3，一些存储在通过API访问的远程服务器上。
然后这家“N”公司迎来了它的“X”日：紧急向潜在的知名客户展示过去三年汇总数据的全面审计。
由于该公司不使用任何总是集成来自多个来源的data的通用系统，因此数据工程师编写的代码首先必须从每个来源中提取数据。而且，当然，每个不同的存储都需要不同的代码。
数据最终计算出来，客户满意，大家都很满意。但是几周过去了，一个新的请求进来了：一个新客户端现在需要稍微不同类型的聚合......整个代码工作重新开始。
但是，有一种解决方案可以消除每次重新发明轮子的需要，称为数据目录。
它是一种抽象模式，基本上是一个统一的元数据存储库。它允许标准化整个数据工作流，当然包括数据集成过程。我们在所有数据存储库之上覆盖了一个额外的抽象层，任何开发人员都可以在其中使用熟悉的实体，例如表和数据库。
此外，数据目录还提供了另一大优势 — 能够限制访问权限和使用基于角色的策略。
假设我们选择通过使用数据目录来简化流程。在这种情况下，我们要采取什么步骤？
事实上，数据集成步骤可能会因所使用的特定数据目录而异，但为了避免抽象推理，让我们使用 Amazon Glue 数据目录的示例看看它是如何工作的。
1. 将数据添加到数据目录
如果您使用名为 Glue Crawler 的 Amazon ETL 组件，则只需指定 Amazon S3 存储中文件所在的位置，然后等待它分析数据并在目录中创建条目。结果，您将获得一个包含所有所需数据的数据库和一个表。整个过程只需点击几下。
这是任何数据目录的主要优势之一 — 易于扩展。我们可以轻松地自动将新记录添加到数据目录中，该记录也将立即包含在分析管道中。
特别是Glue Crawler的好处是，它还可以从多个来源读取数据，包括甚至不在Amazon存储中的关系数据库。
最好的部分是，虽然将元数据添加到数据目录中以使其易于使用，但 Amazon S3 存储中的数据保持不变。
2. 分析获得的数据
启动数据目录并在控制台中获取表和数据库列表后，我们可以使用最广泛的工具来分析这些数据。
例如，Amazon Athena 或 Amazon Redshift 是允许您对存储在 Amazon S3 中的数据运行 SQL 查询的工具。这两种工具都需要元数据，而元数据正是存储在 Glue 爬网程序目录中的内容。
集成多源数据时的陷阱
整合来自不同来源的数据仍然是一个相当复杂的过程。可能会出现哪些障碍，我们如何正面应对它们？在这里，我可能有足够的经验来编制一个简短的列表。但有点剧透——所有这些问题都可以轻松解决。
有时我们面临着集成不同数据源的挑战，我们需要使用连接器或 API。然后我们需要研究文档和激活相应功能的方法。可能还需要编写自定义代码才能从多个源获取数据。然而，这里有一个秘密：编写自己的代码是非常罕见的，因为互联网老大哥总是在这里为您提供现成的解决方案和他人的经验。
数据异构性和不同数据格式的另一个挑战是，我们需要进一步处理接收到的数据，以确保其与分析工具和大数据开发服务的兼容性。此类非结构化数据的一个例子可能是YouTube视频。虽然我们最初可能会在列式文件中提取看似结构化的数据，但我们仍然必须将其转换为像 Parquet 这样的格式，这种格式不方便直接的人际交互，但非常适合大数据工具。
有些人仍然偶尔强调与数据质量有关的问题。但正如我在上一篇文章中已经展示的那样，上述 Glue 数据目录提供了非常方便的工具，用于在与数据库和表相同的简单概念中分析数据质量。
在数据量限制的背景下，出现了另一个挑战。如果数据是内部的并且存储在我们的控制范围内，那么问题纯粹受到财务的限制——我们处理的数据越多，我们使用某些工具支付的费用就越多。但是，当我们从多个 外部数据源（例如 API）读取数据时，可能会出现问题。大量请求可能会使第三方 API 过载，导致其无响应或不可用。
企业偶尔也会担心员工中特定专家的稀缺性。但是，根据我在几个项目上的经验，如果我们从一开始就巧妙地构建所有内容并优化数据目录提供的功能的使用，我们就不会过分关注技术。重点将是解决手头的任务，而不是陷入技术方面并寻找专家。