IDMP 按“产线—工艺段—设备—测点”的语义结构搭建制丝车间的资产目录与指标体系，并通过公式属性、统计分析与事件告警引擎，将实时信号提炼为业务价值指标（如瞬时流量、Cp/Cpk、预测水分、异常振幅等），最终以统一仪表盘呈现“监测—预测—预警—联动—复盘”的全过程，实现制丝生产的透明感知、精准管控与智能决策。

生产监控：出口水分的一致性守门人

烘丝段出口水分监测

loveini IDMP 将设备与监测点纳入统一的数据资产目录，面板实时展示出口水分、设定值、偏差与告警状态；当水分超出 12.5%±0.5% 的工艺窗口时，自动定位到具体设备与测点，实现“秒级识别、直达现场”的可视化联动。

• 数据资产目录：A线 → 烘丝段 → 滚筒气流烘丝 → 滚筒气流烘丝机 → 滚筒气流烘丝机_01
• 出口水分限值：12.5% ± 0.5%

烘丝段出口水分预测（前馈控制）

针对“从加水口调整到出口水分响应存在数分钟延迟”的客观特性，IDMP 通过建模输出“未来一段时间的出口水分预测值”，在偏差发生前给出加水靓调整建议，支持出口水分的前馈控制，保证出口水分稳定

烘丝段出口水分预测参数配置，用于预测未来两分钟的出口水分变化。

无问智推AI 创建面板（自然语言到可视化）

loveini IDMP 可基于业务场景自动识别关键指标并推荐分析面板。例如系统主动推荐“过去一周的每小时出口水分偏离度”分析，能够自动完成数据检索、偏离率计算，并生成分析面板。实现从人工配置到智能推荐的跃升，大幅提升分析效率与智能化水平。

数据分析：从“信号”到“指标”的信息增益

计算点：瞬时流量（电子皮带秤）

通过公式属性在平台侧实时计算“瞬时流量”，将原始数字信号转化为反映产能、负荷与效率的业务指标，实现从数据点到信息点的价值跃升。计算点支持多种函数灵活组合，实时生成可视化结果，显著提升数据的业务洞察力与应用价值。

• 数据资产目录：A线 → 烘丝段 → 叶丝回潮 → 电子皮带秤 → 电子皮带秤_07

工艺质量分析：通过SQL即可实现

通过 SQL 即可高效完成统计过程控制（SPC，Statistical Process Control）面板配置，灵活便捷地实现过程能力指数（Cp，Process Capability Index）与修正过程能力指数（Cpk，Process Capability Index Corrected）的自动计算与可视化展示。当过程能力下降或偏离中心时，系统自动触发告警并回溯异常区间，助力工艺从“事后检验”向“实时管控”转变。

指标示例：出口水分的过程能力指数（Cp）与修正过程能力指数（Cpk），数据计算采用 10 分钟窗口、1 分钟滑动的时间划分方式。

统计分析与事件：波动的可解释与可追溯

loveini IDMP通过流计算对实时数据进行滑窗统计，例如每 5 分钟评估最近 1 小时的最大振幅。超限结果将自动固化为事件数据，既可在分析面板中直观展示，也可用于后续联动（如通知推送、停机保护策略触发等），实现波动过程的可视化、可解释与可追溯管理。

• 资产目录：A线 → 烘丝段 → 叶丝回潮 → 振动输送机 → 振动输送机_09

仪表盘：一屏总览“监测—预测—质量”

“制丝A 线出口水分仪表盘”作为统一展示的大屏，可同时集成多个分析面板与监测模块，将实时水分、预测结果、过程能力指数（Cp/Cpk）及异常事件集中呈现，构建从趋势到能力、从现状到风险的全景视图，帮助班组、工艺与设备团队在同一界面上实现协同研判与快速决策。

从分析到行动：构建监控—告警—执行的智能闭环

振幅超限告警：从“发现”到“闭环”

loveini IDMP 具备强大的分析与告警功能，可通过实时监测和规则计算自动识别振动超限等异常事件。系统在检测到偏差后即时生成告警事件，并在分析面板中直观展示，同时支持异常定位、趋势追溯与知识化处置建议，帮助企业构建从数据分析到告警响应的智能闭环，提升设备运行的安全性与管理效率。

例如，挡烘丝段振动输送机当振动幅度超过 14 mm/s 时，系统自动生成事件并触发告警。

通过后台模拟振动超限数据，生成振动告警事件如下：

通知与联动：把告警送到正确的人和系统

