Asgard AI logo
Asgard 肆佳科技
Enterprise Data Platform
企業資料平台選型評估

套裝軟體 vs OpenSource — 企業資料平台路線整體評估

以「六階段角色框架」對標三條路線，並給出一條保留性價比與擴充性的階段演進路線。

適用對象：中大型製造／傳產企業
地端部署 · IT 具 SQL 基礎 · 尚未建立資料倉庫 · 目標 BI / AI
01 / 58
本報告適用情境

這份評估為誰而寫

  • 中大型製造／傳產企業
  • 有地端部署需求、資料以內部系統（ERP、生管、現場）為主
  • IT 團隊具應用系統開發與 SQL 基礎
  • 尚未建立資料倉庫、過往以採購套裝軟體為主
  • 長期目標是 BI 與 AI 應用

若多數條件符合，本報告結論可直接適用；條件不同（如已有成熟倉庫），各章標示了判讀會如何改變。

02 / 58
Executive Summary

本報告要回答的三個問題

i
一、為什麼這個選型題不容易比？
這些方案本來就不是同一類東西，行銷詞彙卻高度重疊，放在同一張表上自然難有結論。
i
二、各條路線各自是什麼、適合誰？
放進同一張「角色框架」，逐項攤開各自的優勢與限制。
i
三、此類企業應該怎麼走？
一條保留性價比與擴充性的階段演進路線，加上配套的團隊培養計畫。
03 / 58
核心發現

其實只有兩條路：買套裝，還是自建開源

套裝軟體（買現成的）

市面產品眾多，多按模組／年計價、能力綁廠商：

  • 資料整合（ETL）：Informatica、Talend、SSIS、Fivetran、FineDataLink
  • 資料虛擬化：Denodo、TIBCO、IBM、SAP HANA
  • BI／報表：FineBI、Power BI、Tableau

開源自建（自己組）

一套完整平台、零授權費、能力與資料都留在團隊：

  • Airflow · PostgreSQL · dbt · Iceberg · Trino · Grafana
  • 六階段一次覆蓋，任一元件可單獨替換
  • 資料以開放格式存放，永不被鎖定

差別不在「哪個產品功能多」，而在「買斷當下需求」還是「累積帶得走的資產」。

04 / 58
一句話定位

一句話定位：買工具，還是建平台

套裝軟體：一件件買的工具

搬運工具、查詢窗口、報表機——各自獨立產品、各自計價。買到的是單點功能，不是一座平台； 要拼成完整資料平台，得買好幾套、再自己接起來。

開源自建：一座完整的資料工廠

從進料到出貨，六個工站一次到位。零授權費，能力與資料都留在自己手上， 任一工站不合用都能單獨替換。

05 / 58
評估結論

六維度綜合評估：套裝 vs 開源

維度套裝軟體（商用）開源自建
六階段角色覆蓋單一產品只覆蓋一兩格，需多套拼湊完整，六階段一次到位
地端部署可可（全開源）
授權成本結構授權／年訂閱，依模組與用量計價零授權費，投資在人與顧問
團隊能力累積操作技能，綁定廠商業界通用技能，留在團隊
擴充性／退場彈性中低（私有格式、生態綁定）高（開放格式、逐件可換）
AI 整合自由度受產品藍圖限制完全開放

「套裝軟體」涵蓋商用 ETL、資料虛擬化與 BI 等各類產品（細部對標見第 5 章）。

06 / 58
建議

開源自建 + 三階段演進

Phase 1
PostgreSQL 中台起步
Airflow + PG + dbt + Grafana + Asgard Data Insight，3–4 個月跑通第一條業務閉環
Phase 2
治理強化
+ Airbyte（介接 UI 化）+ OpenMetadata（資料目錄）
Phase 3
Lakehouse 升級
+ MinIO + Iceberg + Trino，與大型企業同級、全程零授權費

每階段都有可觀察的觸發條件，且前一階段資產全數延續，不走回頭路。

07 / 58
比選型更重要的事

團隊培養

✓
能力留在哪裡，才是長期勝負
無論選哪條路線，企業長期都需要一個能自主維運資料平台的小團隊。差別只在——商用方案培養出「某套產品的操作員」，開源路線培養出「帶得走的資料工程能力」。本報告的導入服務皆含種子工程師制度、on-hand training 與結業驗收（第 8 章）。
08 / 58
為什麼需要 Data Solution

