理解数据存储：数据仓库、数据湖与湖仓一体
您是否对“数据仓库”、“数据湖”和“湖景房”这些术语感到陌生？ 也许您的日常工作与数据处理并无直接关联。 然而，在当今时代，数据的重要性不言而喻。 企业领导者常以“数据驱动”和“随时随地获取数据”来强调其核心价值。
数据：企业最重要的资产
数据已逐渐成为企业最宝贵的财富。 曾几何时，大型企业每月产生数TB的数据，而这还是十多年前的事。 如今，短短几天内就能产生如此庞大的数据量。 这不禁让人思考，这些数据是否真的都必要且有用。 答案显然并非如此。 很多数据可能从未被使用过，甚至在加载后就变得毫无价值。 我亲眼目睹过许多公司生成大量数据，最终却束之高阁。
然而，现在的情况已大不相同。 云存储变得经济实惠，数据源呈指数级增长，没有人能够准确预测未来一年内系统所需的数据。 即使是旧数据，也可能在未来发挥重要作用。 因此，目前的策略是尽可能多地存储数据，并确保存储形式的高效性，便于后续查询、重用、转换和分发。
接下来，我们将探讨在AWS云平台中实现这一目标的三种原生方法：
- Athena 数据库： 经济高效的云数据湖创建方案。
- Redshift 数据库： 强大的云数据仓库解决方案，可替代大多数本地部署方案，但可能难以跟上数据的指数级增长。
- Databricks： 将数据湖和数据仓库整合为一个统一的解决方案，并提供额外优势。
利用AWS Athena构建数据湖
资料来源：aws.amazon.com
数据湖是存储非结构化、半结构化或结构化数据的理想场所。 理想情况下，数据一旦存储，就不应被修改，应尽可能保持原子性和不可变性，以确保后续重用的最大潜力。 如果在首次加载到数据湖后丢失了数据的原子特性，则无法再次恢复丢失的信息。
AWS Athena 直接基于 S3 存储桶构建，无需服务器集群，这使其成为一种非常经济的数据湖服务。 结构化的文件格式（如 Parquet 或 CSV）用于组织数据。 S3 存储桶存储文件，Athena 在从数据库查询数据时会引用这些文件。
Athena 不支持许多标准数据库功能，如更新语句。 因此，它被认为是一个非常简单的方案，但也正因如此，它能有效防止您修改原子数据湖中的数据。它支持索引和分区，从而实现高效的查询执行，并创建逻辑上独立的数据块（如按日期或键列分隔）。 此外，由于扩展与添加新存储桶一样简单，因此它可以轻松地进行水平扩展。
优点和缺点
优势：
- 经济高效： Athena 的主要优势在于其低成本，仅包括 S3 存储桶费用和每次 SQL 查询使用成本。它是AWS云中构建经济型数据湖的理想选择。
- 易于集成： Athena 作为一项原生服务，可与其他 AWS 服务（如 Amazon QuickSight 和 AWS Glue 数据目录）轻松集成。
- 适合即席查询： Athena 非常适合对大量结构化或非结构化数据运行即席查询，而无需维护复杂的基础设施。
劣势：
- 查询效率： Athena 在快速返回复杂查询方面效率不高，尤其是在查询不符合数据模型假设时。
- 灵活性不足： 在数据模型未来发生变化时， Athena 的灵活性较低。
- 功能有限： Athena 不支持开箱即用的高级功能，如果您需要特定功能，则需要自行实现。
- 高级用途： 如果需要在更高级的表示层中使用数据湖数据，通常需要与其他数据库服务（如 AWS Aurora 或 AWS Dynamo DB）结合使用。
目的和实际用例
如果您需要一个简单的数据湖，而无需复杂的数据仓库功能，那么 Athena 是理想选择。 例如，您不需要定期在数据湖上运行高性能分析查询，而只需要一个具有易于扩展的不可变数据池。 您无需担心存储空间不足，通过实施数据生命周期策略，您可以进一步降低 S3 存储桶的存储成本。 这意味着将数据移动到不同类型的 S3 存储桶中，以便进行归档，从而实现更慢但更具成本效益的检索。
Athena 的一个重要功能是它可以自动创建包含 SQL 查询结果的文件。 然后您可以将此文件用于任何目的。 因此，如果您有多个 Lambda 服务来进一步处理数据，那么这是一个很好的选择。 每个 Lambda 结果都将自动成为结构化文件格式的结果，并为后续处理做好准备。
当大量原始数据流入云基础设施，而您无需在加载时处理这些数据时，Athena 也是一个不错的选择。 这意味着您只需要在云中快速存储数据，并保持易于理解的结构。 另一个用例是为其他服务的数据归档创建专用空间。 在这种情况下，Athena 数据库将成为所有暂时不需要但未来可能需要的数据的廉价备份场所。 此时，您只需摄取数据并将其发送到其他地方。
利用AWS Redshift构建数据仓库
资料来源：aws.amazon.com
数据仓库是存储结构化数据的地方，易于加载和提取。 其主要目的是运行复杂的查询，通过复杂的连接连接多个表。 各种分析功能到位，可计算现有数据的统计数据。 最终目标是利用现有数据提取未来的预测，以便在未来的业务中加以利用。
Redshift 是一个成熟的数据仓库系统，可通过集群服务器进行调整和扩展（水平和垂直）。 它还具有针对快速复杂查询返回而优化的数据库存储系统。 如今，您也可以在无服务器模式下运行 Redshift。 它不是简单地将文件存储在 S3 上，而是一个标准的数据库集群服务器，具有自己的存储格式。
它提供了开箱即用的性能监控工具，以及可自定义的仪表板指标，供您微调用例的性能。 管理也可以通过单独的仪表板访问。 虽然了解所有可能的功能和设置以及它们如何影响集群需要一定的努力，但它仍然比管理本地部署的 Oracle 服务器要简单得多。
虽然 Redshift 中的各种 AWS 限制在日常使用方面设置了一些界限（例如，对一个数据库集群中并发活动用户或会话数量的硬性限制），但其快速的运行速度在一定程度上弥补了这些限制。
优点和缺点
优势：
- 云原生： Redshift 是一款易于与其他服务集成的原生 AWS 云数据仓库服务。
- 集中存储： 它是存储、监控和摄取来自不同源系统的各种类型数据源的中心位置。
- 无服务器选项： 如果您想要一个无需维护基础设施的无服务器数据仓库，Redshift 可以满足您的需求。
- 性能优化： Redshift 针对高性能分析和报告进行了优化，与数据湖解决方案不同，它有一个强大的关系数据模型来存储所有传入数据。
- 兼容性： Redshift 数据库引擎源于 PostgreSQL，保证了与其他数据库系统的高度兼容。
- 实用语句： 它提供了非常有用的 COPY 和 UNLOAD 语句，用于从 S3 存储桶加载和卸载数据。
劣势：
- 并发限制： Redshift 不支持大量并发活动会话， 会议将被暂停并按顺序处理。虽然这在大多数情况下可能不是问题，但对于具有大量活跃用户的系统来说，这确实是一个限制因素。
- 功能差异： 虽然 Redshift 支持许多以前从成熟的 Oracle 系统中已知的功能，但仍然存在差距。 一些预期的功能可能不存在（如数据库触发器），或者 Redshift 仅以有限的形式支持它们（如物化视图）。
- 自定义处理： 每当您需要更高级的自定义数据处理作业时，您都必须从头开始创建它，通常使用 Python 或 Javascript 代码语言。 这不如在 Oracle 系统中使用 PL/SQL 那么自然。
目的和实际用例
Redshift 可以成为您之前在云之外的各种数据源的中央存储，它是以前 Oracle 数据仓库解决方案的有效替代方案。由于它也是关系型数据库，因此从 Oracle 迁移是一个相对简单的操作。
如果您在多个地点都有数据仓库解决方案，但它们在方法、结构或数据之上的预定义通用流程方面不统一，那么 Redshift 是一个不错的选择。它可以帮助您将来自不同地点和国家的所有数据仓库系统整合到一个统一的解决方案中，并允许您按照国家或地区分开数据，以便只有需要的人才能访问数据。同时，它可以让您构建一个涵盖所有企业数据的统一仓库。
另一种情况是，如果您希望构建一个广泛支持自助服务的数据仓库平台。 您可以理解为用户可以构建一组处理流程，但它们从来都不是通用平台的一部分。 这意味着此类服务仅供创建者或由创建者定义的人群访问，并且不会以任何方式影响其他用户。
以下是我们对数据湖和数据仓库的比较。
利用AWS上的Databricks构建湖仓一体架构
资料来源：databricks.com
“湖仓一体”（Lakehouse）是与 Databricks 服务紧密相关的术语。 尽管它不是 AWS 原生服务，但它在 AWS 生态系统中能够良好运行，并提供各种选项来连接和集成其他 AWS 服务。
Databricks 旨在连接以下（以前）非常不同的领域：
- 存储非结构化、半结构化和结构化数据的数据湖解决方案。
- 用于结构化数据，并可快速访问查询（也称为 Delta Lake）的数据仓库解决方案。
- 支持数据湖上的分析和机器学习计算的解决方案。
- 通过集中管理和开箱即用的工具对上述所有领域进行数据治理，从而提高不同类型开发人员和用户的工作效率。
它是数据工程师、SQL 开发人员和机器学习数据科学家可以同时使用的通用平台。 每个小组都有一组工具，他们可以使用这些工具来完成他们的任务。
因此，Databricks 的目标是提供一种万能的解决方案，试图将数据湖和数据仓库的优势结合在一起。 最重要的是，它提供了直接在已构建的数据存储上测试和运行机器学习模型的工具。
优点和缺点
优势：
- 高度可扩展： Databricks 是一个高度可扩展的数据平台，它可以根据工作负载大小进行扩展，甚至是自动进行。
- 协作环境： 它是数据科学家、数据工程师和业务分析师的协作环境。 在同一个空间一起完成所有这些任务是一个很大的好处。 这不仅从组织的角度来看有好处，而且有助于节省单独环境的成本。
- AWS集成： AWS Databricks 与其他 AWS 服务（如 Amazon S3、Amazon Redshift 和 Amazon EMR）无缝集成。 这使得用户可以轻松地在服务之间传输数据，并充分利用 AWS 云服务。
劣势：
- 配置复杂： Databricks 的设置和管理可能很复杂，尤其是对于刚接触大数据处理的用户而言。 它需要高水平的技术专业知识才能充分利用该平台。
- 成本较高： 虽然 Databricks 在其即用即付定价模式方面具有成本效益，但对于大型数据处理项目来说仍然很昂贵。 使用该平台的成本会迅速增加，尤其是在用户需要扩展其资源的情况下。
- 定制有限： Databricks 提供了一系列预构建的工具和模板，但这对于需要更多自定义选项的用户来说也是一个限制。 该平台可能不适合需要更大灵活性和控制大数据处理工作流程的用户。
目的和实际用例
AWS Databricks 最适合拥有大量数据的大型公司。它可以涵盖从不同外部系统加载和管理各种数据源的要求。
通常，要求是实时提供数据。 这意味着从数据出现在源系统中开始，进程应立即拾取并立即或以最小延迟处理数据，并将其存储到 Databricks 中。如果延迟超过一分钟，则认为是近实时处理。 无论如何，这两种情况通常都可以通过 Databricks 平台实现。 这主要是由于连接到各种其他 AWS 原生服务的大量适配器和实时接口。
Databricks 还可以轻松地与 Informatica ETL 系统集成。每当组织系统已经广泛使用 Informatica 生态系统时，Databricks 看起来就像是该平台的一个很好的兼容补充。
总结
随着数据量持续呈指数级增长，令人欣慰的是，我们有解决方案可以有效地应对。 曾经令人头痛的数据管理和维护工作现在只需要很少的管理，团队可以专注于从数据中创造价值。
您可以根据自己的需要选择适当的服务。 虽然 AWS Databricks 可能需要您在做出决定后坚持使用，但其他替代方案更加灵活，即使它们的功能较弱，特别是其无服务器模式。 未来迁移到其他解决方案也很容易。