今日，每秒都在生成 TB 和 PB 的数据，为这些海量数据集寻觅存储处置打算至关关键。复杂的机器和技术如今搜集了令人难以置信的宽泛数据——每天超越 2.5 万亿字节！— 来自设备传感器、日志、用户、消费者和其余中央。数据存储并不像以前看起来那么便捷。在控制和存储数据时，数据控制者须要思考经常使用数据湖或数据仓库作为存储库。
随着数据量、速度和种类的参与，选用适宜的数据平台来控制数据从未像如今这样关键。它应该是迄今为止满足咱们需求的新鲜数据仓库，还是应该是承诺支持任何类型上班负载的任何类型数据的数据湖？
在这里，咱们深化讨论了这两个平台。
数据湖
数据湖是一个中央存储库，可以少量存储一切数据（结构化和非结构化数据）。数据通常以原始格局存储，无需首先启动处置或结构化。在这种状况下，它可以针对手头的目的启动优化和处置，无论是交互式剖析、下游机器学习或剖析运行程序的仪表板。
可以这样想，数据湖就像一个大水体，比如说一个处于人造形态的湖。数据湖是经常使用来自各种起源的数据流创立的，而后，多个用户可以到来湖中对其启动审核并取样。数据湖的美妙之处在于每团体都在检查和操作相反的数据。消弭多个数据源并在数据湖中领有一个可援用的“黄金”数据集来保证组织内的分歧性，由于用于访问组织中智能的任何其余下游存储库或技术都将同步。这很关键。经常使用这种集中的数据源，就不会从不同的孤岛中提取数据；组织中的每团体都有一个繁多的理想起源。
该形式为公司的剖析生命周期提供了近乎有限的才干：
摄取： 数据以任何原始格局抵达并存储以供未来剖析或劫难复原。公司通常会依据隐衷、消费访问以及将应用传入消息的团队来划分多个数据湖。
存储： 数据湖准许企业控制和组织简直有限量的消息。云对象存储以较低的老本为大数据计算提供高可用性访问。
流程： 借助云计算，基础设备如今只有一个 API 调用即可。这是从数据湖中的原始形态失掉数据并格局化以与其余消息一同经常使用的时刻。这些数据也经常经常使用初级算法启动聚合、兼并或剖析。而后将数据推回数据湖以供商业智能或其余运行程序存储和进一步经常使用。
消费： 当咱们议论自助服务数据湖时，消费通常是生命周期中的阶段。此时，数据可供业务和客户依据须要启动剖析。依据复杂用例的类型，最终用户还可以直接或直接以预测（预测天气、财务、静止体现等）或感知剖析（介绍引擎、欺诈检测、基因组测序、 ETC）。
数据湖支持原生流，数据流在其中被处置并在抵达时可用于剖析。数据管道在从数据流接纳数据时转换数据，并触发剖析所需的计算。数据湖的原生流式传输个性使其十分适宜流式剖析。
数据仓库
数据仓库架构依赖于数据结构来支持高性能的 SQL（结构化查问言语）操作。数据仓库是专门为基于 SQL 的访问而构建和优化的，以支持商业智能，但为流剖析和机器学习提供有限的配置。它们遭到 ETL 要求的限度，须要在存储数据之前对其启动预处置。
数据仓库在数据用于剖析之前须要顺序 ETL摄取和转换数据，因此它们关于流式剖析效率低下。一些数据仓库支持“微批处置”以经常以小增量搜集数据。它支持顺序 ETL 操作，其中数据以瀑布模型从原始数据格局流向齐全转换的汇合，并针对极速性能启动了优化。
数据仓库以专有格局存储数据。一旦数据存储在数据仓库中，对该数据的访问仅限于 SQL 和数据仓库提供的自定义驱动程序。一些较新的数据仓库支持半结构化数据，例如 JSON、Parquet 和 XML 文件；与结构化数据集相比，它们对此类数据集的支持有限且性能降低。数据仓库不能齐全支持存储非结构化数据。
数据湖和数据仓库之间的区别
数据仓库和商业智能工具支持历史数据的报告和剖析，而数据湖支持应用数据启动机器学习、预测和实时剖析的新用例。
虽然一些数据仓库裁减了基于 SQL 的访问以提供机器学习配置，但它们不提供原生支持来运转宽泛可用的程序化数据处置框架，例如 Apache Spark、Tensorflow 等。
相比之下，数据湖是机器学习用例的理想选用。它们不只提供基于 SQL 的数据访问，还经过 Python、Scala、Java 等言语为 Apache Spark 和 Tensorflow 等编程散布式数据处置框架提供原生支持。
数据仓库须要在数据用于剖析之前顺序 ETL摄取和转换数据，因此它们关于流式剖析效率低下。一些数据仓库支持“微批处置”以经常以小增量搜集数据。这种流到批处置的转换参与了数据抵达与用于剖析之间的期间，使得数据仓库不实用于多种方式的流剖析。
数据湖支持本地流式传输，其中数据流在抵达时被处置并可供剖析。数据管道在从数据流接纳数据时转换数据，并触发剖析所需的计算。数据湖的原生流式传输个性使其十分适宜流式剖析。
数据仓库支持顺序 ETL 操作，其中数据以瀑布模型从原始数据格局流向齐全转换的汇合，并针对极速性能启动了优化。
相比之下，关于须要继续数据工程的用例，数据湖意外弱小。在数据湖中，ETL 的瀑布方法被迭代和延续的数据工程所取代。可以经过 SQL 和编程接口迭代地访问和转换数据湖中的原始数据，以满足用例不时变动的需求。这种对继续数据工程的支持关于交互式剖析和机器学习至关关键。
掩饰关于数据湖和数据仓库的三大神话
让咱们处置一些关于两种盛行的数据存储类型的经常出现曲解：
误区一：只有要数据湖或数据仓库中的一个
如今，经常听到人们议论数据湖和数据仓库，如同企业必定选用其中一个。但理想状况是，数据湖和数据仓库服务于不同的目的。虽然两者都提供数据存储，但它们经常使用不同的结构，支持不同的格局，并针对不同的用途启动了优化。通常，公司或者会从经常使用数据仓库和数据湖中受益。
数据仓库最适宜宿愿为商业智能剖析操作系统数据的企业。数据仓库在这方面上班得很好，由于存储的数据是结构化、清算和预备剖析的。同时，数据湖准许企业以任何格局存储数据以用于简直任何用途，包括机器学习 (ML) 模型和大数据剖析。
误区 2：数据湖是盛行趋向，数据仓库不是
人工智能 (AI) 和 ML 代表了一些增长最快的云上班负载，组织越来越多地转向数据湖来协助确保这些名目的完成。由于数据湖准许存储简直任何类型的数据（结构化和非结构化）而无需事前预备或清算，因此组织能够保管尽或者多的潜在价值以供未来经常使用，未指定经常使用。此设置十分适宜更复杂的上班负载，例如尚未确定详细数据类型和用途的机器学习模型。
数据仓库或者是这两种选用中更为人所知的一种，但数据湖和相似类型的存储基础设备或者会随着数据上班负载的趋向而继续盛行。数据仓库实用于某些类型的上班负载和用例，而数据湖代表了服务于其余类型上班负载的另一种选用。
误区三：数据仓库易于经常使用，而数据湖很复杂
数据湖须要数据工程师和数据迷信家的特定技艺来分类和应用其中存储的数据。数据的非结构化性质使得那些不了解数据湖如何上班的人更不容易访问它。
然而，一旦数据迷信家和数据工程师构建了数据模型或管道，业务用户通常可以应用与盛行业待业具的集成（自定义或预构建）来探求数据。雷同，大少数业务用户经过衔接的商业智能 (BI) 工具访问存储在数据仓库中的数据。在第三方 BI 工具的协助下，业务用户应该能够访问和剖析数据，无论该数据存储在数据仓库还是数据湖中。
构建现代数据平台的准则
尽量缩小数据平台中人员、网络和磁盘操作的影响。虽然人类永远不可像计算机一样快，但网络和磁盘操作是主观疑问。为了缩小这些疑问的影响，防止在各处复制数据，增强平台读取和处置来自不同位置的数据的才干，包括事务性、颁布/子系统和数据仓库系统，而无需今日移动。构建现代数据平台的准则是：
数据湖和数据仓库：用例
Data Lake 曾经成为一个弱小的平台，企业可以经常使用它来控制、开掘少量非结构化数据并将其货币化，以取得竞争长处。因此，公司对数据湖平台的驳回率急剧参与。
在这种应用大数据的热潮中，不时存在一种曲解，即>数据仓库实用于某些类型的上班负载和用例，而数据湖代表了服务于其余类型上班负载的另一种选用。
用例应该驱动数据平台架构。假设您的用例须要速度、具备已知的数据模型、齐全结构化或十分凑近它，那么 SQL 数据仓库就足够了。然而，假设您须要及时灵敏地对数据启动建模并将其用于多种上班负载，您应该经常使用数据湖。
组织将依托多种技术的最佳处置打算，包括数据仓库和数据湖。最终，组织的选用须要平衡控制多种技术的复杂性和 TCO 与以高性能和经济高效的方式运转更多种类的上班负载的才干。
未来该如何选用
咱们如今处于这样一个阶段，咱们不只可以经常使用数据来回忆过去，还可以了解如今，甚至可以预测未来。数据和工具将不时开展，以协助咱们简直实时地抵达那里。
将数据与高低文分开。出去的数据不必定有你想用它的高低文。所以，在弄分明你想用它做什么之前，把将数据失掉到一个位置的想法分开。由于实践上，您将对该数据启动多种用途。因此，您永远不知道您可以将这些数据用于什么用途。因此，假设您首先失掉数据，而后弄分明您想用它做什么，通常会导以至用这些数据发生更踊跃的结果。
数据仓库供应商正在逐渐从他们现有的模型转向数据仓库和数据湖模型的融合。雷同，数据湖的供应商如今正在裁减到数据仓库畛域，双方正在趋同。例如，BigQuery 如今准许组织在 Amazon S3 上查问数据。雷同，Databricks 和 Qubole 等数据湖平台如今正在果决地转向数据仓库用例。您可以经常使用 ACID 属性、事务分歧性、快照等来控制存储，并将查问引擎更多地与存储控制集成，为客户创立湖仓形式。数据湖和数据仓库之间的融合不只仅是在议论，而是正无理想中运行。