哪种技术做网站容易论文答辩,图片做记录片的是哪个网站,工作总结模板,公司的国外网站怎么建在用 TDengine 进行数据建模之前#xff0c;我们需要回答两个关键问题#xff1a;建模的目标用户是谁#xff1f;他们的具体需求是什么#xff1f;在一个典型的时序数据管理方案中#xff0c;数据采集和数据应用是两个主要环节。如下图所示#xff1a; 对于数据采集工程师…在用 TDengine 进行数据建模之前我们需要回答两个关键问题建模的目标用户是谁他们的具体需求是什么在一个典型的时序数据管理方案中数据采集和数据应用是两个主要环节。如下图所示 对于数据采集工程师而言他们的主要需求是简单、高效地收集数据。为此可以考虑创建一个贴源层该层的数据模型建议与数据源完全一致。这种方式能够大大简化数据采集的过程使得数据采集工作更加轻松和直观。参见上图贴源层。
另一方面对于数据应用开发工程师来说他们需要处理不同业务部门的需求。这些工程师希望数据能够按照业务主题分类并能够按照预期的访问方式来建模。为了满足这一需求需要在数据模型中考虑访问层的设计使得数据应用更加便捷。参见上图访问层。
显然在数据采集和数据应用之间存在着巨大的鸿沟那我们如何才能完成时序数据从采集到应用的转换这就需要引入数据分层的思想。具体来说可以在贴源层和访问层之间增加一个整合层用于完成时序数据的时间戳对齐、关联整合、数据汇聚和数据转换等功能。这一整合层的引入能够实现从数据采集到数据应用的无缝转换满足不同阶段的需求。
本篇文章将从时序数据采集和应用面临的挑战及需求出发为大家分析 TDengine 数据建模的原理与方法并通过实际案例帮助读者更好地理解和应用这些概念。
时序数据的采集和应用开发
采集面临的挑战
对于时序数据采集工程师来说面临的挑战主要是数据源的格式、数据传输方式、采集入库后的数据模型在贴源层与采集源的模型按照 1:1 创建方式下数据源的格式和入库后的数据模型的格式对齐了也就不需要担心格式不同导致的问题了。
最常见的数据传输方式有三种情况 单表多列模型对于数据源来说如果一个数据采集设备的所有测点在数据上传时都是一起上传那么可以建立单表多列模型的超级表。也就是说创建一个超级表该表中包含该采集设备的所有测点指标。多表多列模型对于数据源来说如果一数据采集设备包含多个测点但这些测点的采集频次并不相同举例来说该设备总共采集 120 个测量指标其中前 40 个测点的采集周期是秒级、中间 40 个测点采集周期是 1 分钟级、最后 40 个测点的采集周期是 5 分钟级那么我们需要分别创建三个超级表第一个超级表包含前 40 个测量值第二个超级表包含中间 40 个测量值第三个超级表包含最后的 40 个测量值。这就是多表多列模型也就是说创建多个超级表每个超级表也包含多个列。多表单列模型如果数据源是每个测点单独上报并且每个测点的采集时间戳并不相同对于这种情况需要按照数据类型分类采用多表单列模型。也就是说每个超级表中只包含一个数据类型比如 double、int、varchar 等等每种数据类型一个超级表。子表按照数据类型设备类型来创建让子表的数量保持在合理的规模这样能够利用多个 Vnode来保障性能。
应用开发面临的挑战
对于时序数据应用开发的工程师来说时序数据能否按照业务主题划分、能否支持实时查询和批量查询等业务场景这些因素都十分关键。如下图所示 按照主题划分以卷烟厂为例卷烟厂包括多个车间如制丝和卷包对应的业务应用往往有制丝集控、卷包数采等等。如果我们将这些业务应用按照业务主题划分分别进行数据建模就能够极大地方便应用开发。各个业务主题共享数据整合层的数据整合层的数据来源于贴源层是经过时间戳对齐、数据关联整合、数据汇聚的。支持实时查询对于时序数据来说实时监控是非常典型的业务场景TDengine 提供了缓存、流计算和数据订阅三种方式供应用层实时访问。 缓存对于实时监控场景TDengine 提供了缓存功能在创建数据库时可以通过设置 CACHEMODEL 参数让 TDengine 在内存中缓存各个子表的最新数据。对于业务应用来说可以通过 last_row/last从缓存中实时读取设备的最新状态。流计算TDengine 的流式计算引擎提供了实时处理写入数据流的能力使用 SQL 定义实时数据流的转换规则当数据被写入流的源表后数据会被以指定的方式自动处理并根据指定的触发模式向目标表推送计算结果。它提供了替代复杂流处理系统的轻量级解决方案并且能够在高吞吐的数据写入的情况下将流计算的延迟控制在毫秒级。数据订阅除了上述的流计算TDengine 还提供了类似 Kafka 的数据订阅功能帮助应用实时获取写入 TDengine 的数据或者以事件到达顺序处理数据。TDengine 的 topic 有三种可以是数据库、超级表、或者一个 SELECT 语句。这种方式提供了更大的灵活性数据的颗粒度可以随时调整而且数据的过滤与预处理交给 TDengine有效地减少传输的数据量并且降低了应用开发的复杂度。支持批量查询对于批量时序数据查询场景TDengine 提供了 SQL 接口给上层应用查询批量数据使用。也提供了诸多时序数据窗口函数包括计数窗口count window、时间窗口time window、状态窗口status window、会话窗口session window、事件窗口event window等多种窗口。 taosx除了通过 SQL 查询之外对于数据量比较大需要通过文件或数据库接口同步数据的场景还可以考虑使用 taosx 来同步数据。
数据建模原理和方法
数据建模原理
TDengine 数据建模的核心原理只有一个
让查询直接定位到数据块。
首先我们来观察一下 TDengine 是如何将规模很大的数据切分成很多个数据块的。TDengine 分别从采集点维度和时间戳维度对大规模数据进行分片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 等就是数据采集点。为充分利用其数据的时序性和其他数据特点TDengine 采取一个数据采集点一张表的策略按照此策略上述 d1001、d1002、d1003、d1004 分别建表。标签Label/Tag标签是指传感器、设备或其他类型采集点的静态属性不随时间变化。比如设备型号、颜色、设备的所在地等。采集量Metric采集量是指传感器、设备或其他类型采集点采集的物理量。比如电流、电压、温度、压力、GPS 位置等是随时间变化的。数据类型可以是整型、浮点型、布尔型也可是字符串。
创建超级表
为智能电表这个设备类型建立一个超级表采集量有电流、电压和相位标签有位置和类型。 创建子表
用 smeter 做模板为 6 个智能电表创建 6 张表地理位置标签为北京朝阳、海淀、上海浦东等。 聚合查询
查询北京朝阳区所有智能电表的电压平均值和电流最大值。 多维分析
查询北京地区所有类型为 1 的智能电表的电压平均值。 TDengine 数据建模优势
TDengine 数据建模的优势包括
超级表可以向普通表一样查询但可以指定标签的过滤条件标签可以多至 128 个每个标签代表一个维度标签可以事后增加、删除、修改。这样数据建模时可以先不确定标签或分析维度每个标签可以是一树状结构比如“北京·朝阳·望京”这样便于缩小搜索范围
数据建模案例
以新能源充电站建模场景为例。
背景信息
该客户管理一些充电站
充电站管理的充电桩大约有几百个每个充电桩每天可能多次进行充电每次充电产生一个充电订单充电订单每年大约有 1000 万个数据需要保留 2 年需要监控充电过程中电压、电流等信息对于历史订单能够回放充电过程数据查询方式按照订单查询期望能够实时监控正在充电的订单、以及能够查询历史订单充电过程
数据建模思考
常规思维按照一个采集点一张表的原则这里显然会按照充电桩来创建子表。但是这样一来存在一个问题我们按照订单查询时就无法直接定位到某个或者某几个数据块。按照充电桩来创建子表数据的确会按照充电桩进行分片Sharding并且分片后的数据也按照时间戳进行了分区Partition但是业务查询的时候未指定时间戳范围而是查询指定的 order_id所以无法定位到具体的数据块需要在分片中进行全量数据扫描必然导致性能十分低下。如下图所示 正确的建模思路
让我们回顾 TDengine 数据建模原理
让查询直接定位到数据块。
业务希望按照订单来查询那么我们直接按照订单来对数据进行分片Sharding
也就是说每个订单创建一张子表。这样按照订单查询时我们能够直接定位到该分片这样的好处是查询的性能非常好也非常方便但也存在两个问题
每年新建 1000 万张子表订单数据保留 2 年预计就有 2000 万张子表规模会不会太大数据保留周期是 2 年对于超过 2 年的子表是否能够自动删除呢
幸运的是对于时序数据领域常见的“高基数”问题TDengine 已经很好地解决了2000 万张子表对于关系型数据库来说可能是天文数字但是对于 TDengine 来说就是小菜一碟。
对于超过 2 年的子表TDengine 提供了 TTLTime to Live是用来指定表的生命周期(单位天)。如果创建表时指定了这个参数当该表的存在时间超过 TTL 指定的时间后TDengine 将自动删除该表。 实际数据建模
创建超级表 为单个订单创建子表假设订单号801234567保留 2 年到期自动删除 按照充电订单查询 通过对时序数据采集和应用的挑战及需求的分析本文深入探讨了 TDengine 数据建模的原理与方法。我们不仅揭示了数据建模的核心概念和技术细节还通过实际案例展示了其在新能源场景下的应用效果。希望读者能从中获得启发在实际工作中灵活运用 TDengine 数据建模的方法提高时序数据管理的效率与质量。
