在開始技術分享前首先來輕鬆一下，看一段段子，看下美女，放鬆一下

去醫院，坐長凳上排隊等候，突然很想放屁，但是人多不太好意思。於是拿出手機開啟湯姆貓，聲音調最大點了放屁。就在我暗自慶幸沒人發現的時候。後面一哥們回頭看著我說：“兄弟你用的是什麼牌子的智慧手機，手機裡放屁，我都能聞到臭味。”

架構設計文件一、引言1.1 專案背景

資料品質監測是大資料處理中最重要的一個環節，是資料服務、資料分析、資料探勘等活動的必備支援條件。

1.2 專案概述

提出了一個基於大資料平臺的資料品質管理服務Qualitis，提供統一的流程來定義和檢測資料集的品質並及時報告問題。

1.3 術語表

術語含義專案(project)一系列規則的集合，決定告警人和告警級別，是任務排程的單位之一。規則(rule)資料來源的資料品質模型的定義，決定是否告警，是任務排程的基礎單位。任務(application)資料品質檢測任務，通過執行資料品質任務，可以檢視資料品質校驗結果。

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。

四、 介面設計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隨機數，長度為5signature是string加密簽名。md5(md5(appId + nonce + timestamp) + appToken)，其中md5生成32長度，小寫

其中app_id和appToken需要管理員授予外部系統。

五、系統工程結構設計

系統的工程結構可以分為2層，Web層和Core層。

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