Re: [新聞] 資訊龐大 簡訊實聯制疫調無用

※ 引述《richjf (richArt)》之銘言：
: 資訊龐大 簡訊實聯制疫調無用
: 2021-06-29 02:28 聯合報 / 記者蔡孟妤、徐如宜／高雄報導
: https://udn.com/news/story/122173/5564273
: 簡訊實聯制。聯合報系資料照

身為一位無名的後端工程師,我覺得還是要以業界人的出來講一下
不然一堆人沒搞清楚,隨便亂說實在不太好

要追蹤人去哪裡,需要的就是
{人,什麼時間,什麼地點}
當有人被判定確診後,就可以進去撈
這個人在病徵出現往前14天到被收治為止,有什麼時間,什麼地點
時間,地點知道後,就可以針對每個地點,抓前後幾小時的時間
列出進入這些地點且在特定期間的有哪些人
列出來的人除了是確診高風險之外
如果這些人之中已經在先前確診收治
可以假設這些較早發現的確診者們與此位確診者有接觸史
這些搜尋動作,其實在 SQL 體系的資料庫內都可以很簡單地描述
而且已經有鄉民寫了 SQL,我就不再寫一次
非 SQL 的 key-value,document,graph DB 體系也有對應的查詢寫法
有興趣看要怎麼做的可以去看看各 DB 的官方便用教學
雖然說查詢動作可能看執行環境配置,不一定能一口氣完成
但因為疫調資料請求者的數量,應該是遠不如普羅大眾上傳簡訊的數量來得多
其實有個操作介面可以發動背景task,讓他跑deferred查詢都是可行的
不一定要像網路服務大多數API那樣需要瞬間回應
我個人認為最麻煩的,也許是申請查詢個資這方面的政治問題,而不是技術問題

其實我相信有一定後端經驗的人,都會想到這些資料系統規劃面要怎麼量身訂做
而且在有確實建好 index, 以及在資料量夠大時做 sharding
就算是幾億筆,就算資料規劃沒有做進階的最佳化
單純的 where 條件匡列動作都可以在幾亳秒內解決
比較有點挑戰性的是從特定確診者 join 出相關接觸者,但這也不是不能做到
不然那些銀行信用卡電商怎麼可能營運?

簡訊實聯制的消息剛出來的時候
其實我個人最佩服的點並不是前面提的,這些資料的搜尋要怎麼做
因為這些都只是資料庫基本功而已
最重要的是,只要用簡訊,就可以收集這些可以用來疫調(還是抓逃犯?)的資料
傳簡訊,含商家代碼,就能成功地取得{手機,地點,簡訊傳送時間}
而且公佈推行時間點拿捏也抓得很好
這正好是前面說的要做足跡追蹤時需要的 人 時 地 的取得方式
資料有了,怎麼用就看使用的人怎麼用,工程師要怎麼自動化
但是只要掃 QR code 發簡訊就能提供資料這點,大大降低了提供資料給系統的門檻
安裝 app 有一些普通 3C 使用者看不到的阻礙
有些人可能是手機太舊無法裝 app, 有些人就是沒有用較現代的智慧型手機
像我個人就因為卡在使用 app 必須要升級手機 OS,晚了3天才裝接觸者通知
這還是因為我手機有2FA與各種憑證用途,升級變磚對個人會造成很大困擾

簡訊實聯制也許不是很完美的做法
因為要實施這方法,要有能力有資源跟電信商喬,不然難道要大家都自費上傳簡訊?
但綜合多方面的利弊因素,包含使用門檻,資料收集,與電信商協調等等
也許它對實施者(政府)來說,是可行,且各方面都取得相當程度平衡的一套方法

目前全台的新增確診人數還緩慢減少,要完全撲滅傳染源,需要的是更完善的疫調
不管大家喜歡什麼方式留下足跡或是甚至不想留,還是希望大家可以做好份內的防疫工作有用的方式,大家就多配合
沒用的方式,丟出來以合理的觀點批評討論都沒關係
讓你我多思考,進而補強漏洞,但不需要無理抹黑來鄙視他人的方法
也不要以為打了疫苗就金身護體
異物進入細胞這些事其實在你我的身體都天天上演,只是會不會得病致死而已
重點還是有沒有做好自身衛生習慣,病毒量不夠起連鎖反應,對身體也不會造成威脅

