資料堆疊的隱藏成本

我們在此列出維護資料堆疊相關的隱藏成本（此列表並不完整）。而所謂的資料堆疊，我們大致指的是由以下項目組成的現代資料堆疊：

• 資料來源層（營運/生產資料庫和第三方資料來源）
• 將所有來源資料整理到資料倉儲的 ETL 層
• 儲存層（資料倉儲）
• 查詢層（BI 工具）

本文並非意在引起恐慌、不確定和懷疑（FUD），我們只是認為點出一些成本管理方面的機會會很有幫助。我們並未按順序排列這些成本，因為成本的重要性因組織而異，因此您可以選擇處理某些成本，而不是其他成本。我們將首先介紹問題領域，然後探討降低這些成本的不同方法。

隱藏成本

訓練和學習曲線

一個經常被忽略的成本是，您堆疊中的工具會產生一些訓練管理費用。或者，您可以為已經掌握某些工具或堆疊層的人支付更高的薪資。這種管理費用與您的 BI 工具尤其相關，因為 BI 工具（您資料堆疊的窗口）將有最多人使用，且每個人都有不同程度的經驗。

這裡要指出的另一件事是，學習曲線會產生兩種不同的成本。第一種成本是培訓員工使用這些工具所需的時間，可以通過主動訓練（您為人們舉辦培訓課程）或自學訓練（您期望人們閱讀文件、自行摸索並從做中學）來完成。

第二種成本，採用失敗，可能更不明顯：如果工具難以學習，人們將懶得學習產品，使其能夠有效率地工作。或者，更糟的是，他們根本懶得學習產品，最終您為一個對您的組織產生零價值的許可證付費。

迭代延遲

團隊可以多快地迭代自己的報表？也就是說，您可以根據新資訊（無論新資訊是來自市場變化，還是產品中新加入的事件）多快更新報表？

具體來說，我們指的是，如果對於資料堆疊的每次「建置」（這裡我們指的是「建置」資料倉儲的 ETL 層），您都需要處理整個表格，那麼迭代以對該建置進行變更的成本將非常高昂。

如果在做出變更後，您從分析資料的人員那裡收到回饋，指出某些資料看起來有問題，或者您需要納入更多資料，那麼在模型中新增或變更幾個欄位可能會讓您在薪資和雲端成本方面付出可觀的金額。

殭屍 ETL 工作和報表

人們建立並排程報表。然後他們繼續建立新的報表，並排程這些報表。他們停止查看舊報表，但舊報表仍在繼續執行，即使您僱用了更多人，他們也會建立和排程更多報表……問題是，大多數雲端資料庫供應商按查詢收費，因此您最終會為您沒有利用的分析付費。

巴士係數

雖然並非資料團隊獨有，但當這些團隊的專家離開公司時，資料和團隊孤島很容易發生「知識重置」。

快取成本

快取在很大程度上是一種節省成本的方式，但某些解決方案需要將您的資料快取在單獨的資料庫中，然後向您收費。也許這個成本是值得的，也許不是。

缺乏擴充性

BI 工具應該能夠與您的團隊已經熟悉的工具良好協作。例如，您可以使用 Metabase 來建模您的資料，然後讓人員使用他們想要的任何工具來建立報表。如果有些人更習慣使用試算表軟體，他們可以從 Metabase 匯出資料，並在他們選擇的試算表軟體中進行分析，這完全沒問題。問題在於工具強迫您使用它們。

維護多個事實來源

將大致相同的資料儲存在多個位置可能會導致兩個問題：第一個問題是您最終可能會浪費時間來弄清楚您可以依賴哪些資料。第二個相關且更具破壞性的問題是，您最終可能會根據錯誤或不正確的資料做出決策（錯誤意味著您應該使用其他更相關的資料，而不正確意味著資料本身不準確或不完整）。

帳戶層級調整

雖然是小問題，但仍然很麻煩。由於某些方案提供不同類型的帳戶，在不同的價格點具有不同的能力，因此您必須處理如何分配這些能力的問題。某些建立者授權可能是基本帳戶的 10 倍，因此您必須花時間弄清楚誰獲得授權以及原因，以及何時隨著業務變化增加或減少授權數量。

