Azure Data Lake 刚刚全面上市，尤其是 Azure Data Lake Store 的管理似乎令人生畏，尤其是在处理大数据时。在这篇博客中，我将带您了解使用数据湖和大数据的风险和挑战。然后，我将带您了解我们为帮助最好地管理这些风险和挑战而创建的框架。
如果您需要了解什么是数据湖以及如何创建您的第一个 Azure Data Lake Store 和您的第一个 Azure Data Lake Analytics 作业，请随时关注这些链接。
大数据和数据湖的风险和挑战
大数据带来的挑战如下：
- 容量——庞大的数据量是否变得难以管理？
- 多样性——结构化表格？半结构化 JSON？完全非结构化的文本转储？我们通常可以使用仅包含其中一个的系统进行管理，但如果我们要处理一个巨大的混合体，它就会变得非常棘手
- 速度——数据输入的速度有多快？我们需要多快才能将它送到需要它的人手中？
- 准确性——当数据量不同、来源和结构不同以及它们到达湖的速度不同时，我们如何保持准确性和准确性？
- 同时管理所有四个是挑战的开始。
很容易将数据湖视为任何事物的倾倒场。微软的销售宣传正是如此——“存储便宜，存储一切！！”。我们倾向于同意——但如果数据完全不正确、不准确、过时或完全无法理解，那么它根本没有用，并且会让任何试图理解数据的人感到困惑。这实际上将创建一个没有人愿意进入的数据沼泽。糟糕的数据和管理不善的文件削弱了人们对湖泊作为信息来源的信任。倾倒是不好的。
还有数据淹没——因为数据量趋向于海量，而且速度只会随着时间的推移而增加，我们将看到越来越多的信息可以通过湖获得。到了那个时候，如果湖泊管理不善，那么用户将很难找到他们想要的东西。这些数据可能都是完全相关和准确的，但如果用户找不到他们需要的东西，那么湖本身就没有价值。从本质上讲，数据淹没是指数据量如此之大，以至于您无法找到其中的内容。
如果您忽略这些挑战，将湖泊视为垃圾场，您将污染您的湖泊，它将不再适合使用。
如果没有人使用数据湖，那将是一项毫无意义的努力，不值得维护。
每个人都需要共同努力，以确保湖泊保持清洁、管理和有利于数据潜水！
这些是我们在使用 Azure Data Lake 时面临的风险和挑战。但是我们如何管理它呢？
框架
我们把湖分成不同的部分。关键是湖中包含各种不同的数据——一些已经过清理并可供业务用户使用，一些是无法辨认的原始数据，需要在使用之前进行仔细分析。通过确保数据得到仔细管理，您可以立即了解数据的准备程度。
数据从左到右流动——更左边的区域表示直接从源系统输入数据的位置。水平部分描述了准备的级别——手动、流和批处理。
- 手工——又名实验室。这里的数据是使用临时脚本手动准备的。
- 流——这里的数据是半实时的，来自事件中心，并在通过流分析等特定于流的工具进行处理后登陆。一旦登陆，就没有进一步的数据处理——湖本质上是一个批处理工具。
- 批处理——这是更传统的数据处理，许多 BI 开发人员看到的那种“ETL”。我们有一个原始数据的登陆区域，一个过渡区域，在此区域中，数据被清理、验证、丰富和增强，并添加了额外的来源和计算，然后最终被放置在一个可供业务使用的精选区域中。
我们正在使用 Data Lake Store 的空白画布，并在顶部应用文件夹结构、文件管理流程和管理流程。
文件夹结构本身可以任意详细，我们自己遵循一个特定的结构：
原始数据区域是进入湖的任何文件的着陆点，每个数据源都有子文件夹。这允许轻松浏览 Lake 中的数据源，并确保我们不会两次收到相同的数据，即使我们在不同的系统中使用它也是如此。
然而，Enriched 和 Curated 层有特定的用途。我们不会在没有业务驱动的情况下获取数据并对其进行丰富/清理/处理，这不是我们为了好玩而做的事情。因此，我们可以为它分配一个项目或系统名称，此时它被组织到这些终端系统中。这意味着我们可以在 Enriched 中查看与 Curated 中相同的结构。
本质上，原始数据按来源分类，而丰富和策划的数据按目的地分类。
我们创建的框架或我们赋予它的过程没有什么复杂的，但是让每个人都了解它的意图和数据湖的一般用途是非常重要的。如果一个用户在添加数据时没有遵循流程，或者 ETL 开发人员没有清理测试文件，系统就会开始崩溃，我们就会屈服于我们一开始讨论的挑战。
总而言之，Azure Data Lake Store 中的结构是维持秩序的关键：
- 您需要强制执行和维护文件夹结构。
- 请记住，无论是使用非结构化数据还是表和 SQL，结构都是必要的
- 请记住，读取模式应用了临时结构——但如果你不知道你在看什么，这将很难做到！
原文：https://adatis.co.uk/Shaping-The-Lake-Data-Lake-Framework/