大數據分析倉庫服務設計

        最近一直在做數據分析這一塊的產品,在這個過程中一直思考和實現一個即簡單又通用的數據存儲模型;目標是通過這個模型可以完成大部分的數據分析需求,而使用者並不需介入這個模型的設計和定製。經過這段時間幾個版本的設計和實施,已經把這個模型抽象出來並在 BeetleX 數據分析的 V4 版中實現。

        爲了應對大數據分析處理,服務的數據存儲選擇了 ElasticSearch 解決大規模數據存儲和集羣化處理(即現在互聯網上非常火的 ELK 中的 E)。通過 ElasticSearch 自身的優勢可以輕鬆應對數十上百億的數據規模進行分析處理。

        接下來簡單分享一下這個數據倉庫存儲型的設計,做過統計分析的朋友一定會因爲統計維度的增加感到有些苦惱,畢竟維度的增加意味着倉庫的結構有所調整,結構的變化引起調整也是比較麻煩。而在設計這個數據倉庫存儲最重要也是解決這一問題,爲了更好地處理這問題在設計依據以下方向需求:“誰在什麼時候得到了那些數據?”。針對這一需求把數據信息列劃分爲三大類分別是:數值、時間和標籤。

數值

        數值是數據中最主要的主要項目,在實際應用中主要包括數量,金額等;通過彙總這些數據可以瞭解到業務數據情況。

**時間
**

        時間主要描述的數據源產生的時間,更多用於描述某些時間段的數據結果;但在彙總上爲了得到更直觀結果往往把時間轉成基礎單位作爲一個數據維度來分析,如:年,月,日和時等。

標籤

在數據倉庫存儲中,數值和時間基本是固定的也不會增加,它們反映了在什麼時間得到什麼樣的數據結果。但除了這兩個信息源外更重要是 "誰" 在什麼時間得到了多少數據結果。但這個 "誰" 就存在非常不確定性了,它會隨時間有所增加或減少,具有非常多的信息源。這個類信息源最常見的有: 客戶,員工,經理,城市,地區,產品,分類。。。。等等。在這些根本無法完全總結出來的在這裏全定義爲標籤。

設計

        既然數值和時間相對固定的數據源,那可以直接在設計上定義相關信息列即可。但對於標籤來說在設計上就不這麼簡單了,因爲它是可變化的,每條數據源都有着不同的情況;爲了解決這一問題所以在設計上使用一個非結構化的信息例來存儲所有這些標籤。存儲還是比較簡單的關鍵是這個非結構化的信息列需要支持查詢和內容標籤管理;內容標籤管理需要自動化地把客戶,員工,經理,城市,地區,產品,分類。。。。等等這些分析出來,並提供給用戶選擇。

服務接口

        服務設計兩大接口,分別是數據導入和數據分析彙總。

  {
    "ID": "0001000013",
    "Total":20,
    "Quantity":2,
    "CreateTime""2006-05-22T00:00:00",
    "Tag":[
            {"產品":"Steeleye Stout"},
            {"國家":"USA"},
            {"客戶":"Wolski"}
        ]
  }

        服務雖然提供了自己有的圖表展示功能,但很多時候需要制定符合實際需求的數據展示功能;爲了滿足這些需求服務提供了分析匯部接口用於獲取分析後的數據進行數據展示處理。彙總接口分爲兩類,分別是時間維度的分析和標籤維度的分析。

        時間維度可以分析出指定時間和標籤的數據做一個時間進行統計,統計的時間有年,月,日,時等。通過時間統計可以做一些時間上的同比和環比數據分析彙總。

        標籤維度可以選擇任意標籤組合並得到一份在某個時間區間的分析結果,而這種分析彙總更多是反映標籤下的數據分佈佔比情況;如: 某城市銷售最火的產品,或不同系統問題產生的最多模塊和相關開發人員等等。

總結

        經過前三個版的實現的積累,在第 4 個版本會得到一個更全面大數據分析倉庫服務。通過服務可以更方便統計地分析各種業務數據,包括銷售,醫療信息,系統日誌等各種數據源的收集各分析彙總。以下是 V4 的功能預覽:

BeetleX

開源跨平臺通訊框架 (支持 TLS)
提供高性能服務和大數據處理解決方案

https://beetlex.io

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/cXNLa1UOwwssi4FluWRqkg