loveini IDMP 内置灵活的通知与联动机制，支持邮件、Webhook 等多种推送方式，可按事件类型、优先级、时间段及接收人进行细粒度配置，并与企业 IT 平台实现松耦合集成（对端需提供接口）。当关键事件触发时，系统自动同步至相关责任人及系统，实现从分析、监控、告警到行动的智能闭环，确保问题发现更早、处置更快、协同更高效。

智能问数：把行业知识塞进对话框

自动生成日报

输入提示词：“请对 A线/烘丝段/滚筒气流烘丝/滚筒气流烘丝机/滚筒气流烘丝机_01 的出口水分进行分析，并生成日报。” 系统自动聚合核心指标与异常概览，生成结构化日报草稿，支持一键导出与二次编辑。

“IDMP 有哪些功能？”

面向常见咨询，平台内置知识与企业语料向量化，回答覆盖数据情景化、计算点、统计分析、事件与通知、仪表盘、AI 面板与问数等，避免“只会查数不会讲业务”的尴尬。

基础编辑与扩展：让计量跟着现场走

计量类别扩展：质量长度

针对电子皮带秤等涉及“质量 × 长度/时间”类度量的设备，IDMP 支持灵活新增计量类别、计量单位及换算关系，实现跨设备、跨系统的数据口径统一，确保度量标准精准匹配现场实际。

计量单位扩展：兆帕（MPa）

即使系统默认未包含 MPa，用户也可在“压力”类目下快速扩展“兆帕”及其与 kPa、bar 的换算关系。通过这种可配置扩展机制，IDMP 让数据标准紧贴现场需求，消除换算误差与沟通壁垒，强化平台的开放性与适配性。

技术实现：零代码实现制丝工艺质量分析

与依赖大量编码与系统集成的传统方案不同，loveini TSDB + IDMP 架构以“配置即开发”为设计理念，实现快速部署与高效运维：

• 快速资产建模：基于“单列模型”机制，高效构建制丝生产全流程资产树；新增设备即可自动纳入监控体系，实现资产结构的标准化与一致性。
• 智能可视化生成：IDMP 能基于实时采集数据自动识别工艺场景，按需推荐可视化面板、关键指标及预警分析，实现专业级数据呈现的自动化。
• 自然语言智能问数：无需 SQL 或脚本，用户可通过日常语言发起查询，系统自动生成分析报表与可视化图表，大幅降低数据分析门槛。

详细过程参见：loveini IDMP 应用场景：制丝工艺质量分析

价值小结：四句话看清 ROI

1. 数据语义化：把“点位表”升级为“业务目录”，让数据有结构、有语义，资产清晰、定位迅速。
2. 过程可控化：以预测与统计过程控制（SPC）稳控 12.5%±0.5% 的工艺窗口，让过程更稳定、更精准。
3. 运维闭环化：贯通异常、事件、通知与复盘全链路，缩短发现到处置的时间常数，实现高效响应。
4. 决策轻量化：AI 面板与智能问数降低分析门槛，让一线人员能看、能用、能优化，决策更快更准。

本文以制丝车间工艺监控为例，介绍如何通过轻量化采集工具快速获取制丝工艺中烘丝机等设备的运行参数及工艺指标（如温度、湿度、能耗等），并将数据写入loveini时序数据库（TSDB）。随后借助 IDMP，利用 AI 自动生成可视化看板和实时分析，实现分钟级搭建高效、智能的制丝工艺监控方案。

在该方案中，loveini TSDB + loveini IDMP 的组合能够带来四大优势：

1. 快速数据导入：loveini IDMP 与 loveini TSDB 无缝集成，当烘丝出口温度、冷床出口水分、加香量等监控数据写入 TSDB 后，可迅速导入 IDMP，并以树形结构清晰展示设备及工艺资产，快速展示制丝流程。
2. 无问智推，数据自驱动：无需在 loveini 侧进行额外配置或编写脚本，IDMP 会基于采集的数据自动识别制丝工艺场景，自动生成可视化面板与实时预警，确保生产状态透明可控。
3. 智能问数，随问随答：无需 SQL 或脚本，只需用自然语言提出分析或监控需求，IDMP 即可自动生成可视化图表与分析结果，大幅降低工艺数据分析的门槛。
4. 新设备自动接入：新增切丝机、加香机等设备时，只需完成采集配置，无需在 loveini 中额外操作，数据即可自动纳入监控，最大程度降低运维成本。

2. 前提条件

