# FST VADO (Virtual Assistive Data Officer) Basics

FST VADO (虛擬資料長) 幫助用戶對於數位系統間的資料歷程擷取 (Data Lineage)、資料邏輯，與資料稽核軌跡 (Audit Trail) 進行梳理與延伸發展。

FST VADO 能以 ++不影響既有流程++ 的前提下，為既有系統添加額外的資料處理邏輯與資料歷程追蹤，以敏捷、滾動式的方式滿足多變的跨組織的資料需求、合規要求。

為了達成以上事務，FST VADO 內含資料軟體引擎與工具集，稱之為 FST LOC (FST Logic Operation Centre)。

此篇章將概括性地講述 FST VADO 的產品概念與特色，而後續資訊技術方面的細節請見 FST LOC 的篇章。

## Concepts

### Why FST VADO

FST VADO 能使用戶擁抱既有系統，++平行地++ 配置出一層邏輯層與資料目錄層，降低既有系統負擔的同時，還能服務其他周邊系統 (Data Consumers) 的資料需求。

在邏輯層與資料目錄層中，內建由 FST LOC 進行的自動微服務管理 (Microservices)，用戶不用特地為了使用容器化平台技術，而改變既有系統的開發、維護方式。

FST VADO 有如此的設計，就是因為 FST VADO 本身的定位與方法論的核心觀點為:

:::info
**資料在進到資料庫以前，就已經存在了，就已經可以被追蹤溯源了，就已經可以上標籤跟註解了**
:::

近幾年，隨著資料累積速度愈來愈快，以及參與系統開發與維護的人員的更迭，儘管企業內部的資料工程團隊變得集中特化，但資料的累積成果十分發散。

大量的 ETL、Replications、Data Pipelines 與 Metadata 使得資料管理變得複雜糾結，面向業務單位與資料科學單位的資料準備 (Data Preparation) 將得花上愈來愈多的時間，要得向前溯源來驗證資料，還要得向後相容來避免重工。瞻前顧後的結果就是累積出大量的一次性資料，或者是數個資料孤島 (Data Silo)。

因此 FST VADO 所瞄準的並不只有已經被存在資料庫裡的資料，更重要的是:
"**產生這些資料的業務邏輯**"。

在既有系統中，一個終端客戶的請求，如果被一組業務邏輯執行了一萬次，就至少會有一萬筆資料被產生，甚至還會被分散在不同資料庫。與其處理那一萬筆資料，不如追溯那一組業務邏輯，並且為這一組業務邏輯進行延伸，平行地配置額外的邏輯、資料歷程追蹤與資料目錄。

當大多主要的業務邏輯與 FST VADO 有平行配置後，愈多既有系統內資料的資料目錄 (Data Catalogue) 與資料歷程 (Data Lineage) 就會被累積出來，同時，基於這些資料目錄與資料歷程，未來任何新的資料準備與數位轉型，就變得更容易掌握，更容易重複利用，更容易形成數位資料驅動的組織文化。

:::info
使用 FST VADO 的中長期階段，最重要也最有價值的應用方式就是實現 API Mart (有別於 Data Mart)，裡面上架著多個資料目錄，並使跨組織的資料交換都透過這樣的方式管理與追蹤。
:::

### Users

在 FST VADO 中，用戶分類大致有以下三種:

- 資訊人員 (包含開發者) IT/Developers
- 管理者 (包含稽核人員) Administration/Auditors
- 業務端人員 (包含分析師) Business/Analysts

用戶間的互動為:

1. 資訊人員依照業務端需求，配置各項邏輯、資料目錄
2. 管理者配置資料目錄的存取權與資料可視度 (Data Visibility)
3. 業務端人員查看與使用資料目錄與資料歷程
4. 回到步驟 1. 循環並滾動式累積更多的資料目錄與資料歷程

另外，當用戶互動延伸到跨部門資料分享與交換時，得益於資料目錄與資料歷程，過程變得更容易掌控與稽核。

### Logic

在 FST VADO 上面可配置的邏輯 (為了好分辨，以下稱之為 ++LOGIC++)，是平行於既有系統的業務邏輯或資料流程，而非直接被寫在既有系統中，因此 FST VADO 提供一系列讓 LOGIC 取得既有系統中的資料的方式，分為 ++主動式++ 與 ++被動式++。

