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