OpenBI

工具介绍

## 這是什麼 傳統開源 BI 往往逼你寫 SQL、養資料團隊，或者把庫連到別人的雲。OpenBI 想走另一條路：Docker 一鍵自託管，把庫接上後，用大白話提問，背後用 text-to-SQL 跑查詢，再把結果變成圖表和儀表盤——資料全程留在你自己的機器上。 它把自己定位成「AI-native」BI：聊天、知識庫、看板、匯出、定時推送、甚至 Telegram 機器人串在一條鏈上，而不是「先做完傳統 BI 再貼一個 Chat 外掛」。 ## 能打的地方 - **對話查數 + 可審計 SQL**：用自然語言提問，經 MindsDB 轉成 SQL 打到線上庫，並回顯實際執行的 SQL，方便核對「AI 到底查了什麼」。 - **結構化 + 文件一起問**：除了 Postgres/MySQL 等庫，還可上傳 PDF、CSV、Excel、Markdown 做向量檢索；同一條回答裡可以混活資料與制度/紀要類文件（RAG）。 - **結果直接變看板**：聊天結果可自動生成 AntV G2 圖表或透視表，Gridstack 拖拽排布，WebSocket 即時同步，團隊同屏看變化。 - **匯出與分發一條龍**：一鍵 PDF（帶版本歷史，存 MongoDB GridFS）；PPTX 走自託管 Presenton，按看板上下文生成可編輯幻燈片；Cron 定時重新整理看板，經郵件 / Telegram / Webhook 推送。 - **移動端與連接面**：完整 Telegram Bot（瀏覽看板、提問、收 PDF/PPTX、切專案與 agent）；宣稱 90+ 資料來源（含 Snowflake、BigQuery、Stripe、HubSpot、Shopify、GitHub、Notion 等），憑據 Fernet 加密落盤。 ## 適合誰 · 誰不用碰 **適合**：有 Docker 運維能力、資料敏感不願上 SaaS BI 的小團隊；業務同學想先「問一句出一張圖」，分析師願意盯 SQL 是否靠譜；需要把銷售庫和 PDF 紀要、制度文件放在同一套問答裡的場景。 **先別碰**：要開箱即用、零運維的團隊（這是 6 服務 Docker Compose，不是點一下注冊）；強合規的商業產品要二次分發/改程式碼的（許可是 **CC BY-NC-ND**，非商業、禁止衍生，和常見 MIT 差很多）；需要成熟中文文件、大廠 SLA、複雜許可權與資料治理的中大型數倉團隊——專案仍很早期，GitHub 關注度也極低，當實驗可以，當核心報表平臺風險偏高。 ## 上手門檻 程式碼與說明主要在 GitHub / Product Hunt 英文語境，**未宣稱中文介面**，大陸拉映象/讀文件通常要過網路門檻。部署形態是 Docker Compose 多服務，還要自備 LLM 與各資料來源連線；免費體現在「軟體本身開源可自建」，算力、API 和運維成本在你這邊。註冊學習曲線中等偏高：會 Docker 能跑起來，但要把 text-to-SQL、agent、知識庫和定時任務調穩，需要一點耐心和排錯能力。許可務必自行核對：非商業限制可能卡死公司內部規模化使用。 ## 和同類怎麼選 | 維度 | OpenBI | Metabase | Apache Superset | | --- | --- | --- | --- | | 核心定位 | AI 對話優先的自託管 BI（text-to-SQL + RAG + 匯出/機器人） | 成熟開源 BI，問數與看板並重 | 重量級開源視覺化/SQL 實驗室 | | 價格模式 | 開源自託管（CC BY-NC-ND） | 開源 + 商業版 | 純開源（Apache） | | 易用性 | 對話門檻低，部署與調參偏重 | 業務向友好，生態成熟 | 靈活但學習曲線陡 | | 大陸可用性 | 自託管可控；獲取與文件偏海外 | 社群與資料多，自託管常見 | 同上，企業實踐多 | 具體以各家官網為準。 一句話：要「穩、合規商用、社群大」選 Metabase/Superset；要「全棧 AI 聊天 + RAG + Telegram/PPT 匯出」且能接受早期專案與 NC 許可，再試 OpenBI。 ## 值不值得試 **小眾才需要試**——方向清楚，功能拼圖也全，但成熟度與許可都還沒到「直接上生產」那一檔。有自託管硬需求、又想驗證「全員用中文/英文問庫」的團隊，用測試庫跑一週 Docker 最划算；已經有人在用 Metabase 且只差一個 Chat 外掛的，不必為了概念整體搬家。