從點對點串接到統一資料層

現況每條跨系統需求都靠客製 SQL Job、人工匯出
→
蔓延串接路徑越來越多，沒人畫得出全貌
→
轉折導入 Data Solution
→
目標各系統 → 統一資料平台
→
產出BI 看板 / AI 查詢
09 / 58
常見徵狀

沒有統一資料層的四個徵狀

  • 點對點串接蔓延：每條需求一支客製 Job，沒人畫得出全貌
  • 欄位定義各說各話：同一個「數量」「日期」各系統口徑不同
  • 報表需求壓在 IT 身上：每個新報表都是一次客製開發
  • AI 無從談起：資料散落各處，任何 AI 專案都卡在第一步
10 / 58
必備觀念

OLTP vs OLAP：兩種設計目標

OLTP 交易處理OLAP 分析處理
誰在用ERP、生管、現場系統報表、看板、趨勢分析、AI
典型操作大量小筆讀寫少量大範圍掃描彙總
設計重點單筆即時、正確、不能停大量掃描快、彙總快
資料保留通常只留近期長年累積，歷史就是價值
11 / 58
為什麼不能直接在來源查

在 OLTP 上跑分析的三個後果

!
拖慢生產系統
一句掃半年的報表查詢，會和現場下單、報工搶資源。
!
表結構不適合分析
OLTP 表為交易正確性設計，分析常要跨數十張表 JOIN。
!
歷史查不到
來源系統會清舊資料，趨勢與 AI 需要的長期歷史不在裡面。
12 / 58
採購習慣的失靈

為什麼「買套裝軟體」在資料這件事上失靈

套裝軟體的邏輯（對 ERP 有效）
  • 需求明確 → 選一套功能符合的
  • 廠商導入 → 上線使用
  • 流程固定的系統行之有年
資料平台的兩個本質差異
  • 資料需求是長出來的，不是定義出來的——每次成長都是一次加購
  • 價值在累積：十年生產資料是資產，鎖進私有格式換廠商成本複利成長
13 / 58
範圍與方法

評估對象與三步方法

  • 路線一｜商用套裝（低代碼資料整合）：Informatica、Talend、Microsoft SSIS、Fivetran、FineDataLink 等——本報告以 FineDataLink 為代表
  • 路線二｜資料虛擬化：TIBCO Data Virtualization、IBM Cloud Pak for Data、SAP HANA、Dremio、Denodo 等——本報告以 Denodo 為代表
  • 路線三｜開源自建：Airflow / PostgreSQL / dbt / Iceberg / Trino + 顧問導入
i
三步評估方法
一 建立中立的「六階段角色框架」——先有一把共同的尺；二 把每個方案放進框架對標——看清「是什麼、不是什麼」；三 以適用情境條件做多維度評估——功能、地端、自主維運、擴充性、鎖定、AI、成本。
14 / 58
一筆資料的旅程

每日各課別產出看板，資料怎麼來

來源ERP 工單 + 現場報工
→
擷取每天自動抓出來
→
儲存倉庫集中存放
→
轉換清洗、對齊口徑、彙總
→
查詢SQL 取數
→
應用看板 / 報表 / AI 問答
15 / 58
框架

六階段角色（用工廠比喻）

階段工廠比喻白話
1 Sources 來源上游供應商資料的產地：ERP、生管、現場、檔案、感測器（只盤點不選型）
2 Ingestion 擷取進貨物流定時/即時把資料搬進平台，重點是穩定、自動、不漏
3 Storage 儲存中央倉庫資料集中的家，決定容量、成本、格式是否開放
4 Transform 轉換加工產線清洗、對齊口徑、彙總成可用的成品表
5 Query 查詢出貨窗口讓人與系統用 SQL 取數的引擎
6 Consumption 應用客戶端BI 看板、報表、自然語言問答、AI 模型
16 / 58
三橫切面

貫穿所有階段的支撐角色

Orchestration 排程

生管排程：誰先誰後、失敗怎麼辦。代表：Apache Airflow。

Governance 治理

品保 + 文管：口徑一致、權限、血緣、變更紀錄（git 版控為基礎）。

Observability 監控

戰情室：排程有沒有失敗、資料量異常、磁碟夠不夠。

