ClickHouse在工业互联网场景的OLAP平台建设实践

原创许亮京东云开发者

一、背景介绍

京东工业是2021独立出来成立的新事业群-京东工业事业群，包括工业品、工业服务、工业互联等四大板块业务。工业互联业务主要是搭建工业互联网平台，用于将实时现场工业数据汇入平台进行分析，做数据智能工作。目前支持业务有国家电网管理平台、综合能源、碳中和交易、电力交易等业务。本文重点介绍下京东云 ClickHouse 在京东工业的综合能源领域的应用。工业互联网场景的数据主要有如下三个特点：

一、数据量大

微型的客户几百个设备，大型的客户十几万个仪表设备，上报频率每分钟1~60条不等，上报数据量很大。

二、查询实时性要求高

大部分客户将大屏实时应用当做实时仪表盘用，随时盯盘，使用上最高频的应用就是实时应用。

三、数据一致性要求高

会经常发生底层环境的变动导致难以预料的脏数据，但是客户不允许错。比如设备错乱，出现过一堆设备部署错位置，导致很长一段时间上报数据都是数值错位；再比如新加字段，客户全局更新设备，导致需要引入新字段；或者更换单位，将t/h 转换成 kg/h，数值瞬间放大1000倍。

二、技术架构

由于业务架构的演进，工业互联网平台也经历了以下技术架构的演进。

架构1.0 存储聚合分离

第一代架构

第一代的整体架构如下图，分为数据过滤、数据处理引擎、Influxdb和Kylin几个重要的组成部分。

数据过滤

1、策略工厂过滤脏数据。通过全局通用规则+企业特定个性化规则来过滤。

2.、异常处理流程。可能前方环境变化导致误判，需要将异常数据转发暂存。

数据处理引擎

1、维度和特征拉宽

如设备维度、组织架构维度、告警规则等，用于OLAP和算法模型

2、数据差分

- 如流量、电量等维度，方便复杂的查询瞬时状态以及复杂聚合

- 抗中间数据丢失

3、预警告警

- 监测非脏数据是否触发企业设定的告警规则

- 触发告警处理流程

Influxdb

明细时序数据落库

Kylin

查询聚合数据数据

业务表现和感受

Kylin实际业务表现

1、需要提前搭建依赖的各种hadoop环境，运维压力大。

2、需要提前预设好所有的cube、dimension、measures等等组合关系，上线后不能改。

3、仅仅是基于预计算的查询引擎，并不存储数据，导致无法查询历史明细数据。

Influxdb架构图

Influxdb实际业务表现

1、当时分布式版本还没开源，运维当时大部分没听说过这个新东西；

2、配套工具和文档很难找，入门困难，概念有点复杂，tag、series、fields…；

3、聚合查询性能坑爹，明细查询几乎无提升；

4、没有大厂核心应用背书。

综合感受

1、运维负担大：运维两套数据库，且kylin在性能一般的测试环境经常宕机

2、使用难度大：需要区分是查询明细还是聚合数据

3、数据一致性难保证：物联网和工业场景经常需要改数据

4、架构基本满足需求，但是缺点大于优点，需要更好的架构方案

架构2.0 ClickHouse合二为一

第二代架构希望解决第一代的架构三个的痛点：

一、运维负担重，2套存储框架；

二、使用负担大,查询需要分数据源；

三、数据一致性维护困难。

第二代架构使用的是ClickHouse官方推荐实践：Kafka引擎表+物化流程+本地表+分布式表

第二代架构优缺点分析

优点：

1、解决所有痛点，一套方案解决。

2、性能优秀。支持稳定大吞吐量数据写入，满足做中台建设的基础存储要求；超高的数据压缩率，节省磁盘存储；合理设置索引后，数据查询速度极快。

缺点：

1、数据量巨大；2、QPS不高，无法toC。

业务表现

ClickHouse 架构图

ClickHouse 性能对比图

实践感受

一、架构清晰简洁。最简单的多主分片结构，只依赖个zk，任何运维半天都能搭起来。

二、一站式方案，既能存数据，有能查数据，而且内部默认对查询的性能优化就很好。

三、SQL友好，只要有mysql的基本技能就无缝衔接到ClickHouse的使用，没有入门门槛。

总结一下，ClickHouse是很优秀的存储查询一揽子方案，对于需要大量group by和排序的聚合查询场景是几乎不二选择。对DBMS的支持目前也是够用的，像mysql的一样使用感受大大降低运维、研发等的使用门槛。

新的问题

大屏应用遭遇性能瓶颈

主要瓶颈如下：

一、瞬时查询数吞吐量大

数据基本按照日分区，如果切换到“年”，那么该接口就要瞬间聚合365个分区的数据，接口延时5~10s。

二、瞬时查询QPS高

大屏应用组件奇多，粗粗一算，刷新首页大屏瞬间十几个sql就提交到ClickHouse，如果都是跨越365分区的按年查询，压力更是暴增。

官方建议每秒最多查询100次。

基于以上原因，下一代开始考虑尝试架构实时数仓：生产和消费相分离

架构3.0 ClickHouse+实时数仓

第三代架构如下：

DWD 明细数据层：

1、分主题的明细大宽表数据。

业务上解耦拆分大宽表。

2、维度数据。

更建议提前维度拉宽，避免join；可以预留备用字段，业务上mapping使用。

DWS 数据聚合层：

1、物化流程聚合

AggregatingMergeTree

面向：针对明细数据不经常修改的场景

优点：实现简单快速，性能丝滑，查询优化明显

缺点：明细数据发生变更，需要时间评估和修复

2、定时任务调度

脚本或者可视化任务上下线调度

面向：针对明细数据经常修改的场景,需要强数据一致性

优点：数据一致性随时可以保证

缺点：需要前期建设工作，包括分析提炼业务数据模式等

ADS数据应用层：

1、数据生产消费解耦层：使用redis，按照QPS 5W+设计

2、数据应用：直接使用redis里的数据，不需要访问下层数仓。

三、ClickHouse 实践总结

ClickHouse的适用场景

一、复杂查询聚合的OLAP场景，基本不支持OLTP场景

典型特征是存在大量的group by、order by运算。

二、需要支持稳定大量数据写入

ClickHouse一般可以支持每秒几百MB的数据量写入，优化过的更高。

三、不需要高频的查询

裸奔使用，官方建议每秒最多查询100次，但是按照上述实时数仓方案优化过会大大提升。最适合在内部运营人员内部使用的场景上落地。

四、当你OLAP聚合之外，也需要明细查询的场景，这是优秀的方案

五、其它：不需要高级的DBMS功能，如事务性；不需要经常很复杂的表间操作，比如join。

ClickHouse的适用场景实践

一、官方提供的 kafka引擎表+物化流程+本地表+分布式表的大宽表使用流程。

尽可能使用提前的维度拉宽+大宽表+合理物化ETL流程解决问题，而不是复杂的表间join。

使用好大量的mergeTree家族的不同表引擎，比如在数据去重，数据聚合等等特殊场景。

二、所有的数据库方案都是数据仓库解决方案的一部分，需要站在数据仓库的高度上去想问题。

没有绝对的银弹可以解决所有数据问题，合理搭配去使用数据库，扬长避短，各司其职。

ClickHouse 引擎表家族

- End -

继续滑动看下一个