# 2023 Data Architecture Challenge

[TOC]

## [Action] 公開徵求 Call for ...

### 共同籌備 Co-host

* Define Scope - 目前這個活動有待決定該怎麼進行，目前有兩個方向
* 短期的技術工作坊（如兩天）
* 目標：針對單一種資料架構，手把手教學
* 長期的設計暨實作競賽（如三個月）
* 目標：設計、實作、成本估算、效能優化
* SOW (Scope of Work) - 確認執行方法後，才有辦法決定：
* 需要哪些資源？例如：用來實作的雲端資源(AWS, GCP, Azure credit)、獎項、場地、出席費、講師費
* 需要多少時間來籌備？這個活動該是短期的活動，還是長期的競賽？
* 內容可能涵蓋
* Data Collection/Fetching 如何下載單一保險商的公開資料集資料
* 目前遇過單一家保險商的資料（前五大），解壓縮後高達 0.5 PB。所以光是資料爬取就已經是個不錯的練功題目。
* 美國有 900+ 醫療保險商必須提供這份公開資料。( @jazzwang 按：個人相信只能挑最多三間的資料來玩～)
* Data Pre-processing 為了瞭解資料的特徵或易於做後續處理，思考是否要做一些前置處理或格式轉換。
* Data preparation 對單一公開資料進行資料分析，確認資料欄位的關聯性，潛在資料處理流程的關聯性，是否有資料傾斜（Data skew）狀況
* Data Model Design 以終為始：從 API 需求反推最終的資料表模型
* Data Processing Pipeline Design 怎麼對公開資料進行 ETL 處理，使用哪一種資料處理方式的成本較低？
* Data Query Architecture 怎樣的查詢架構，反應延遲 Query Latency 較低？維運成本 Operation Cost 較低呢？（可能沒辦法兼顧，所以要估算合理的）
* Data Value 這份資料處理後，到底該怎樣產生商業價值？（數據變現）

> @jazzwang [開放構想] 若真的要辦比賽，光 Data Collection 的架構就可以是一個「初賽」題目。當然，不排除弄得更廣義一點，分成「資料爬蟲組」「資料驗證組」「資料處理組」「資料分析組」「資料查詢組」「資料價創組」（缺點：這樣搞會有點龐大，評審團會很難評分）。

> @jazzwang [原始構想] 給定一組資料集，並給定 API 設計，初賽時由參賽隊伍提出 Data Pipele 架構, Data Model，決賽時報告 Data Architecture, Data Obserability, Data Governmance, Operation Cost 等不同面向的簡報，由主辦單位打各隊 API 來驗證實作正確性。（缺點：這樣搞，籌備團隊會比較累，要想好 CI/CD 來讓各隊提交結果。優點：這樣比較能把 scope 限縮在一定範圍，也比較好預估應該拉多少 Cloud Infra 的贊助）

* 初步想過四種可能的 Data Processing 跟 Data Query 架構
* Big Data at REST - 用 Hadoop + Spark 等批次處理工具，配 MPP (Presto/Impala 等) 或 RDBMS/NoSQL
* Big Data in Motion - 用 Kafka, kSQL 等串流處理工具，配 MPP (Presto/Impala 等) 或 RDBMS/NoSQL
* SQL 用到底 - RDBMS 從 ETL 到 Query 一路用到底 (e.g. PostgreSQL 可以 LOAD JSON file 啊)
* Graph 新潮流 - 由於資料特徵是 Linked Data，所以可能很合適轉成 Graph Data Model。挑戰性是 Graph Query

### 獎項/活動贊助 Sponsorship

* 若為設計暨實作競賽，@jazzwang 個人預計贊助一個「佳作」獎項。

### 開發者回饋 Developer Feedback

* 若您是 Data Engineer/Data Scientist/Data Analyst ，你希望從這個活動獲得什麼？知識 Business Domain Knowledge？技能成長？

## [Why] Objectives 活動緣起與我心裡想問的問題

