我们需要数据湖吗？ 数据仓库要做什么？

本文是我在medium上的文章的翻译- 数据湖入门，结果很受欢迎，可能是因为它的简单性。 因此，我决定用俄语写，并添加一点内容，让一个不是数据专家的普通人清楚什么是数据仓库（DW），什么是数据湖（Data Lake），以及它们是如何实现的。相处起来。

我为什么想写有关数据湖的文章？ 我从事数据和分析工作已经有 10 多年了，现在我肯定在剑桥的 Amazon Alexa AI 从事大数据工作，该公司位于波士顿，尽管我住在温哥华岛的维多利亚，经常访问波士顿、西雅图，在温哥华，有时甚至在莫斯科，我在会议上发言。 我也会时不时写一些东西，不过我主要是用英文写的，而且我已经写过了 一些书，我也有分享北美的分析趋势的需求，有时会写在 电报.

我一直与数据仓库打交道，从 2015 年开始，我开始与 Amazon Web Services 密切合作，并且通常转向云分析（AWS、Azure、GCP）。 自 2007 年以来，我一直在观察分析解决方案的演变，甚至曾在数据仓库供应商 Teradata 工作，并在 Sberbank 实施该解决方案，那时大数据与 Hadoop 就出现了。 大家开始说存储时代已经过去了，现在一切都在Hadoop上，然后他们又开始谈论Data Lake，再次强调，现在数据仓库的终结肯定已经到来了。 但幸运的是（也许对于一些通过 Hadoop 赚了很多钱的人来说是不幸的），数据仓库并没有消失。

在本文中，我们将了解什么是数据湖。 本文面向对数据仓库经验很少或没有经验的人。

图中是布莱德湖，这是我最喜欢的湖泊之一，虽然只去过一次，但我终生难忘。 但我们将讨论另一种类型的湖——数据湖。 也许你们中的许多人已经不止一次听说过这个术语，但多一个定义不会伤害任何人。

首先，以下是数据湖最流行的定义：

“所有类型的原始数据的文件存储可供组织中的任何人分析”- Martin Fowler。

“如果你认为数据集市是一瓶水——经过净化、包装和包装以方便饮用，那么数据湖就是一个自然形式的巨大水库。 用户，我可以为自己收集水、深入潜水、探索”- James Dixon。

现在我们确信数据湖与分析有关，它允许我们以原始形式存储大量数据，并且我们可以对数据进行必要且方便的访问。

我经常喜欢把事情简单化，如果我能用简单的语言解释一个复杂的术语，那么我就能自己理解它是如何工作的以及它的用途。 有一天，我在 iPhone 照片库中闲逛，突然意识到，这是一个真正的数据湖，我什至为会议制作了一张幻灯片：

一切都很简单。 我们用手机拍照，照片保存在手机上，并且可以保存到iCloud（云文件存储）。 手机还收集照片元数据：显示的内容、地理标签、时间。 结果，我们可以使用iPhone的用户友好界面来查找我们的照片，我们甚至可以看到指示符，例如，当我搜索带有“火”一词的照片时，我找到了3张带有火图像的照片。 对我来说，这就像一个商业智能工具，工作非常快速且准确。

当然，我们不能忘记安全性（授权和身份验证），否则我们的数据很容易最终进入公共领域。 有很多关于大公司和初创公司的新闻，他们的数据由于开发人员的疏忽和未能遵循简单的规则而被公开。

即使是这样一个简单的图片也可以帮助我们想象什么是数据湖、它与传统数据仓库的区别及其主要要素：

1. 加载数据中 （摄取）是数据湖的关键组成部分。 数据可以通过两种方式进入数据仓库——批量（间隔加载）和流式（数据流）。
2. 文件存储 （存储）是数据湖的主要组成部分。 我们需要存储能够轻松扩展、极其可靠且成本低廉。 例如，在AWS中它是S3。
3. 目录和搜索 （目录和搜索） - 为了避免数据沼泽（这是当我们将所有数据转储到一堆时，然后就无法使用它），我们需要创建一个元数据层来对数据进行分类以便用户可以轻松找到他们需要分析的数据。 此外，您还可以使用其他搜索解决方案，例如 ElasticSearch。 搜索通过用户友好的界面帮助用户找到所需的数据。
4. 处理 （处理）-此步骤负责处理和转换数据。 我们可以转换数据、改变其结构、清理数据等等。
5. 安全 （安全）- 花时间进行解决方案的安全设计非常重要。 例如，存储、处理和加载过程中的数据加密。 使用身份验证和授权方法很重要。 最后，需要一个审计工具。

从实践的角度来看，我们可以通过三个属性来表征数据湖：

1. 收集并储存任何东西 — 数据湖包含所有数据，包括任何时间段内未处理的原始数据和已处理/清理的数据。
2. 深层扫描 — 数据湖允许用户探索和分析数据。
3. 灵活接入 — 数据湖为不同数据、不同场景提供灵活的接入。

