文? | 閔令超 網(wǎng)易智企高級(jí)應(yīng)用開發(fā)工程師

前言

數(shù)據(jù)報(bào)表分析對(duì)于企業(yè)管理者的分析決策有著至關(guān)重要的作用，因此數(shù)據(jù)報(bào)表的靈活可用以及數(shù)據(jù)的準(zhǔn)確性顯得至關(guān)重要。本文會(huì)介紹基于 Elasticsearch 的數(shù)據(jù)指標(biāo)系統(tǒng)，希望對(duì)大家有一定的借鑒和幫助。

背景

數(shù)據(jù)報(bào)表通常在業(yè)務(wù)開發(fā)中是必不可少的一部分，對(duì)于 To B 的應(yīng)用更是如此。企業(yè)在使用產(chǎn)品的過(guò)程中必然需要對(duì)于整個(gè)的業(yè)務(wù)情況有一個(gè)準(zhǔn)確的判斷和分析，這就需要我們能夠提供給企業(yè)盡可能多維度的詳細(xì)的數(shù)據(jù)報(bào)表。

初始數(shù)據(jù)報(bào)表方案

在項(xiàng)目的初期，為了業(yè)務(wù)的快速發(fā)展，往往采取的是比較簡(jiǎn)單的架構(gòu)進(jìn)行處理，如下圖所示。根據(jù)產(chǎn)品對(duì)于指標(biāo)的定義，通常開發(fā)通過(guò)代碼的形式直接定義指標(biāo)的運(yùn)算，依賴自研或者開源的定時(shí)任務(wù)調(diào)度系統(tǒng)，跑出相應(yīng)的指標(biāo)計(jì)算結(jié)果，保存到中間表中，查詢的時(shí)候根據(jù)不同的篩選條件，從不同的中間表中獲取指標(biāo)的計(jì)算結(jié)果。

?

存在的問(wèn)題

口徑不一致。在上述架構(gòu)中，當(dāng)不同的業(yè)務(wù)有數(shù)據(jù)交叉場(chǎng)景時(shí)，往往是從其他業(yè)務(wù)方復(fù)制相關(guān)指標(biāo)計(jì)算的代碼拿來(lái)使用，這會(huì)造成數(shù)據(jù)指標(biāo)口徑發(fā)生變化時(shí)，各個(gè)業(yè)務(wù)的相同的指標(biāo)出現(xiàn)了指標(biāo)口徑不一致的問(wèn)題。

開發(fā)效率低。每次添加指標(biāo)/修改指標(biāo)都需要修改代碼、添加數(shù)據(jù)庫(kù)字段等多步驟 ，導(dǎo)致整個(gè)的指標(biāo)開發(fā)周期特別的長(zhǎng)。

不同維度的指標(biāo)的計(jì)算邏輯處理邏輯、任務(wù)不同，每次修改邏輯需要修改多個(gè)地方。

基于 Elasticsearch 的數(shù)據(jù)報(bào)表方案

隨著業(yè)務(wù)的發(fā)展，指標(biāo)的定義越來(lái)越多，報(bào)表也變得越來(lái)越豐富，基于定時(shí)任務(wù)架構(gòu)的弊端暴露的越來(lái)越明顯，開發(fā)的負(fù)擔(dān)變的越來(lái)越重，在這時(shí)候，就需要對(duì)上述架構(gòu)升級(jí)，減少業(yè)務(wù)開發(fā)的工作量。此階段，由于數(shù)據(jù)量仍然不是很大，同時(shí)為了業(yè)務(wù)方便開發(fā)和維護(hù)，可以參考數(shù)倉(cāng)系統(tǒng)，搭建一個(gè)簡(jiǎn)易的數(shù)據(jù)指標(biāo)系統(tǒng)。

考慮到上述存在的問(wèn)題，首先需要明確大的方向和目標(biāo)。

規(guī)范化數(shù)據(jù)指標(biāo)的開發(fā)流程，保證數(shù)據(jù)口徑的統(tǒng)一。

提供數(shù)據(jù)指標(biāo)平臺(tái)，便于業(yè)務(wù)開發(fā)能夠基于 SQL 開發(fā)大部分的指標(biāo)，減少指標(biāo)的開發(fā)工作量，提高指標(biāo)的開發(fā)效率。