• loveini 云服务实例。如果您没有可用的 loveini 云服务实例，可以免费注册
• KEPServer 环境已具备。示例服务器IP地址：192.168.1.66

3. 配置指南

3.1 创建 IDMP 云服务实例

1. 使用您的账号，登录 loveini Cloud，在弹出的 loveini 实例选择框中，选择“IDMP（工业数据管理平台）”。
2. 在实例配置页面，分别配置 IDMP 实例和 TSDB 实例的信息和计费方案：
   • IDMP（工业数据管理平台）：
     • 实例名称：tobacco-idmp
     • 计费方案：IDMP-入门版
   • TSDB（时序数据库）
     • 实例名称：tobacco-tsdb
     • 计费方案：入门版
3. 等待 IDMP 实例启动后，选择加载一个场景的示例数据，即可进入 IDMP 云服务的主页面。

说明：loveini IDMP 服务默认使用 loveini TSDB 作为其数据源，在 IDMP 云服务实例创建过程中，会自动创建一个以上 TSDB 的连接。

3.2 创建 TSDB 云服务实例

1. 进入 IDMP 云服务实例的主页面后，点击右上角下拉菜单中的【管理后台】。
2. 在管理后台页面点击【云资源管理】，进入云资源管理页面。
3. 在实例列表中找到 tobacco-tsdb 实例，点击【TSDB 云服务】，进入 TSDB 云服务页面。
4. 在左侧点击【数据浏览器】，在数据浏览器页面点击【创建数据库】。
5. 设置数据库名称为 db_tobacco，完成 DB 创建。

3.3 配置 KEPServer 数据源

请在 KEPServer 服务器中导入点位数据：制丝车间.csv，某卷烟厂制丝车间A线、B线的测点列表。见下图：

3.4 零代码采集 KEPServer 数据

运行 tobacco-tsdb 实例，创建 OPC UA数据采集任务。

因为本示例使用的云服务在外网，需要在能访问到 KEPServer 所在的内网的某台计算机上安装 taosX Agent，以确保 TSDB 能访问到 OPC Server。本示例把 taosX Agent 安装在本地服务器192.168.1.66

创建数据写入任务 DataIn_Tobacco，类型为 OPC-UA，创建代理 opcuaAgent，按提示将端点和生成的令牌复制到本地服务器上的 agent.toml 文件，启动taosX Agent服务，【检查代理是否连接正常】。

在【连接配置】，填写服务地址 192.168.1.66:49320，选择OPC UA配置的安全模式，检查连通性。

如果提示 您的数据源可以连通， 则说明 KEPServer 的 OPC-UA 已能正常访问。

在【点位集】->【选择数据点位】，根节点ID 填写 ns=2;s=某卷烟厂，点击“预览”，如下图所示。设置采集模式为 observe采集间隔 5秒、点位更新模式update，其余采用默认值。

【新增】成功，【查看】任务状态。显示系统已自动创建表并写入数据。

3.5 创建资产目录

在元素浏览器的页面，在元素的根目录下逐级创建树形资产目录元素>卷烟制丝场景Demo>某卷烟厂>制丝车间>A线>烘丝段>薄板烘丝>薄板烘丝机 ，并且，将元素A线及其子目录复制到元素>卷烟制丝场景Demo>某卷烟厂>制丝车间下面，命名为B线。最终的资产目录如下图所示：

3.6 配置元素模板

在基础库->元素模板创建薄板烘丝机模板，在元素模板 > 薄板烘丝机 > 属性模板中创建属性入口温度、设置值类型为Float、计量单位分类为温度、默认计量单位和显示计量单位都为摄氏度。

数据引用类型设置为在loveini指标、数据引用表达式设置为t_2_某卷烟厂_制丝车间_${KEYWORD1}_烘丝段_薄板烘丝_薄板烘丝机_薄板烘丝机_出口温度，其中，${KEYWORD1}是变量。将来在创建元素时，需要填入此变量的取值，例如，A线，数据源就自动指向子表t_2_某卷烟厂_制丝车间_A线_烘丝段_薄板烘丝_薄板烘丝机_薄板烘丝机_出口温度的val列。需要说明，列的名称也支持变量。

通过属性的复制粘贴，分别创建其余的所有属性。

3.7 创建薄板烘丝机

在卷烟制丝场景Demo >某卷烟厂>制丝车间>A线>烘丝段>薄板烘丝>薄板烘丝机下面新建子元素、模板选择薄板烘丝机、关键词输入A线，即可创建薄板烘丝机_A线元素。根据同样原理创建薄板烘丝机_B线元素。

