一、背景介紹

京東工業(yè)是2021獨(dú)立出來成立的新事業(yè)群-京東工業(yè)事業(yè)群，包括工業(yè)品、工業(yè)服務(wù)、工業(yè)互聯(lián)等四大板塊業(yè)務(wù)。工業(yè)互聯(lián)業(yè)務(wù)主要是搭建工業(yè)互聯(lián)網(wǎng)平臺(tái)，用于將實(shí)時(shí)現(xiàn)場工業(yè)數(shù)據(jù)匯入平臺(tái)進(jìn)行分析，做數(shù)據(jù)智能工作。目前支持業(yè)務(wù)有國家電網(wǎng)管理平臺(tái)、綜合能源、碳中和交易、電力交易等業(yè)務(wù)。本文重點(diǎn)介紹下京東云 ClickHouse 在京東工業(yè)的綜合能源領(lǐng)域的應(yīng)用。工業(yè)互聯(lián)網(wǎng)場景的數(shù)據(jù)主要有如下三個(gè)特點(diǎn)：

一、數(shù)據(jù)量大

微型的客戶幾百個(gè)設(shè)備，大型的客戶十幾萬個(gè)儀表設(shè)備，上報(bào)頻率每分鐘1~60條不等，上報(bào)數(shù)據(jù)量很大。

二、查詢實(shí)時(shí)性要求高

大部分客戶將大屏實(shí)時(shí)應(yīng)用當(dāng)做實(shí)時(shí)儀表盤用，隨時(shí)盯盤，使用上最高頻的應(yīng)用就是實(shí)時(shí)應(yīng)用。

三、數(shù)據(jù)一致性要求高

會(huì)經(jīng)常發(fā)生底層環(huán)境的變動(dòng)導(dǎo)致難以預(yù)料的臟數(shù)據(jù)，但是客戶不允許錯(cuò)。比如設(shè)備錯(cuò)亂，出現(xiàn)過一堆設(shè)備部署錯(cuò)位置，導(dǎo)致很長一段時(shí)間上報(bào)數(shù)據(jù)都是數(shù)值錯(cuò)位；再比如新加字段，客戶全局更新設(shè)備，導(dǎo)致需要引入新字段；或者更換單位，將t/h 轉(zhuǎn)換成 kg/h，數(shù)值瞬間放大1000倍。

二、技術(shù)架構(gòu)

由于業(yè)務(wù)架構(gòu)的演進(jìn)，工業(yè)互聯(lián)網(wǎng)平臺(tái)也經(jīng)歷了以下技術(shù)架構(gòu)的演進(jìn)。

架構(gòu)1.0? ?存儲(chǔ)聚合分離

第一代架構(gòu)

第一代的整體架構(gòu)如下圖，分為數(shù)據(jù)過濾、數(shù)據(jù)處理引擎、Influxdb和Kylin幾個(gè)重要的組成部分。

數(shù)據(jù)過濾

1、策略工廠過濾臟數(shù)據(jù)。通過全局通用規(guī)則+企業(yè)特定個(gè)性化規(guī)則來過濾。

2.、異常處理流程。可能前方環(huán)境變化導(dǎo)致誤判，需要將異常數(shù)據(jù)轉(zhuǎn)發(fā)暫存。

數(shù)據(jù)處理引擎

1、維度和特征拉寬

如設(shè)備維度、組織架構(gòu)維度、告警規(guī)則等，用于OLAP和算法模型

2、數(shù)據(jù)差分

- 如流量、電量等維度，方便復(fù)雜的查詢瞬時(shí)狀態(tài)以及復(fù)雜聚合

- 抗中間數(shù)據(jù)丟失

3、預(yù)警告警

- 監(jiān)測非臟數(shù)據(jù)是否觸發(fā) 企業(yè)設(shè)定的告警規(guī)則

- 觸發(fā)告警處理流程

Influxdb

明細(xì)時(shí)序數(shù)據(jù)落庫

Kylin

查詢聚合數(shù)據(jù)數(shù)據(jù)

業(yè)務(wù)表現(xiàn)和感受

Kylin實(shí)際業(yè)務(wù)表現(xiàn)