明確整個(gè)數(shù)據(jù)報(bào)表的生產(chǎn)流程，參考數(shù)倉(cāng)建設(shè)方案，規(guī)范化整個(gè)數(shù)據(jù)指標(biāo)的產(chǎn)出流程。

提供有效的 SDK，方便業(yè)務(wù)方的調(diào)用。

需要支持多數(shù)據(jù)源，在業(yè)務(wù)中往往不止一個(gè)數(shù)據(jù)源，可能會(huì)有 MySQL、Hive、ElasticSearch 等多個(gè)數(shù)據(jù)源，所以需要支持從多數(shù)據(jù)源匯集數(shù)據(jù)的能力。

需要對(duì)于指標(biāo)的異常進(jìn)行及時(shí)告警，方便開發(fā)排查業(yè)務(wù)異常。

術(shù)語(yǔ)簡(jiǎn)介

• 原子指標(biāo)：原子指標(biāo)是指最細(xì)粒度的指標(biāo)，即不能再向下拆分的指標(biāo)，例如 指標(biāo) A=指標(biāo) B+指標(biāo) C，那么這里指標(biāo) B 和指標(biāo) C 即為原子指標(biāo)。

• 復(fù)合指標(biāo)：復(fù)合指標(biāo)是多個(gè)原子指標(biāo)通過(guò)計(jì)算處理獲取的結(jié)果，例如 指標(biāo) A=指標(biāo) B+指標(biāo) C，這里指標(biāo) A 就是表示復(fù)合指標(biāo)。

• 維度：數(shù)據(jù)查詢的角度。一般是指日期、客服組等信息。如下圖中標(biāo)紅部分即為維度信息。

• 時(shí)間周期：時(shí)間周期是用來(lái)描述一個(gè)指標(biāo)的計(jì)算范圍。在統(tǒng)計(jì)指標(biāo)的過(guò)程中必須指定用于計(jì)算的時(shí)間周期字段，通常，原子指標(biāo)的計(jì)算的最小時(shí)間周期為小時(shí)，天數(shù)據(jù)基于小時(shí)數(shù)據(jù)做聚合得出。

• 報(bào)表：報(bào)表是一系列復(fù)合指標(biāo)/原子指標(biāo)的集合，通常業(yè)務(wù)方獲取的指標(biāo)數(shù)據(jù)都是一張報(bào)表。

• 業(yè)務(wù)域：一個(gè)項(xiàng)目往往會(huì)有多條業(yè)務(wù)線，每條業(yè)務(wù)線我們可以理解為一個(gè)業(yè)務(wù)域，以七魚為例，如在線會(huì)話、呼叫等，任何的原子指標(biāo)、復(fù)合指標(biāo)、報(bào)表都屬于某一個(gè)業(yè)務(wù)域。

架構(gòu)

基于上述目標(biāo)，這里以 Elasticsearch 的聚合查詢能力為依托，搭建如下的數(shù)據(jù)指標(biāo)平臺(tái)架構(gòu)。

整體分為5大部分：

原始數(shù)據(jù)層： 主要是關(guān)系型數(shù)據(jù)庫(kù)中的表數(shù)據(jù)

明細(xì)層： 主要是通過(guò) binlog 同步到 Elasticsearch 中保存。

業(yè)務(wù)層：主要包括兩大部分，指標(biāo)計(jì)算和項(xiàng)目管理。指標(biāo)計(jì)算主要是基于明細(xì)層數(shù)據(jù)以及業(yè)務(wù)開發(fā)和產(chǎn)品定義的指標(biāo)口徑，產(chǎn)出相應(yīng)維度的指標(biāo)。項(xiàng)目管理主要是維度、指標(biāo)、業(yè)務(wù)域相關(guān)配置等。

網(wǎng)關(guān)：提供統(tǒng)一的 SDK 便于業(yè)務(wù)方的直接調(diào)用。

業(yè)務(wù)方/控制臺(tái)，業(yè)務(wù)方調(diào)用sdk獲取報(bào)表數(shù)據(jù)以及維度、指標(biāo)等控制臺(tái)的配置。

