不同階段有不同的架構 ## 1. 匯出法 後台做匯出 CSV 或是 Excel，讓 data team 用 excel 分析 缺點: 因為是即時算，下載慢，若 query 沒寫好，用戶一直做匯出還會倒站 ## 2. 自幹法 直接在 Rails 上，產生 json object 搭配前端套件(例如 chart.js)，做出表格和圖表 缺點: 資料分析師幫不上忙，都需要工程師來做 ## 3. Rails 的 BI gem 在 Rails 上讓資料分析師可以直接寫 SQL 做分析，產生一些報表。例如以下套件: * https://github.com/ankane/blazer * https://www.honeybadger.io/blog/blazer-business-intelligence-ruby-on-rails/ 缺點: 1. 沒有經過 ETL 程序的話，原始 DB schema 可能不方便分析 2. blazer 畢竟只是 Rails 的 gem，沒有完整的 BI 功能，功能有限 ## 4. ETL 進 BI 系統 如果想要資料分析師可以好好幫上忙，就需要安裝獨立的 BI 系統，然後將資料透過 ETL 流程轉過去。 BI 系統有很多家，例如 * Metabase https://www.metabase.com/ (這有 open source 可以自己裝，推薦) * Amazon QuickSight * 微軟的 Power BI * FineBI * Tableau 看數據量有多大，底層是否要換分析專用的 DB，例如 Amazon Redshift , GCP BigQuery 等，這些 BI 系統應該都有支援。 分析用的 table 和營運用的不同，你需要做 ETL 轉換，不然 SQL 會很難寫，也很不好重用，有兩個方向: ### 一天轉個幾次 這可以自已開發，或是用 gem https://github.com/thbar/kiba 有個遵循的架構。不會太難，就是讀資料然後轉存過去。 ### 即時轉 這難度就高了，每次資料變更就立即更新，不但影響production效能，維持資料的一致性難度也很高。 我個人是懷疑沒有這種需求啦，統計性質的報表分析根本不需要即時 如果是業務用，那根本應該做在應用程式上，而不是還要經過ETL進到報表系統再用。 ## 5. ELT 進 BI 系統 這是最近比較新的方式，更進一步不需要工程師來寫 ETL 了，直接從原始資料庫，數據工程師透過 dbt https://www.getdbt.com/ 這個服務，用 SQL 進行多層轉換。 * [只會 SQL 也能成為資料工程師？用 DBT(data build tool) 解決資料團隊的缺糧危機](https://medium.com/dbt-local-taiwan/%E5%8F%AA%E6%9C%83sql%E4%B9%9F%E8%83%BD%E6%88%90%E7%82%BA%E8%B3%87%E6%96%99%E5%B7%A5%E7%A8%8B%E5%B8%AB-%E7%94%A8dbt-data-build-tool-%E8%A7%A3%E6%B1%BA%E8%B3%87%E6%96%99%E5%9C%98%E9%9A%8A%E7%9A%84%E7%BC%BA%E7%B3%A7%E5%8D%B1%E6%A9%9F-5e25c02dc41) * [ELT方法的變革對數據驅動營運的重要性](https://tuna.mba/p/220807) 這招最大的好處就是，數據分析團隊只要很會 SQL 就可以做完全部事情，就不需要麻煩後端工程師去寫 ETL 程序了。 ## 為何要轉 schema? 由於分析目的和營運不同，針對分析用的 資料庫 table 需要做個轉換 營運用的資料表注重正規化，因為需要經常寫入，並避免資料不一致。 而分析用的資料表會盡量扁平，因為才好 join、欄位超多沒關係、不用擔心資料重複，也不需要寫入資料 ## BI 工具 有資料之後，就可以在上面挑一個 BI 工具來用，方便 “資料分析師” 去玩 和做圖表 BI 工具很多，付費各家都有出有很貴的，免費開源的推薦 metabase ## 底層資料庫 各家也有出針對分析用途專門的資料庫，可以處理巨量資料 例如 google bigquery 或 aws redshift 等等 不過資料量少的話，就繼續用 mysql 或 postgresql 也行 這些資料庫都支援 SQL 語法