许多组织在过去几年中已经围绕数据整合或转型制定了战略，或者现在正在积极参与此类活动。 这些策略通常由交叉的优先事项驱动，包括需要打破孤立的数据系统，实现集成、快速的跨数据集分析，以及随着数据量和复杂性的增长而大规模有效地工作。
为了协助这种转型，通常以某种方式组合实施两类技术 – 数据湖技术和数据仓库技术，有时结合使用。 数据湖和数据仓库的技术经常混为一谈，并且可以在非正式讨论中互换使用，但在概念和实现层面，它们的使用目的不同，并且在企业信息系统中起到不同的作用。 本页将尝试在一般、供应商和产品无关级别描述这些技术，并从 ArcGIS 系统的角度解释 Esri 使用这些技术的战略方法。
数据湖在定义和构造上可能有很大差异，但作为一个一般概念，数据湖是各种类型的单个数据项目（文件）的集中存储库，这些项目存储在一个大型、可扩展的存储系统中，支持跨文件进行索引、编目和运行分析。 数据可以是结构化的，也可以是非结构化的，以各种文件格式存储，并根据入站数据流或创建该数据的其他系统进行组织。 然后，使用数据湖提供商通过软件提供的工具和功能对数据进行访问、可视化和分析。
例如，组织可能会使用数据湖来存储数千个 CSV 文件，这些文件表示车辆位置、速度和方向的每小时轨迹。 数据湖软件可能支持对这数千个文件运行批处理分析，以提取速度超过一定数量的场景或检测频繁停止位置的趋势。 传统的数据系统需要将这么多文件合并到一个数据集中以进行访问，但数据湖允许这种查询和分析体验在海量数据池中大规模运行。 在同一个数据湖中，同一个组织可能会存储不同格式的数据，这些数据根据基于文件的存档格式汇总客户资料和销售数据，以将先前的活动与活动订单或客户的实时交易数据库相关联。
数据湖主要从 ArcGIS 访问，作为提出分析问题的数据源，然后在空间或基于地图的界面中查看结果。 由于这些存储系统通常在结构类似的文件中包含非常大的数据集合，因此处理该数据的过程通常先汇总内容，然后再运行地理空间分析或将这些数据集与其他空间或非空间图层进行比较以回答特定的分析问题。 通常，这些分析需要进行大量处理，因此工作流程通常涉及几个步骤：
数据湖还可以用作影像数据集或栅格文件的资料档案库，这些文件可通过 ArcGIS Pro 中的云连接文件进行访问，或用作镶嵌数据集的一部分。 数据湖影像可以添加到镶嵌数据集中，并用于发布影像服务，作为使用栅格分析运行的分析的源，在 ArcGIS Pro 中查看，以及用于地理处理、分析或呈现工作流。
使用 ArcGIS 的一些数据湖工作流示例可能包括：
数据仓库是另一种类型的存储系统，在设计、定义和构造方面可能会有所不同。 作为一般概念，数据仓库与关系数据库管理系统最相似，它允许存储大型结构化数据集，具有跨数据集查询、分析和汇总功能。 通常，数据仓库与传统关系数据库系统在以下方面所有区别：可支持的数据规模、可以执行的分析的类型和种类以及完成这些进程的速度。
数据仓库通常也采用更加云原生的配置，或者以软件即服务模型提供，其中客户端使用由构建数据仓库技术的公司托管和管理的计算容量和存储连接到同样由该提供商托管的系统。 另一个常见的数据仓库组件是使用非关系数据模型，例如星型模型、维度数据模型或其他类似概念。
可以采用多种不同的形式使用 ArcGIS 中的数据仓库。 首先，最常见的模式是从 ArcGIS Pro 连接到数据仓库，以对表、视图或数据集运行查询。 这是通过查询图层创建的，查询图层是 ArcGIS Pro 中的一种图层类型，可以针对支持的关系数据库管理系统或云数据仓库运行用户定义的 SQL。 有关支持的数据库和云数据仓库的列表，请参阅 ArcGIS Pro 文档。
查询图层以表格的形式返回数据库的结果，如果其中包含 ArcGIS 可识别的空间列，则可以在地图上显示该表格，然后可以将其用于可视化、用作分析的输入或制图地图创建的输入。 此图层是与仓库的实时连接，因此每次更改地图范围时都会发送一个新查询，该查询将返回一组新的行，可能反映更新的源数据、更新的计算或只是新的空间范围。
如果需要基于 Web 的访问，则可以将此查询图层发布到 ArcGIS GIS Server 站点的动态地图服务中，这会将 ArcGIS Pro 地图中的任何符号系统或定义传递到服务配置中，但现在每个用户请求都将触发从 ArcGIS Server 到数据仓库的更新 SQL 查询。
数据仓库针对大型、分析或摘要查询进行了优化，允许数据所有者回答诸如“过去 24 小时内我们商店的数百万笔交易中不同产品类别的平均购买规模是多少”等问题。像这样的查询通常会定期运行，结果用于支持仪表板、数据摘要或图表，直到它们稍后定期更新。 数据仓库还可供数据分析师或数据科学家用于更加迭代的探索性分析，通常用于定义并重复使用汇总统计数据或报表。
因此，ArcGIS 中连接到数据仓库的查询图层_通常_应查询此类分析的结果，而不是一组特定的事务性行（例如 24 小时内所有百万个事务的列表）。 虽然数据仓库在功能上可以逐行查询，但它们并未针对此类事务交互进行优化，并且体验可能会令人沮丧，例如尝试查询 100 万行以在地图上显示，这可能会导致返回（并显示）所有请求行的响应时间长达 5 分钟。
将数据仓库支持的查询图层发布到 ArcGIS Enterprise 后，对于某些提供商，ArcGIS 可以实施额外的性能优化。 借助云数据仓库，ArcGIS 引入了额外的逻辑来帮助高效处理查询和使用计算资源，特别是对于 AWS Redshift、Google BigQuery 和 Snowflake 数据库，这些数据库可能会根据总计算消耗量收取成本。 在发布期间，ArcGIS 可以（可选择）在源数据仓库中自动创建具体化视图，这可以提高性能并节省查询的总体成本。 另一个选项是“快照”模式，在发布期间将数据副本移动到 ArcGIS Data Store，然后按照发布者设置的计划定期保持最新状态，以便 GIS 系统始终具有一组最新的结果，但相对较慢的查询不会持续发送到源数据仓库。
还存在与数据仓库集成的其他方法，但不太常见，如下所示：