📚 课程目录第1章集成需求与架构总览

1. 集成需求与架构总览

PI System 是工业领域广泛使用的实时数据基础设施，核心组件包括 PI Data Archive（时序归档）、PI Asset Framework（资产模型）、PI Interface（数据采集接口）与 PI Web API（对外服务接口）。数据湖分析平台（如基于 Hadoop、Spark、对象存储与湖仓一体表格式构建的平台）则擅长海量历史数据的低成本存储、跨源关联与机器学习。两者集成的本质，是把"高频、强时序、带资产语义"的实时数据，与"海量、多源、面向分析"的批式数据打通，形成从现场到决策的完整数据链。

业务驱动与典型场景

集成的驱动力通常来自四类诉求。第一类是长周期历史留存：PI Data Archive 为保障在线查询性能，通常只保留有限年限的高精度数据，而合规审计、设备全生命周期分析往往需要十年以上的历史，数据湖是更经济的承载层。第二类是跨源关联分析：把 PI 的工艺参数与 MES 的批次记录、LIMS 的化验结果、ERP 的工单成本放在同一张宽表中，才能做良率归因、能耗对标。第三类是高级分析与 AI 建模：在数据湖侧用 Spark、Python 生态做特征工程与模型训练，例如用振动、温度、电流的时序特征预测设备劣化。第四类是统一指标口径：避免各业务系统各自计算 OEE、单耗，改由数据湖统一加工后回供报表。

典型场景可以归纳为三条主线：其一是批量历史回灌，把 PI 中多年的历史值一次性抽取到数据湖，用于建模与回溯分析；其二是准实时增量同步，按分钟或小时把新增归档值、事件帧写入湖表，支撑近实时看板；其三是语义与上下文同步，把 AF 的资产层级、模板、属性、单位、UOM 一并搬到湖侧，使分析人员不必面对裸位号。三条主线的时效性、数据量与一致性要求差异很大，架构设计必须分别对待。

整体技术架构

一个可落地的集成架构通常分为五层：源侧（PI Data Archive、AF Server、PI Event Frames）、抽取层（PI Web API、AF SDK、PI Integrator for Business Analytics 或自研连接器）、传输与暂存层（消息队列或对象存储落地区）、湖侧加工层（原始区 Raw、清洗区 Cleansed、主题区 Curated 的分层建模）、服务层（BI、特征平台、模型服务）。下图给出这一架构的关键数据流与语义流关系。

关键挑战与设计取舍

时间戳与乱序。PI 归档值的时间戳是事件时间，接口补传、网络抖动会导致数据迟到。若按处理时间分区，同一小时的数据可能落到不同分区，导致重算困难。正确做法是以事件时间作为分区键，并在湖侧按水位线做幂等合并（如按 tag + timestamp 去重）。

语义一致性。PI 中的位号（Tag）本身不带业务含义，含义在 AF 的资产层级与属性中。若只同步值而不同步语义，分析人员面对的是成千上万个裸位号。因此必须把 AF 的 Element、Attribute、Template、UOM 一并同步，并在湖侧建立"资产维度表 + 时序事实表"的星型结构。

质量码处理。PI 的每个值都带质量码。数据湖侧若直接丢弃质量码，会把 Bad 值当作真实值参与计算。建议在 Raw 区保留原始质量码，在 Cleansed 区按规则处理：Bad 值置空并标记，Questionable 值保留但打标签，Good 值正常使用。

增量抽取的水位线。常见做法是记录每个 Tag 或每个 AF 属性的最后同步时间戳，下次从该时间戳之后开始抽取。需要注意 PI 的归档值可能被回填（backfill），因此水位线应留一定回溯窗口（例如 24 小时），并在湖侧做幂等去重。

一个可参考的落地参数示例

以下是一份增量同步任务的配置示例，用于说明关键参数如何设置。参数为教学示例，实际值需根据现场点位数量与网络带宽调整。

sync_job:
  source: PI Web API
  endpoint: https://piwebapi.example.com/piwebapi
  auth: kerberos
  tags:
    - "PLANT1.AREA2.PUMP101.VIBRATION"
    - "PLANT1.AREA2.PUMP101.TEMPERATURE"
  mode: incremental
  watermark_field: last_sync_ts
  lookback_hours: 24          # 回溯窗口，应对回填
  batch_size: 5000            # 单次请求最大点数
  interval_seconds: 300       # 调度周期
  target:
    format: parquet
    partition_by: [event_date, event_hour]
    dedup_key: [tag, timestamp]
  quality:
    keep_quality_code: true
    bad_value_action: set_null

判断同步是否正常，可以观察三个指标：水位线推进（last_sync_ts 是否随调度周期稳定前移）、重复率（去重后记录数 / 原始记录数，正常应接近 1）、质量码分布（Good 占比是否与 PI 侧一致）。若水位线停滞，通常是接口超时或权限问题；若重复率异常升高，说明回溯窗口过大或去重键设置不当。

架构设计的第一原则是"先对齐语义，再搬运数据"。很多集成项目失败并非因为传输不稳定，而是因为湖侧只有值、没有资产上下文，导致数据无法被业务理解和使用。

综上，PI System 与数据湖的集成不是简单的数据搬运，而是一次"时序 + 语义 + 质量"的完整迁移。理解业务驱动、选对抽取方式、设计好分区与去重策略、保留质量码与资产语义，是后续各章展开具体实现的基础。