簡單來說，
主動式包含:

- LOGIC 主動呼叫既有系統的 API
- LOGIC 連線至既有系統的資料庫取得資料

被動式包含:

- 任一個客戶端 (程式或用戶) 呼叫 LOGIC 執行，例如用 HTTP API 的方式呼叫
- 既有系統額外埋 Code 呼叫 LOGIC 執行 (One-line-code)
- 既有系統 API Gateway 分流呼叫 LOGIC 執行
- LOGIC 訂閱既有系統中的 Message Queue 或 ESB，不影響既有訂閱者與發布者
- 既有系統資料庫的資料變更 (CDC) 分流額外推播至 LOGIC

無論是 LOGIC 主動從既有系統取得資料，或者既有系統主動呼叫 LOGIC，對於 LOGIC 而言，能取得的資料不外乎:

- 描述某個終端客戶的靜待資料、動態交易資料或行為紀錄，的資料
- 某個既有系統的訊息或事件
- 某個資料庫中發生的資料變動

之所以是平行配置，是因為 LOGIC 無法干涉既有系統中的業務邏輯與資料邏輯流程，因此 LOGIC 中所做的任何事情是否需要回饋到既有系統的流程，就得按照實際需求或系統架構，但原則上 LOGIC 中可以做的事情有以下:

1. 針對 LOGIC (主動/被動) 取得的資料進行簡易處理與運算，例如欄位取值、條件判斷，或數學運算等
2. 透過 FST VADO 提供的資料連結器 (++Agent++) 從其他資料源取得額外資料，例如另一個資料庫或既有系統的 API
3. 透過內建的事件溯源 (Event Sourcing) 功能，尋找過去發生過的 Event
4. 依照業務、資料分析需求，對於 1. 2. 3. 的產出進行註解或上標籤，效果等於為既有系統中的某個資料添加 Metadata
5. 額外將 1. 2. 3. 4. 中的中間資料儲存到指定的地方，例如存到另外一個資料庫
6. 產生最終結果，用於資料目錄中的資料回傳
7. 對於 1. 2. 3. 4. 5. 6. 所做的事情，依照業務端人員與分析師的溯源需求，留下資料歷程

LOGIC 本身能由動態腳本語言進行配置，目前支援 JavaScript 與 TypeScript，未來也會支援 Python、Java、C# 等其他主流平台語言。

:::info
LOGIC 配置的方式，參考了一種主流的被稱為 Function-as-a-Service (FaaS) 的方式，特點是可以使程式能被動態地配置與部署，專注邏輯本身，不用理會複雜的基礎建設設定，進一步簡化版本迭代的複雜度。
:::

### Agent

Agent 為 LOGIC ==主動式==地取得資料時，所需要的資料連結器 (Connector)

以下為各式協定的 Agent:

- 資料庫類
- MySQL
- PostgreSQL
- OracleDB
- IBM DB2
- SQL Server
- Snowflake (Coming soon)
- Denodo (Coming soon)
- MongoDB (Coming soon)
- 訊息佇列類
- Kafka (Coming soon)
- Java Message Service (Coming soon)
- 檔案系統類
- SMB
- FTP
- S3
- 其他
- HTTP(S)
- SMTP

### Data Source

為了使 LOGIC ==被動式==地取得資料 (意即，主動呼叫 LOGIC)，FST VADO 提供資料來源端口 (Data Source)，依照既有系統合適的方式進行整合。

Data Source 包含:

- API Route
- HTTP(S)
- Message Queue Pub/Sub
- Kafka
- JMS (Coming soon)
- Scheduler
- Database CDC

API Route 為大部分場景中主要的整合方式，既有系統或任何客戶端只要向 API Route 傳送 HTTP 請求，都可以主動呼叫 LOGIC，API Route 的設置方式就如同市面上常見之 API Gateway 一般。一旦 LOGIC 完成了執行，就可以透過 API Route 把結果回傳給原請求者。

:::info
API Route 同時也是最常見的，用於存取資料目錄時所用的端口。
:::

MQ Pub/Sub 為較進階的整合方式，FST VADO 透過訂閱 (Subscribe) 某 MQ 的 Topic 等待訊息發生，如發生則呼叫 LOGIC，並且可以再將 LOGIC 的最終結果發布 (Publish) 到指定的某 MQ 的 Topic。