> [揭露] 這個題目源自於 @jazzwang 工作上遭遇的實際挑戰，執行團隊已討論架構並開發近一年，但實務處理資料時仍遇到諸多挑戰。由於該產品與架構並非 @jazzwang 能決定，因此以下單純從一個旁觀者的角度切入，沒太多利害關係，也會只談學理上會遇到的技術挑戰。過去兩個月中，@jazzwang 個人心裡至少有四種不同的資料架構雛形，也認為從上(美國政府)而下(醫療保險公司/資料處理商/查詢服務提供者)，這份資料在 Volume (資料量)、Variety (資料多樣性/複雜度)、Veracity (資料真實性/模糊程度) 非常有趣，不同的資料架構可以提供不同的 Velocity （資料處理速度、商務需應反應速度），至於這份資料的 Value (資料鑑價) 真的見仁見智了，也是以下會列舉不同角色該問的問題其中一項。

> 當然，會挑這份資料跟這個題目，是因為公開資料的特徵，所以人人可以存取與從這個出發點去發想。醫療保險也貼近多數人的日常生活體驗（雖然很可能多數人連健保給付範圍都未必清楚），會比製造業資料、金融業資料，會再容易理解（當然我相信還需要一些名詞對應台灣的用語，也可能需要多一些台灣與美國國情不同處的額外資訊）。

> 在 2019 年一場關於資料經濟的會議裡，有業界先進提到「資料科學家的核心能力是『問問題』，其次才是『洞察』」。因此這個競賽，也可以是開放性問答，讓參賽團隊可以自己從不同面向切入，去發問，去挖掘不同的未來（價值創造/開創未出現的新需求 vs 滿足既有市場需求）。

* Q1: [法][Law] 身為一個政府官員，請探討台灣是否需要要求各商業醫療保險也公布保障範圍與給付金額？

> @jazzwang 按：我並不清楚台灣目前有沒有要求公開保險保障範圍。但 2023 年一月自己住了一週醫院，才發現原來要查額外加保的醫療給付，聯絡起來也是挺耗時的。若您是保險業相關從業人員，歡迎提供台灣的法令與現況供參考。

* Q2: [資料產品] 身為一個資料產品經理，請探討打造一個醫療保險的跨站搜尋具備什麼樣的商業價值呢？
* Q2.1: [資料產品] 獲利模式 Business Canvas / 價值主張 Value Proposition Canvas
* Q2.2.1 目標客群 Target Audience - 該跟誰收錢？
* 「羊毛出在狗身上，豬來買單」？
* Q2.2.2 定價策略 Pricing - 怎樣的定價才合理？
* Q2.2: [資料產品] 單就公開保險給付內容，可以取得不同商業保險的策略佈局嗎？
* 假設目標客群是「競業」，商業模式是「產業報告」?
* Q3: [人][People] 為了要執行這樣一個專案或產品研發，需要哪些團隊？
* Product Manager - to define Data Product
* Program Manager - 規劃時程,流程,進度稽核
* Data Team - to develop data processing pipeline (ETL)
* Backend Team - to develop Backend API and its Query model
* Frontend Team - to develop Web UI
* (潮一點：Chatbot 當人機介面？可能就會需要 AI/ML 團隊，至少要處理 NLP 自然語言)
* Q4: [流][Process]
* 目前這份資料的更新頻率為 <u>1 個月更新一次</u>。
* Q4.1：多久處理完這份資料才算合理？
* Q4.2：是否該保留歷史資料？
* Q4.3：批次處理？串流處理？（當然很可能不是二選一，最後很可能受限於[財](營運成本)跟硬體限制(記憶體不夠 OOM)，只能挑某一個，或被迫混著用）
* Q4.4：Data Validation 輸入資料是否需要先驗證正確性？Exception Handling 故障告警與錯誤處理？怎麼做到不要部分壞掉就得重新計算一次？
* Q5: [技][Technology]
* Q5.1：Sizing 要處理這麼大的資料，需要多少記憶體，多少核心，網路多快？怎麼從原始資料推估預計的叢集大小？
* Q5.2：Workflow 為了避免處理到一半才發現
* Q5.3：查詢的反應速度能容許多少 ms/second 的延遲？
* Q6: [財][Cost/Cash Flow]
* 身為資料處理商，合理的營運成本該抓在哪個範圍？
* 身為保險業者，提供 Transparency in Coverage (TiC) 的 Machine Readable Files (MRFs) 需要哪些額外的成本？
* Q7: [知][Business Domain Knowledge]
* 身為資料工程師，是否需要具備足夠的商業知識才能處理資料？
* 身為資料工程師，是否需要足夠的 Data Modeling 背景知識（例如：不同的 Data Schema 種類，星狀 Star、關聯式 Relational、

