物联网行业, clickhouse 表设计

32 天前
 za30312

在做一个物联网平台,原来使用的是 tdengine , 通过一个产品一张超级表,一个设备一张子表的概念进行设计的,子表的表名做为设备 id 。 参考: https://docs.taosdata.com/basic/model/

现在被要求使用 clickhouse ,看了一下网上 没有特别统一的方案。 问的 AI 方案是单表

CREATE TABLE device_metrics (
    event_time DateTime64(3) CODEC(DoubleDelta),   -- 时间戳(毫秒级)
    device_type Enum8('water_meter'=1, 'electric_meter'=2, 'cnc_machine'=3), -- 设备类型标签
    device_id UInt32,                             -- 设备唯一 ID
    location String,                               -- 位置标签
    metrics Nested(                                -- 动态指标(兼容不同设备)
        key String,                               -- 指标名(如"voltage")
        value Float32                             -- 指标值
    )
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_time)                  -- 按月分区
ORDER BY (device_type, device_id, event_time)      -- 排序键(加速设备时序查询)
TTL event_time + INTERVAL 2 YEAR;                  -- 自动清理过期数据

想问下大家针对时序数据,clickHouse 的表是如何设计的?

2249 次点击
所在节点    程序员
16 条回复
homewORK
31 天前
一个类型一张表,没用什么复杂字段。通过设备物模型创建需要的列。
nooneanyone
31 天前
clickhouse 可以设计在一张表里,查询的时候少 select 点列就行
bbsingao
31 天前
CH 如果没有什么特殊理由,就放在一张大表中
HomeZane
31 天前
你这点东西,单表完全没问题呀
za30312
31 天前
因为一期,会有上 W 台设备,秒级传输, 数据量还是有一些的。 主要还是想问看大家表怎么设计, 对后面业务进行各个维度分析方便。

业务主要是一些工厂内的设备与能源表。 例如:水、电、气油表以及 机床等。 重点还是动态扩展采集点/测点这块以及后面的使用
dlmy
31 天前
你这点内容完全可以放在 ClickHouse 的一张表里,我司的宽表每张都有几百个字段,也是放在一张表里,缺点就是查询的时候不能带很多列
za30312
31 天前
@dlmy 因为实际上不同的产品 采集的信息完全不同。 是每个产品建一张表, 所有产品都用一张表, 根据某个字段区分(但这样的话 产品一多, 几百的字段根本不够)
spritecn
31 天前
不要想那么多,先跑起来....其实考虑一下 mysql,influxDB,itoDB 这些
Super8
31 天前
我一般是按业务拆分设计
比如设备心跳业务,就是心跳上报时间、设备编码标识。
如果是采集业务,就按不同业务设备设计,比如设备有温度,温度,振动,电流,电压,清洁度等等,都设计到一张表里面去,有的业务设备采集表字段有一百多个字段,有业务设备采集表字段很少。识情况而定。
Super8
31 天前
@za30312 #5 我负责的系统接入设备有 5W 多台了,总共使用分布式表 + 本地表组合的方式设计 clickhouse 表.
Super8
31 天前
@Super8 #10 也做了分区和分片
dlmy
31 天前
@za30312 #7 @za30312 如果项目规模不大,团队人手也不多,前期真没必要考虑什么扩展。

你可以参考一下我目前在弄的一个数仓分层方案:
1 、将采集到的原生数据作为基础数据层,标记为 ODS 层,存入 Kafka 中,后面接入 Flink
2 、使用 Flink 对 ODS 层的数据进行清洗和规范化操作,标记为 DWD 层,存入 Kafka 中
3 、使用 Flink 对 DWD 层数据进行加工补齐,也可在此阶段做一些基础宽表,标记为 DWM 层,存入 Kafka 中
4 、使用 Flink 对 DWM 层数据进行处理,分组、聚合、开窗、统计、多流合并,形成主题宽表,标记为 DWS 层,存入 ClickHouse 中
5 、根据需求从 ClickHouse 中读取数据,标记为 ADS 层,进行可视化展示

这个架构你想怎么扩展都行,数据可以在任意一层进行持久化,因为数据分层后形成了固化的存储模型,可以提供平台级别的通用组件支持。

但要注意的点是:这个方案特别烧钱,我目前所在的团队有 40 多个人,已经做了 3 年多,没人没钱的话不建议去碰这个。
siaronwang
31 天前
这是 ap 场景还是 tp 场景?
za30312
31 天前
@dlmy 感谢回复, 这个方案更像在做数据湖或者数仓的东西,关于这个东西,我们这边是做好了各个子系统,再进行抽数入湖,按标准流程建数仓等。

我这边目前只需要考虑如何做好这个表设计,存好数据, 方便后面的查询。
简单就直接 每个产品一张表
复杂就这样:Kafka 引擎表+物化流程+本地表+分布式表
za30312
31 天前
@siaronwang 物联网应该都是 ap 的场景,ClickHouse 也只适合 ap 的场景吧
dlmy
31 天前
@za30312 #14 我这边的业务是充电桩,有 30 多万台设备,我觉得跟你的大致业务应该差不太多。

我目前在做的这个方案借鉴了原大数据数仓的分层模型,但是具体设计跟实现细节还是有着很大的差别,这里更注重于数据模型的抽取跟存储架构的落地,先把结构化数据和非结构化数据的公共存储模型抽取出来进行固化,后续业务团队想进行任何数据相关的操作就很简单了,因为数据模型设计的好,存储流程也很规范,所以整体架构运行的很稳定,能快速响应各种各样的数据需求。

只不过我这个方案是企业级的数据治理平台,而你要做的需求是其中的一个小功能,我不熟悉你的具体业务,没法更细的提供技术方案,但如果后续你公司的业务发展起来了,可以参考一下这个架构。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1139116

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX