FST Network 如何以尖端技術打造 Logic Operating Centre (LOC) 雲端資料治理平台
FST Network Tradition Chinese Blog #1
敬啟讀者: 本文描述的技術細節乃是針對 FST Network 的舊版 LOC 而寫。LOC 仍然在快速演進當中，好滿足客戶的資料需求並迎合技術潮流，因此最新消息和技術分享請參閱我們的官方部落格以及官方產品文件。
什麼是 Logic Operating Centre？
解決尋找資料的難題
現代企業因業務所需，得運用大量資料，而資料也已經成為提升商業競爭力不可或缺的關鍵。然而，企業資料往往分散在眾多不同的資料庫或檔案儲存空間，也可能得透過不同的 API 介面來存取。而每當一個新的商業需求浮現，管理人員便得花時間尋找資料，並請求開發部門將它們串接起來。
假設今天有新的需求，即使需要用到的資料過去使用過，但因為沒有留過使用紀錄與規則，所以又要重新提取。
— FST Network 執行長朱俊嘉
Logic Operating Centre (簡稱 LOC) 的設計初衷便是為了解決這類需求 — — 它扮演了整合企業資料的橋樑，將資料邏輯 (data logic) 連結成資料程序 (data processes)，將現有的資料及服務拉到一起使用。資料程序可以於需要時佈署、撤回和修改，並且被保存在 LOC 中，大大減少了日後要沿用相同邏輯打造新資料程序的時間。
延伸閱讀
- FST Network完成8,000萬元募資將前進日、英市場，協助企業管控數據的方式有何不同？
- 專訪 FST Network 技術團隊：以資料科學與雲原生技術打造「虛擬資料長」，讓企業「無痛」完成資料治理，更高效率且能接軌創新應用！
LOC 等於是在企業內創造出一個「邏輯資訊層」(logic intelligence layer)，將各個異質系統和資料整合在一塊。其最終目的是化身為企業的虛擬資料長 (virtual assistive data officer, VADO)，不只是企業的系統，更是能在企業中協助管理資料的得力幫手。
追蹤資料流向
但單純整合資料使用或許還不夠。企業或許也想關心，資料是什麼時候被使用？是誰在使用它，下一個接手的又是誰？
FST Network 商務長陳逸軒認為，企業資料治理的需求，不只要做到透明化，更要能一目瞭然資料間的關係，以保險業為例，當業務部門查詢某張保單的資料時，能否一併知道這張保單的要保人還購買了哪些保險商品。
LOC 對於資料程序也提供了資料歷程 (data lineage) 的支援：資料程序可以在執行過程發出「事件」，這些日誌可以稍後在 LOC 使用者介面中瀏覽，使企業清楚檢視資料如何流動。這些事件也可以用來傳遞資訊給其他資料程序，讓後者知道它們何時該接棒處理下去。
自動化的雲端佈署
從技術面來看，LOC 其實和近年流行的 FaaS (Function as a Service) 雲端服務非常類似 — — 凡舉 Google、微軟及亞馬遜都建置了自己的 FaaS 服務，讓使用者只需撰寫一支函式，其餘的佈署及執行皆由雲端平台本身包辦，使用者完全不須具備相關概念。
對於 LOC 的資料程序來說，原理也是類似的。這意味著使用者可以用所謂的低程式碼 (Low-code) 方式來快速建置資料程序，進一步省下更多時間。
當然，LOC 的資料程序比正規的 FaaS 更為強大 — — 一個資料程序可由多重邏輯函式組成，而且使用者可設定多個資料程序被同一個資料來源 (data source) 觸發。
LOC 的核心與相關服務，皆是佈署在 Kubernetes (俗稱 K8S) 環境內，而該環境可於私人伺服器到第三方雲端服務在內的任何地方運行。Kubernetes 是由 Google 團隊開發並開源的容器管理工具，它帶來了強大的佈署及營運管理功能，而且在全球已經廣為使用。根據統計，全球雲端開發者當中，每約五人就有一人在使用 Kubernetes。
在之後的文章中，我們會來更深入檢視 LOC 如何運用 Kubernetes。
從技術角度看 LOC
概觀來說，LOC 由三個主要部分組成：
LOC Core
LOC 的核心引擎，使用 Rust 語言開發。它負責執行並管理使用者建置的資料程序。
Rust 語言是近年的新興後端語言之一，儘管學習起來比 Go 或 Python 更困難，卻擁有更佳的執行效能與更低的記憶體使用率 (這意味著你能在同樣的伺服器上榨出更多服務容量)，而且會實施嚴苛的檢查來確保程式能穩定運作。這也是為何 Rust 在知名國外網站 Stack Overflow 年度調查中，能夠從 2016 至 2022 年連續七度蟬聯「最受喜愛語言」的頭銜。
LOC Studio
LOC Core 的圖形化使用介面，這是一般 LOC 使用者會最常用來操作 LOC 的管道。LOC Studio 本身的後端同樣以 Rust 開發，前端則使用 React 和 TypeScript 打造。React 由 Facebook 設計並開源，是當今市占率最高的現代前端框架之一。這類框架能在瀏覽器中即時渲染內容，帶來了具備高度互動性的介面。
LOC Studio 的兩大主要功能，一是資料程序和 API route (用來呼叫資料程序的 URL 路徑) 的建置與佈署，二是 Data Discovery — — 瀏覽由資料程序發出的資料事件，這些事件構成了前面提過的資料歷程。
LOC CLI
對於更專業的開發人員，LOC CLI 是可在本機執行的命令列工具 — — 開發者可從本機直接上傳資料程序到雲端，並透過終端機管理資料程序的佈署。
但 LOC CLI 不僅僅是文字介面版的 LOC Studio 而已；開發者可在免登入的情況下，於稱為 Simple Runtime 的本機容器直接進行測試 (FST 開發團隊提供了個以 Docker Compose 在本機運行的簡易版 LOC 環境)。如此一來，開發人員便可避免為了重複除錯而得一再佈署資料程序，也能率先測試資料介接是否符合預期。
資料程序
在這當中其實還有一個角色得討論，就是由使用者建置的資料程序。
資料程序本身的程式可用 JavaScript 或 TypeScript 撰寫 ，而每個資料程序在佈署時會被自動打包成容器，每個容器本身會包含一個 Deno runtime (一個用來執行使用者程式的引擎) 以及相關的 Rust 後端程式來執行這些程式碼。同樣的，我們會在之後的專文中來更深入探討這部分。
目前 TypeScript 僅有 CLI 支援。讀者或許會對 TypeScript 較為陌生 — — 但簡單來說，微軟開發的 TypeScript 其實就是 JavaScript 的加強版。TypeScript 在 JavaScript 的基礎上加上了額外的檢查機制，對專業開發者而言助益甚大，如今在各大前端框架也已廣為支援。
而在 LOC 資料程序容器中，會內建有稱為 agents 的一系列服務，讓資料程序能存取 HTTP API、遠端檔案、資料庫，以及操作用來串接資料邏輯、記錄資料狀態的 session 資料及事件等等。換言之，agents 扮演了資料程序如何與企業既有系統溝通的關鍵。
前面也提過，資料程序可由資料來源觸發。資料來源包括 API 端點、排程器 (scheduler) 及訊息佇列 (message queue) 三類，這賦予了企業能以更加靈活的方式決定資料來源何時該執行。
結語
LOC 是一個以資料邏輯驅動的雲端平台。它對於企業現有系統及資料是非侵入性 (non-intrusive) 的，但能夠扮演介接一切的「水管」角色。
過多的數據湖、資料庫存有的繼承生態、湖底淤泥、以及不同的出入水口，其雜亂無章的程度將花費數不清的功夫來整理。其實，我們所需要用到的日常水源是透過水管提供的，因此，在企業內唯有被水管要到的水才是優先要清理與瞭解釐清的目標對象。 透過管理與暸解水管的作法，能夠取代數據海底撈這樣的窘境， 並能漸進式完成一個難以達成的數據難題。
短期來說，它可以當成一種雲端式的微服務使用，而且可以由客戶決定要安裝在何處並自行管理。長遠下來，企業甚至可逐漸淘汰舊系統，將主要的商業邏輯移植至 LOC 內、並以 LOC 來快速建置新的資料流程。當然，LOC 資料程序也具備記錄資料歷程的能力，使企業得以追蹤資料的使用和流向，從中尋找潛在的商業機會或發現問題。
為了達到這種目的，FST 選擇了一系列最現代化的開發工具來打造 LOC。其後端採用高效能的 Rust 語言，而 LOC Studio 的介面則是能帶來高互動性的 React 框架。而由於 LOC 建置在 Kubernetes 上，它也擁有強大的維運可靠性，且能自動佈署使用者建置的資料程序。使用者可以用 JavaScript 或 TypeScript 輕易撰寫資料程序 — — 這兩種語言的門檻都不高 — — 又無須了解佈署與執行的細節。
本篇就寫到這裡。在下一篇文章中，我們將來看 LOC 如何運用包含 Kubernetes 在內的一系列技術，打造出一種可快速佈署的 FaaS 服務平台。
本文的相關材料感謝 FST Network 的產品及開發部門鼎力協助。
欲進一步了解 Logic Operating Centre (LOC) 或想觀看實際產品展示嗎？歡迎來信 support@fstk.io 詢問細節。
