TiDB 在零氪科技（LinkDoc）大數據醫療系統的實踐

公司介紹

零氪科技作為全球領先的人工智慧與醫療大數據平台，擁有國內最大規模、體量的醫療大數據資源庫和最具優勢的技術支撐服務體系。多年來，零氪科技憑藉在醫療大數據整合、處理和分析上的核心技術優勢，依託先進的人工智慧技術，致力於為社會及行業、政府部門、各級醫療機構、國內外醫療器械廠商、葯企等提供高質量醫療大數據整體解決方案，以及人工智慧輔助決策系統（輔助管理決策、助力臨床科研、AI 智能診療）、患者全流程管理、醫院輿情監控及品牌建設、葯械研發、保險控費等一體化服務。

LinkDoc 的主要應用場景

LinkDoc 通過將患者真實的病例數據和演算法模型應用於腫瘤治療，構建精準的診療模型並提供數據支持，從而輔助醫院管理決策、輔助科研、輔助臨床診療。目前 Hubble 系統「肺癌淋巴結跳躍轉移風險預測」模塊可避免肺癌病人由於誤判而導致提前 8-10 個月的複發，每年能讓近兩萬病人的生命再延長 8-10 個月。Hubble 系統「 AI - 肺結節智能診斷」模塊全自動地識別 CT 影像中所有的結節，識別率達 91.5%。LinkDoc 希望憑藉醫療大數據整合、處理和分析上的核心技術優勢，以互聯網人工智慧上的創新研發，提升中國醫師的全球醫學水準，並通過支持藥物研發與醫療保險行業的發展，讓每一位患者享有普惠、精準的醫療服務。

支撐 LinkDoc 業務的底層資料庫平台也面臨著醫療行業新領域的技術 & 業務挑戰，如數據量的快速增長(億級別)、大數據量下的清洗邏輯的數據擦寫、分析型事物對資料庫的讀壓力都要求我們在資料庫平台進行重新探索，選擇一款適合醫療大數據業務的資料庫解決方案。

選擇 TiDB

1. 業務痛點

• 數據量大，單實例 MySQL 擴容操作複雜；
• 寫入量大，主從延時高，由於業務對數據有低延時的要求，所以傳統的 MySQL 主從架構在該項目下不能滿足需求，大量數據寫入下主庫成為性能瓶頸；
• 隨著數據量越來越大，部分統計查詢速度慢；
• 分庫分表業務開發和維護成本高。

2. 需求

• 高可靠性 & 穩定性；
• 可擴展性，可隨數據量 & 請求量增長快速提升存儲 & 請求處理能力；
• 更低的延時。

3. 方案調研

未選擇 TiDB 之前我們調研了 MyCAT、Cobar、Atlas 等中間件解決方案，這些中間件整體來說就是讓使用者覺得很 「擰巴」，從社區支持、MySQL 功能兼容、系統穩定性上都不盡人意，需要業務做大量改造，對於快速發展的公司來說切換成本太高。

在 LinkDoc 首席架構師王曉哲的推薦下我們調研了 TiDB, TiDB 的如下特性讓我們眼前一亮：

• 兼容絕大部分 SQL 功能（意味著業務可以簡單改造後平滑遷移至 TiDB）；
• 水平擴展能力；
• 分散式事務；
• 故障快速恢復能力；
• 監控指標覆蓋度。

上線 TiDB

1. 兼容性測試

經過兼容性測試後我們對業務做了如下簡單改造：

• Blob 類型數據遷移至 HBase 做 key-value 存儲；
• Batch delete 改成小批量多次操作，一批刪除 1000 條。

2. 灰度上線

由於業務對於主從同步延時要求較高，我們採用業務雙寫的方案切換了我們的第一個應用。灰度第一階段業務同時寫 MySQL、TiDB，讀走 MySQL，並驗證數據一致性，經過2周的驗證後我們灰度第二階段。灰度第二階段業務雙寫 TiDB、MySQL，讀業務走 TiDB。經過一個月的業務驗證後我們徹底下掉了 MySQL。

3. 系統架構

上線過程中也遇到一個小坑，之前用的阿里雲普通實例 + SSD 雲盤跑 TiDB，在該配置下經常會遇到性能抖動問題，在 PingCAP 同學的建議下我們更換了阿里雲本地 SSD 型機型，目前系統運行良好。

系統配置 & 架構如下：

生產集群部署情況（機器基於阿里雲）：

目前現狀和下一步規劃

目前 TiDB 在 LinkDoc 已承載數據量最大的兩個業務。平時 QPS 6K，峰值 12K。

後續將使用 TiDB 承載更多大數據量業務庫, 並調研 TiSpark。通過 TiDB 構造成一個兼容分析型和事務型的統一資料庫 HTAP 平台。

致 PingCAP

非常感謝 PingCAP 小夥伴們的大力支持，從硬體選型、業務優化、系統培訓到上線支持 PingCAP 都展現了熱情的服務態度、專業的技術能力，幫助 LinkDoc 順利上線 TiDB，解決系統難題，支持業務快速發展。相信在這樣一群小夥伴的努力下 TiDB 會越來越成熟、承載更多的業務場景，用技術創造奇蹟。

? 作者介紹：楊浩 現任零氪科技 運維&安全負責人，曾就職於阿里巴巴-技術保障部-CDN。專註 CDN、安全、自動化運維、大數據等領域。