這些分層帳戶的另一個問題是，由於只有某些帳戶類型允許建立報表或進行變更，因此它們保證您會在工作流程中建立瓶頸（想想：臨時請求隊列）。

如何降低資料堆疊成本

以下是一些您可以採取的行動的非詳盡列表，以減輕上述問題。每個建議都可以幫助減少上述一項或多項成本。

使用不需要 SQL 即可查詢資料的工具

您肯定需要一個可以使用 SQL 的工具，但您也需要一種讓不懂 SQL 的人與資料互動的方式。查詢產生器越直覺，人們就能越快上手 BI 工具，這意味著更多人實際上會使用您付費的軟體。

舉辦培訓課程和資料分享

這些培訓課程不必是正式的。只需讓大家聚在一起，讓他們通過製作與自己相關的儀表板來學習。一旦人們掌握了工具，並了解資料在哪裡，您只需為新員工舉辦培訓課程。

而且您不能僅僅培訓工具的使用；您必須向人們展示他們可以使用哪些資料以及在哪裡使用。如果工具好用，它應該有大量的文件和學習資源。但是，如果人們不知道在哪裡可以找到與其領域相關的資料，那麼這些知識就會被浪費。

記錄您的資料

說到培訓：資料文件是您公司核心基礎架構的一部分，但是，是的，好吧，祝您好運。只有在您指派人員執行資料文件時，您的資料才有可能被記錄下來；也就是說，您需要為這項工作開單並實際完成它。如果您還沒有資源來完成這項工作，您可以嘗試一些強制功能，這些功能可能至少可以記錄一些資料。例如，您可以在團隊或公司會議上輪流重點介紹某些模型或報表，這可以激勵人們實際將內容寫下來（例如，填寫欄位描述、為儀表板新增背景資訊等）。記錄您的資料可能看似西西弗斯式的任務，但點點滴滴都有幫助，這些文件將在知識共享、新人培訓和決策制定方面帶來回報。

定期清理排程報表

某些工具隨附稽核工具，可以告訴您排程報表的執行頻率。如果您懷疑有人沒有查看某些報表，請封存它們，看看是否有人抱怨。即使他們抱怨，也請與他們討論降低報表執行頻率，或完全關閉報表，僅在需要時讓人們執行。

更輕鬆地建立、維護和修改模型

讓每個團隊都能輕鬆管理自己的資料集。這些團隊了解資料描述的領域，因此他們能夠很好地識別哪些資料相關，哪些資料不相關。

這裡一個有用的區別是基礎模型和報表模型之間的差異。

理想情況下，您應該擁有一組基礎模型：由資料團隊、分析師或工程師管理的已清理、相對原始的資料。這些模型中的資料是乾淨且正確的，但尚未針對特定領域進行管理。對這些模型的變更應該不頻繁，因為它們的變更成本可能很高。

報表模型是下游模型，團隊可以建立和更新這些模型，以回應用戶需要回答的問題。這些模型輕巧且靈活。它們的製作成本較低，雖然可以由分析師驗證，但並不受分析師的限制。

本節值得寫一整篇文章，所以我們現在就此打住。

避免使用分層帳戶工具

如果您想收緊對誰可以做什麼的控制，那應該是權限問題，而不是定價問題。我們 (Metabase) 採用分層產品模型（免費版與企業版/專業版）的原因之一是因為我們認為帳戶層級模型很煩人。Metabase 並非個例，但總體而言，如果您避開那些不會讓您弄清楚您想為哪些人支付更多費用的軟體，您將產生較少的管理費用。

分散您的資料團隊

如果您有一個深厚的資料人才庫，請將分析師嵌入團隊中，以培養領域專業知識，並幫助團隊學習如何自行建立報表。理想情況下，資料分析師應該花費與撰寫報表一樣多的時間來教導和審查他人的報表。

謹慎升級（或讓其他人為您執行升級）

僅在您能從新功能中受益時才升級工具。或者（更好的是）通過將升級外包給服務來降低風險並節省時間。如果出現問題，那也不是您的問題。