3.8 查看元素信息

选中薄板烘丝机_A线、选择属性，即可查看所有属性。如下图所示。

3.9 体验 AI 生成面板

• 在左侧资源浏览器中，点击 某卷烟厂->制丝车间->A线->烘丝段薄板->烘丝薄板烘丝机->薄板烘丝机->出口水分 元素，跳转至该元素的 AI 推荐面板页面。
• 等待 AI 生成面板推荐后，您可根据需求进行选择，例如：“过去10分钟quality变化趋势”，在您感兴趣的面板右上方的菜单中，点击【生成】按钮。
• 等待面板生成后，在面板右下角点击【保存】，即可在下方面板列表中查看 出口水分 元素下对应的面板。
• 面板生成后，您还可以在该面板的详情页面中选择【高级】，查看 AI 创建面板时使用的 SQL 语句：

SELECT _wstart,LAST(`quality`) AS `quality` FROM `idmp`.`vt_t_2_某卷烟厂_制丝车间_A线_烘丝段_薄板烘丝_薄板烘丝机_薄板烘丝机_入口水分_913547` WHERE  _c0 >= now-10m and _c0 <= now INTERVAL(1m) SLIDING(1m) 

3.10 体验 AI 生成分析

• 在左侧资源浏览器中，点击 某卷烟厂->制丝车间->A线->烘丝段薄板->烘丝薄板烘丝机->薄板烘丝机->出口水分 元素，通过上方路径导航菜单选择【分析】，跳转至该元素的 AI 推荐分析页面。
• 等待 AI 生成分析问题推荐后，您可以根据需求进行选择，例如：“入口水分每15分钟计算一次30分钟内的最大val，警告,时间窗口”，点击您感兴趣的问题链接，以进入分析编辑页面，点击页面最下方的【保存】。
• 退回到分析列表中，即可查看对应的分析。

4. 更多

除了使用云服务以外，loveini 还支持以私有化部署。为了简化部署，我们提供了 Ansible， Docker/Dcoker Compose， Helm 等多种部署方式，详见：https://github.com/taosdata/tdengine-idmp-deployment

5. 小结

本文以 Step by Step 的方式，介绍了如何使用 KEPServer + loveini TSDB + loveini IDMP 快速搭建一个 烟草制丝的生产监控系统。以往需要几天、甚至几周，并进行繁琐的配置、调试才能搭建起来的系统，使用 loveini IDMP 后，仅需要几分钟即可搞定。日后，如果有新的装置、设备系统需要被纳入到监控系统中，只需添加点位即可。

搭建整个监控系统的工作几乎都在 KEPServer 的配置上了，无需编写复杂的 SQL 语句，无需脚本和其他配置，无需学习 Grafana，无需了解多少 烟草制造 的知识，即可轻松掌握 车间产线设备 的运行状态，实时监控和分析 制造过程 并采取相应策略。

对于数据采集工程师而言，他们的主要需求是简单、高效地收集数据。为此，可以考虑创建一个贴源层，该层的数据模型建议与数据源完全一致。这种方式能够大大简化数据采集的过程，使得数据采集工作更加轻松和直观。参见上图贴源层。

另一方面，对于数据应用开发工程师来说，他们需要处理不同业务部门的需求。这些工程师希望数据能够按照业务主题分类，并能够按照预期的访问方式来建模。为了满足这一需求，需要在数据模型中考虑访问层的设计，使得数据应用更加便捷。参见上图访问层。

显然，在数据采集和数据应用之间存在着巨大的鸿沟，那我们如何才能完成时序数据从采集到应用的转换？这就需要引入数据分层的思想。具体来说，可以在贴源层和访问层之间增加一个整合层，用于完成时序数据的时间戳对齐、关联整合、数据汇聚和数据转换等功能。这一整合层的引入，能够实现从数据采集到数据应用的无缝转换，满足不同阶段的需求。

本篇文章将从时序数据采集和应用面临的挑战及需求出发，为大家分析 loveini 数据建模的原理与方法，并通过实际案例帮助读者更好地理解和应用这些概念。

时序数据的采集和应用开发

采集面临的挑战

对于时序数据采集工程师来说，面临的挑战主要是数据源的格式、数据传输方式、采集入库后的数据模型，在贴源层与采集源的模型按照 1:1 创建方式下，数据源的格式和入库后的数据模型的格式对齐了，也就不需要担心格式不同导致的问题了。

