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

公司介紹

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

LinkDoc 的主要應用場景

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

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

選擇 TiDB

1. 業務痛點

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

1. 需求

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

1. 方案調研

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

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

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

上線 TiDB

1. 兼容性測試

通過兼容性測試後咱們對業務作了以下簡單改造：

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

1. 灰度上線

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

1. 系統架構

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

系統配置 & 架構以下：

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

目前現狀和下一步規劃

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

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

致 PingCAP

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

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