Scheduler 為定時 (週期性或單次) 呼叫 LOGIC，適合用於排程類型的工作。

最後，FST VADO 雖然並無內建 Database CDC 工具，但透過與各資料庫的內建 CDC 整合，或與第三方 CDC 工具整合，就能使 LOGIC 獲得資料變動，並且進行一系列的處理與資料歷程紀錄。

### Event

FST VADO 不儲存原始資料，也就是說 LOGIC 裡面的事情做完後，如果沒有特地將資料傳送到他處，因為資料會在 LOGIC 中原地揮發，所以就沒有辦法再輕易取得原先進到 LOGIC 的資料了。

Event 是 FST VADO 唯一的必要儲存資料型態，存放於 FST VADO 中的 Event Store，前面提及的 Metadata、標籤 (Label) 或資料歷程 (Data Lineage) 等，這些本身都是以 Event 的形式存在。

之所以 FST VADO 內建 Event 這樣的型態，無非是為了能做到資料歷程與溯源，FST VADO 在其中包覆了 ++事件溯源 (Event Sourcing)++ 與 ++讀寫分離 (CQRS)++ 的方法論，但用戶不用特別意識到這些特殊方法論，用戶只要將 Event 當作是一種 ++事件日誌紀錄++ 即可。

一個 Event 有三個須填入的資訊、選擇性註解，以及自動產生的資訊:

- **Source DID**
- 須指定
- 任一字串
- 此欄位用來表達 "從何處、何物、何人發動的事件"
- **Target DID**
- 須指定
- 任一字串
- 此欄位用來表達 "向何處、何物、何人發動的事件"
- **Label Name**
- 須指定
- 任一字串
- 此欄位用來表達 "事件的名稱"，也就是標籤名稱本身
- **Meta**
- 可留白
- 任一字串
- 此欄位用來記錄 "註解"，甚至也可以放入非結構化資料
- **Timestamp**
- 時間戳記
- 自動產生
- *其他欄位*
- (請見 FST LOC 篇章)

下列是一些 Event 的例子:

- 客戶評分單位想要向一個電子郵件是 `[e-mail]` 的終端客戶，貼上 `VIP_2022` 的標籤，因為這位客戶在某個 LOGIC 的判斷中，符合成為 2022 的 VIP 的條件
- Source DID
- `客戶評分單位`
- Target DID
- `user:[e-mail]`
- Label Name
- `VIP_2022`
- Meta
- `符合 2022 年某某某活動累積購物金額與品項的條件`
- 記錄從系統 A 到系統 B 有一筆客戶行為資料被傳送
- Source DID
- `System A`
- Target DID
- `System B`
- Label Name
- `Send_Customer_Action_Data:open_page`
- Meta
- `{"customer_id":"abc123","action_name":"open_page","detail":"page/xyz456"}`
- 記錄某 FST VADO 用戶對某資料目錄進行存取
- Source DID
- `loc_user:[e-mail]`
- Target DID
- `data_catalogue:Unit_A_FOOBAR`
- Label Name
- `Access_Data_Catalogue`
- Meta
- `Purpose: xxxxxx`
- 部門 A 的管理者向某 FST LOC 用戶貼上授權檢查用的屬性標籤 (進階使用方式)
- Source DID
- `##abac:unit:loc_unit_a`
- Target DID
- `loc_user:[e-mail]`
- Label Name
- `##abac:label:職能:分析師`
- Meta
- `##abac:digital_signature:loc_unit_a:0x53a087f64fa9892209c02eb86d4c08c14be6436fed42bcc76a713b583254a632`

由於 Event 的使用方式非常彈性，FST VADO 鼓勵使用下列兩種模型來簡易設計 Event 的記錄方式:

1. 一般動詞法 (記錄 Source DID 對 Target DID 進行的行為)
- 將 Label Name 設為一個動詞開頭的名稱，例如 `Set_XXX`, `Send_XXX`, `Get_XXX`, `觸發了 ABC` 等
3. 形容詞法 (記錄 Target DID 的形容詞、狀態)
- 將 Label Name 設為一個形容詞或純粹的標籤名，例如 `VIP_2022`, `高風險`, `部門_A`, `忽略計算條件:ABC123` 等