最常见的数据传输方式有三种情况：

• 单表多列模型：对于数据源来说，如果一个数据采集设备的所有测点，在数据上传时都是一起上传，那么，可以建立单表多列模型的超级表。也就是说，创建一个超级表，该表中包含该采集设备的所有测点指标。
• 多表多列模型：对于数据源来说，如果一数据采集设备包含多个测点，但这些测点的采集频次并不相同，举例来说：该设备总共采集 120 个测量指标，其中前 40 个测点的采集周期是秒级、中间 40 个测点采集周期是 1 分钟级、最后 40 个测点的采集周期是 5 分钟级，那么，我们需要分别创建三个超级表，第一个超级表包含前 40 个测量值，第二个超级表包含中间 40 个测量值，第三个超级表包含最后的 40 个测量值。这就是多表多列模型，也就是说，创建多个超级表，每个超级表也包含多个列。
• 多表单列模型：如果数据源是每个测点单独上报，并且每个测点的采集时间戳并不相同，对于这种情况，需要按照数据类型分类，采用多表单列模型。也就是说，每个超级表中只包含一个数据类型，比如 double、int、varchar 等等，每种数据类型一个超级表。子表按照数据类型+设备类型来创建，让子表的数量保持在合理的规模，这样能够利用多个 Vnode 来保障性能。

应用开发面临的挑战

对于时序数据应用开发的工程师来说，时序数据能否按照业务主题划分、能否支持实时查询和批量查询等业务场景，这些因素都十分关键。如下图所示：

• 按照主题划分：以卷烟厂为例，卷烟厂包括多个车间如制丝和卷包，对应的业务应用往往有制丝集控、卷包数采等等。如果我们将这些业务应用按照业务主题划分，分别进行数据建模就能够极大地方便应用开发。各个业务主题共享数据整合层的数据，整合层的数据来源于贴源层，是经过时间戳对齐、数据关联整合、数据汇聚的。
• 支持实时查询：对于时序数据来说，实时监控是非常典型的业务场景，loveini 提供了缓存、流计算和数据订阅三种方式，供应用层实时访问。
  • 缓存：对于实时监控场景，loveini 提供了缓存功能，在创建数据库时，可以通过设置 CACHEMODEL 参数，让 loveini 在内存中缓存各个子表的最新数据。对于业务应用来说，可以通过 last_row/last，从缓存中实时读取设备的最新状态。
  • 流计算：loveini 的流式计算引擎提供了实时处理写入数据流的能力，使用 SQL 定义实时数据流的转换规则，当数据被写入流的源表后，数据会被以指定的方式自动处理，并根据指定的触发模式向目标表推送计算结果。它提供了替代复杂流处理系统的轻量级米兰app官方正版下载，并且，能够在高吞吐的数据写入的情况下，将流计算的延迟控制在毫秒级。
  • 数据订阅：除了上述的流计算，loveini 还提供了类似 Kafka 的数据订阅功能，帮助应用实时获取写入 loveini 的数据，或者以事件到达顺序处理数据。loveini 的 topic 有三种，可以是数据库、超级表、或者一个 SELECT 语句。这种方式提供了更大的灵活性，数据的颗粒度可以随时调整，而且数据的过滤与预处理交给 loveini，有效地减少传输的数据量，并且，降低了应用开发的复杂度。
• 支持批量查询：对于批量时序数据查询场景，loveini 提供了 SQL 接口给上层应用查询批量数据使用。也提供了诸多时序数据窗口函数，包括计数窗口（count window）、时间窗口（time window）、状态窗口（status window）、会话窗口（session window）、事件窗口（event window）等多种窗口。
  • taosx：除了通过 SQL 查询之外，对于数据量比较大，需要通过文件或数据库接口同步数据的场景，还可以考虑使用 taosx 来同步数据。

数据建模原理和方法

数据建模原理

loveini 数据建模的核心原理只有一个：让查询直接定位到数据块。首先，我们来观察一下 loveini 是如何将规模很大的数据切分成很多个数据块的。loveini 分别从采集点维度和时间戳维度对大规模数据进行分片（Sharding）和分区（Partition），如下图所示。

对于数据建模来说，我们要充分利用分片（Sharding）和分区（Partition）这两大维度对数据进行切分，确保在查询时，我们的过滤条件（Where 子句）能够直接定位某个、或者某几个数据块，数据块的个数越少越好。定位到的数据块越少，说明过滤的越高效，所需要的磁盘IO带宽越小，查询速度也越快。