17 / 58
完整框架總圖

資料平台六階段角色框架

Sources
→
Ingestion
→
Storage
→
Transform
→
Query
→
Consumption

另有 Orchestration / Governance / Observability 三橫切面貫穿全部。這張框架是後面所有比較的尺。

18 / 58
必備觀念一

ETL vs ELT：先加工再進倉，或先進倉再加工

ELT（現代主流，本報告採用）
  • 先載入、再轉換
  • 原始資料完整保留，隨時可回頭重算
  • 轉換邏輯是倉庫裡的 SQL 檔（可版控、可審核）
  • 代表：dbt + 任一倉庫，Lakehouse 標準做法
ETL（傳統）
  • 先轉換、再載入
  • 原始資料不保留（只留成品）
  • 轉換邏輯在 ETL 工具裡（常為圖形化）
  • 代表：Informatica、SSIS、FineDataLink
19 / 58
必備觀念二

資料儲存架構的四個世代

世代 1
資料倉庫 DW
結構化、查詢快但貴、綁廠商（1980s–）
世代 2
資料湖 Lake
什麼都能丟、便宜但難治理，易成「資料沼澤」（2010s–）
世代 3
倉 + 湖雙軌
兩者優點兼得，但資料兩份、搬運成本高（2015–）
世代 4
Lakehouse
一份資料、多引擎、便宜 + 有治理（2020–）

Lakehouse = 在便宜儲存上加一層「表格式」（如 Apache Iceberg）。這是第 5 章目標藍圖的依據。

20 / 58
框架的用途

用框架重新理解「為什麼選型會混亂」

  • 行銷詞彙高度重疊：資料中台、數據集成、Data Fabric、一站式平台
  • 有的產品只做一格（如 Denodo 專注查詢層）
  • 有的做兩三格（如 FineDataLink 做擷取 + 轉換 + API）
  • 有的「平台」其實是一個產品家族，每格各自計價（帆軟全家桶）
  • 開源路線則是每格挑一個最成熟的元件，組成完整平台
21 / 58
先放回正確位置

為什麼 FineDataLink 與 Denodo 難直接比

i
進貨物流 vs 出貨窗口
FineDataLink 解決「怎麼把資料搬進來、加工」；Denodo 解決「怎麼不搬資料就查到」。比較它們就像比較「進貨物流」與「出貨窗口」——都重要，但不是同一個職位。

更關鍵的是，兩者都沒回答「資料的家在哪裡」（Storage）——而對尚未建倉的企業，這正是首要目的。

22 / 58
路線一

低代碼資料整合（ETL）工具

市面同類（商用低代碼資料整合）：Informatica、Talend、Microsoft SSIS、Fivetran 等。本報告以 FineDataLink 為代表——中文生態完整、台灣有在地支援。

FineDataLink 官方產品架構

FineDataLink 官方產品架構：四個功能模組（覆蓋 Ingestion + 部分 Transform + Data API；Storage 需自備、BI 另購）。資料來源：finedatalink.com

23 / 58
路線一

FineDataLink：優勢與限制

優勢
  • 低代碼上手快，對沒有資料工程背景的團隊友善
  • 中文生態最完整，台灣有帆軟分公司
  • CDC 即時同步成熟
  • 與帆軟全家桶（FineReport / FineBI）整合順
限制
  • 是工具不是平台：儲存、查詢、治理仍是空的
  • 轉換邏輯存在產品內（圖形化），換工具需重建
  • 授權費不公開，全家桶各自計價
  • 團隊學到的是 FDL 操作，非業界通用技能
24 / 58
路線二

資料虛擬化（資料不落地）平台

市面同類（資料虛擬化）：TIBCO Data Virtualization、IBM Cloud Pak for Data、SAP HANA、Dremio 等。本報告以 Denodo 為代表——資料虛擬化的市場領導者。

Denodo 官方架構

Denodo 官方架構：來源 → 資料虛擬化層 → 應用（覆蓋 Query 跨源聯邦查詢 + 語意層；不持久化、不做歷史累積）。資料來源：community.denodo.com

25 / 58
路線二

Denodo：優勢與限制

優勢
  • 資料不搬動——法規禁止資料外移或已有多座倉庫時的業界標準答案
  • 見效快（在對的場景）：接上來源就能查
  • 企業級治理完整：語意層、權限、目錄、GenAI 助手