* Q1: [法令] 身為一個政府官員，請探討台灣是否需要要求各商業醫療保險也公布保障範圍與給付金額？
* Q2: [資料產品] 身為一個資料產品經理，請探討打造一個醫療保險的跨站搜尋具備什麼樣的商業價值呢？
    * Q2.1: [資料產品] 單就公開保險給付內容，可以取得不同商業保險的策略佈局嗎？
    * Q2.2: [資料產品] 獲利模式 Business Canvas
        * Q2.2.1 目標客群 Target Audience - 該跟誰收錢？
            * 「羊毛出在狗身上，豬來買單」？
        * Q2.2.2 定價策略 Pricing - 怎樣的定價才合理？

## [What]

Let's talk about the public dataset first

### Legal Compliance 法規源頭

這份公開資料源自於美國 CMS Transparency in Coverage (TiC) Rule 法律規範。

[1] https://github.com/CMSgov/price-transparency-guide

該法令自 2022 年七月一日起生效，各大保險業者必須於網站上公開 Coverage (保險保障範圍)的 Machine Reable Files (MRFs)

[2] https://www.uhc.com/broker-consultant/news-strategies/resources/machine-readable-files-required-on-public-sites-by-july-1-2022
[3] 美國第一大 UHC 的 FAQ - https://www.uhc.com/content/dam/uhcdotcom/en/HealthReform/PDF/Provisions/reform-external-transparancy-FAQs.pdf

### Data Characteristic 資料特徵

雖然美國政府已明定公開資料的 JSON Schema 與 XML Schema，但 Schema 中有許多欄位是 Optional。加上不同的保險商定義保險方案的商業思維不同，造就了公開資料的多樣性。有的多個小檔，每個小檔包含 1~4 個保險方案。有的一個超大的 XML 檔。有的只有數十個 JSON 檔案，但需要參考外部的 Reference JSON 檔。這些變因也直接/間接造就了資料架構設計的挑戰。

### Known Technical Challenge

以下說明已知架構設計挑戰：

#### (A) One size can't fit all

* 檔案格式大致上分成 JSON 與 XML 兩種。所以 Data Pipeline 必須

### Sample Datasets

>（限制：由於這份公開資料內容跟美國醫療院所的特約價格有關，所以許多網站限制從北美的 IP 連線才能看到檔案下載路徑）

* US #1 - UnitedHealth Group - https://transparency-in-coverage.uhc.com/
* US #2 - Anthem https://www.anthem.com/machine-readable-file/search/
* US #3 - 美國安泰人壽 Aetna - https://www.aetna.com/health-care-professionals/transparency-in-coverage.html
* US #4 - 美國康健人壽 Cigna - https://www.cigna.com/legal/compliance/machine-readable-files
* US #5 - Humana https://developers.humana.com/syntheticdata/Healthplan-Price-Transparency

Source: https://collectivemedical.com/resources/payers/

Reference: https://www.valuepenguin.com/largest-health-insurance-companies

## [How]

### Hackathon (for 3 month)

### Workshop (for 1~2 days)

flowchart TD
    A[Christmas] -->|Get money| B(Go shopping)
    B --> C{Let me think}
    C -->|One| D[Laptop]
    C -->|Two| E[iPhone]
    C -->|Three| F[fa:fa-car Car]