翻译：张玲 校对：丁南亚
本文约9200字，建议阅读20分钟。
本文打破了关于数据湖的 8 个误解。 误解包括3个方面，并提出了5个技巧来构建可以提供商业价值的灵活数据湖。
本文的目的是构建数据湖并为调整企业数据策略提供背景信息。 这些信息历来是不透明且令人困惑的，咨询公司和提供商提出了相互矛盾的意见。
不幸的是，这种令人困惑和误导的建议导致人们不断询问有关技术平台的背景信息的问题，而不是询问有关战略或业务成果的问题。 这种技术驱动的决策过程试图让主观讨论变得更加客观。 例如，他们问什么是亚马逊数据湖？ 或者什么是最好的数据湖软件。 也许有一家供应商渴望将值得流行的、符合 HIPPA 的数据湖推入医疗保健领域。 因此，对于那些想要澄清数据湖如何实现数据洞察的人来说，这些关于数据湖的讨论更加令人困惑。
亚马逊数据湖
#数据湖
符合 HIPPA 标准的数据湖
打破这些与数据湖策略、架构和实施建议相关的神话将帮助您了解数据湖失败的原因以及它们在实施过程中面临的各种挑战。 它还将有助于阐明供应商和咨询公司提供的建议。 可能违背数据湖最佳实践的原因。
让我们开始一一打破这些误解吧！
误区一：数据湖还是数据仓库，必须二选一
通常建议在数据湖和数据仓库之间进行选择，但这是错误的。
看看现实 - 数据仓库和数据湖之间的区别
这种必须在数据湖和数据仓库之间做出选择的看法错误地限制了讨论的框架。 当人们通过询问数据仓库是否已过时来开始讨论时，似乎是时候放弃企业数据仓库了。 这些问题的出发点是错误的，并且正在引导你误入歧途。
通常，当公司需要对特定设计模式进行某种形式的技术投资时，就会出现这些讨论。 例如，他们声称某些操作可以或必须在数据仓库中发生，然后将这些操作定义为采用数据湖架构的限制和风险。
那么供应商宣传的数据湖架构限制有哪些示例呢？
供应商会说数据湖受到限制，因为无法像数据仓库那样轻松地按需扩展计算资源。 这是事实，但具有误导性。 这就像抱怨汤姆·布雷迪一定是一名糟糕的运动员，因为他在职业橄榄球生涯中从未打出本垒打。 既然汤姆·布雷迪是一名橄榄球运动员，你会期望他成为一名本垒打投手，其投球会越过芬威公园（也称为讨厌杆）的左外野本垒打墙吗？ 不。
讨厌的极点
那么为什么供应商和咨询公司在这里应用数据仓库计算概念呢？
事实上，声称数据湖没有计算资源是一种 FUD 营销策略（灌输对数据湖的负面看法，向你的头脑注入怀疑和恐惧，让你错误地认为除了数据仓库之外别无选择）。 数据湖无法按需扩展计算资源，因为没有计算资源可扩展。
FUD 营销技巧
,_不确定性_和_怀疑
在数据湖架构中，计算资源分离是一个核心抽象，这就是 Redshift Spectrum、Presto 和 Athena 解决方案存在的原因。 以亚马逊的Athena为例。 Athena不是一个数据仓库软件，而是一个基于开源FaceBook Presto开发的按需查询引擎。 它提供“计算”资源来按需查询数据作为服务。 与 Athena 一样，Amazon 的 Redshift Spectrum 可以使用与 Redshift 集群分离的计算资源来查询数据湖中的数据。
红移光谱
#aws-redshift-spectrum
急板
#aws-数据湖
雅典娜
按照设计，Data Lake 中的查询数据服务很好地抽象了这个引擎模型，无论您有 Amazon Data Lake (AWS Data Lake)、Oracle Data Lake、Azure Data Lake 还是 Google Cloud 上的 BigQuery Data Lake，这些模型都是相似的。 数据湖数据内容可以通过Athena等查询引擎或Redshift、BigQuery、Snowflake等“仓库”进行查询。这些服务提供计算资源而不是提供数据湖。
红移
#aws-redshift
大查询
#bigquery
因此，对于大多数企业来说，数据湖和数据仓库如何共存才是正确的讨论，而不是如何选择其中之一。 当有人向您提供两个选项之间的选择时，他们可能是利益相关者，这意味着他们的产品或业务合作伙伴也提供相关功能。
误解2：数据仓库是一个数据湖
这种想法可能会诱使您放弃数据湖并将所有数据放入数据仓库中。
着眼现实——定义有效的数据湖
事实上，有一些供应商和咨询公司提倡将数据仓库作为数据湖模型。
不同的供应商和咨询公司会建议使用模式（或其他物理或逻辑结构）来表示数据仓库中从“原始”到其他状态的数据的生命周期。 任何业务需要的成熟度数据都可以在仓库范围内。 结束。
传统上，数据仓库旨在反映企业已完成的业务。 它还反映了企业完成的一系列一致交易。 例如，完成的交易可能提供有关收入、订单、“最佳客户”和其他领域的重要信息。
然而，在数据仓库“导入所有数据”模型中，数据仓库包含所有数据内容，其中将包括临时且易变的原始数据。
将所有原始数据重新打包到数据仓库中的操作更像是操作数据库（Operational Data Store，ODS）或数据集市的操作，而不是数据仓库的操作。 你能把所有的数据都放到一个数据仓库里吗？ 不能。 仅仅因为你可以在技术上做某事并不意味着它就是正确的架构。
操作数据库
将所有数据放入仓库的建议表明，事务数据只是逻辑组织数据的功能。 那些在企业内部定义和推广这种逻辑定义的人将不会被理解，甚至更糟的是，他们会被忽视，因为这种做法几乎是发生在数据仓库中的“数据沼泽”，尽管教科书上定义数据沼泽发生在数据湖。 对于任何被迫处理后果的人来说，这都是一场数据处理噩梦。
数据处理
#数据牧马人数据整理
该模型将限制您对数据仓库技术及其模型的限制，并且还要求您将所有数据导入到数据仓库中。 如果您喜欢四处寻找供应商、设置人为限制、降低数据意识并承担技术债务erp软件架构图，那么这种方法肯定适合您。
技术债务
如果做得好，数据湖可以最大限度地减少技术债务，同时还可以加速企业团队的数据消耗。 鉴于数据仓库、查询生成和数据分析市场的变化速度不断加快，最大限度地减少风险和技术债务应该成为您战略的核心。
数据湖架构
误解三：数据湖只能用Hadoop来实现
您经常会发现将数据湖与 Hadoop 或 Hadoop 相关供应商技术堆栈等同的讨论和示例，这可能会造成数据湖与 Hadoop 特定技术密切相关的错觉。
看看现实——Hadoop不是数据湖
虽然 Hadoop 技术可用于构建和运营数据湖，但它们并不能反映其支持的数据湖的底层策略和架构。
重要的是要认识到，数据湖首先反映的是策略和架构，而不是技术。 Pentaho 联合创始人兼首席技术官 James Dixon（“数据湖”一词的创造者）表示：
这种情况类似于传统商业智能分析程序的构建方式。 根据最终用户给出的数据问题列表，从数据流中过滤出与问题相关的字段属性，并批量记录在数据集市中。 这种方法一直有效，直到您提出新问题为止。 数据湖可以彻底解决这个问题。 您可以将所有数据存储在数据湖中，填充数据集市和数据仓库以满足传统数据需求，对于新问题erp软件架构图，您可以启用数据湖中的原始数据进行即席查询。 并生成报告。
Hadoop和其他技术一样，可以支持策略和架构的实施。 如果您现在有一个数据湖，那么有许多非 Hadoop 选项，即使它们使用 Hadoop 相关技术。 例如，您的数据湖需要支持 Snowflake 等数据仓库解决方案和 AWS Athena、Presto、Redshift Spectrum 和 BigQuery 等就地查询方法。
AWS 雅典娜
#aws-雅典娜
红移光谱
#红移
不要以为数据湖只能使用Hadoop来实现。 如果您遵循仔细抽象的数据湖架构，则可以根据其他技术的发展和对更广泛的企业生态系统的支持来选择其他技术，从而最大限度地降低风险。
误区四：数据湖仅用于“存储”数据
在这种情况下，数据湖只是存储所有数据的地方。 您只需将所有数据放入数据湖，然后启用新的数据管理模型即可获得成功。 这相当于将所有文件放入笔记本电脑巨大硬盘上的“无标题文件夹”中。
看看现实 - 数据湖不仅仅是存储数据的地方
当供应商将数据湖定义为存储的同义词时，这可能会变得复杂。 例如，Microsoft 将产品打包为 Azure Data Lake Storage 或 Azure Data Lake Storage Gen2。 数据湖确实提供了存储数据的功能，但这只是其特性之一。
如前所述，数据湖应被视为企业更广泛的数据堆栈中的战略要素。 这包括支持数据仓库等下游系统或 Tableau 或 Oracle ETL 等工具中的事务数据集成。 数据处理。
因此，数据湖不仅可以存储数据，还可以兼容数据仓库和数据分析技术栈中的技术。 事实上，大多数数据湖是动态的生态系统，而不是静态的封闭系统。 当数据仓库的负载适中时，数据湖是一个活跃的数据源，不断向其传送数据。 反之亦然，当负载超重时，数据湖对数据进行适当的动态处理，以降低成本、提高效率。
数据湖适当地组织数据，以向使用数据的下游系统（包括数据仓库）提供下游价值。 例如，数据湖在支持数据仓库集成交易数据方面发挥着积极作用。
我们有一个客户使用数据湖对数十个网站和第三方酒店的标签进行质量控制分析，这有助于识别负责工作的不同团队之间可能存在的差异和执行错误。 另一个客户在将数据导入企业数据仓库之前，使用数据湖过滤来自不同部门、第三方和合作伙伴系统的不准确或重复的多渠道订单。
这两个例子都凸显了数据湖在确保下游交易数据的准确性和合规性方面发挥的积极作用。
正如麦肯锡员工所说：“……数据湖不仅保证了技术栈的灵活性，也保证了业务能力的灵活性。” 作为一种服务模型，数据湖是为了交付业务价值，而不仅仅是存储数据。
交付商业价值
误区 5：数据湖仅存储“原始”数据
与误解 2 相关的是，“将所有数据倒入数据仓库”的方法意味着数据湖不会增加价值，因为只有原始数据驻留在数据湖中。 他们主张：“如果数据湖只处理原始数据，那么就无需担心数据湖。所有原始数据或处理后的数据都只能传输到数据仓库。”
着眼现实——定义有效的数据湖策略和架构
数据仓库或SQL查询引擎的典型工作流程
如前所述，这与数据仓库旨在反映已建立的事务数据的基本前提相矛盾。 历史数据更好的比较不是在数据仓库和数据湖之间，而是在ODS和数据湖之间。
从历史数据的角度来看，数据湖是一个ODS，而不是一个数据仓库，因为数据湖从上游获取的是粗糙且不稳定的原始数据。 ODS数据的时间范围通常很窄，可能只包含90天内的数据。 对于特定的数据字段，时间范围可能更窄。 另一方面，数据湖对保留数据没有时间范围限制，因此时间范围更广。
那么，数据湖只是用来存储“原始”数据吗？
不。
根据设计，数据湖应该具有某种程度的数据输入管理（即管理进入数据湖的数据）。 如果您没有管理数据输入模式的意识，那么您的技术堆栈中的其他地方可能会出现问题。 对于数据仓库或任何其他数据系统来说也是如此，垃圾输入，垃圾输出。
数据湖的最佳实践应包括一个具有初始数据池的模型，您可以在其中最小化优化模型以处理数据以进行下游处理或协助处理数据。 数据处理可能发生在 Tableau 或 PowerBi 等分析工具中，也可能发生在将数据加载到数据仓库（如 Snowflake、Redshift 和 BigQuery）的应用程序中。
优化
我们合作的一位客户将 Adobe 事件数据发送到 AWS 以支持企业 Oracle 云环境。 为何从 AWS 转向 Oracle？ 因为这是 Oracle BI 环境中最高效、最具成本效益的数据处理模型，特别是考虑到使用 AWS Data Lake 和 Athena 作为按需查询服务的灵活性和经济性。
Adobe 事件数据发送到 AWS 以支持企业 Oracle 云环境
#oracle-数据湖
通过最大化数据有效性和提高数据处理效率，您可以最大限度地降低下游数据处理器产生的数据处理成本。
误区六：数据湖只适用于“大”数据
如果您花时间阅读数据湖，您可能会认为数据湖只有一种类型，而且它看起来像里海（尽管名称中带有“海”，但它是一个湖）。 数据湖被描述为一个巨大的、包罗万象的实体，旨在保存所有知识，因此企业大数据湖或大数据架构只有一个同义词。
看看现实 - 数据湖有各种形状和大小
不幸的是，“大数据”的观点给人一种错觉，即数据湖只适用于里海大小的数据，这当然使数据湖的概念令人畏惧。 因此，用如此沉重的术语描述数据湖会使那些可以从中受益的人无法访问它们。
另一种观点是，数据湖和大数据只能选其一。 就像自然界的湖泊一样，数据湖也有各种不同的形状和大小。 每种类型的数据湖都有一种自然状态，通常反映数据的生态系统，就像自然界中鱼类、鸟类或其他生物的生态系统一样。
这里有些例子：
根据设计，所有数据湖类型都应采用能够最大限度降低风险并提供更大灵活性的抽象。 此外，它们的结构应该有利于数据处理，而与数据的大小无关。 当数据科学家、业务用户或 Python 代码使用数据湖时，请确保他们拥有一个可以轻松处理数据并可大规模定制的数据环境。
数据湖示例
无论您的用例是机器学习、数据可视化、报告还是将数据交付到数据仓库和数据集市，根据数据的大小和您思考数据的方式，都可以创建使用这些数据湖的新方法。
误解七：数据湖不安全
数据湖是不安全的数据对象集合，组织中任何只想获得帮助并获取所需信息的人都可以使用它。
看看现实 - 安全是一种选择，请务必考虑它
从某种意义上说，人们将依赖隐式安全技术解决方案（即自动AWS S3 AES对象加密），而不构建可以管理安全和下游用例的显式架构。 这可能会导致安全漏洞，但这可以说是许多系统中的漏洞，而不仅仅是数据湖本身的漏洞。 因此，数据湖本质上不安全的想法是不准确的。
安全可以而且应该是我们的首要任务，以下是需要考虑的四个方面：
人们可以争论这些不同策略的优点，但说数据湖本质上不安全是不正确的。
误区 8：数据湖可能变成数据沼泽
曾有文章评论说，数据湖最终会变成数据沼泽，因为它们只是存储，缺乏治理、管理、没有数据生命周期/保留策略、也没有元数据。
着眼于现实——正确选择人员、流程和技术
在极端情况下，这是事实。 如果您将数据湖视为笔记本电脑上的通用“无标题文件夹”，那么它可能会变成数据沼泽（请参阅误解 4），因此存在风险。 然而，对于习惯以这种方式进行文件转储的任何人来说，他们对成功安排人员、流程和技术有点不感兴趣。
那么，什么是真正的数据沼泽？ 真正的数据沼泽是由糟糕的设计造成的，而不是疏忽的管理。
对数据湖的更大威胁不是缺乏治理、管理、生命周期策略和元数据，而是缺乏防止这种情况发生的工具、角色、责任和系统的生态系统。 数据湖之所以成为沼泽，不仅仅是因为“倾倒文件”，还因为数据湖的相关人员、流程和技术安排过于复杂。 如果您认为您的企业数据仓库很慢，那么您的数据湖也会很慢。
简单性、敏捷性和灵活性是数据湖的众多优点中的一部分。 当重要的业务逻辑和流程出现在湖中时，您将面临创建缺乏简单性、无法响应变化、设计过于僵化的解决方案的风险。 这就是您需要警惕的数据沼泽。 数据沼泽成本高昂、耗时，而且无法满足任何人的期望。 这听起来很熟悉吗？
对于那些正在规划或已经部署数据湖的人来说，要小心数据湖的定位和功能蔓延。 尽管技术上复杂的数据处理可以在数据湖中完成，但供应商通常将传统数据仓库和其他 ETL 产品中的特性和功能定义为数据湖功能。
但是，您可能已经拥有在数据湖之外执行这些处理操作的工作流程、工具、人员和技术。 并非所有数据处理都符合您的上游和下游流程。 请仔细考虑数据湖中数据嵌套处理带来的复杂性。 性高潮的风险。
请注意，当前或计划中的数据湖越来越像传统 ETL 工具和数据仓库的组合。 如果您经历过构建企业级数据仓库的过于复杂的任务，那么这一点很容易发现。
数据驱动型企业的数据湖架构和策略
数据湖的发展模式与我们所知的技术的发展模式相同。 新概念出现，然后被先驱者和技术江湖骗子采用。 随着时间的推移，成功的模式就会变得清晰。 这种清晰性来自于通过努力工作（主要是通过失败）吸取的教训。
因此，数据湖技术术语、最佳实践和致力于构建更好平台的投资正在不断改进。 业务实践的经济学、架构方法和优化方法不断变化，使得团队能够以适应应用场景的方式将这些数据湖解决方案集成到企业的数据堆栈中。
不幸的是，这些批评逐渐变成了“数据湖不成功”、“数据湖相当于数据沼泽”、“数据湖与Hadoop等特定技术联系过于紧密”等广为流传的信息。 最后，有人抱怨“什么是数据湖”的定义过于模糊和不稳定。
批评是任何技术发展的重要组成部分。
然而，技术发展的关键是退一步推进，这样做是因为这些批评并不是针对数据湖的。 事实上，这些评论可以针对任何技术，尤其是数据项目。 例如，“数据仓库”一词与数据湖的定义一样模糊且不断变化（参见误解2），并且在Google 中搜索“失败的数据仓库”将会出现有关失败项目的故事。 这是否意味着我们应该放弃“数据仓库”这个词或停止追求这些项目？
不。
通常，鄙视数据湖的咨询公司或企业将他们提供的产品和服务视为万能药，致力于自己的愿景和最佳实践。 如果咨询公司或供应商不相信某个模型，为什么会要求他们参与他们不相信的解决方案？ 将数据湖工作委托给此类咨询公司或供应商可能是数据湖失败的原因。
在我们深入探讨如何构建数据湖或如何与企业一起定制数据湖之前，我们有一些提示可以帮助您进行规划。
如何构建数据湖
#亚马逊数据湖
开始：从小事做起，保持灵活性
到目前为止，我们已经讨论了什么是数据湖或者构建数据湖的步骤是什么的基本问题。 我们还忽略了一个重要的事实：数据湖和数据仓库不仅可以共存，而且可以共同繁荣。
因此，停止购买闪亮的 Hortonworks 数据湖解决方案，并聘请软件开发工程师、客户经理、解决方案架构和支持技术工程师来构建企业数据湖！
从小事做起，保持灵活性。 以下是有关如何运行数据湖实施的一些提示：
将您的解决方案与现代 BI 分析工具（例如 Tableau、Power BI、Amazon Quicksight 或 Looker）集成
作为数据湖的成功早期采用者，您应该关注业务价值方法而不是实施的技术方法，这意味着您不必担心新的 Cloudera Data Lake 产品、如何启动 AWS Lake Formation 工作流程、 Gartner Rubik 立方图，或者 Azure 团队希望您购买的数据湖分析解决方案。
AWS湖组
数据湖专注于业务价值，并为您提供在全面数据分析的背景下构建工作的机会，这将提高您实现数据湖目标和衡量业务绩效的速度。
使用无代码、完全自动化和零管理的 Amazon Redshift Spectrum 或 Amazon Athena Services 开始您的工作。
亚马逊红移频谱
亚马逊雅典娜服务
想讨论数据湖架构或数据湖分析吗？ 请致电我们的数据专家团队。
称呼
原标题：
数据湖？ 关于架构、战略和分析的大神话
原文链接：
译者介绍：张凌，在职数据分析师，计算机硕士毕业。 从事数据工作需要重塑自我的勇气和终身学习的毅力。 但我仍然喜欢它的严谨并痴迷于它的艺术。 数据的海洋一望无际，数据工作充满挑战。 感谢Datapai THU提供了这样一个专业的平台。 希望在这里能和最专业的你们一起进步！
“超过”