限制
  • 前提不成立：價值在整合「已存在的多座倉庫」，此情境還沒有倉庫
  • 查詢壓力落在來源系統，與生產交易搶資源
  • 歷史累積無解：查不到來源已清掉的歷史
  • 年訂閱成本高（公開參考 NT$600–750 萬/年）；專屬 VQL 人才池小
26 / 58
路線三

開源自建：每階段選一個最成熟的元件

角色起步元件（Phase 1）目標元件（Phase 3）
Ingestion 擷取Airflow Python 任務Airbyte（UI、300+ 連接器）
Storage 儲存PostgreSQLMinIO + Parquet + Iceberg
Transform 轉換dbt（SQL 模型化）dbt（同一套，改跑 Trino）
Query 查詢PostgreSQL 本身Trino（分散式、可跨源）
Consumption 應用Grafana + Asgard Data Insight+ Metabase（自助分析）
Orchestration 排程Apache Airflow（全程不變）（同左）
Governance 治理git + SQL 版控+ OpenMetadata
27 / 58
本章關鍵頁

角色覆蓋矩陣：三條路線一張圖看完

階段角色FineDataLink（+FineReport/FineBI 另購）Denodo開源自建
1 Sources盤點——
2 Ingestion● 核心強項○ 不搬資料● Airflow / Airbyte
3 Storage○ 需自備○ 刻意不做● PG → Iceberg
4 Transform◐ 低代碼（鎖產品內）◐ 虛擬視圖● SQL / dbt（可版控）
5 Query○● 核心強項● PG → Trino
6 Consumption◐ 需另購◐ 對外供數● Grafana / Metabase / ADI
Orchestration◐ 產品內◐ 快取排程● Airflow
Governance◐ 產品內權限● 語意層/目錄● git → OpenMetadata
Observability◐ 任務運維◐ 平台監控● Grafana / Prometheus

● 完整覆蓋    ◐ 部分覆蓋    ○ 不覆蓋

28 / 58
評估維度

八個評估維度

功能覆蓋

六階段角色覆蓋程度

地端部署

可否全部署在自有機房

團隊自主維運

廠商退場後能否獨立維運

知識移轉

能力是否留在企業團隊

擴充性

資料量成長時走不走得上去

廠商鎖定

格式是否開放、退場成本

AI 整合

能否自由對接 AI 應用

成本結構

錢花在授權、硬體還是人

29 / 58
路線一評估

商用套裝路線（以 FineDataLink 為例）

維度評估
功能覆蓋擷取轉換強，儲存自建、BI 另購
團隊自主維運易上手，但架構問題仍需原廠
知識移轉產品操作，人才不流通
擴充性生態內順，跨出受限
廠商鎖定中高（私有格式）
成本結構授權費（報價制）+ 每模組計價
!
適用情境判讀
可快速看到第一張報表，但資料的家、口徑治理、歷史累積沒被回答；若目標含 AI 與長期擴充，與「買斷當下需求」有結構性矛盾。
30 / 58
路線二評估

資料虛擬化路線（以 Denodo 為例）

維度評估
功能覆蓋查詢層世界級，但不持久化、不累積歷史
團隊自主維運需 VQL 專屬技能，台灣人才池小
知識移轉技能綁 Denodo
擴充性角色單一，資產累積仍需另建倉
廠商鎖定高（VQL 私有）
成本結構年訂閱 NT$600–750 萬/年（公開參考）
!
適用情境判讀
Denodo 解決的是「倉庫太多」，而此情境的問題是「還沒有倉庫」。聯邦查詢把分析負載壓在生產系統上，對製造現場是營運風險。多年後資料域成熟時可再評估——屆時 Trino 也能承擔同角色（零授權費）。
31 / 58
路線三評估

開源自建 + 顧問陪跑

維度評估
功能覆蓋六階段完整，每格皆業界主流
地端部署完全地端、全開源，資料不出廠
團隊自主維運以「顧問退場、團隊接手」為驗收
知識移轉業界通用技能，新人可補位
廠商鎖定最低（開放格式 + git 內 SQL）
成本結構零授權費 + 一次性導入 + 自有硬體
✓
三個傳統顧慮，各有對策
「元件要自己組」→ 顧問提供經實證的架構藍圖（第 5 章）；「學習曲線」→ 階段演進控制坡度（第 6 章）；「沒有單一廠商究責」→ 導入合約含保固與訓練驗收（第 8 章）。
32 / 58
常見疑慮