现在我们可以谈谈数据仓库和数据湖之间的区别。 通常人们会问：

• 那么数据仓库呢？
• 我们是用数据湖取代数据仓库还是对其进行扩展？
• 没有数据湖还可以吗？

简而言之，没有明确的答案。 这一切都取决于具体情况、团队的技能和预算。 例如，将数据仓库迁移到 Oracle 到 AWS，并由 Amazon 子公司创建数据湖 - Woot - 我们的数据湖故事：Woot.com 如何在 AWS 上构建无服务器数据湖.

另一方面，供应商 Snowflake 表示您不再需要考虑数据湖，因为他们的数据平台（直到 2020 年它是一个数据仓库）允许您将数据湖和数据仓库结合起来。 我与 Snowflake 的合作不多，它确实是一款可以做到这一点的独特产品。 发行价格是另一回事。

总之，我个人的观点是，我们仍然需要一个数据仓库作为我们报告的主要数据来源，任何不适合的我们都存储在数据湖中。 分析的全部作用是为企业提供轻松的决策途径。 无论人们怎么说，业务用户使用数据仓库比使用数据湖更有效，例如在 Amazon 中 - 有 Redshift（分析数据仓库）和 Redshift Spectrum/Athena（基于 S3 中的数据湖的 SQL 接口）蜂巢/急速）。 这同样适用于其他现代分析数据仓库。

我们来看一个典型的数据仓库架构：

这是一个经典的解决方案。 我们有源系统，使用 ETL/ELT 将数据复制到分析数据仓库并将其连接到商业智能解决方案（我最喜欢的是 Tableau，你的呢？）。

该方案有以下缺点：

• ETL/ELT 操作需要时间和资源。
• 通常，用于在分析数据仓库中存储数据的内存并不便宜（例如 Redshift、BigQuery、Teradata），因为我们需要购买整个集群。
• 业务用户可以访问经过清理且经常聚合的数据，但无法访问原始数据。

当然，这一切都取决于您的情况。 如果您的数据仓库没有问题，那么您根本不需要数据湖。 但是，当出现空间、电力或价格不足等问题时，您可以考虑选择数据湖。 这就是数据湖非常受欢迎的原因。 以下是数据湖架构的示例：

使用数据湖方法，我们将原始数据加载到数据湖（批量或流式），然后根据需要处理数据。 数据湖允许业务用户创建自己的数据转换（ETL/ELT）或分析商业智能解决方案中的数据（如果有必要的驱动程序）。

任何分析解决方案的目标都是为业务用户提供服务。 因此，我们必须始终按照业务要求开展工作。 （在亚马逊，这是原则之一——逆向工作）。

使用数据仓库和数据湖，我们可以比较这两种解决方案：

可以得出的主要结论是，数据仓库并不与数据湖竞争，而是补充。 但这取决于您来决定什么适合您的情况。 亲自尝试并得出正确的结论总是很有趣的。

我还想告诉大家我开始使用数据湖方法时的一个案例。 一切都很琐碎，我尝试使用 ELT 工具（我们有 Matillion ETL）和 Amazon Redshift，我的解决方案有效，但不符合要求。

我需要获取网络日志，对其进行转换并聚合以提供两种情况的数据：

1. 营销团队想要分析 SEO 的机器人活动
2. IT 想要查看网站性能指标

非常简单，非常简单的日志。 这是一个例子：

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

一个文件大小为 1-4 兆字节。

但有一个困难。 我们在全球有 7 个域名，一天内创建了 7000 个文件。 这体积并不算多，只有 50 GB。 但我们的 Redshift 集群的规模也很小（4 个节点）。 以传统方式加载一个文件大约需要一分钟。 也就是说，问题没有得到正面解决。 当我决定使用数据湖方法时就是这种情况。 解决方案看起来像这样：

这非常简单（我想指出的是，在云中工作的优点是简单）。 我用了：

• AWS Elastic Map Reduce (Hadoop) 的计算能力
• AWS S3 作为文件存储，具有加密数据和限制访问的能力
• Spark 作为 InMemory 计算能力，PySpark 用于逻辑和数据转换
• Spark 带来的 Parquet
• AWS Glue Crawler 作为有关新数据和分区的元数据收集器
• Redshift Spectrum 作为现有 Redshift 用户的数据湖 SQL 接口

最小的 EMR+Spark 集群在 30 分钟内处理了整个文件堆栈。 AWS还有其他案例，特别是很多与Alexa相关的案例，其中有大量数据。

最近我了解到数据湖的缺点之一是 GDPR。 问题是，当客户端要求删除它并且数据位于其中一个文件中时，我们无法像数据库中那样使用数据操作语言和 DELETE 操作。

我希望这篇文章能够澄清数据仓库和数据湖之间的区别。 如果您有兴趣，我可以翻译更多我的文章或我读过的专业人士的文章。 并介绍我使用的解决方案及其架构。

来源： habr.com