最後，之所以 Event 裡面要有 Source、Target、Label 等資訊的原因就是因為在後續的溯源與歷程追蹤上，可被視覺化為網路圖 (Network Graph)，形成 [Data Lineage](#Data-Lineage) ，因此對於人類的閱讀與自動化分析都降低了不少複雜度，例如:

> 因每個 Event 都有時間戳記，故可以用時間範圍來搜尋符合條件的 Events 們，並且一同繪製成網路圖

flowchart LR
    B("user:[e-mail]")
    C("user:[e-mail]")
    D("item:notebook")
    E("item:mouse")
    F("item:smart_phone")
    A("客戶評分單位")
    B-->|"Bought_Item"|D
    C-->|"Bought_Item"|D
    B-->|"Bought_Item"|E
    C-->|"Bought_Item"|F
    A-->|"VIP_2022"|B
    A-->|"VIP_2022"|C

延伸一提，Event 的建立有分 ++手動++ 與 ++被動++ 兩種，前者為用內建工具手動地建立 Event，後者為在 LOGIC 裡面配置如何建立 Event 的方式

### Data Catalogue

資料目錄為資訊人員的一個主要配置產出的單位，也是一個能輕易衡量 FST VADO 平行配置率的指標。

一個資料目錄的配置，會包含到這些配置:

1. 數個 LOGIC 的配置
- 建立 Event 的配置
- Agent 們 (可有可無)
2. 一個 Data Source 的配置
3. 一個 Data Policy 的配置

:::info
一個資料目錄被配置完後，本身會以一個微服務的型態存在，裡面的 LOGIC 會主動或被動式地取得資料。

隨後外部其他用戶或系統即可向此一資料目錄取得資料，過程中會根據 LOGIC 們裡面配置的 Event 建立方式，記錄資料歷程與標籤。
:::

### Data Policy (Access Control)

一個資料目錄的 Access Control 過程，分為下列幾個動作:

1. Authentication (身分認證)
- 資料目錄會知道請求者是誰
2. Authorisation (授權檢查)
- 資料目錄會知道請求者是誰，並且決定接受請求與否
3. Data Visibility (資料可視度)
- 如果資料目錄接受請求，那麼要回傳怎麼樣的資料，是否對回傳資料進行去識別化

Data Policy 會透過來自 Data Source 的標頭檔或其他資訊進行身分認證與授權檢查，如果接受請求，則可以針對回傳內容的值 (可以配置到各個不同欄位) 進行額外變換，有下列幾種:

- Original 原始值
- Masking 遮罩值
- Redaction 屏蔽刪減值
- Null 空值

:::info
在 Authorisation 與 Data Visibility 的階段，FST VADO 使用一種被稱為 Attribute-based Access Control (ABAC) 的授權設定方式，讓管理者類型的用戶針對各個資料目錄設定存取授權。

ABAC 特別的地方就是，讓資料擁有端自己本身 (也就是資料目錄) 根據請求者身上有的屬性標籤 (Attribute Labels)，來判斷是否要接受請求或者決定資料可視度。

有別於直敘枚舉式的 RBAC (角色群組型授權設定)，ABAC 更能處理複雜多變的請求者們的請求，也能因應未知的屬性標籤組合。
:::

例如，當一個資料目錄的 Data Policy 的配置為 ==身上擁有 "部門 A" 跟 "職能:分析師" 跟 "參與專案 X" 三種屬性標籤的用戶才能存取，並能看到回傳資料中所有欄位的原始值== 的話，只要不吻合這個屬性標籤條件的請求者向這個資料目錄發送請求，那麼就會被拒絕請求。

或例如，當一個資料目錄的 Data Policy 的配置為 ==身上擁有 "部門 A" 跟 "職能:實習生" 跟 "參與專案 X" 三種屬性標籤的用戶可以存取，但只能看到回傳資料中 `x` 欄位跟 `y` 欄位的遮罩值== 的話，那麼就只有 `x` 跟 `y` 欄位存在在被回傳的資料中，並且 `x` 跟 `y` 欄位只有遮罩值。

### Data Lineage

當用戶們已經配置了多個資料目錄，並且資料目錄中的 LOGIC 們的配置中，都有涵蓋著各式各樣對於==上標籤==與==資料歷程追蹤==的配置，也就是 ++如何建立 Event++ 的配置，之後每當資料目錄的 Data Source 被送入資料，LOGIC 們被執行的時候，漸漸地在 FST VADO 內的 Event Store 就會累積出大量的 Events。

此時，分析師人員與稽核人員透過 FST VADO 內建的資料探索工具 (Data Discovery)，瀏覽這個 FST VADO 上的 Events，並且透過篩選挑選特定幾種 Events 之後，繪製成 Data Lineage，也就是在 [Event](#Event) 小篇章中的網路圖視覺化。

無論是分析師人員對於過去某段資料歷程感到疑惑而進行深入調查，或者稽核人員想要在跨組織的資料交換過程中找到與 ABAC 授權控制有關的 Audit Logs (就是與 ABAC 屬性標籤有關的 Event)，都會是十分有用的功能。

### Data Mesh

資料網格是近年來被提出，新一代的企業內部的資料工程與治理的實現方式，透過各單位 (各領域、各部門) 自行以自身的專業觀點立場建立資料目錄，並使不同單位間以 API 與 Metadata (資料上的標籤或註解) 的方式溝通，或整合出新的資料目錄，進而形成複雜彈性的網路網格，而非只是單純資料庫之間的 ETL 或資料管線，避免到處建立資料孤島，及丟失資料歷程。

FST VADO 正是以融合彈性邏輯配置、資料目錄、事件溯源、ABAC、自動化微服務管理，加上一個最能擁抱既有系統、最能發揮 FaaS 特性的方式，讓用戶能一步步實現資料網格。

## Installation Prerequisites (Different Licenses)

FST VADO 為了能平行地與既有系統整合，被設計為 Environment-agnostic 的方式進行安裝，意即只要符合以下的作業系統或雲端服務提供者，FST VADO 就能被安裝在用戶指定的數位環境。

### With existing Kubernetes (v1.20+)

- Kubernetes Distribution
- Cloud providers
- AWS EKS
- Azure AKS
- GCP GKE
- On-prem or private cloud
- Kubernetes
- OpenShift
- VMware Tanzu
- Kubernetes Node
- FST VADO LITE
- 1 and only 1 master node
- 8 CPU cores, 32 GB RAM, 500 GB Storage (SSD preferred) per node
- FST VADO Basic / Premium
- At least 3 master nodes
- At least 4 CPU cores, 16 GB RAM, 500 GB storage (SSD preferred) per node

### Without existing Kubernetes (On-prem)

- Operation System
- Ubuntu 18.04 LTS / 20.04 LTS
- VM total number
- FST VADO LITE
- 1 VM
- FST VADO Basic / Premium
- At least 3 VMs
- VM Hardware Spec
- FST VADO LITE
- 8 CPU cores, 32 GB RAM, 500 GB Storage (SSD preferred) in the VM
- FST VADO Basic / Premium
- At least 4 CPU cores, 16 GB RAM, 500 GB storage (SSD preferred) per VM

## License Comparison

| Features \ License | FST VADO LITE | FST VADO Basic | FST VADO Premium |
| ---------------------------- | ------------- | -------------- | ---------------- |
| High Availability | ✖ | ✔ | ✔ |
| FST LITE UI | ✔ | ✖ | ✖ |
| FST LOC Studio | ✖ | ✖ | ✔ |
| FST LOC SDK | ✔ | ✔ | ✔ |
| Data Discovery | ✔ | ✔ | ✔ |
| Data Repository | ✔ | ✔ | ✔ |
| Data Lineage Visualisation | ✖ | Limited | ✔ |
| Low Code Logic Editing | ✖ | ✖ | ✔ |
| Agents | Limited | ✔ | ✔ |
| API Route | ✔ | ✔ | ✔ |
| MQ Pub/Sub | ✖ | ✔ | ✔ |
| Scheduler | ✖ | ✔ | ✔ |
| ABAC | ✖ | Essential | ✔ |
| Data Catalogue | Essential | Essential | ✔ |
| Data Catalogue Bazaar | ✖ | ✖ | ✔ |

## Use Cases

> Coming soon