3. 数据湖分析平台核心概念
把 PI System 的数据接入数据湖分析平台，最容易出现的误解是：以为“数据湖”就是一块大硬盘，把 PI 的历史数据导进去就完事了。实际上，一个可用的数据湖分析平台由五个相互配合的层次构成——数据湖存储、计算引擎、元数据管理、数据目录、开放表格式。它们各自解决不同的问题，在 PI 集成链路中承担不同的职责。理解这五者的定位，才能判断一次集成方案是否完整、瓶颈可能出现在哪里。
一、数据湖存储：负责“放得下、放得久、放得便宜”
数据湖存储是对象存储或分布式文件系统（如 S3、OSS、HDFS、ADLS），它只提供字节级的读写能力，不关心数据是什么、属于谁、什么时间写入。它的核心优势是低成本、高扩展、与计算解耦：存储可以独立扩容，计算集群可以随时创建和销毁。
在 PI 集成中，存储层承接的是从 PI Data Archive 或 PI AF 抽取出来的时序数据、事件帧和属性快照。典型做法是按时间分区写入，例如 pi/piarchive/plant1/tag_group=A/date=2024-06-01/part-0001.parquet。这里要特别注意：存储层本身不保证数据一致性，也不提供事务。如果写入过程中任务失败，可能留下半截文件，这正是后面“开放表格式”要解决的问题。
二、计算引擎：负责“算得动、算得快”
计算引擎是真正执行 SQL、Spark 作业、流处理或机器学习训练的部分，常见的有 Spark、Flink、Trino/Presto、ClickHouse 等。它与存储分离，意味着同一份数据可以被不同引擎读取，也意味着引擎的选择取决于负载类型：
- 批处理：用 Spark 对 PI 历史数据做日/月聚合、插值补齐、质量码过滤；
- 交互式查询：用 Trino 直接查 Parquet 文件，支撑分析师临时探索；
- 流处理：用 Flink 消费 PI 的实时更新，做分钟级滚动计算或异常检测。
在集成定位上，计算引擎是“消费方”，它不拥有数据，只读取存储层中的文件。因此，引擎能否高效工作，取决于存储层的数据布局（分区、文件大小、列式格式）和元数据层能否快速给出“哪些文件需要读”。
三、元数据管理：负责“知道有什么、在哪里、什么结构”
元数据管理是数据湖的“骨架”。它记录表结构（schema）、分区信息、文件列表、统计信息（min/max、行数）以及版本快照。没有元数据管理，计算引擎就只能靠目录扫描来发现文件，效率极低且无法保证一致性。
在 PI 集成场景中，元数据管理需要额外承载 PI 特有的语义：PI Tag 名称、AF 元素路径、工程单位、时间戳精度、质量码定义等。这些信息如果只留在 PI 侧，数据湖中的表就只是无意义的数字列；只有把它们登记到元数据层，下游才能正确解释数据。例如，一个 pi_archive 表除了 timestamp、value 两列，还应记录 tag_name、uom、quality 的映射关系。
四、数据目录：负责“找得到、看得懂、敢用”
数据目录面向人和组织，解决的是发现与信任问题。它提供搜索、血缘、标签、权限申请、数据质量评分等功能。元数据管理偏技术、偏机器可读；数据目录偏业务、偏人可读。
在 PI 与数据湖集成中，数据目录的价值体现在：工程师能按“装置—设备—测点”层级找到对应的 PI 数据表；分析师能看到某张表来自哪个 PI Server、更新频率如何、最近一次同步是否成功；数据治理人员能追踪从 PI Tag 到报表指标的完整血缘。没有数据目录，数据湖很容易变成“数据沼泽”——文件很多，但没人知道该用哪个。
五、开放表格式：负责“像表一样可靠地读写文件”
开放表格式（Delta Lake、Apache Iceberg、Apache Hudi）是近年数据湖架构的关键补位。它在对象存储之上增加了一层事务日志，使一堆 Parquet 文件表现得像一张有 ACID 语义的表。它解决三个核心问题：
- 原子写入：一批 PI 数据要么全部可见，要么全部不可见，不会出现半截文件；
- 模式演进：PI 侧新增一个质量码字段时，可以安全地加列而不重写历史数据；
- 时间旅行：可以查询“昨天下午 3 点时的表状态”，便于回溯和审计。
在集成链路中，开放表格式是存储层与计算引擎之间的“契约层”。它让 PI 数据的批量导入、增量更新、删除修正都变得可控，也让不同引擎（Spark、Trino、Flink）能基于同一份元数据一致地读取数据。
六、五者在集成中的协同关系
把五者串起来看：PI System 是数据源，通过 PI Integrator、PI Web API 或自定义抽取程序，把数据写入数据湖存储；开放表格式为这些文件提供事务和表语义；元数据管理登记表结构、分区和 PI 语义映射；计算引擎读取元数据后定位文件并执行计算；数据目录把结果暴露给人和组织，形成发现、申请、使用、反馈的闭环。
七、集成定位的实践判断
在实际项目中，可以用几个问题快速判断五层是否到位：
- 写入 PI 数据时，是否按时间分区、文件大小是否在 128MB～512MB 量级？——这是存储层布局问题；
- 失败重跑时，会不会出现重复数据或半截文件？——这是开放表格式是否启用的问题；
- 新增一个 PI 质量码字段，是否需要重写全部历史？——这是模式演进能力问题；
- 分析师能否在不问工程师的情况下找到某个装置的 PI 数据表？——这是数据目录成熟度问题；
- 同一份数据被 Spark 和 Trino 读取时，结果是否一致？——这是元数据管理与开放表格式协同的问题。
总结来说，PI System 提供的是高密度、强语义的时序数据；数据湖分析平台提供的是低成本、可扩展、多引擎的分析能力。两者之间的集成质量，不取决于“导了多少数据”，而取决于存储、计算、元数据、目录、开放表格式这五层是否各司其职、彼此衔接。理解它们的定位，是后续设计抽取策略、分区方案、表格式选型和治理流程的基础。