1、需要提前搭建依賴的各種hadoop環(huán)境，運(yùn)維壓力大。

2、需要提前預(yù)設(shè)好所有的cube、dimension、measures等等組合關(guān)系，上線后不能改。

3、僅僅是基于預(yù)計(jì)算的查詢引擎，并不存儲(chǔ)數(shù)據(jù)，導(dǎo)致無法查詢歷史明細(xì)數(shù)據(jù)。

Influxdb架構(gòu)圖

Influxdb實(shí)際業(yè)務(wù)表現(xiàn)

1、當(dāng)時(shí)分布式版本還沒開源，運(yùn)維當(dāng)時(shí)大部分沒聽說過這個(gè)新東西；

2、配套工具和文檔很難找，入門困難，概念有點(diǎn)復(fù)雜，tag、series、fields…；

3、聚合查詢性能坑爹，明細(xì)查詢幾乎無提升；

4、沒有大廠核心應(yīng)用背書。

綜合感受

1、運(yùn)維負(fù)擔(dān)大：運(yùn)維兩套數(shù)據(jù)庫，且kylin在性能一般的測試環(huán)境經(jīng)常宕機(jī)

2、使用難度大：需要區(qū)分是查詢明細(xì)還是聚合數(shù)據(jù)

3、數(shù)據(jù)一致性難保證：物聯(lián)網(wǎng)和工業(yè)場景經(jīng)常需要改數(shù)據(jù)

4、架構(gòu)基本滿足需求，但是缺點(diǎn)大于優(yōu)點(diǎn)，需要更好的架構(gòu)方案

架構(gòu)2.0? ClickHouse合二為一

第二代架構(gòu)希望解決第一代的架構(gòu)三個(gè)的痛點(diǎn)：

一、運(yùn)維負(fù)擔(dān)重，2套存儲(chǔ)框架；

二、使用負(fù)擔(dān)大,查詢需要分?jǐn)?shù)據(jù)源；

三、數(shù)據(jù)一致性維護(hù)困難。

第二代架構(gòu)使用的是ClickHouse官方推薦實(shí)踐：Kafka引擎表+物化流程+本地表+分布式表

第二代架構(gòu)優(yōu)缺點(diǎn)分析

優(yōu)點(diǎn)：

1、解決所有痛點(diǎn)，一套方案解決。

2、性能優(yōu)秀。支持穩(wěn)定大吞吐量數(shù)據(jù)寫入，滿足做中臺(tái)建設(shè)的基礎(chǔ)存儲(chǔ)要求；超高的數(shù)據(jù)壓縮率，節(jié)省磁盤存儲(chǔ)；合理設(shè)置索引后，數(shù)據(jù)查詢速度極快。

缺點(diǎn)：

1、數(shù)據(jù)量巨大；2、QPS不高，無法toC。

業(yè)務(wù)表現(xiàn)

ClickHouse 架構(gòu)圖

ClickHouse 性能對比圖

實(shí)踐感受

一、架構(gòu)清晰簡潔。最簡單的多主分片結(jié)構(gòu)，只依賴個(gè)zk，任何運(yùn)維半天都能搭起來。

二、一站式方案，既能存數(shù)據(jù)，有能查數(shù)據(jù)，而且內(nèi)部默認(rèn)對查詢的性能優(yōu)化就很好。

三、SQL友好，只要有mysql的基本技能就無縫銜接到ClickHouse的使用，沒有入門門檻。

總結(jié)一下，ClickHouse是很優(yōu)秀的存儲(chǔ)查詢一攬子方案，對于需要大量group by和排序的聚合查詢場景是幾乎不二選擇。對DBMS的支持目前也是夠用的，像mysql的一樣使用感受大大降低運(yùn)維、研發(fā)等的使用門檻。

新的問題

大屏應(yīng)用遭遇性能瓶頸

主要瓶頸如下：

一、瞬時(shí)查詢數(shù)吞吐量大

數(shù)據(jù)基本按照日分區(qū)，如果切換到“年”，那么該接口就要瞬間聚合365個(gè)分區(qū)的數(shù)據(jù)，接口延時(shí)5~10s。