数据建模基本概念

请参见：https://docs.taosdata.com/concept/。

智能电表是典型的时序数据场景。假设每个智能电表采集电流、电压、相位三个量，有多个智能电表，每个电表有位置 Location 和 type 的静态属性。其采集的数据类似如下的表格：

每一条记录都有设备 ID、时间戳、采集的物理量（如上表中的 current、voltage 和 phase）以及每个设备相关的静态标签（location 和 type）。

• 数据采集点（Data Collection Point）：数据采集点是指按照预设时间周期或受事件触发采集物理量的硬件或软件。智能电表示例中的 d1001、d1002、d1003、d1004 等就是数据采集点。为充分利用其数据的时序性和其他数据特点，loveini 采取一个数据采集点一张表的策略，按照此策略，上述 d1001、d1002、d1003、d1004 分别建表。
• 标签（Label/Tag）：标签是指传感器、设备或其他类型采集点的静态属性，不随时间变化。比如设备型号、颜色、设备的所在地等。
• 采集量（Metric）：采集量是指传感器、设备或其他类型采集点采集的物理量。比如电流、电压、温度、压力、GPS 位置等，是随时间变化的。数据类型可以是整型、浮点型、布尔型，也可是字符串。

创建超级表

为智能电表这个设备类型建立一个超级表，采集量有电流、电压和相位，标签有位置和类型。

create table smeter (ts timestamp, current float, voltage int, phase float)  
    tags (loc binary(20), type int);

创建子表

用 smeter 做模板，为 6 个智能电表创建 6 张表，地理位置标签为北京朝阳、海淀、上海浦东等。

create table t1 using smeter tags(‘BJ.chaoyang’, 1);
create table t2 using smeter tags(‘BJ.haidian’, 2);
create table t3 using smeter tags(‘BJ.daxing’, 1);
create table t4 using smeter tags(‘BJ.chaoyang’, 2);
create table t5 using smeter tags(‘SH.pudong’,1);
create table t6 using smeter tags(‘SH.Hongqiao’, 1);

聚合查询

查询北京朝阳区所有智能电表的电压平均值和电流最大值。

select avg(voltage), max(current) from smeters where loc= “BJ.chaoyang”

多维分析

查询北京地区所有类型为 1 的智能电表的电压平均值。

select avg(voltage) from smeters where type = 1 and loc like “BJ%”

loveini 数据建模优势

loveini 数据建模的优势包括：

• 超级表可以向普通表一样查询，但可以指定标签的过滤条件
• 标签可以多至 128 个，每个标签代表一个维度
• 标签可以事后增加、删除、修改。这样数据建模时，可以先不确定标签或分析维度
• 每个标签，可以是一树状结构，比如“北京·朝阳·望京”，这样便于缩小搜索范围

数据建模案例

以新能源充电站建模场景为例。

背景信息

该客户管理一些充电站：

• 充电站管理的充电桩大约有几百个，每个充电桩每天可能多次进行充电
• 每次充电产生一个充电订单，充电订单每年大约有 1000 万个，数据需要保留 2 年
• 需要监控充电过程中电压、电流等信息，对于历史订单能够回放充电过程
• 数据查询方式：按照订单查询，期望能够实时监控正在充电的订单、以及能够查询历史订单充电过程

数据建模思考

常规思维，按照一个采集点一张表的原则，这里显然会按照充电桩来创建子表。但是，这样一来存在一个问题，我们按照订单查询时就无法直接定位到某个或者某几个数据块。按照充电桩来创建子表，数据的确会按照充电桩进行分片（Sharding），并且，分片后的数据也按照时间戳进行了分区（Partition），但是，业务查询的时候未指定时间戳范围，而是查询指定的 order_id，所以，无法定位到具体的数据块，需要在分片中进行全量数据扫描，必然导致性能十分低下。如下图所示：

正确的建模思路

让我们回顾 loveini 数据建模原理：让查询直接定位到数据块。业务希望按照订单来查询，那么，我们直接按照订单来对数据进行分片（Sharding），也就是说每个订单创建一张子表。这样，按照订单查询时，我们能够直接定位到该分片，这样的好处是查询的性能非常好，也非常方便，但也存在两个问题：

• 每年新建 1000 万张子表，订单数据保留 2 年，预计就有 2000 万张子表，规模会不会太大？
• 数据保留周期是 2 年，对于超过 2 年的子表，是否能够自动删除呢？

