背景
從事資料架構多年，一直被問到一些問題，例如：what、why。
- what：産品的資料架構是怎樣的
- why：為什麼是怎樣的，選型依據是怎麼樣的
我一直回答不好這個問題，一是因為從研發轉向資料架構規劃，自己一直處在學習中，二是解決的問題，在問題發生時都沒有可參考的大廠經驗，也是處在摸索階段。最近資料架構逐漸穩定，從 TiDB 社群活動中也受益頗多，做了很多資料架構的思考，借着 6.0 的釋出，談一下自己總結的資料技術架構方法，通過一個案例，場景式展現整個設計過程。通過本文的一些描述，希望能夠給初步踏上架構選型之路上的同學們一些幫助。
聲明
資料架構的選型需要參考的因素很多，因能力有限，本文所述隻是基于作者視角做的一些總結、分享，如有常識性錯誤，請及時通知作者修改。 本文是從整體架構過程中，抽取資料架構有關的過程做分析，作為企業級架構過程參考可能有所不足。 本文是一個架構理論總結，其 POC 過程盡量還原真實情況，可能存在疏漏，僅供參考。
資料架構的一般過程
總結我司多年的經驗，資料架構的一般過程如下：
- 架構需求分析
- 技術産品選型
- POC 設計與測試
- 整體架構設計
各階段輸入 / 輸出如下：
| 階段 | 輸入 | 輸出 |
| 架構需求分析 | 系統需求說明書 | 技術需求矩陣、架構權衡點 |
| 技術産品選型 | 權衡點矩陣 | 備選産品清單 |
| POC 設計與測試 | 備選産品清單 | POC 場景設計、POC 驗證結果 |
| 整體架構設計 | POC 驗證結果 | 資料架構設計說明書 |
本文遵從上述資料架構設計的一般過程，從實際項目抽象一個典型的項目作為模闆，叙述上述過程的具體實踐。
架構需求分析
架構需求分析一般從系統需求說明書入手，本節抽取系統需求說明書中的一分部内容說明，最後形成技術需求矩陣、架構權衡點。
企業組織架構
組織說明：
- 總公司：管理主體，對系統的主要訴求是浏覽器端的各層級管理報表，實時大屏需求。
- 分公司：實際的經營主體，對系統的主要訴求是浏覽器端的實時管理報表，實時大屏，模型分析需求、标簽。通過模型分析評價專賣店的運作情況，發現風險，通過标簽分析本省或者本地區消費者的消費偏好，管理本省或者本地區營銷活動。
- 零售：分為店長端和店員端應用，店長端主要通過微信小程式浏覽本店實時交易報表、管理庫存、管理活動 / 折扣，店員端主要通過桌面端完成商品銷售。
- 消費者：消費者通過微信小程式完成附件店鋪尋找、商品預覽、活動預覽等功能。
元件規劃與特性分析
抽象上述各組織産品需求，設計子產品如下：
應用子產品技術需求分析：
- 交易型應用：管理、交易、活動；強事務、高并發，活動開展時存在熱點商品問題，此類功能相對固定，需求變更不多，但穩定性要求極高
- 分析型應用：報表、大屏、标簽、模型分析；低延遲、實時線上分析、海量離線計算，此類功能需求多，需求變更多，工作量占比在 80%，要求極度靈活的報表組織能力和資料分析能力
- 接口型應用：應對第三方交易對接，接受或者輸出實時、批量銷售庫存資訊，此類功能遵循一個穩定的接口規範，變更較少，但要考慮流量消峰、資料審計、傳輸補償等安全問題，技術比較複雜
根據咨詢公司資料回報，專賣店日均銷售筆數為 60 筆，專賣店中的旗艦店，日均交易超過 1200 筆。單日估計最大訂單數量 1000 萬，即訂單表單日存儲資料量約 1000 萬，一年的訂單表資料 36 億，按照以前的項目經驗，僅估算交易資料，項目整體資料量一年約 72 億。
非功能性限制：
- 交易功能響應時間小于 1 秒，針對網絡短暫不穩定的情況，需提供解決方案。管理應用響應時間小于 3 秒，分析型應用小于 3 秒
- 需符合目前主流安全标準（非本文描述範圍，也較為敏感，簡單處理）
- 實時分析需能查詢三年以内的交易明細資料，3 年之外的交易資料可以做歸檔處理。歸檔資料需能夠再次讀取
- 相容目前主流雲平台部署，可以實作基于雲的彈性伸縮
硬體采購限制：
- 硬體部署在自建機房
- 硬體裝置需按需投入，分階段投入
- 本次建設暫不考慮多中心設計
- 基于成本原因，優先采用開源産品
技術需求矩陣
根據組織需求和産品子產品設計，轉化為對技術元件的需求：
| 組織級别 | 報表 | 大屏 | 模型分析 | 标簽 | 管理 | 銷售 | 活動 |
| 總公司 | OLAP T+1 | OLAP T+1 | |||||
| 分公司 | OLAP 實時 | OLAP 實時 | 離線計算、OLAP T+1 | 離線計算、全文搜尋 | OLTP | ||
| 專賣店 | OLTP | OLTP、高速緩存 | OLTP | ||||
| 消費者 | LBS | OLTP、高速緩存 |
客戶背景分析
客戶方屬于成本敏感性一般的企業，對高端硬體的投入以實際需求為主，年初預算、年中采購、年末審計。客戶方有獨立的資訊部門，但技術能力較弱，沒有技術儲備，資訊部門的負責人思路較為超前，對新技術有較多了解，願意采用較為先進的技術解決問題。
研發團隊背景分析
研發團隊有前端研發、後端研發、資料研發、運維四組人組成，前端研發與資料架構關系較小，不做介紹，其他三組人背景如下：
- 後端研發：java 語言背景，以 28 歲以下年輕人為主，占比 80%，具有基本 java 研發能力與基本的 SQL 基礎，剩餘 20% 為 java 技術專家，負責封裝基礎元件，與中間件的互動，平台級元件
- 資料研發：python 語言背景，spark 實踐經驗，SQL 較為熟練，以固化離線彙總需求、利用 python 模組化、客戶實時資料查詢需求為主要工作内容
- 運維：人數很少，多年 mysql 資料庫運維經驗，多團隊共享一個運維團隊，兼職 DBA 工作
研發團隊最嚴重的問題是 DBA 與研發配置不合理，SQL 稽核工作可能不到位，有線上 SQL 性能風險；運維為多個研發團隊共享，運維工作需要高度工具化，減少、減輕運維工作量，才能保證項目正常開展。
權衡點矩陣
結合技術需求矩陣、客戶背景分析、研發團隊背景分析，跟相關技術架構決策者溝通後，總結架構權衡點如下：
| 權衡點 | 需求來源 |
| OLTP MySql 協定 | 技術需求矩陣、研發團隊背景分析 |
| OLAP MySql 協定 | 技術需求矩陣、研發團隊背景分析 |
| TP、AP 統一入口 | 架構決策 |
| 具備冷熱資料分離能力 | 架構決策、硬體采購限制 |
| 具備 CDC 能力 | 架構決策、硬體采購限制 |
| 本地部署，非雲産品 | 硬體采購限制 |
| 可友善的進行硬體擴容 | 硬體采購限制 |
| 具有 java 用戶端、python 用戶端 | 研發團隊背景分析 |
| 具有良好的可觀測性、具有自診斷、自修複，或者部分實作了自診斷、自修複特性 | 研發團隊背景分析 |
| 社群活躍，支援良好，有較多案例 | 架構決策 |
| 能夠适配 Spark，實作并行讀寫 | 研發團隊背景分析 |
設計此表格的目的是在架構選型時做評估用，類似于招标檔案中的技術要求，各個資料庫産品需要應标。表中的架構決策是指架構師和相關決策者根據經驗增加的要求。
資料庫架構選型
先畫個圖表看看我們到底需要哪種類型的資料庫：
| | 分布式 | 叢集 | 單機 | 雲部署 | 本地部署 | | ---- | --- | -- | :- | :-- | :--- | | OLTP | ✅ | ✅ | | | ✅ | | OLAP | ✅ | ✅ | | | ✅ | | HTAP | ✅ | ✅ | | | ✅ | | KV | | | | | | | 文檔 | | | | | | | 圖資料庫 | | | | | | | 列簇 | | | | | | | 時序 | | | | | | | 空間 | | | | | | | 記憶體 | ✅ | ✅ | | | ✅ | | 搜尋引擎 | ✅ | ✅ | | | ✅ |
記憶體資料庫、搜尋引擎因我司技術平台技術內建的原因，沒有什麼可選擇性，采用 Redis、Elasticsearch，其他類型在這次規劃中，可以重新選擇。
OLTP 架構選型
目前 OLTP 類型的資料庫，分為單體資料庫和分布式資料庫，基于本項目的資料量估算和成本原因，不采用開源單體資料庫，采用開源分布式資料庫，目前開源分布式資料庫有三種架構方式：
- 分庫分表 + 中間件
說明：此種架構，在成熟的單體資料庫與應用之間加資料代理層，在資料代理層中配置放置規則，實作資料分庫分表、讀寫分離。 優勢：底層資料庫較為成熟，成本低，穩定性好 劣勢：随着資料量的增大，分片規則、擴縮容等方面的工作面對較多挑戰；如果做了讀寫分離，強一緻性讀很難保障，都需要加注解；叢集可觀測性不友好。
- 去中心化的分布式資料庫
說明：此種架構目前作為分布式的架構最為常見，也就是大家經常說的 Shared-nothing 架構。此架構節點之間不共享資料，可以平滑的擴縮容，通過共識算法保證多副本的可用性。 優勢：高内聚、低耦合；有較為廣泛的應用；可以動态水準擴充；可保證強一緻性。
- 共享存儲分布式資料庫
說明：此架構多個計算節點共享一個存儲叢集，多個節點之間無需日志複制，用實體檔案複制代替。 優勢：此種架構依賴于底層硬體的創新，例如非易失存儲、遠端直接資料存取等技術，我認為是未來分布式資料庫發現的方向之一，由于減少了主從之間日志複制的環節，系統的穩定性有了更可靠的保障。 劣勢：目前類似技術被大廠綁定，正常采購很難低成本獲得類似硬體，而且此類技術也不算成熟。
ETL 與 OLAP 架構選型
OLAP 的資料一般來源于 OLTP，可能會有第三方資料補充，ETL 一般伴随着 TP 和 AP 選型的不同而改變從 OLTP 同步資料到 OLAP，存在四種方式：
- 定時抽取
說明：此架構通過設定每日定時任務，根據 timestamp 等字段，抽取每日增量到分析庫，基于分析庫做離線計算與線上分析。 優勢：實作簡單，工具成熟 劣勢：實時性不足；抽取過程容易幹擾 TP 正常業務；抽取一般在淩晨，一旦抽取失敗，工作時間發現并修複，會嚴重幹擾 TP 業務。
- 實時同步
說明：此架構通過 TP 資料庫的 CDC 技術同步資料到流處理平台，AP 資料庫主動或者被動從流處理平台擷取增量資料，批量回放到庫表中。 優勢：資料相對實時；對 TP 幹擾小；随時進行資料回放修複同步錯誤。 劣勢：無法保證強一緻性；一般需要在應用端建立兩個資料源，應用開發人員需要厘清楚 TP 和 AP 業務。
- 日志同步
說明：此架構常見于 HTAP 資料庫，資料庫内建 TP 和 AP 兩個存儲模型，TP 和 AP 之間通過日志同步，應用通過一個統一入口通路，通路入口根據 SQL 代價或者其他評估方案自動采用不同引擎提供服務，不必感覺底層實作。 優勢：TP 和 AP 之間可以保證強一緻性；應用無需過多關心底層實作，通過一個入口通路。 劣勢：對硬體有較高要求
- 共享存儲
說明：此架構的 TP 和 AP 引擎公用一個共享存儲，資料不存在複制過程。 優勢：沒有日志的邏輯複制過程，用實體檔案複制代替（共享存儲特性），實時性好，系統負擔小。 劣勢：技術不太成熟，依賴于新的硬體，例如非易失存儲、遠端直接資料存取等技術。
模型、标簽架構選型
受研發團隊背景和子產品複用要求的限制，模型、标簽複用 python(Jupyter Notebook)、spark(SparkSQL) 等已經實作的元件，不再過多考慮其他方案。
備選産品圈定
首先參考一下，墨天倫的排名，篩選開源、關系型資料庫，選取 TOP5 如下：
根據架構權衡點的要求，所標明資料庫要求本地部署、相容 MySQL 協定，排除 PolarDB、GaussDB、openGauss，隻剩下 TiDB、OceanBase，根據權衡點，繪制對元件情況如下：
| 權衡點 | TiDB | OceanBase |
| OLTP MySql 協定 | 支援 | 支援 |
| OLAP MySql 協定 | 支援 | 支援 |
| TP、AP 統一入口 | 支援 | 支援 |
| 具備冷熱資料分離能力 | 支援放置政策 | 支援放置政策 |
| 具備 CDC 能力 | 支援 | 支援 |
| 本地部署，非雲産品 | 支援 | 支援 |
| 可友善的進行硬體擴容 | 支援 | 支援 |
| 具有 java 用戶端、python 用戶端 | 相容 MySQL 用戶端 | 相容 MySQL 用戶端 |
| 具有良好的可觀測性，具有自診斷、自修複，或者部分實作了自診斷、自修複特性 | 流量可視化、SQL 語句分析、慢查詢分析、叢集診斷、Clinic | OCP、SQL Diagnoser |
| 社群活躍，支援良好，有較多案例 | 另行分析 | 另行分析 |
| 能夠适配 Spark，實作并行讀寫 | 支援 TiKV 直讀、直寫，支援直讀 TiFlash | 支援 JDBC 讀寫 |
在社群方面的表現見下表（資料截止到 20220601）：
| 開源項目 | 發版模式 | 已解決 Issues（github） | Star/Fork | 社群版本使用者數量 |
| TiDB | 基于同一個版本庫，開源版本與商業版本同步發版 | 9K+ | 31.5K/5.1K | 2K+ |
| OceanBase | 基于不同的版本庫，開源版本落後于商業版本，同步頻率未知 | 400+ | 4.3K/972 | 400+ |
OceanBase 盛名已久，但因為開源時間晚于 TiDB，資料上并不好看，但 OceanBase 的發版方式，讓開源版本與商業版本的核心特性有較大差距，TiDB 的開源版本與商業版本是同一套代碼，開源使用者完全可以跟随版本釋出使用到最新的特性和 BUG 修複，在這一點上 TiDB 比 OceanBase 更具有優勢。 可觀測性對資料庫的運維十分重要，TiDB 的流量可視化可以更直覺的觀測到讀寫熱點，Clinic 可以一鍵打通本地環境與社群專家的溝通管道，這兩方面也具有一定優勢。 根據以上分析，本次架構設計中 TiDB 列為 POC 測試産品，OceanBase 列為備選産品。
POC 設計與測試
POC 設計一般考慮幾個方面的功能：
- 核心業務場景：核心業務場景是指資料庫上線之後需要解決的關鍵場景，核心業務場景支援不好，可以一票否決資料庫選型。
- 典型性能場景：典型性能場景是指系統可能會遇到的高并發、熱點讀寫場景，是資料庫選型在本項目中的能力上線，通常類似場景也會涉及到記憶體資料庫與關系型資料庫的配合，需要根據場景，提出合了解決方案，并嘗試靠近設計目标。
- 價值導向場景：價值導向場景一般指項目甲方的關鍵人員所使用的功能場景，如果保障此類場景的穩定，需要通過架構設、資源隔離等多種手段達到目标。 根據前文功能設計，選取 POC 場景如下：
- 壓力測試 - 登入：測試登入性能瓶頸
- 壓力測試 - 訂單送出：測試訂單送出性能瓶頸
- 壓力測試 - 商品資訊查詢：測試商品資訊查詢瓶頸，由于存在多級緩存，最終測試結果并不能表達關系型資料庫的能力。
- 壓力測試 - 三表關聯性能測試：選取典型的報表查詢 SQL，至少是三表關聯的查詢
- 穩定性測試 - 登入：由于客戶場景存在持續性壓力高峰，對登入做超過 6 小時的穩壓測試
- 穩定性測試 - 熱點混合場景：由于客戶場景存在持續性壓力高峰，對 1、2、3 三個場景做混合負載穩壓測試
- 穩定性測試 -HTAP 混合場景：由于客戶場景存在持續性壓力高峰，2、4 兩個場景做混合負載穩壓測試
我們一般使用 metesphere 或者 jmeter 測試。metesphere 一般用于正式環境壓力測試，有很多優秀的特性，部署時需要有一定的資源保障，jmeter 即開即用，相容多種測試場景，本文截取 jmeter 的部分截圖做一些展示和說明。 jmeter 截圖：
grafana 截圖：
其實簡言之，就是在 average 合理的範圍區間裡（一般是非功能性需求，訂單送出 1 秒之内，查詢 3 秒之内），當 cpu、記憶體、磁盤 IO 達到 100% 時，Throughput 穩定在哪個值，這個值就是并發。經過多輪參數調整和回歸測試，最後得到的最大值就是最優并發。