開源軟體的資安與漏洞風險

疑慮實際情況
程式碼公開 = 容易被入侵？公開讓全球持續檢視；主流專案有正式 CVE 通報與修補，常快於商用版本週期
沒有廠商，漏洞誰修？元件皆有專職組織（Apache、各母公司），且都有付費商業支援可加購
有大企業在用嗎？PostgreSQL／Airflow／Iceberg／dbt 誕生並運行於 Netflix、Airbnb 等生產環境
授權有法律風險嗎？多為 Apache 2.0 / MIT；少數例外（MinIO AGPL v3）導入時由顧問盤點
33 / 58
成本結構（非報價）

五年期成本結構量級比較

成本項商用套裝Denodo開源自建
軟體授權／訂閱報價制、逐模組加購NT$600 萬+/年，五年累計數千萬0
導入／顧問原廠導入（另計）原廠/代理（另計）一次性導入（依範圍議價）
硬體自備自備自備（Phase 1 一台 VM 起）
團隊人力操作為主仰賴外部專家1–3 名種子工程師（訓練後自主）
五年後的處境持續付授權、能力在廠商持續付訂閱、能力在廠商不再付授權、能力在自己團隊
34 / 58
綜合結論

建議路線三，濃縮成三句話

✓
只有它回答了全部六個角色
特別是「資料的家」與「歷史累積」這兩個最核心的需求。
✓
錢花在會留下來的地方
授權費換成團隊能力與開放格式的資料資產。
✓
不關門
未來若要商用 BI，開源資料層隨時可對接；反過來轉換成本高得多。
35 / 58
為什麼目標是 Lakehouse

三個具體理由

資料資產的保險

資料以開放格式（Parquet + Iceberg）存在自己的儲存上，十年後任何引擎都讀得到。

一份資料、多引擎

報表、批次加工、AI 訓練用不同引擎讀同一份資料，不需複製。

成本曲線平緩

儲存用便宜物件儲存、計算依需擴充；資料成長十倍，成本不會成長十倍。

36 / 58
完整架構總圖

地端全開源 Lakehouse 架構

SourcesERP / 生管 / 檔案 / API
→
IngestionAirbyte（批次 + CDC）
→
StorageMinIO + Iceberg + Lakekeeper
→
Transformdbt（SQL 模型 + 測試 + 血緣）
→
QueryTrino（分散式 SQL）
→
ConsumptionGrafana / Metabase / ADI

Airflow 排程、git 治理、Prometheus + Grafana 監控橫向貫穿全部元件。

37 / 58
Storage 拆開看

Lakehouse 的內部：五層解剖

L5 計算引擎
Trinodbt
L4 目錄
Lakekeeper
L3 表格式
Apache Iceberg
L2 檔案格式
Parquet
L1 物件儲存
MinIO

儲存與計算徹底解耦——換引擎時，資料一個位元組都不用搬。

38 / 58
元件名冊

各元件是誰：一句話介紹

元件角色一句話
Apache Airflow排程（橫切面）業界排程標準，以 Python 定義 DAG。Airbnb 開源
AirbyteIngestion300+ 連接器，UI 設定同步，內建 CDC
MinIOStorage L1地端 S3 相容物件儲存標準解
Apache IcebergStorage L3開放表格式，Netflix 開源；ACID、時間旅行、欄位演進
dbtTransformSQL 轉換模型化：依賴解析、測試、血緣
TrinoQuery分散式 SQL，跨源聯邦查詢（對應 Denodo 核心能力，零授權費）
Metabase / GrafanaConsumption自助分析 / KPI 看板 + 監控
Asgard Data InsightConsumption（AI）自然語言查詢與 AI 分析入口
39 / 58
重點元件放大

dbt 與 Airflow：日常維運的兩個介面

dbt 模型依賴血緣圖

dbt 自動產生的模型依賴（血緣）圖

40 / 58
誠實的取捨

架構的已知取捨與限制

