數據質量分析

數據質量分析
1、引言
1.1 項目背景
數據質量監測是大數據處理中最重要的一個環節，是數據服務、數據分析、數據挖掘等活動的必備支持條件。

1.2 項目概述
提出了一個基於大數據平臺的數據質量管理服務Qualitis，提供統一的流程來定義和檢測數據集的質量並及時報告問題。

1.3 術語表
術語 含義
項目(project) 一系列規則的集合，決定告警人和告警級別，是任務調度的單位之一。
規則(rule) 數據源的數據質量模型的定義，決定是否告警，是任務調度的基礎單位。
任務(application) 數據質量檢測任務，經過運行數據質量任務，能夠查看數據質量校驗結果。
2、整體設計
2.1 整體架構設計

2.2 灰度功能設計
因爲每一個Qualitis後端服務是冪等的，要灰度只須要對單個後端服務進行隔離，讓其沒法接受用戶請求。

2.3 高可用及性能設計
Qualitis各個服務之間是冪等的，能夠經過同時起多個Qualitis服務，對Qualitis服務進行負載均衡進行實現。以下圖所示： 負載均衡
負載均衡這一策略，不只實現了高可用，而且也實現了性能的提高。

性能方面的設計，考慮如下方案。但目前暫未實現。

1.查詢緩存
使用分佈式緩存，將查詢結果緩存起來，就沒必要查詢的時候，每次都查詢數據庫，大大的減小了數據庫的壓力，而且提高了查詢的速度。

2.4 多線程同步設計
1.進程同步
因爲存在多個Qualitis實例，多個實例之間可能會存在同時刷新監控任務狀態的狀況，因此須要解決進程同步的問題。

Qualitis系統採用Zookeeper協調多進程，多個Qualitis實例會爭搶在Zookeeper中創建臨時節點，創建臨時節點成功的，會做爲Monitor角色，由Monitor角色對監控任務，並刷新任務的狀態。

2.線程限流
當觸發監控任務提交時，須要鏈接hive meta store，判斷保存未經過校驗的數據的數據庫是否存在。

當提交任務量上來是，可能會對hive meta store形成巨大壓力，因此須要對任務提交進行限流。

Qualitis系統使用線程池的方式，對鏈接hive meta store進行限流，若是從線程池中拿不到線程，任務會等待，直到拿到線程，才鏈接hive meta store。

3、 模塊設計
3.1 整體模塊設計圖

3.2 用例圖

4、 接口設計
4.1 內部接口
內部接口主要分爲兩類接口：
1.管理員接口
2.用戶接口

管理員接口設計: /qualitis/api/v1/admin/*
用戶接口設計: /qualitis/api/v1/projector/*
經過兩種不一樣的接口定義方式，將用戶的權限區分開。

4.2 外部接口
外部接口url定義:/qualitis/outer/api/v1/*
此類接口調用須要在query中增長以下參數:

參數名 必選 類型 說明
app_id 是 string 系統分配的受權應用APP_ID.
timestamp 是 string 時間戳。毫秒級的時間戳，時效性：7天
nonce 是 string 隨機數，長度爲5
signature 是 string 加密簽名。md5(md5(appId + nonce + timestamp) + appToken)，其中md5生成32長度，小寫
其中app_id和appToken須要管理員授予外部系統。

5、系統工程結構設計
系統的工程結構能夠分爲2層，Web層和Core層。

Web層主要包括Controller和Service，主要包含對外提供服務的服務層，Core層主要包括核心代碼邏輯和存儲層。