共勉之

--

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.204.12.153 (臺灣)

好,幫你畫重點

人時地三個欄位都有 index 的話, 查詢也不需要做給大眾用, 我想就是任你玩了

應該差不多就是這些

重點欄位也就人時地三個,SQL體系就多個流水號 要嘛 人時(range) compound -> 地(sort時),要嘛 地時(range) compound -> 人 其他的進階抽取應該都基於這幾個基本動作 而且會請求資料的是疫調人員,也不是一般民眾 所以理論上把這些基本查詢的 performance 顧好就可以,參數就是疫調人員要去煩惱的 因為領域關係,公司在CAP的取捨上,讓我太久沒有在工作上用SQL體系的東西了 但如果是key-value或document流派的做法的話,個人實戰到今天為止應該有10年上下 只是工作上還是有很多未解決的問題等著我,趴數多高其實也沒什麼好說嘴的

沒錯,還要考量到商家性質,去推測停留時間可能會多長 時間,深度等參數還要因為各種因素客製化 我是不覺得能像平常網路服務那樣參數給好,需要一定的人工與疫調的專業介入 除此之外,時間這方面沒有做成進出各簡訊一次我覺得有點可惜 不過就如同前面說的,這可能是實聯制團隊他們有什麼現實考量,做了一些 trade off

我也有裝社交 app 啊, 也幫家裡的科技麻瓜裝長輩裝了 但這裡就有幾個我親身碰到的問題 - iPhone 要求當時最新的 iOS 版本 有用作開發等特殊需求者必須停在舊版,你要怎麼裝? - 會被警告的目前看來是藍牙直接接觸 像上面老兄說的接觸者的接觸者要不要匡列,app 寫死就不一定能事後調整匡列範圍

某些方面來說這也是減少人與人接觸的動機(?

也沒多專業,就只是根據報導內容合理推測而已 臨時起意寫的推論有疏漏之處,也歡迎指正

個人其實對這整套系統的整體考量到實作細節都很有興趣 不知道像這種 case 有沒有機會對開源圈分享開發與建置過程?

我同意使用情境可能不會在最初的實作就可以完善 像是要確診者的接觸關連要抓到多少 tier,進出場地時間前後匡列範圍要抓多少 這些都有可能要因為病毒株傳染力或場地環境因素做調整 不過再怎麼變化,也不至於到需要線性爬 raw data 至少把查詢目標拆開來看分解動作,應該都不脫離前面推文說的基本 operation 而這些 operation 在只有 index 的情況下其實最慢都可以亳秒殺,姑且算個 5ms 好了 各種 join 或是查多少人,要分幾段,分幾層查,查詢目標的數量級也有限 5ms*10個場地*14天都出門*每層關連匡列人數 在這些資料呈現出來的 graph 上遊走,去取得查詢目標,需要花好幾天 那麼: - 我是不太相信真的會這麼慢,而且上面唐鳳都跳出來解釋沒那麼慢了 - 就算真的這麼慢,我也不太相信是因為實作或工程因素,但不會需要硬找 raw data - 真的漏掉什麼情境,需要針對應用情境補 index 也就痛第一次 情境隨著應用實戰確立後,不會三不五時重建 index 哪個環節要 cache 也能夠掌握,常用的查找方法也可以存下來 要建 view 還是怎樣加速都可以,後續使用不太可能會一直這麼慢

沒錯,架構設計正確對性能改善遠比改程式有效

真是不好意思R,在下菜逼巴剛任職時,任職單位尚在草創期,在下出生年份也不夠早R

我是不太喜歡沒有講明原由,就硬說"這個東西啊就是這樣"就是了 這跟那些速成懶人包沒什麼差別 反正重點都 highlight 在上面了,自己看

※ 編輯: fielia (123.204.10.16 臺灣), 06/30/2021 13:52:51