從整個(gè)架構(gòu)體系來(lái)看，上述架構(gòu)主要是統(tǒng)一了各個(gè)業(yè)務(wù)的原始層和明細(xì)層數(shù)據(jù)，并基于此開發(fā)了數(shù)據(jù)指標(biāo)配置系統(tǒng)，能夠快速的響應(yīng)業(yè)務(wù)需求，將數(shù)據(jù)指標(biāo)的開發(fā)周期大大縮短，也避免了開發(fā)人員直接在代碼里面編寫指標(biāo)計(jì)算代碼，帶來(lái)口徑不統(tǒng)一或者重復(fù)建設(shè)的問(wèn)題。

原始數(shù)據(jù)層/明細(xì)層

從上圖中可以看到，最底層部分是原始數(shù)據(jù)層和明細(xì)層，這個(gè)是整個(gè)架構(gòu)的基礎(chǔ)所在。從原始層到明細(xì)層同步采用 binlog+ 自定義消息的同步方式，具體架構(gòu)如下：

同步數(shù)據(jù)主要有三種模式：

binlog 模式。通過(guò) binlog 模式，同步數(shù)據(jù)庫(kù)中相應(yīng)表中的數(shù)據(jù)，根據(jù)指定的關(guān)聯(lián)表的唯一鍵，可以將多張表的數(shù)據(jù)同步到一張大寬表中，方便指標(biāo)的運(yùn)算。binlog 同步可以依靠開源的 Canal、Maxwell 等組件，也可以是自研組件等。

全量同步模式。當(dāng) binlog 同步出現(xiàn)數(shù)據(jù)丟失，或者需要?dú)v史數(shù)據(jù)同步時(shí)，采用全量同步的模式進(jìn)行數(shù)據(jù)的補(bǔ)全和修正。全量同步主要依賴業(yè)務(wù)的定時(shí)任務(wù)調(diào)度系統(tǒng)。

自定義 topic。當(dāng)數(shù)據(jù)統(tǒng)計(jì)需要添加自定義字段而又不想在數(shù)據(jù)庫(kù)中添加相應(yīng)字段時(shí)，可以通過(guò)自定義 topic 將想要添加的字段添加到對(duì)應(yīng)的大寬表中。

明細(xì)層數(shù)據(jù)的存儲(chǔ)在 es 中，通過(guò)明細(xì)層可以完成業(yè)務(wù)到數(shù)據(jù)的轉(zhuǎn)換，保存維度信息以及最細(xì)粒度的數(shù)據(jù)。聚合層可基于明細(xì)層進(jìn)行復(fù)雜的指標(biāo)計(jì)算。

明細(xì)層數(shù)據(jù)保存在 Elasticsearch 中，我們需要考慮索引的分片規(guī)則，防止由于分片規(guī)則導(dǎo)致索引的數(shù)據(jù)分布不均勻，會(huì)對(duì)于搜索和聚合產(chǎn)生較大的影響。對(duì)于索引的劃分，通常采用月份進(jìn)行劃分索引，這樣保證明細(xì)數(shù)據(jù)在各個(gè)索引中會(huì)比較均勻的分布，同時(shí)，當(dāng)索引較多時(shí)，也方便對(duì)于歷史索引做冷數(shù)據(jù)處理，聚合的速度也能夠保存比較穩(wěn)定的狀態(tài)，不會(huì)因?yàn)槟硞€(gè)索引的數(shù)據(jù)過(guò)多，降低聚合的速度。

聚合層

聚合層負(fù)責(zé)對(duì)業(yè)務(wù)指標(biāo)進(jìn)行沉淀、向上提供統(tǒng)一的計(jì)算口徑，同時(shí)可以基于現(xiàn)有的指標(biāo)進(jìn)行組合查詢，避免重復(fù)計(jì)算指標(biāo)。目前指標(biāo)的查詢計(jì)算均通過(guò) Elasticsearch 計(jì)算。通過(guò)依賴 ElasticsearchSql 組件，可以使得業(yè)務(wù)方通過(guò)編寫 SQL 的方式定義原子指標(biāo)，如下

SELECT COUNT(*) FROM table_1 WHERE condition_1<>2 AND condition_2=2 GROUP BY A,B

如上面語(yǔ)句所示，WHERE 即原子指標(biāo)計(jì)算的查詢條件，GROUP BY 即指標(biāo)計(jì)算的維度。具體計(jì)算流程如下：

