00
背景
隨着新冠肺炎在全球蔓延，政府在疫情防控方面投入了大量精力。然而常規地區的疫情監測是在固定的行政區域統計被感染人數，常規的個體疫情追蹤則是個人主動上傳信息輔助手機定位來評估健康指數。這樣做不僅費時耗力，而且信息更新不及時會影響防控效果。
針對這些問題，我們小組開發了一套面向疫情防控密切接觸人羣大數據分析系統：使用測溫手環高頻採集人羣體溫等生物數據並實時上傳，利用手機藍牙探測周邊設備藍牙信號 RSSI 實時分析密切接觸的關係網絡，將地圖劃分爲多個區塊並採用 Geohash 進行編碼並結合 SEIR 疫情傳播模型進行區域安全指數的評估。
鑑於ES具有實時性，可擴展性以及可以把地理位置、全文搜索分析結合到一起的優點，我們使用ES兜底來存儲區塊信息、個人生物信息和關係網絡。
01
使用 ES 存儲區塊信息
我們將整個地圖沿經緯線進行近似矩形區塊劃分，利用Geohash函數給區塊編碼。爲了實現在不同經度範圍內的疫情監測，我們使用動態區塊劃分：若查看局部區塊疫情則採用長二進制編碼，劃分區塊數量更多，可以查看更細粒度的區域情況；若查看全局疫情則採用短二進制編碼，劃分區塊數量少能從宏觀上監測疫情變化。
劃分後的任意區塊包含該區塊的用戶集合，由於動態區塊劃分，隨着用戶位置的變動，後端會實時更新所有區塊內的用戶區塊信息，如圖所示我們可以通過左上的控件動態調整block塊大小，實時顯示各個block塊的地區安全指數（ASI）。
Elasticsearch 提供了使用緯度－經度表示的座標點 `geo_point` 字段類型表示地理位置，我們使用 geo_point 標註用戶地理位置信息。Elasticsearch 本身也支持 geohash 檢索，我們可以很方便地根據區塊名獲得區塊內的用戶信息。
我們對每一個動態劃分的矩形塊給定一個唯一的 geohash 編碼。劃分數量、劃分粗細粒度根據存放在Elasticsearch 中的用戶危險等級和geo_point字段決定。
例如：當某一區塊中的用戶變少甚至沒有時，將直接取消這一區塊的劃分（表面上表現爲安全區塊，實際已刪除）；當某個用戶的危險等級變高時，我們將根據該用戶在 Elasticsearch 中的歷史 geo_point 字段值判斷出用戶去過的區塊，爲了更好地追蹤軌跡，我們將盡可能細分這些危險的區塊或及時下調區塊的安全指數。
具體做法爲：危險用戶所在的安全大區塊將被細分下去，我們的算法將計算出這些新劃分出的小塊的安全指數，這樣就做到了對高風險地區區塊的精細劃分；另外，當大區塊的安全狀態恢復時，將使用更少的區塊數對它進行動態劃分。
通過這樣的動態劃分算法設計，我們在保證精準追蹤危險區域的同時，也做到了一些算力的節省。如圖：通過geo_point字段，我們在 Kibana 上追蹤用戶 uid 爲2過去一週所經過的地區。
由於區塊的信息是實時更新的，並且區塊名就是 geohash 編碼，因此我們很容易就能在地圖上標記出區塊信息。利用 Elasticsearch 中的檢索功能可以輕鬆查出用戶在過去一段時間內去過的地方，因此，用危險區塊的 geohash 編碼、用戶的 geo_point 以及這些地理位置的歷史時間，我們就能檢索出有感染風險的用戶。
綜上，系統將根據 Elasticsearch 中用戶的危險等級和 geo_point 來進行動態區塊劃分以及評分。
02
使用 ES 存儲個人信息
爲了實時檢測用戶的體溫、心率等生物數據，提高算法模型評估用戶健康安全指數的可靠性和準確性，我們採購了第三方手環並根據SDK開發App。實時發送用戶體溫，步數，心率等信息到後端並幫助用戶分析周邊疫情情況。因爲查詢對於延時要求高，所以我們還是使用ES存儲。
如圖所示爲用戶在自己的手機app內查看自己的生物數據以及手機藍牙掃到附近的設備。
根據用戶當日上傳的體溫數據及14日內行動軌跡通過定量計算用戶安全指數的方法評定用戶健康情況，安全指數範圍0-60爲危險，90-100顯示健康，61-89程度介於兩者之間。
如圖所示用戶可以在app中查看自己的健康安全指數和14天內的行跡。
03
使用 ES 存儲關係網絡
我們通過手機藍牙會掃到近距離接觸用戶的RSSI強度和MAC地址並將接觸時間，接觸距離，接觸頻次等數據存入ES。
在此之前，我們曾對關係網絡的存儲方案做過探討，使用neo4j來存儲圖關係並用Cypher查詢目標接觸人羣可以滿足需求，但是當數據庫中的用戶節點較多時，要快速查找滿足條件的節點會比較耗時。另外，neo4j缺乏ES這樣強大的全文檢索能力。
考慮到用戶的歷史關係網絡不會發生改變也不會頻繁更新給後端數據庫造成壓力，我們最後決定使用ES來存儲關係網絡。我們使用ES提供的父子關係結構來存儲中心用戶手機藍牙掃到的周邊人羣信息，這樣做的好處是父子文檔均被routing到同一分片，查詢時效率較高。
疾控人員可以在前端輸入用戶id查詢特定用戶的關係網絡，查詢時我們採用懶加載模式：一級關係爲直接接觸人羣，只需通過父文檔查詢子文檔即可；二級關係爲間接接觸，也就是將一級關係查詢到的子文檔中的用戶id再作爲中心用戶進行查詢，以此類推。
爲了防止在多級關係查詢中雙方互掃藍牙設備造成有環的問題，我們將中心用戶id與接觸人羣id按照大小排序並使用下劃線連接用作全局唯一關鍵字。
另外，疾控中心需要查詢的接觸人羣信息具有時效性，超出14天的接觸人羣基本不會考慮。基於此，我們增加了阻斷權重，當用戶與任意接觸者的最新一次的接觸時間超過14天時，阻斷權重置爲100，關聯的信息不顯示在社交拓撲網絡中。
如圖所示搜索uid爲1的用戶密切接觸人羣二級關係網絡，圓圈顏色由計算的用戶安全指數決定，健康顯示綠色，危險顯示紅色，黃色介於二者之間，圓的半徑與掃描到的人數成正比，邊的權重爲通過藍牙RSSI衰減計算出的距離。
04
冷熱分離、定期備份
因爲密切接觸的關係網絡數據索引具有一定的時效性，對於分析密切接觸的人羣我們只需要14天內的索引，默認14天之外的索引數據爲冷數據。針對這種情況，我們使用官方提供的索引shard分配感知將14天之外的索引移到SATA盤，降本增效。對於SSD、SATA機器節點分別打上冷熱標籤，索引按天建立、根據時間劃分指定索引的冷熱屬性。
因爲存儲在ES上的地理區塊數據索引也默認只保留14天，超過14天的索引我們採用ES官方提供的快照/恢復Snapshot/Restore API，將這些索引定期備份到HDFS上。
05
總結
目前我們這套基於 ES 空間搜索的疫情追蹤分析系統已經產出三個受理專利以及兩個軟著，當然我們也在隨着疫情政策以及個人隱私保護政策的變化改進我們的產品，也希望社區的小夥伴們可以結合 ELK stack 技術多做出一些“抗疫”產品。
正文完
作者：黃有爲/張劉毅/陸峯/黃茂雷/梁立媛
中科院計算所大數據研發團隊
本文編輯：筷子
嗨，互動起來吧！
喜歡這篇文章麼？
歡迎留下你想說的，留言 100% 精選哦！
Elastic 社區公衆號長期徵稿，如果您有 Elastic 技術的相關文章，也歡迎投稿至本公衆號，一起進步! 投稿請添加微信：medcl123
招聘信息
Job board
社區招聘欄目是一個新的嘗試，幫助社區的小夥伴找到心儀的職位，也幫助企業找到所需的人才，爲伯樂和千里馬牽線搭橋。有招聘需求的企業和正在求職的社區小夥伴，可以聯繫微信 medcl123 提交招聘需求和發佈個人簡歷信息。
關
注
我
們
Elastic中文社區公衆號 (elastic-cn)
爲您彙集 Elastic 社區的最新動態、精選乾貨文章、精華討論、文檔資料、翻譯與版本發佈等。
喜歡本篇內容就請給我們點個[在看]吧
本文分享自微信公衆號 - Elastic中文社區（elastic-cn）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。