取捨因應
元件數量多（8–10 個）分階段導入，Phase 1 只有 5 個，每階段擴充有觸發條件
沒有 24×7 原廠支援導入期顧問承擔，訓練以「團隊能自行排障」驗收，各元件有商業支援可加購
即時性為分鐘級製造 KPI 分鐘級已足；未來秒級需求可外掛 Kafka，不動主架構
MinIO 採 AGPL v3企業內部使用無虞，導入時由顧問完成授權盤點，必要時可換物件儲存
i
這是「目標藍圖」，不是 Day 1 要全部建起來的東西——下一章說明如何分三階段走到這裡。
41 / 58
為什麼不一步到位

分階段的三個理由

性價比

起步資料量 GB 級、表數十張，一台 PostgreSQL 綽綽有餘；直接上 Lakehouse 是用大砲打蚊子。

學習坡度

先在 5 個元件的小架構學會核心觀念，再逐步接觸進階元件。

風險控制

第一條業務閉環 3–4 個月見效，用成果決定下一階段投資。

42 / 58
三階段總覽

每階段都是可運作的完整平台

Phase 1
PostgreSQL 中台起步
Airflow + PG + dbt + Grafana + ADI，第一條業務閉環上線
Phase 2
治理強化
+ Airbyte（介接 UI 化）+ OpenMetadata（資料目錄）
Phase 3
Lakehouse 升級
+ MinIO + Iceberg + Trino，與大型企業同級架構

階段之間以「觸發條件達成」推進，不是半成品。

43 / 58
Phase 1

PostgreSQL 資料中台

來源ERP / 生管 / 檔案
→
排程介接Airflow
→
中台倉庫PostgreSQL（staging / core / marts）
→
轉換dbt SQL 模型
→
應用Grafana + Asgard Data Insight
  • 五個核心元件，一台 VM 即可起步，以 git 版控貫穿
  • 挑一條真實業務閉環（如 MES 報工 → 生管決策）跑通，但架構從第一天就通用
  • 日常維運在 Airflow / Grafana / ADI 三個網頁介面完成
  • 約 3–4 個月，含種子工程師訓練與結業驗收
44 / 58
Phase 2 / 3

每次升級都有可觀察的觸發條件

導入項觸發條件帶來什麼
Airbyte（介接 UI 化）資料來源 > 5 種，或出現 SaaS/雲端來源新來源從「寫程式」變「UI 點幾下」，CDC 內建
OpenMetadata（資料目錄）非 IT 開始用中台，或表數 > 20全公司可搜尋的資料目錄、欄位級血緣、變更審核
MinIO + Iceberg資料近 TB 級、PG 掃描變慢、需長年歷史成本大降、容量近乎無上限、時間旅行、開放格式
Trino跨庫查詢、併發成長、報表變慢單一 SQL 入口、水平擴充、跨源聯邦查詢（對應 Denodo，零授權費）
45 / 58
演進，而非重做

資產延續對照表

資產Phase 1Phase 2Phase 3
三層資料模型建立沿用沿用（搬到 Iceberg）
轉換 SQL（dbt）建立持續擴充改跑 Trino，邏輯不重寫
Airflow 排程建立沿用沿用
git 版控流程建立沿用沿用
看板 / AI 查詢建立沿用換連線目標即可
團隊能力排程/建模/版控+ 介接/資料目錄+ Lakehouse/分散式查詢
46 / 58
本章結論

簡易版起步 = 完整藍圖的第一階段

✓
「簡易版起步」與「完整架構」不是二選一——Phase 1 的 PostgreSQL 中台就是完整藍圖的第一階段形態。投資節奏由觸發條件控制，每一塊錢都花在已被驗證的需求上。
47 / 58
BI

三種互補的看數據方式

工具適合誰說明
Grafana管理層 KPI 看板、產線即時戰情Phase 1 即上線，固定版面、自動更新、支援告警
Metabase業務／生管自助探索Phase 2/3 加入，拖拉式，不寫 SQL 也能自己拉圖表
商用 BI（選配）特定部門偏好 FineBI／Power BI開源資料層以標準 SQL 對外，任何商用 BI 都能連
Grafana 看板

Grafana 看板：KPI、趨勢、告警集中一頁

48 / 58
AI 入口

Asgard Data Insight：自然語言查詢

使用者「上月各課別達成率排名？」
→
ADI語意理解 → 生成 SQL → 驗證 → 執行
→
marts 層治理過的乾淨彙總表
→
回傳答案 + 圖表 + 引用的數據口徑
49 / 58
關鍵前提

