資料分析結果解讀系統服務化構建資料解讀通用模型

本篇文章旨在討論常見的資料統計程式設計模型以及資料解讀通用的解決方式

以上是內容概要

首先我們先看一張完整的流程圖，再依次展開各個模組的技術實現細節

整個流程我們可以分為元資料收集，資料加工，資料儲存，資料分析和資料展現四個部分

元資料是用來描述業務的最小單位，任何涉及資料統計及處理的業務的都是從元資料收集開始的。元資料既可以是從其他資料來源抽取同步而來，也可以從業務終端收集而來。

業務終端是指生產環境下的業務行為的觸發點，比如智慧型手錶系統中的使用者佩戴行為就是業務終端，佩戴智慧型手錶的使用者的一次擺手或者走路就是一次元資料的觸發點，共享單車系統中的使用者騎行行為也是一次元資料的觸發。

假設我們的系統是乙個物聯網系統，那麼負責元資料收集的功能元件一般由感測器完成。

在涉及到資料處理的相關系統中，資料加工是資料解讀整個過程中的第二部分，主要任務是對終端收集到的資料進行初次加工，過濾明顯的異常資料，也就是嚴重的噪音資料，近而進行第一次持久化處理。

下面舉兩個例子

在感測器-server端的架構中，這裡的持久化存在感測器的快閃儲存器中。

當然持久化的時間和儲存能力視具體情況而定。

在工業生產環境及大資料量，併發情況下，以上的架構會引入訊息hub或者訊息佇列的角色

感測器-server端 ==》感測器-mq-server端

broker就是服務訊息儲存和分發排程的訊息中心，注意作為資料解讀的第二部分，資料加工只能完成以上**的客戶端角色的任務，也就是只負責傳送資料到應用程式伺服器或者mq訊息中心

以上是元資料流轉的整體流程，接下來介紹資料加工的輸出介質和格式

接上文提到資料持久化繼續深入闡述

在常見的資料加工階段，系統會對初加工的資料進行儲存，儲存的介質是本地資料庫或者記憶體快閃儲存器。本地資料庫以sqlite最為推薦。按照業務規則會以小時，天，日，周，月等不同的維度進行持久化。各個統計維度會成為更高維度的資料基礎，比如以天為維度的統計計算是以小時的統計結果為基礎。

那麼問題來了，已生成的資料會涉及到重新統計分析和覆蓋寫入嗎？

除了嚴格意義上的財務系統以外，這裡的統計分析在系統中更多充當流水資料的作用，一旦統計完成，不會再次更新和覆蓋重寫。

以上的統計都是同步機制嗎

很確定的說，不是。同步和非同步並存，遵循同步和非同步的使用場景要求，更多場景下，配合上午說到的流水資料的屬性，以非同步模式處理更多。

資料儲存以最終持久化資料為準，以資料庫的形式儲存。元資料的資料型別包括結構化資料，非結構化資料，半結構化資料。資料庫對應包括關係型資料庫，非關係型資料庫。如何選型，取決於業務型別等多種因素。

實際上，在這個宣揚大資料，人工智慧的時代，涉及到資料處理的應用系統對於資料庫的儲存都是以redis，mongodb為標配的。大量的不確定的元資料的儲存，處理，分布式計算，更適合使用mongodb，增強應用系統的穩定性和後續擴充套件彈性，而快取，排名，佇列的相關場景，redis更為擅長。

資料分析是資料處理的核心，以上從資料採集開始的各個部分都是為了這一步的資料分析做準備。

下圖是整個資料分析處理的基本處理方式

資料產品就是產品經理基於已有的資料設計出來以資料為主要展示內容的產品。我們暫把資料產品也歸為網際網路產品，那麼資料產品會有兩個特點

1 主要以資料來實現產品的功能

2產品呈現給使用者的最終目的是更有效，更直觀的解讀原始資料

例如以下兩張圖

資料解讀的結果最終需要以產品的形式來呈現。無論報表，趨勢圖，甚至是列表，頁面，都是展示形式不同而已，核心還是資料。資料的價值也就在整個資料處理的過程中體現。

本篇文章描述了基於資料統計相關的程式設計模型。在實際開發中，可以基於這個模型進行擴充套件和調整，同時結合同步非同步機制，資料庫儲存模型，結合物聯網感測器，構建高可用，有實際生產價值的網際網路應用系統。

資料分析結果解讀 系統服務化構建 資料解讀通用模型