二、瞬時(shí)查詢QPS高

大屏應(yīng)用組件奇多，粗粗一算，刷新首頁大屏瞬間十幾個(gè)sql就提交到ClickHouse，如果都是跨越365分區(qū)的按年查詢，壓力更是暴增。

官方建議每秒最多查詢100次。

基于以上原因，下一代開始考慮嘗試架構(gòu)實(shí)時(shí)數(shù)倉：生產(chǎn)和消費(fèi)相分離

架構(gòu)3.0? ClickHouse+實(shí)時(shí)數(shù)倉

第三代架構(gòu)如下：

DWD 明細(xì)數(shù)據(jù)層：

1、分主題的明細(xì)大寬表數(shù)據(jù)。

業(yè)務(wù)上解耦拆分大寬表。

2、維度數(shù)據(jù)。

更建議提前維度拉寬，避免join；可以預(yù)留備用字段，業(yè)務(wù)上mapping使用。

DWS 數(shù)據(jù)聚合層：

1、物化流程聚合

AggregatingMergeTree

面向：針對明細(xì)數(shù)據(jù)不經(jīng)常修改的場景

優(yōu)點(diǎn)：實(shí)現(xiàn)簡單快速，性能絲滑，查詢優(yōu)化明顯

缺點(diǎn)：明細(xì)數(shù)據(jù)發(fā)生變更，需要時(shí)間評估和修復(fù)

2、定時(shí)任務(wù)調(diào)度

腳本或者可視化任務(wù)上下線調(diào)度

面向：針對明細(xì)數(shù)據(jù)經(jīng)常修改的場景,需要強(qiáng)數(shù)據(jù)一致性

優(yōu)點(diǎn)：數(shù)據(jù)一致性隨時(shí)可以保證

缺點(diǎn)：需要前期建設(shè)工作，包括分析提煉業(yè)務(wù)數(shù)據(jù)模式等

ADS數(shù)據(jù)應(yīng)用層：

1、數(shù)據(jù)生產(chǎn)消費(fèi)解耦層：使用redis，按照QPS 5W+設(shè)計(jì)

2、數(shù)據(jù)應(yīng)用：直接使用redis里的數(shù)據(jù)，不需要訪問下層數(shù)倉。

三、ClickHouse 實(shí)踐總結(jié)

? ??

ClickHouse的適用場景

一、復(fù)雜查詢聚合的OLAP場景，基本不支持OLTP場景

典型特征是存在大量的group by、order by運(yùn)算。

二、需要支持穩(wěn)定大量數(shù)據(jù)寫入

ClickHouse一般可以支持每秒幾百M(fèi)B的數(shù)據(jù)量寫入，優(yōu)化過的更高。

三、不需要高頻的查詢

裸奔使用，官方建議每秒最多查詢100次，但是按照上述實(shí)時(shí)數(shù)倉方案優(yōu)化過會(huì)大大提升。最適合在內(nèi)部運(yùn)營人員內(nèi)部使用的場景上落地。

四、當(dāng)你OLAP聚合之外，也需要明細(xì)查詢的場景，這是優(yōu)秀的方案

五、其它：不需要高級(jí)的DBMS功能，如事務(wù)性；不需要經(jīng)常很復(fù)雜的表間操作，比如join。

ClickHouse的適用場景實(shí)踐

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

盡可能使用提前的維度拉寬+大寬表+合理物化ETL流程解決問題，而不是復(fù)雜的表間join。

使用好大量的mergeTree家族的不同表引擎，比如在數(shù)據(jù)去重，數(shù)據(jù)聚合等等特殊場景。

二、所有的數(shù)據(jù)庫方案都是數(shù)據(jù)倉庫解決方案的一部分，需要站在數(shù)據(jù)倉庫的高度上去想問題。

沒有絕對的銀彈可以解決所有數(shù)據(jù)問題，合理搭配去使用數(shù)據(jù)庫，揚(yáng)長避短，各司其職。

ClickHouse 引擎表家族

- End -

ClickHouse在工業(yè)互聯(lián)網(wǎng)場景的OLAP平臺(tái)建設(shè)實(shí)踐