AI 問答的品質，取決於資料層的品質

i
AI 之所以能答對，是因為它查的是「口徑已對齊、命名已標準化」的 marts 層成品表。這就是為什麼本報告堅持「先把資料的家蓋好」——沒有治理過的資料層，任何 AI 工具都只能猜。
Metabase 自助分析

Metabase 自助分析：業務人員拖拉即可建立圖表

50 / 58
再往後

資料平台上的進階 AI 應用

AI 應用回答的問題需要的資料基礎
品質追溯分析這批不良品與哪些機台/班別/物料批號相關？報工 + 品檢 + 批號關聯（1 年+）
產能/交期預測這張工單實際會何時完成？工單 + 報工 + 換線歷史（1–2 年）
設備預測維護哪台設備可能要出狀況？稼動 + 維修 + 感測器（Lakehouse 階段）
排程最佳化怎麼排換線最少、交期最穩？以上全部 + 換線規則
✓
「資料基礎」欄正是階段演進的隱性時間表——今天開始累積，一年後第一批 AI 應用原料就緒；晚一年建平台，所有 AI 應用整體延後一年。
51 / 58
Handover

為什麼 Handover 是選型的一部分

商用套裝Denodo開源自建
日常維運靠誰自己（產品操作）原廠/代理為主自己（訓練後）
新需求擴充靠誰原廠模組 + 加購原廠/代理自己（顧問備援）
能力沉澱在哪廠商生態廠商生態企業自己的團隊
人員流動風險重招重訓（技能不流通）人才池小技能業界通用，市場可補人

開源路線把「培養團隊」當成交付物的一部分——不是附贈的教育訓練，而是有驗收標準的工程交付。

52 / 58
種子工程師制度

指派 2 名種子工程師，全程參與導入

不是旁聽，是動手

在顧問引導下實際建立部分資料表與排程——平台有一部分是「自己蓋的」。

訓練即工作

課綱與專案里程碑同步，學的東西當週就用在正式環境。

雙人制

避免單點依賴，互為備援與 code review 對象。

具基本 SQL / 程式經驗即可（.NET、Java 等應用開發背景完全適用）。

53 / 58
On-hand Training

六週核心課綱：跟著做 > 自己做

週次主題結業能力
1中台架構 + git 版控 + PG 三層模型理解三層設計、能完成版控提交與審核
2Airflow 入門 + 第一個排程 DAG能讀懂與手動操作既有排程
3排程撰寫模式（冪等/增量/回補）能選對可重用模板
4dbt 模型 + schema 變更 + 資料測試能新增模型、走完變更流程
5Grafana 看板 + ADI + 故障 SOP能配看板、設告警、處理常見故障
6結業實作：獨立新增一張中台資料表整合前五週能力，顧問僅在旁提示
54 / 58
知識移轉產出物

導入結束時全數移交（存於客戶自己的 git）

產出物內容
架構文件整體架構圖、各元件配置、連線與權限清單
維運手冊 Runbook排程失敗、資料延遲、磁碟告警、備份還原 SOP
資料血緣文件每張表的來源、欄位、口徑、更新頻率
排程模板三種可重用模式範本
訓練教材六週課綱講義 + 實作演練
變更管理流程git 審核流程與慣例
55 / 58
長期能力路線圖

團隊能力與平台架構同步演進

Phase 1 結業
獨立新增資料表
SQL / dbt 建模 / 排程 / 版控
Phase 2 進階
介接與目錄
Airbyte 介接管理 / 資料目錄維護
Phase 3 進階
Lakehouse 維運
分散式查詢調校
長期
自主規劃新情境
企業資料團隊獨立運作

顧問角色從「主導」逐階段轉為「備援」。

56 / 58
建議的下一步

三個具體動作

✓
第一步 · 內部對齊
內部對齊本報告的評估結論。
✓
第二步 · 範圍規劃
若同意開源演進路線，進入需求訪談與 Phase 1 範圍規劃。
✓
第三步 · 指派種子工程師
指派 2 名種子工程師人選，於 Phase 1 啟動時到位。
57 / 58

謝謝

Asgard 肆佳科技 · 企業資料平台選型評估

肆佳科技股份有限公司

asgard-ai.com
官網 asgard-ai.com · 歡迎交流
58 / 58