下载掌阅APP，畅读海量书库
立即打开
在数据工程团队的日常用语中，可能没有哪两个词像数据仓库和数据湖那样占据如此多的空间。虽然数据仓库和数据湖不能互换，但这些技术正在迅速融合，每种技术都提供了两全其美的优势。
许多组织确实需要在其数据管道中使用这两种系统，但它们的用途却截然不同。数据仓库通常以结构化（行-列）的格式来存储数据。此类数据经过了高度转换（定义的预处理过程的结果），且仅在有明确的存在理由时才会在数据仓库中出现——至少理论上是这样的。
相反，数据湖能存储任何结构化数据、半结构化数据和非结构化数据。与数据仓库不同，数据湖不需要具有高度指定的数据输入程序，你可以将任何喜欢的格式转储到湖中并直接访问它。其结果是系统的容量通常更高，并且在治理和数据方面往往更加复杂。
数据仓库需要“写时模式”访问，这意味着我们在数据进入仓库时就设置了数据的结构。这些数据的进一步转换必须在每一步都明确其新结构。
数据仓库是完全集成和托管的解决方案，使其易于构建和开箱即用。与数据湖不同，数据仓库通常需要更多的结构和模式，这通常会对数据清洗的过程要求更高，并在读取和使用数据时降低复杂性。
现代数据仓库的概念部分归功于Kimball集团，该集团在20世纪80年代开发了数据仓库/商业智能生命周期方法论（ https://oreil.ly/uxbcY ）。这种系统设计上的创新支持了企业在各个层面上的业务价值，包括工程师最常从事的数据摄取和预处理阶段。Kimball在将数据存储技术确定为商业资产而不仅仅是技术偏好的过程中发挥了重要作用。
现代数据仓库通过其写时模式架构遵循这种方法，并且可以与Looker和Tableau等商业智能工具进行集成。简单来说，数据仓库中的数据一定有其存在的原因，而这些原因应当与某种业务目标相对应。
目前，常见的数据仓库技术包括以下几种。
Amazon Redshift
作为第一个广受欢迎（且随时可用）的云数据仓库，Amazon Redshift位于AWS之上，利用源连接器将数据从原始数据源传输到关系型数据库中。Redshift的列式存储结构和并行处理使其成为分析型工作负载的理想选择。
Google BigQuery
与Redshift类似，Google BigQuery利用了Google的专有云平台GCP（Google Cloud Platform）并使用了列式存储结构，通过并行处理来实现快速查询。BigQuery是一种可根据使用模式进行扩展的无服务器解决方案，这一点与Redshift不同。
Snowflake
与依赖专有云运行的Redshift或GCP不同，Snowflake的云数据仓库功能由AWS、Google、Azure和其他公有云基础设施提供支持。与Redshift不同，Snowflake允许用户为计算和存储单独付费，这让数据仓库成为寻求更灵活支付方案的团队的绝佳选择。
鉴于其预打包功能和对SQL的强大支持，数据仓库促进了快速、可操作的数据查询，使其成为数据分析团队的理想选择。
虽然数据仓库对于商业分析用例非常有价值，但它同时也存在一些缺点，你尤其应该记住那些与管理数据质量相关的缺点：
灵活性有限
数据仓库并不是市面上最灵活的数据存储解决方案。这并不是说它们不能很好地进行扩展（许多著名的现代解决方案都可以做到），而是说在数据仓库中，数据的格式是有限的。数据仓库中的条目必须强制转换为具有明确模式的表格形式。像JSON（JavaScript Object Notation）这样的半结构化数据及其查询通常不受支持，而且不良数据常常会被遗漏。
仅支持SQL
查询数据仓库需要使用查询语言，如SQL。这一过程通常不支持使用Python等指令式编程语言进行数据操作，尽管这些语言由于强大的库生态系统对机器学习非常有用。所以，许多机器学习的实现需要通过SQL将数据移出仓库，以便进一步处理。当然，这种对数据的移动经常会中断，并且会出现容量、新鲜度和模式异常。
工作流之间存在冲突
一部分数据科学家在一个快速迭代的产品上紧密合作，他们可能会发现写时模式系统提供的清洁度带来的问题比好处要多。当你想快速工作时，对数据结构采用宽松的标准会更有利。这种结构将不断变化，而不断变化的模式并不是数据仓库乐于支持的。
基于这些原因，数据团队同时采用数据仓库和数据湖来处理分析型工作负载的情况并不少见，因为它们分别有着不同的用途。
数据湖是现代数据系统另一种日益流行的存储和计算选择，它也依赖于高质量的分析型数据来提供最佳结果。
与数据仓库不同，数据湖架构允许“读时模式”访问。这意味着我们可以在准备使用数据时再推断数据的结构。
数据湖是数据仓库的DIY版本，允许团队根据系统需求选择自己想要使用的各种元数据、存储和计算技术。数据湖非常适合希望构建定制化平台的数据团队，通常由少数（或更多）数据工程师提供支持。借助数据湖，数据科学家、机器学习工程师和数据工程师可以从更大的数据池中提取半结构化数据和非结构化数据。
数据湖的概念最早是由软件公司Pentaho的创始人兼前首席技术官James Dixon提出的，他将其描述为“在一个更自然的环境中的一大片水域。数据湖的内容从源头涌入并填满整个湖泊，湖的不同用户都可以来检查、探索或取样”。
非常早期的数据湖主要建立在Apache Hadoop MapReduce和HDFS（Hadoop Distributed File System）上，利用Apache Hive通过SQL引擎来查询数据。在21世纪10年代初期，Apache Spark让数据湖更加稳定，为数据湖中大型数据集的分布式计算提供了一个通用框架。
数据湖的一些通用特征包括：
解耦存储和计算
此功能不仅可以节省大量成本，而且有助于解析并丰富数据以进行实时流式传输和查询。
支持分布式计算
分布式计算有助于提高大规模数据处理的性能，因为它允许更好的分段查询性能、更容错的设计和更佳的并行数据处理能力。
定制化和互操作性
由于其“即插即用”的特性，随着公司数据需求的演进和成熟，数据湖可以让栈中的不同元素轻松地协同工作，从而支持数据平台的可扩展性。
主要基于开源技术进行构建
这有助于降低供应商被锁定的风险并提供强大的定制功能，对于拥有大型数据工程团队的公司来说非常适用。
处理非结构化或弱结构化数据的能力
数据湖可以支持原始数据，这意味着在处理数据时具有更大的灵活性，非常适合数据科学家和数据工程师。使用原始数据可以更好地控制聚合与计算。
支持复杂的非SQL编程模型
与大多数数据仓库不同，数据湖支持Apache Hadoop、Apache Spark、PySpark等高级数据科学和机器学习框架。
虽然数据仓库提供的结构让数据团队可以轻松有效地运用数据（即收集分析洞察并支持机器学习能力），但这种结构会使它们在某些应用程序中不够灵活且成本高昂。另外，数据湖具有无限的灵活性和定制化能力来支持广泛的用例，但随着灵活性的提高，还会出现许多与数据组织和治理相关的其他问题。
以下是数据团队尝试在其数据湖环境中获得更可靠的数据时所面临的一些突出挑战：
数据完整性
数据湖中的资源在文件级别进行操作时无法保证其数据模式。如果你在数据湖中转换数据时对它的模式有些假设，那么你正在进行一种称作“盲目ETL”（blind ETL）的危险操作。由于不可预见的上游变化，转换可能会在任何时候失败。
沼泽化
沼泽化是指数据湖随时间推移产生技术负债和隐性知识的趋势。通常来说，你必须依靠熟练的数据工程师或数据科学家来了解特定数据所在的位置、利益相关方是谁，并预计数据将如何变化。但过于依赖他们会让数据湖变得“沼泽化”，这意味着没人能完成任何工作，因为数据认知所需的学习成本实在是太高了。
更多端点
数据可靠性通常是数据湖中一个更大的挑战，因为人们可以通过更多方式来收集、操作和转换数据。管道中的步骤越多，出错的可能性就越大。
数据湖通常被用作大量非结构化数据的收集点，例如应用程序数据或用于某些机器学习任务而自动生成的数据。这些数据可以在数据湖中保持其原始格式，也可以通过像AW S Glue这样的数据集成层提供给可能会作为上游资源的数据仓库或商业智能工具。
较小的团队可能会使用数据湖作为唯一的数据存储工具，以实现快速移动的目的，而不是依赖强大的基础设施——尽管这种做法的从业者应该始终警惕“数据沼泽”问题。
当云仓库供应商开始添加诸如Redshift Spectrum或Delta Lake等提供湖式好处的功能时，湖仓一体首次出现在人们的目光中。同样，数据湖也添加了提供仓库式特性的技术，例如SQL功能和模式。数据仓库和数据湖之间的差异如今正在不断缩小，所以你能够在一个软件包中获得两全其美的体验。
以下功能正在帮助湖仓一体进一步弱化这两种技术之间的界限：
高性能SQL
Presto和Spark等技术在数据湖上提供了接近交互速度的SQL界面。这开辟了数据湖直接服务于分析和探索需求的可能性，而无须对传统数据仓库进行汇总和ETL。
模式
Parquet等文件格式为数据湖表引入了更严格的模式，以及用于提高查询效率的列式格式。
原子性、一致性、隔离性和持久性（Atomicity ， Consistency ， Isolation ， and Durability，ACID ）
Delta Lake和Apache Hudi等数据湖技术在写入/读取事务中引入了更高的可靠性，并让数据湖更接近传统数据库技术标准中的理想ACID属性。
托管服务
对于希望减少与构建和运行数据湖相关的运营成本的团队，云服务供应商提供了各种托管湖服务。例如，Databricks提供Apache Hive、Delta Lake和Apache Spark的托管版本，而Amazon Athena提供完全托管的数据湖SQL查询引擎，Amazon的Glue提供完全托管的元数据服务。
随着为光速分析提供信息的实时数据聚合和数据流传输的兴起（想想Uber、DoorDash和Airbnb等硅谷科技巨头的速度），湖仓一体未来几年可能会在各行各业的数据团队中变得越来越受欢迎，且越来越重要。
不同的数据仓库和数据湖通过数据集成层来进行桥接。AWS Glue、Fivetran和Matillion等数据集成工具从不同来源收集数据，统一这些数据，并将其转换为上游来源。数据集成的一个典型用例是收集数据湖的数据并以结构化格式将其加载到数据仓库中。
ETL是数据集成中一个众所周知的过程。ETL通常描述集成的步骤，其中首先从一个或多个数据存储库中提取数据，转换为新的结构或格式，最后加载到目标数据存储库中。
我们已经讨论了现代数据管道的核心元素，现在深入了解一下它们是如何协同工作的，以及我们可以做些什么来确保过程中的每一步都能确保很高的数据质量。