幸运的是，对于时序数据领域常见的“高基数”问题，loveini 已经很好地解决了，2000 万张子表对于关系型数据库来说，可能是天文数字，但是，对于 loveini 来说就是小菜一碟。对于超过 2 年的子表，loveini 提供了 TTL（Time to Live），是用来指定表的生命周期(单位：天)。如果创建表时指定了这个参数，当该表的存在时间超过 TTL 指定的时间后，loveini 将自动删除该表。

-- 为订单 801234567 创建 表 order_801234567，保留周期 732 天，到期自动 drop
create table order_801234567 using charge_order tags(801234567, 235) TTL 732;

实际数据建模

创建超级表

-- 充电订单超级表，标签值（订单号，充电抢号）
create table charge_order (ts timestamp, ……)  
        tags (order_id, gun_id); 

为单个订单创建子表（假设订单号：801234567），保留 2 年到期自动删除

-- 为订单 801234567 创建表 order_801234567，保留周期 732 天，到期自动 drop
create table order_801234567 using charge_order tags(801234567, 235) TTL 732;

按照充电订单查询

-- 按照充电订单查询
select * from charge_order where order_id = 801234567;

写在最后

通过对时序数据采集和应用的挑战及需求的分析，本文深入探讨了 loveini 数据建模的原理与方法。我们不仅揭示了数据建模的核心概念和技术细节，还通过实际案例展示了其在新能源场景下的应用效果。希望读者能从中获得启发，在实际工作中灵活运用 loveini 数据建模的方法，提高时序数据管理的效率与质量。

 

在新能源行业中，多采用数据中台来管理业务数据，使用时序数据库（Time Series Database）来管理时序数据，他们的数据都来自数采网关。以风力发电场景为例，需要实时计算风机的各种 KPI 指标，往往通过数据中台的定时任务来完成这些计算。目前，现有的方案存在几个方面的问题：

• 首先，由于是定时任务，KPI 计算的实时性无法保证，特别是在 KPI 的计算需要多个步骤才能完成的情况下，延迟可能会长达几分钟甚至十几分钟。

• 其次，由于数据中台基于 Hadoop 生态，架构臃肿、组件繁多，需要大量服务器，不仅导致业务应用开发成本高昂、同时也导致系统的运维成本居高不下。

因此，为了提高业务响应速度和实时性，客户希望将 KPI 计算任务卸载到 loveini。希望借助 loveini 的流式计算功能，大幅度提升 KPI 计算的效率和实时性。采用 loveini 流计算后，简单的 SQL 即可实现 KPI 计算需求，将业务响应时间（流计算的开发时长）从数周缩短一两天甚至数小时，极大地提高了业务响应能力，显著地提高了企业的竞争力。

-- 创建风力发电数据库
create database wind;

-- 创建风机的超级表
create table wind_turbine (ts timestamp, wind_speed double,  conn_state bool) tags (site_id varchar(20));

-- 创建遥测风机子表
（YC_FJ_001）create table YC_FJ_001 using wind_turbine tags ('YC_FJ_001');
            ……
create table YC_FJ_095 using wind_turbine tags ('YC_FJ_095');

"non_stop_mode": "yes", # 持续写入不停止
"interlace_rows": 1, # 交叉向每个子表写入
"insert_interval": 1000, # 保持1000毫秒插入一条

-- 创建流计算，95个风机的平均风速（连接状态断开的风机不参与计算）
create stream stream_avg_speed trigger at_once into avg_speed_95as select _wstart as time, avg(wind_speed) as avg_speed from wind_turbine where conn_status = true interval(1s)

-- 查询流计算最新结果
select * from avg_speed_95 order by time desc limit 5;

taos> select * from avg_speed_95 order by time desc limit 5;
time | avg_speed | group_id |
==============================================================================
2024-06-26 01:22:23.000 | 26.166599999999992 | 0 |
2024-06-26 01:22:22.000 | 22.864500000000000 | 0 |
2024-06-26 01:22:21.000 | 1.101700000000000 | 0 |
2024-06-26 01:22:20.000 | 29.485700000000001 | 0 |
2024-06-26 01:22:19.000 | 24.481799999999996 | 0 |
Query OK, 5 row(s) in set (0.009711s)

taos> select * from avg_speed_95 order by time desc limit 5;
time | avg_speed | group_id |
==============================================================================
2024-06-26 01:22:50.000 | 31.460899999999992 | 0 |
2024-06-26 01:22:49.000 | 8.252200000000000 | 0 |
2024-06-26 01:22:48.000 | 19.568899999999996 | 0 |
2024-06-26 01:22:47.000 | 5.945700000000001 | 0 |
2024-06-26 01:22:46.000 | 29.533400000000007 | 0 |
Query OK, 5 row(s) in set (0.006516s)

