大數(shù)據(jù)階段

阿里巴巴大數(shù)據(jù)

• 數(shù)據(jù)采集層
  （1）數(shù)據(jù)庫(kù)同步（DataX/同步中心）
  （2）消息中間件（離線、實(shí)時(shí)）
• 數(shù)據(jù)計(jì)算層
• 數(shù)據(jù)服務(wù)層
• 數(shù)據(jù)應(yīng)用層

一. 日志收集

二、數(shù)據(jù)同步

1.同步基礎(chǔ)

（1）直連同步

image.png

• 直連同步是指通過定義好的規(guī)范接口APi（ODBC/JDBC等），直接連接數(shù)據(jù)庫(kù)。
• 優(yōu)點(diǎn)：配置簡(jiǎn)單，實(shí)現(xiàn)容易，適合操作型業(yè)務(wù)系統(tǒng)的數(shù)據(jù)同步。
• 缺點(diǎn)：對(duì)原系統(tǒng)性能影響大，大批量數(shù)據(jù)同步會(huì)降低甚至拖垮業(yè)務(wù)系統(tǒng)性能，業(yè)務(wù)庫(kù)使用主備策略，從備庫(kù)抽取數(shù)據(jù)可避免性能影響。但數(shù)據(jù)量交大，采用抽取方式性能較差，不太適合從業(yè)務(wù)系統(tǒng)到數(shù)倉(cāng)系統(tǒng)的同步。

（2）數(shù)據(jù)文件同步

image.png

• 數(shù)據(jù)文件同步：通過約定好的文件編碼、大小、格式等，直接從原系統(tǒng)生成數(shù)據(jù)的文本文件，從專門的文件服務(wù)器（如ftp）加載到目標(biāo)數(shù)據(jù)庫(kù)系統(tǒng)中。
• 適用場(chǎng)景：數(shù)據(jù)源包括多個(gè)異構(gòu)的數(shù)據(jù)庫(kù)系統(tǒng)，互聯(lián)網(wǎng)的日之類數(shù)據(jù)通常以文本文件形式存在，這些都適合數(shù)據(jù)文件同步方式。
• 缺陷：文件上傳下載可能會(huì)導(dǎo)致丟包活錯(cuò)誤，一般會(huì)添加校驗(yàn)文件（記錄文件數(shù)據(jù)量以及文件大小等），以供下游目標(biāo)系統(tǒng)驗(yàn)證數(shù)據(jù)同步的準(zhǔn)確性。
  可以增加壓縮和加密操作，提高文件傳輸效率和安全性。

（3）數(shù)據(jù)庫(kù)日志解析同步

image.png

• 目前主流數(shù)據(jù)庫(kù)實(shí)現(xiàn)了使用日志文件進(jìn)行系統(tǒng)恢復(fù)，通過解析日志文件獲取變更數(shù)據(jù)，從而實(shí)現(xiàn)增量數(shù)據(jù)同步需求。

• 數(shù)據(jù)庫(kù)日志解析同步方式實(shí)現(xiàn)了實(shí)時(shí)與準(zhǔn)實(shí)時(shí)同步的能力，延遲
  以控制在毫秒級(jí)別，并且對(duì)業(yè)務(wù)系統(tǒng)的性能影響也比較小，目前廣泛應(yīng)
  用于從業(yè)務(wù)系統(tǒng)到數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)的增量數(shù)據(jù)同步應(yīng)用之中。

• 缺點(diǎn)：
  (1)數(shù)據(jù)延遲：處理高峰可能數(shù)據(jù)延遲
  (2)投入較大：需要日志實(shí)時(shí)抽取任務(wù)
  ***(3)數(shù)據(jù)漂移和遺漏：數(shù)據(jù)漂移， 般是對(duì)增量表而言的，通常是指
  該表的同一個(gè)業(yè)務(wù)日期數(shù)據(jù)中包含前一天或后一天凌晨 附近的
  數(shù)據(jù)或者丟失當(dāng)天的變更數(shù)據(jù)。

2. 阿里數(shù)據(jù)倉(cāng)庫(kù)的同步萬式