當(dāng)然在聚合指標(biāo)數(shù)據(jù)的過(guò)程中，過(guò)多的指標(biāo)聚合查詢，可能會(huì)導(dǎo)致 Elasticsesrch 的 CPU 負(fù)載過(guò)高，為了避免這個(gè)問(wèn)題我們需要調(diào)整任務(wù)策略，每個(gè)指標(biāo)一次批量處理多家企業(yè)，這樣可以大大降低請(qǐng)求的次數(shù)，提高了任務(wù)的執(zhí)行速度，保證了 Elasticsearch 集群的穩(wěn)定。

在實(shí)際的業(yè)務(wù)指標(biāo)開發(fā)中，經(jīng)常會(huì)碰到產(chǎn)品對(duì)于指標(biāo)的定義的改變，當(dāng)指標(biāo)定義改變時(shí)，需要測(cè)試用戶對(duì)于改指標(biāo)變化的反饋程度，以及能夠提供相應(yīng)的策略，方便回滾到老的指標(biāo)定義的數(shù)據(jù)。

針對(duì)上面的問(wèn)題，我們提出了環(huán)境和版本的概念。指標(biāo)的上線會(huì)有業(yè)務(wù)定義的多套環(huán)境，例如灰度和全量。通過(guò)環(huán)境，可以給一部分企業(yè)嘗試切換新的指標(biāo)定義，測(cè)試反饋效果。同時(shí)，每一個(gè)原子指標(biāo)會(huì)有多個(gè)版本，每一次定義的改變都會(huì)產(chǎn)生一個(gè)版本，復(fù)合指標(biāo)可以選擇相應(yīng)版本的指標(biāo)進(jìn)行結(jié)果的計(jì)算，如果客戶對(duì)于新的指標(biāo)定義不滿意，依然可以回滾到之前的版本。具體的操作流程如下圖所示：

業(yè)務(wù)方調(diào)用

業(yè)務(wù)方添加指標(biāo)并調(diào)用的整個(gè)流程如下圖：

如上圖所示，業(yè)務(wù)方需要添加指標(biāo)時(shí)，需要在原子指標(biāo)池中添加相應(yīng)的指標(biāo)計(jì)算規(guī)則，默認(rèn)初始化版本為 V1，如果需要同步歷史數(shù)據(jù)則在添加指標(biāo)時(shí)創(chuàng)建歷史數(shù)據(jù)同步任務(wù)，創(chuàng)建完任務(wù)之后，系統(tǒng)會(huì)自動(dòng)計(jì)算并同步所選時(shí)間段的指標(biāo)數(shù)據(jù)，歷史數(shù)據(jù)同步完成之后方可在指標(biāo)建模中勾選新指標(biāo)。指標(biāo)建模完成之后，通常是需要業(yè)務(wù)方在自己的定制化報(bào)表中添加建模之后的指標(biāo)，通過(guò) SDK 獲取相應(yīng)的報(bào)表時(shí)，會(huì)自動(dòng)返回添加的指標(biāo)值。

總結(jié)與展望

當(dāng)然，上述的架構(gòu)仍有一定的局限性，當(dāng)業(yè)務(wù)發(fā)展到比較大的規(guī)模，業(yè)務(wù)線逐漸增多，業(yè)務(wù)數(shù)據(jù)量級(jí)也逐漸增大，企業(yè)對(duì)于數(shù)據(jù)的需求要求會(huì)變的更加的多樣，往往我們的報(bào)表不能充分的滿足客戶的需求，這個(gè)時(shí)候，就需要給客戶提供自定義報(bào)表的能力，使其不局限于系統(tǒng)內(nèi)提供的報(bào)表查詢維度，對(duì)于一個(gè)指標(biāo)，企業(yè)可以從任意的可選維度進(jìn)行查詢分析。這個(gè)時(shí)候這套方案已經(jīng)不能滿足客戶的需求。所以需要對(duì)報(bào)表系統(tǒng)再次進(jìn)行架構(gòu)升級(jí)，這時(shí)候可以搭建業(yè)務(wù)內(nèi)部的數(shù)倉(cāng)系統(tǒng)，整合內(nèi)部企業(yè)分析以及對(duì)外數(shù)據(jù)報(bào)表輸出能力。

總結(jié)

以上是生活随笔為你收集整理的基于Elasticsearch的数据报表方案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。