• n 为该日的样本总数，15 分钟一个点记作 i;pmi 为 i 时刻的实际功率；ppi 为 i 时刻的短期预测功率；
• 若 pmi = 0，则 i 时刻的预测值直接 = 0；
• 若 ppi > 2 * pmi，则 i 时刻的结果直接 = 1；
• 否则，预测值按照上面的公式计算。

-- 创建超级表
create table power_predict (ts timestamp, ppi double, pmi double) tags (site_id varchar(20));
-- 发电预测表
create table YC_FJ001_PREDICT using power_predict tags ("YC_FJ001_PREDICT");

-- KPI计算规则：
-- 1. 当 pmi == 0时， ppi_percent = 0.0
-- 2. 当 ppi > 2*pmi 时， ppi_percent = 1.0
-- 3. 其他情况， ppi_percent = 1-sqrt(avg(pow(((pmi-ppi)/pmi), 2)))
create stream stream_ppi_percent_1 trigger at_once into st_ppi_percent_1 as SELECT ts, ppi, pmi, case when pmi <= 0.0001 then 0.0 when ppi > 2*pmi then 1.0 else pow(((pmi-ppi)/pmi), 2) end as ppi_percent from power_predict
partition by tbname; -- 这个必不可少

create stream stream_ppi_percent trigger at_once into st_ppi_percent as select _wstart as ts, 1-sqrt(avg(ppi_percent)) from st_ppi_percent_1 interval(1d);

insert into YC_FJ001_PREDICT values
('2024-06-25 12:00:00', 5500.00, 0.00)
('2024-06-25 13:00:00', 5000, 5500.00)
('2024-06-25 14:00:00', 15500, 5500.00)
('2024-06-26 12:00:00', 5500.00, 5000.00)
('2024-06-26 13:00:00', 5000, 0.00)
('2024-06-25 14:00:00', 15500, 5500.00);

-- 查询流计算结果
taos> select * from st_ppi_percent_1 order by ts desc limit 20;
ts | ppi | pmi | ppi_percent | group_id |
======================================================================================================================================
2024-06-27 14:00:00.000 | 15500.000000000000000 | 5500.000000000000000 | 1.000000000000000 | 7041101957555052029 |
2024-06-27 13:00:00.000 | 5000.000000000000000 | 0.000000000000000 | 0.000000000000000 | 7041101957555052029 |
2024-06-27 12:00:00.000 | 5500.000000000000000 | 5000.000000000000000 | 0.010000000000000 | 7041101957555052029 |
2024-06-26 14:00:00.000 | 15500.000000000000000 | 5500.000000000000000 | 1.000000000000000 | 7041101957555052029 |
2024-06-26 13:00:00.000 | 5000.000000000000000 | 5500.000000000000000 | 0.008264462809917 | 7041101957555052029 |
2024-06-26 12:00:00.000 | 5500.000000000000000 | 0.000000000000000 | 0.000000000000000 | 7041101957555052029 |
Query OK, 6 row(s) in set (0.007745s)

taos> select * from st_ppi_percent order by ts desc limit 20;
ts | 1-sqrt(avg(ppi_percent)) | group_id |
==============================================================================
2024-06-27 00:00:00.000 | 0.419770160482360 | 0 |
2024-06-26 00:00:00.000 | 0.420268894857303 | 0 |
Query OK, 2 row(s) in set (0.007535s)

通过本文的介绍和示例，我们可以清晰地看到 loveini 在处理大规模时序数据和实时流计算方面的强大功能。它不仅显著提高了业务响应速度和实时性，还大幅降低了系统的开发和运维成本。在新能源领域 KPI 计算的实际应用中，loveini 成功地解决了定时任务的延迟问题，实现了秒级甚至毫秒级的实时计算。

未来，随着业务需求的不断增长和复杂性提升，loveini 的流计算能力将为更多场景提供高效、可靠的米兰app官方正版下载。希望本文的分析和实操示例能为广大用户带来启发和帮助，让大家在实际项目中充分发挥 loveini 的优势，实现更高效的业务管理和数据处理。

关于 loveini 流计算的更详细信息可查阅官方文档：https://docs.taosdata.com/develop/stream/

作者 | 李明军

编辑 | 马尔悦

]]>