长庆油田的一个采油厂，管着3200口井。每口井上挂着一台抽油机——就是那种”磕头机”，一下一下地把原油从地下抽上来。磕头机的头上有一个载荷传感器，每冲程记录一组载荷-位移数据，这组数据画出来就是示功图。示功图是诊断油井工况的核心工具——抽油杆断脱、气锁、液击、供液不足，全靠它来判断。
这个采油厂的技术员老李跟我说，他每天要看的示功图大概有两百多张。3200口井不是每口每天都要看，但即使按10%抽检，也有三百多张。每张图看30秒也得一个多小时。更累的是对比——今天的图和上周的图比，看看载荷曲线有没有变化。示功图变了，井下工况可能变了。
他有没有可能只看那些有变化的图？理论上行。前提是系统自动对比今天的图和历史图，把变化超阈值的图挑出来。这个功能采油厂买了一套软件，用了一个月就不用了——太慢。一口井的历史示功图存在RTU本地和厂级服务器上，服务器用的是SQL Server，查一口井一个月前的示功图要等十几秒。批量查3200口井？直接超时。
老李的需求其实不复杂：把所有井所有历史示功图存到一个能快速查询和对比的地方。
这件事为什么这么难？
油气田数据到底长什么样
油田生产数据不是单一类型的数据，是一个多源、多频、多结构的混合体。
数据类型 | 采集来源 | 采样频率 | 单井日数据量 | 分析用途 |
井口压力/温度 | RTU/压力变送器 | 1-5分钟 | 288-1440条 | 生产动态监测 |
产液量/产油量 | 计量站/多相流量计 | 1-24小时 | 1-24条 | 产量递减分析 |
含水率 | 在线含水仪/人工化验 | 4-24小时 | 1-6条 | 见水阶段判断 |
抽油机载荷 | 载荷传感器 | 每冲程(3-6秒) | 14400-28800条 | 示功图分析 |
冲程/冲次 | 位移传感器 | 每冲程 | 14400-28800条 | 抽油机工况 |
电机电流/电压 | 电参数仪 | 1-5分钟 | 288-1440条 | 能耗/平衡度 |
示功图快照 | 载荷-位移同步采集 | 1-4小时/次 | 6-24组 | 工况诊断 |
气油比 | 人工/在线色谱 | 日/周 | 1条/天 | 油藏管理 |
动液面深度 | 液面仪 | 日/周 | 1条 | 泵效评估 |
看这张表，数据频率跨度极大。从每冲程（3-6秒）一次的高频载荷数据，到每周一次的气油比数据，频率差异达5个数量级。
示功图是最难管理的数据。一次示功图采集是在一个冲程内（约4秒）同步记录载荷和位移，通常采集100-200个数据点构成一条曲线。每口井每天采集6-24次。3200口井，每天产生约2万到7.7万组示功图数据，每组100-200个点。粗算每天约200万到1500万个示功图数据点。
加上井口压力温度、电参数、产液量等常规监测数据，一个3200口井的采油厂日均数据总量在千万级到亿级。
RTU数据管理的三个痛点
油田数据采集的基础设施是RTU（Remote Terminal Unit）。每口井（或每几口井）一套RTU，采集传感器数据，通过数传电台、GPRS或者光纤上传到采油厂级服务器。这套架构用了二十多年，成熟稳定。但数据管理层面有三个一直没解决的痛点。
数据分散。 RTU的设计思路是本地存储+定时上传。RTU本地有一块存储器，通常是几MB到几十MB，能存几天到几周的数据。通信恢复后批量上传。问题在于，如果通信长期中断（油田偏远地区GPRS信号不稳定），RTU存满了新数据就会覆盖旧数据。数据丢了就丢了，没有备份。一座油田几百上千口井，总有一些井因为各种原因——施工挖断光缆、基站故障、RTU损坏——导致数据断档。断档的数据在历史趋势分析里就是一个个空洞，分析结果的可靠性打折扣。
历史短。 采油厂级服务器通常存的是最近几个月到一年的数据，再早的归档到磁带或者直接丢弃。原因是存储空间不够。SQL Server存几千万条高频数据就很吃力了，存几年？没那个硬盘。但油田生产是一个长周期过程——油井的产量递减以年为单位，抽油机磨损以月为单位。没有长期历史数据，怎么分析产量递减规律？怎么做设备全生命周期管理？
示功图存不了。 示功图是一组载荷-位移的曲线数据，不是一个标量值。关系型数据库存这种数据，要么把每个点展开成一行（数据量爆炸），要么把整条曲线序列化为一个blob字段（查不出来也没法比较）。所以很多油田的示功图数据只存在RTU本地或者专门的示功图分析软件里，和分析软件绑死了。换个分析软件？历史数据迁移不出来。
时序数据库的解题路径
老李的需求——把所有历史示功图存到一个能快速查询和对比的地方——时序数据库能不能做到？
能。但需要解决几个问题。
多频数据统一管理。 油田数据频率跨度大——载荷数据每冲程一次，压力数据每分钟一次，产液量每天一次。时序数据库天然支持不同采样频率的数据共存。TDengine里每口井可以建立多张子表，分别对应不同采集频率的数据流。低频数据和高频数据各走各的子表，互不干扰。查询时通过井号标签关联，不需要JOIN操作。
示功图存储。 示功图本质是一个冲程内的同步采样数据序列。TDengine支持存储多列数据（载荷、位移、时间偏移），一次示功图采集作为一行或者一个数据块写入。查询某口井某天的所有示功图，直接通过井号标签和时间范围过滤。3200口井每天7.7万组示功图，写入量约每秒几十到几百组，对TDengine毫无压力。
长期存储。 TDengine的列式压缩对油田数据效果显著。井口压力温度变化平缓，delta编码压缩率可达原始数据的1-2%。示功图数据虽然是高频，但同口井相邻冲程的示功图曲线相似度高，压缩率也不错。一个3200口井的采油厂，一年的全量生产数据压缩后可能在几十GB到百GB级别。一台中等服务器存5-10年数据没问题。
工况诊断支持。 自动识别异常示功图是老李最想要的功能。实现路径是：在TDengine中通过SQL查询某口井今天和上周同一天的示功图数据，通过UDF（用户定义函数）做曲线相似度计算（如DTW——动态时间规整），相似度低于阈值的结果推送给老李。这个分析在TDengine内部完成，不需要把数据导出来。3200口井全量扫描一次，几分钟可以跑完。
油井工况诊断的深层逻辑
说完数据存储，聊聊诊断本身。为什么示功图这么重要？
游梁式抽油机（磕头机）的工作原理是电机驱动游梁做上下摆动，通过抽油杆带动井下深井泵做上下冲程。上冲程时泵吸入液体，下冲程时泵排出液体。载荷传感器安装在悬点（抽油杆顶部），记录的是整个杆柱在上冲程和下冲程中受到的力。
正常工况下，示功图是一个近似平行四边形的封闭曲线。上冲程载荷高（杆柱自重+液柱重量），下冲程载荷低（杆柱自重-浮力+摩擦）。不同工况会在曲线上留下不同的”痕迹”：
- 供液不足：上冲程后半段载荷下降，图形右下角”凹”进去
- 气锁：图形面积显著缩小，载荷曲线变形
- 抽油杆断脱：上冲程载荷骤降，图形变成扁条状
- 液击：下冲程初期载荷突变，有冲击尖峰
这些特征需要和正常工况的示功图做对比才能识别。不同井的”正常”示功图不一样——井深、杆柱组合、泵径、冲程冲次都不同。所以不能用统一阈值来判断，得建立每口井的”基线示功图”，然后做个体化对比。
这就回到老李的需求了：系统自动把每口井今天的示功图和它自己的历史基线对比，变化超阈值才推给他看。这个功能的技术实现就依赖时序数据库的历史数据存储和查询能力。关系型数据库做不了，不是因为功能不支持，是性能扛不住——3200口井全量做一次对比查询就得几十分钟，时效性太差。
产量递减分析
油田生产的核心关注点之一是产量递减。油藏自然递减是规律，不可逆。但递减率的变化趋势是判断油藏开发阶段和调整措施有效性的关键指标。
递减分析需要的历史数据是：每口井的日产液量、日产油量、含水率，时间跨度至少一年以上，最好三到五年。通过Arps递减方程（指数递减、双曲递减、调和递减）拟合历史产量数据，预测未来产量趋势。
这些数据在传统方案里存在Excel里，一个技术员管几十口井，Excel文件散布在不同电脑上。要做全区产量趋势分析？先找齐所有文件，再花一天时间合并数据。
用TDengine存这些数据后，一次SQL查询就能拉出3200口井三年的日产数据。配合Python做Arps拟合和可视化，原来一天的工作量压缩到几分钟。
抽油机优化
抽油机的运行参数——冲程长度、冲次、平衡度——直接影响泵效和能耗。冲次太高容易发生液击（泵来不及充满），冲次太低产量上不去。平衡度差会增加电机能耗和减速箱磨损。
TDengine的数据订阅功能在这里有价值。电参数仪实时采集电机电流、电压、功率数据写入数据库。当电流不平衡度超过设定阈值时——平衡度异常——系统自动推送给运维人员。这个实时性靠定时查数据库做不到，时序数据库的数据订阅机制可以实现秒级推送。
更进阶的应用是优化冲程冲次。通过示功图分析泵充满程度，结合动液面深度和地层供液能力，计算最优冲次。这个分析需要多源数据的联合查询——示功图数据、动液面数据、产液量数据、电参数数据——都在TDengine里，通过井号标签关联，一条SQL搞定。
几个落地中的现实问题
油田的数字化基础参差不齐。老油田的RTU设备老旧，通信协议以Modbus为主，不支持OPC UA。新油田的RTU较新，支持IEC 61850和OPC UA。TDengine支持多种协议的数据接入，但RTU到数据库之间的ETL链路仍然需要额外的数据采集网关或者工业网关来转换协议。这部分投入和数据库无关，但项目总成本中占比不小。
数据质量的问题在油田尤其突出。载荷传感器在恶劣环境下（高温、腐蚀、振动）的寿命有限，漂移和故障常见。一个采油厂3200口井，一年下来可能有200-400口井的载荷传感器需要更换或校准。传感器更换前后的示功图数据会有突变，自动诊断算法需要识别这种传感器变更引起的变化，避免误报为工况异常。
气田的数据特征和油田不同。天然气井的压力波动更剧烈，产量受季节需求影响大，气井的递减规律和油井不同。但数据管理层面的需求是类似的——多频、多源、长期存储、快速查询。这类数据库在气田场景的适用性不需要多说。
反直觉的一点
油田行业有个反直觉的现象：数字化投入最大的不是大型油田，而是中小型油田。
原因简单——大型油田有人有钱，已经建了一套又一套系统，存量系统的迁移和改造反而比新建更难。中小型油田没有历史包袱，从零开始建数据平台反而更容易采用新技术。
某民营油气公司，只有不到200口井，在2024年上了TDengine做数据底座。投入不到30万，上线两个月后示功图自动诊断功能就跑起来了。老李来参观的时候表情很复杂——他的采油厂三千多口井，花了几百万做的系统至今没把示功图自动诊断跑起来。
不是钱的问题，是架构选型的问题。选错了数据库，再多的投入也跑不出想要的效果。