特點(diǎn)：a. 數(shù)據(jù)源種類多 b. 數(shù)據(jù)量大

（1）批量數(shù)據(jù)同步：
DataX：支持異構(gòu)數(shù)據(jù)或文件系統(tǒng)之間高速數(shù)據(jù)交換。

image.png

（2）實(shí)時(shí)數(shù)據(jù)同步
TimeTunnel:

image.png

Time Tunnel 支持主動(dòng)、被動(dòng)等多種數(shù)據(jù)訂閱機(jī)制，訂閱端自動(dòng)負(fù)載均衡，消費(fèi)者自己把握消費(fèi)策略。對(duì)于讀寫比例很高的 Topic ，能夠做到讀寫分離，使消費(fèi)不影響發(fā)送。同時(shí)支持訂閱歷史數(shù)據(jù)，可以隨意設(shè)置訂閱位置，方便用戶回補(bǔ)數(shù)據(jù)。

3.數(shù)據(jù)同步遇到的問題與解決方案

（1）分庫(kù)分表的處理

• 背景：業(yè)務(wù)增長(zhǎng)，數(shù)據(jù)量飛速增加，需要?jiǎng)”眷`活的系統(tǒng)擴(kuò)展能力和高并發(fā)處理能力。主流數(shù)據(jù)庫(kù)提供了分布式分庫(kù)分表方案來解決這個(gè)問題。
• 缺陷： 分庫(kù)分表設(shè)計(jì)增加了數(shù)據(jù)同步的復(fù)雜度。
  如果有一個(gè)中間表，具備將分布在不同數(shù)據(jù)庫(kù)中的不同表集成為 個(gè)表的能力，就能讓下游應(yīng)用像訪問單庫(kù)單表一樣方便。
• 阿里巴巴的 TDDL ( Taobao Distributed Data ayer ）就是這樣一個(gè)
  分布式數(shù)據(jù)庫(kù)的訪問引擎，通過建立中間狀態(tài)的邏輯表來整合統(tǒng)一分庫(kù)
  分表的訪問。
  TDDL 是在持久層框架之下、 JDBC 驅(qū)動(dòng)之上的中間件，它與 JDBC
  規(guī)范保持一致，有效解決了分庫(kù)分表的規(guī)則引擎問題，實(shí)現(xiàn)了 SQL
  析、規(guī)則計(jì)算、表名替換、選擇執(zhí)行單元并合并結(jié)果集的功能，同時(shí)解
  決了數(shù)據(jù)庫(kù)表的讀寫分離、高性能主備切換的問題，實(shí)現(xiàn)了數(shù)據(jù)庫(kù)配置
  信息的統(tǒng)一管理。

image.png

image.png

（2）高效同步和批量同步
（3）增量與全量同步的合并

• 合并技術(shù)大多采用 merge 方式( update+insert ）：當(dāng)前流行的大數(shù)據(jù)平臺(tái)基本都不支持 update 操作 ，現(xiàn)在我們比較推薦的方式是全外連接（ full outer join) ＋數(shù)據(jù)全量覆蓋重新加載（ insert overwrite ），即如日調(diào)度，則將當(dāng)天的增量數(shù)據(jù)和前一天的全量數(shù)據(jù)做全外連接，重新加載最新的全量數(shù)據(jù)。
  在大數(shù)據(jù)量規(guī)模下，全量更新的性能比 update 要高得多。此外，如果擔(dān)心數(shù)據(jù)更新錯(cuò)誤問題，可以采用分區(qū)方式，每天保持一個(gè)最新的全量版本，保留較短
  的時(shí)間周期（如3~7 天）

  
  
  image.png

（4）同步性能的處理

（5）數(shù)據(jù)漂移的處理

• 背景：ods 層的數(shù)據(jù)需要根據(jù)按時(shí)間切分，通常根據(jù)數(shù)據(jù)中的時(shí)間戳來切分，單實(shí)際由于時(shí)間戳字段準(zhǔn)確性而導(dǎo)致數(shù)據(jù)發(fā)生漂移。

常用數(shù)據(jù)字段：
modified time：數(shù)據(jù)庫(kù)表中標(biāo)識(shí)數(shù)據(jù)記錄更新時(shí)間的時(shí)間戳字段
log_time：數(shù)據(jù)庫(kù)日志中用來標(biāo)識(shí)數(shù)據(jù)記錄更新時(shí)間的時(shí)間戳字段
proc_time：記錄具體業(yè)務(wù)過程發(fā)生時(shí)間的時(shí)間戳字段
extract time：標(biāo)識(shí)數(shù)據(jù)記錄被抽取到時(shí)間的時(shí)間戳字段

• 數(shù)據(jù)漂移原因：
  a. 由于數(shù)據(jù)抽取是需要時(shí)間的， extract_ti me 往往會(huì)晚于前三個(gè)時(shí)
  間。
  b. 前臺(tái)業(yè)務(wù)系統(tǒng)手工訂正數(shù)據(jù)時(shí)未更新 modified_time
  c. 由于網(wǎng)絡(luò)或者系統(tǒng)壓力問題， log_time 或者 modified_time 會(huì)晚
  proc time

• 通常做法: proc_time< modified_time< log_time< extract_time

• 根據(jù) extract_time 來獲取數(shù)據(jù)。這種情況數(shù)據(jù)漂移的問題最明顯

• 根據(jù) modified_time 限制。在實(shí)際生產(chǎn)中這種情況最常見，但是往往會(huì)發(fā)生不更新 modified time 而導(dǎo)致的數(shù)據(jù)遺漏，或者凌晨時(shí)間產(chǎn)生的數(shù)據(jù)記錄漂移到后 天。

• 根據(jù) log_time 限制。由于網(wǎng)絡(luò)或者系統(tǒng)壓力問題， log time 會(huì)晚proc_time ，從而導(dǎo)致凌晨時(shí)間產(chǎn)生的數(shù)據(jù)記錄漂移到后一天。例如，在淘寶“雙 l l ”大促期間凌晨時(shí)間產(chǎn)生的數(shù)據(jù)量非常大，用戶支付需要調(diào)用多個(gè)接口，從而導(dǎo)致 log time 晚于實(shí)際的支付時(shí)間。

• 根據(jù) proc_time 限制。僅僅根據(jù) proc_time 限制，我們所獲取的ODS 表只是包含一個(gè)業(yè)務(wù)過程所產(chǎn)生的記 ，會(huì)遺漏很多其他過程的變化記錄，這違背了 ODS 和業(yè)務(wù)系統(tǒng)保持 致的設(shè)計(jì)原則

處理方法主要有以下兩種：
( l ）多獲取后一天的數(shù)據(jù)

• 向后多取一天，保障數(shù)據(jù)只多不少。具體數(shù)據(jù)切分下游根據(jù)不同業(yè)務(wù)場(chǎng)景使用pro_time限制，會(huì)有數(shù)據(jù)誤差。例如 個(gè)訂單是當(dāng)天支付的，但是第天凌晨申請(qǐng)退款關(guān)閉了該訂單，那么這條記錄的訂單狀態(tài)會(huì)被更新，下游在統(tǒng)計(jì)支付訂單狀態(tài)時(shí)會(huì)出現(xiàn)錯(cuò)誤。

(2 ）通過多個(gè)時(shí)間戳字段限制時(shí)間來獲取相對(duì)準(zhǔn)確的數(shù)據(jù)
首先根據(jù) log_time 分別冗余前一天最后 15 分鐘的數(shù)據(jù)和后一天凌晨開始 15 分鐘的數(shù)據(jù)，并用 modified time 過濾非當(dāng)天數(shù)據(jù)，確保數(shù)據(jù)不會(huì)因?yàn)橄到y(tǒng)問題而遺漏。然后根據(jù) log_time 獲取后一天 15 分鐘的數(shù)據(jù) 針對(duì)此數(shù)據(jù)，按照主鍵根據(jù) log_time 做升序排列去重。因?yàn)槲覀冃枰@取的是最接近當(dāng)天記錄變化的數(shù)據(jù)（數(shù)據(jù)庫(kù)日志將保留所有變化的數(shù)據(jù)，但是落地到 DS 表的是根據(jù)主鍵去重獲取最后狀態(tài)變化的數(shù)據(jù)）。最后將前兩步的結(jié)果數(shù)據(jù)做全外連接，通過限制業(yè)務(wù)時(shí)間proc_time 來獲取我們所需要的數(shù)據(jù)。

TODO 沒懂

三、離線數(shù)據(jù)開發(fā)

了解需求→模型設(shè)計(jì)→ETL 開發(fā)→測(cè)試→發(fā)布上線→日常運(yùn)維→任務(wù)下線。

image.png

image.png

SQLSCAN 主要有如下三類規(guī)則校驗(yàn)：
代碼規(guī)范類規(guī)則，如表命名規(guī)范、生命周期設(shè)置、表注釋等。
代碼質(zhì)量類規(guī)則，如調(diào)度參數(shù)使用檢查、分母為 提醒、 NULL
值參與計(jì)算影響結(jié)果提醒、插入字段順序錯(cuò)誤等。
代碼性能類規(guī)則，如分區(qū)裁剪失效、掃描大表提醒、重復(fù)計(jì)算檢
測(cè)等。

image.png

image.png

image.png

image.png

四、實(shí)時(shí)數(shù)據(jù)開發(fā)

常見問題：

1. 去重指標(biāo)：

（1）精確去重：需要記錄之前的所有明細(xì)
（2）模糊去重：

• 布隆過濾器
• 基數(shù)統(tǒng)計(jì)：是利用哈希的原理，按照數(shù)據(jù)的分散程度來估算現(xiàn)有數(shù)集
  的邊界，從而得出大概的去重值總和

2.數(shù)據(jù)傾斜

( 1 ）去重指標(biāo)分桶
通過對(duì)去重值進(jìn)行分桶 Hash ，相同 值一定會(huì)被放在同一個(gè)桶去重，最后再把每個(gè)桶里面的值進(jìn)行加和就得到總值，這里利用了每個(gè)桶的 CPU 和內(nèi)存資源。
(2 ）非去重指標(biāo)分桶
數(shù)據(jù)隨機(jī)分發(fā)到每個(gè)桶中，最后再把每個(gè)桶的值匯總，主要利用的是各個(gè)桶的能力。

3.事務(wù)處理

的幾個(gè)流計(jì)算系統(tǒng)幾乎都提供了數(shù)據(jù)自動(dòng) ACK 、失敗重發(fā)以及事務(wù)信息等機(jī)制。

• 超時(shí)時(shí)間 :由于數(shù)據(jù)處理是按照批次來進(jìn)行的，當(dāng) 批數(shù)據(jù)處理超時(shí)時(shí)，會(huì)從拓?fù)涞?端重發(fā)數(shù)據(jù)。另外，批次處理的數(shù)據(jù)量不宜過大，應(yīng)該增加一個(gè)限流的功能（限定一批數(shù)據(jù)的記錄數(shù)或者容量等），避免數(shù)據(jù)處理超時(shí)。
• 事務(wù)信息:每批數(shù)據(jù)都會(huì)附帶 個(gè)事務(wù) ID 的信息，在重發(fā)的情況下，讓開發(fā)者自己根據(jù)事務(wù)信息去判斷數(shù)據(jù)第一次到達(dá)和重發(fā)時(shí)不同的處理邏輯。
• 備份機(jī)制: 開發(fā)人員需要保證內(nèi)存數(shù)據(jù)可以通過外部存儲(chǔ)恢復(fù)，因此在計(jì)算中用到的中間結(jié)果數(shù)據(jù)需要備份到外部存儲(chǔ)中。

為了保證數(shù)據(jù)的幕等性。

4.數(shù)據(jù)存儲(chǔ)

（1）表名設(shè)計(jì)
設(shè)計(jì)規(guī)則：匯總層標(biāo)識(shí)＋數(shù)據(jù)域＋主維度＋時(shí)間維度
（2）rowkey 設(shè)計(jì)
設(shè)計(jì)規(guī)則： MD5 ＋主維度＋維度標(biāo)識(shí)＋子維度1 ＋時(shí)間維度＋子維度2

5.數(shù)據(jù)服務(wù)

實(shí)時(shí)數(shù)據(jù)落地到存儲(chǔ)系統(tǒng)中后，使用方就可以通過統(tǒng)一的數(shù)據(jù)服務(wù)
獲取到實(shí)時(shí)數(shù)據(jù)。

6.流式數(shù)據(jù)模型

五層（ DS DWD DWS ADS DIM ）
下面通過簡(jiǎn)單的例子來說明每一層存儲(chǔ)的數(shù)據(jù)。

• ODS層（原始數(shù)據(jù)層）：訂單粒度的變更過程， 一筆訂單有多條記錄。
• DWD層（事實(shí)明細(xì)層）：訂單粒度的支付記錄，一筆訂單只有一條記錄。
• DWS層（通用匯總層）： 賣家的實(shí)時(shí)成交金額，一個(gè)賣家只有一條記錄，并且
  指標(biāo)在實(shí)時(shí)刷新。
• ADS層（個(gè)性化匯總層）：外賣地區(qū)的實(shí)時(shí)成交金額，只有外賣業(yè)務(wù)使用。

• DIM 層（維度表）：訂單商品類目和行業(yè)的對(duì)應(yīng)關(guān)系維表。

  
  
  image.png

7.多流關(guān)聯(lián)

image.png

左右表都要緩存。
雙流關(guān)聯(lián)流程，在實(shí)際處理時(shí)，考慮到查找數(shù)據(jù)的性能，實(shí)時(shí)關(guān)聯(lián)這個(gè)步驟一般會(huì)把數(shù)據(jù)按照關(guān)聯(lián)主鍵進(jìn)行分桶處理，并且在故障恢復(fù)時(shí)也根據(jù)分桶來進(jìn)行，以降低查找數(shù)據(jù)量和提高吞吐量。

8.維表使用

在實(shí)時(shí)計(jì)算中，關(guān)聯(lián)維表一般
會(huì)使用當(dāng)前的實(shí)時(shí)數(shù)據(jù)（ T）去關(guān)聯(lián) T-2 的維表數(shù)據(jù)，相當(dāng)于在 的數(shù)
據(jù)到達(dá)之前需要把維表數(shù)據(jù)準(zhǔn)備好，并且一般是 份靜態(tài)的數(shù)據(jù)。

采用維表關(guān)聯(lián)的原因：

1 數(shù)據(jù)無法及時(shí)準(zhǔn)備好
0點(diǎn)時(shí)前一天的數(shù)據(jù)沒有準(zhǔn)備好

2. 無法準(zhǔn)確獲取全量的最新數(shù)據(jù)
   需要當(dāng)天獲取實(shí)時(shí)的最新數(shù)據(jù)。
3. 數(shù)據(jù)無序性

維表關(guān)聯(lián)： 全量加載和增量加載

如何進(jìn)行實(shí)時(shí)任務(wù)優(yōu)化

• ( 1 ）獨(dú)占資源和共享資源的策略
  在一臺(tái)機(jī)器中，共享資源池可以被多個(gè)實(shí)時(shí)任務(wù)搶占，如果一個(gè)任務(wù)在運(yùn)行時(shí)80% 以上的時(shí)間都需要去搶資源，這時(shí)候就需要考慮給它分配更多的獨(dú)占資源，避免搶不到 CPU資源導(dǎo)致吞吐量急劇下降。
• (2 ）合理選擇緩存機(jī)制，盡量降低讀寫庫(kù)次數(shù)
  內(nèi)存讀寫性能是最好的，根據(jù)業(yè)務(wù)的特性選擇不同的緩存機(jī)制，讓
  最熱和最可能使用的數(shù)據(jù)留在內(nèi)存中，讀寫庫(kù)次數(shù)降低后，吞吐量自
  就上升了。
• (3 ）計(jì)算單元合并，降低拓?fù)鋵蛹?jí)
  拓?fù)浣Y(jié)構(gòu)層級(jí)越深 性能越差，因?yàn)閿?shù)據(jù)在每個(gè)節(jié)點(diǎn)間傳輸時(shí)，
  部分是需要經(jīng)過序列化和反序列化的，而這個(gè)過程非常消耗 CPU 和時(shí)間
• (4 ）內(nèi)存對(duì)象共享，避免字符拷貝
  在海量數(shù)據(jù)處理中，大部分對(duì)象都是以字符串形式存在的，在不同
  線程間合理共享對(duì)象，可以大幅降低字符拷貝帶來的性能消耗，不過
  注意不合理使用帶來的內(nèi)存溢出問題。
• (5 ）在高吞吐量和低延時(shí)間取平衡
  高吞吐量和低延時(shí)這兩個(gè)特性是一對(duì)矛盾體，當(dāng)把多個(gè)讀寫庫(kù)操作
  或者 ACK 操作合并成一個(gè)時(shí)，可以大幅降低因?yàn)榫W(wǎng)絡(luò)請(qǐng)求帶來的消耗，
  不過也會(huì)導(dǎo)致延時(shí)高一些，在業(yè)務(wù)上衡量進(jìn)行取舍。

六、數(shù)據(jù)服務(wù)

image.png

DWSOA

image.png

OpenApi

image.png

SmartDQ

image.png

OneService

image.png

1. 資源

系統(tǒng)的資源是有限的，如果能合理分配資源，使資源利用最大化，
那么系統(tǒng)的整體性能就會(huì)上一個(gè)臺(tái)階。下面講述合理的資源分配是如何
提高性能的。
( 1 ）剝離計(jì)算資源
調(diào)用者調(diào)用接口獲取的數(shù)據(jù)，有些指標(biāo)需要多天數(shù)據(jù)的聚合，比如
最近 天訪客瀏覽量、最近 365 天商品最低價(jià)格等；有些指標(biāo)還包含一
些復(fù)雜的計(jì)算邏輯，比如成交回頭率，其定義為在統(tǒng)計(jì)時(shí)間周期內(nèi)，有
兩筆及以上成交父訂單的買家數(shù)除以有成交父訂單的買家數(shù)。
如此復(fù)雜的計(jì)算邏輯，如果放在每次調(diào)用接口時(shí)進(jìn)行處理，其成本
是非常高 的。因此剝離復(fù)雜的計(jì)算統(tǒng)計(jì)邏輯，將其全部交由底層的數(shù)據(jù)
公共層進(jìn)行處理，只保留核心的業(yè)務(wù)處理邏輯。詳細(xì)內(nèi)容請(qǐng)參見第 章。
(2 ）查詢資源分配
查詢接口分為兩種： Get 接口，只返回一條數(shù)據(jù)； Lis 接口，會(huì)返
回多條數(shù)據(jù)。一般來說， Get 查詢基本都轉(zhuǎn)換為 查詢，響應(yīng)時(shí)間比
較短，或者說查詢代價(jià)比較小。而 List 查詢的響應(yīng)時(shí)間相對(duì)較長(zhǎng)，且返
回記錄數(shù)比較多，這就增加了序列化以及網(wǎng)絡(luò)傳輸?shù)某杀荆樵兇鷥r(jià)肯
定會(huì)更高一些。

image.png

image.png

(3 ）執(zhí)行計(jì)劃優(yōu)化
①查詢拆分。

image.png

②查詢優(yōu)化。
查詢優(yōu)化是分析用戶請(qǐng)求中的 SQL 語(yǔ)句，將符合條件的 List查詢轉(zhuǎn)換為 Get 查詢，從而提高性能。

（4）緩存優(yōu)化

• 元數(shù)據(jù)緩存

• 模型緩存

  
  
  image.png
  
  

  對(duì) DSL 進(jìn)行語(yǔ)法、詞法分析，并替換 WHERE 中的常量。比如
  where user_id = 123 替換為 where user_id ＝？。
  ·以替換后的語(yǔ)句做 key ，去本地緩存中進(jìn)行查找。如果命中，則
  提取出緩存中的模型，直接將 SQL 提交給 查詢。
  如果上一步?jīng)]有命中， 則進(jìn)行正常的解析處理，并緩存解析后的
  結(jié)果。
  需要注意的是，由于模型緩存在本地，為了避免占用太多的內(nèi)存，
  需要定期將過期 的模型淘汰掉。假如元數(shù)據(jù)有變更，則緩存中的模型有
  可能已經(jīng)失效或者是錯(cuò)誤的，因此需要全部清理掉。

(3 ）結(jié)果緩存

image.png

3.查詢能力
( 1 ）合并查詢
(2 ）推送服務(wù)

4. 穩(wěn)定性

5. 發(fā)布系統(tǒng)
   ( l ）元數(shù)據(jù)隔離
   一般的應(yīng)用都會(huì)有 個(gè)環(huán)境：日常環(huán)境、預(yù)發(fā)環(huán)境和線上環(huán)境。日常環(huán)境用于線下開發(fā)測(cè)試。預(yù)發(fā)環(huán)境隔離了外部用戶的訪問，用于在正式發(fā)布前校驗(yàn)即將上線的代碼。

   
   
   image.png

(2 ）隔離發(fā)布

隔離：機(jī)房隔離，分組隔離
安全限制：數(shù)據(jù)limit，字段限制，超時(shí)時(shí)間

監(jiān)控：
( 1 ）調(diào)用日志采集
如果要對(duì)調(diào)用做監(jiān)控，首先要保證調(diào)用日志的完整性。對(duì)于每次調(diào)
用都進(jìn)行了采集，采集的信息包括：

• 基礎(chǔ)信息 ，包括調(diào)用時(shí)間、接口名、 方法名、返回記錄數(shù)等。
• 調(diào)用者信息，包括調(diào)用者應(yīng)用名、來源 IP 地址等。
• 調(diào)用信息，包括調(diào)用指標(biāo)、查詢篩選條件等。
• 性能指標(biāo)，包括響應(yīng)時(shí)間、是否走緩存等。
• 錯(cuò)誤信息，包括出錯(cuò)原因、錯(cuò)誤類型、數(shù)據(jù)源、錯(cuò)誤堆械等。
  (2 ）調(diào)用監(jiān)控
  有了調(diào)用日志，就可以監(jiān)控系統(tǒng)的健康狀況，及時(shí)發(fā)現(xiàn)問題。監(jiān)控可以從以下幾個(gè)方面展開：
• 性能趨勢(shì)。總體 QPS 趨勢(shì)圖、 RT 趨勢(shì)圖、響應(yīng)時(shí)長(zhǎng)區(qū)間分布。分組性能統(tǒng)計(jì)、單機(jī) QPS 統(tǒng)計(jì)，以對(duì)當(dāng)前系統(tǒng)容量做評(píng)估。
• 零調(diào)用統(tǒng)計(jì)。找出最近 天無調(diào)用的表，進(jìn)行下線處理，節(jié)約成本。
• 慢 SQL 查找。找出響應(yīng)時(shí)間較長(zhǎng)的 SQL ，及時(shí)進(jìn)行優(yōu)化。
• 錯(cuò)誤排查。當(dāng)系統(tǒng)的調(diào)用錯(cuò)誤數(shù)突增時(shí)，能從錯(cuò)誤日志中及時(shí)發(fā)現(xiàn)出錯(cuò)原因、出錯(cuò)的數(shù)據(jù)源等。

5. 降級(jí)、限流
   ( 1）限流
   是應(yīng)用內(nèi)的 QPS保護(hù)
   如果某個(gè)調(diào)用者的調(diào)用量突增 ，或者對(duì)某個(gè)數(shù)據(jù)源的查詢流量突增，超過了預(yù)設(shè)的QPS 闌值，則后續(xù)的請(qǐng)求立即失敗返回，不再繼續(xù)處理。通過快速失敗，將超出系統(tǒng)處理能力的流量直接過濾掉，保障了系統(tǒng)的可用性。
   (2 ）降級(jí)
   降級(jí)主要有兩種做法：

• 通過限流措施，將 QPS 置為 0，則對(duì)應(yīng)的所有訪問全部立即失敗，防止了故障的擴(kuò)散。
• 通過修改元數(shù)據(jù)，將存在問題的資源置為失效狀態(tài)，則重新加載元數(shù)據(jù)后，對(duì)應(yīng)的訪問就全部失敗了，不會(huì)再消耗系統(tǒng)資源。

五、數(shù)據(jù)挖掘

略