作者 | Lior Gavish

譯者 | 翟珂

策劃 | 武穆

開發內部數據產品，無論是功能強大的執行儀表板，還是由機器學習驅動的營銷預測買家模型，或者是BI團隊的新客戶模型，都是數據團隊為公司增加價值的最有效方式之一。

但是，開發一個外部數據產品卻有些不同：雖然更容易增加價值，但也更困難。這是一個不同的動作，需要你的團隊構建新的習慣。

同時，開發一個外部數據產品也是一種新的思維方式，需要更高水平的協調性、紀律性和嚴謹性。

這并不是說它不能由同一個團隊完成，也不是說你的內部數據使用者不能得到與你的外部客戶相同的服務水平。

餐廳銷售點提供商Toast公司的數據工程經理Noah Abramson最近談到了他們在這方面的經驗：“我們的一大價值是為我們的客戶提供商業洞察力。餐館，隨著時間的推移，他們的表現如何？他們昨天的銷售額是多少？誰是他們的主要客戶？與我們的餐廳客戶互動是數據平臺團隊的工作……我們說我們的客戶都是Toast員工。我們試圖讓他們所有人都能獲得盡可能多的數據。我們的團隊為所有的內部數據訪問提供服務，從產品到市場到客戶支持到硬件運營。”我也很幸運，在過去的工作中，我有機會在Monte Carlo的數據可觀測平臺中構建內部數據產品以及外部數據產品。

在這篇文章中，我們將總結這些經驗，并介紹數據團隊如何通過了解與構建內部產品不同的5個關鍵維度來成功推出外部數據產品，其中包括：

• 架構
• 用戶期望
• 投資回報率
• 自助服務
• 迭代

但首先，重要的是要了解到底什么是外部數據產品或數據應用，以及開發出來的應用類型將如何指導做出決策。

什么是外部數據產品？有哪些數據應用實例？它們如何影響你的決策？

外部數據產品是面向或影響客戶的任何數據資產。范圍可以從用于客戶計費流程的數據集到完全獨立的數據密集型應用，并有自己的用戶界面提供給客戶操作。

目前數據領域最熱門的趨勢之一是，公司在其SaaS產品中創建數據應用程序或添加額外層，以幫助客戶分析數據 ，就像前面提到的Toast公司一樣。

Snowflake有一個有用的列表，列出了五種常見類型的數據應用類型（完整的參考架構）：

• 客戶360：營銷或銷售自動化，需要對客戶關系有一個完整的看法。
• 物聯網：對來自物聯網設備和傳感器的大量時間序列數據進行近乎實時的分析。
• 應用健康和安全分析：通過分析大量的日志數據，識別潛在的安全威脅和監測應用程序的運行狀況。
• 機器學習（ML）和數據科學：訓練和部署機器學習模型，以構建預測性應用，如推薦引擎。
• 嵌入式分析：在應用程序中提供的品牌分析和可視化。

然而，外部數據產品不需要是完全內置的應用程序，也不需要集成在主要的SaaS產品中。例如，Monte Carlo公司的做法就不是這樣。

我們是一個數據密集型的SaaS應用，可以在用戶界面中進行監控、報警和提供線索。還可以在用戶界面中向客戶提供洞察力報告，并為他們提供選擇，使用Snowflake數據共享集成在他們自己的Snowflake環境中。

在后一種情況下，我們只是為客戶提供構件，使其能夠進一步定制他們想要的可視化方式或與其他數據相結合。

對什么是數據應用或外部數據產品有一個全面的認識是很重要的，因為這能促使團隊確保給予更高的嚴謹性，最好是在工程之外出錯。

下面這些問題很重要：

• 我們有哪些外部數據產品，它們有哪些類型？
• 他們在為誰服務？有哪些使用案例？
• 他們是否滿足這些期望？我們如何衡量呢？
• 我們是否擁有合適的工具和流程？

從后續五個維度評估外部數據產品也很重要。

架構

與內部產品一樣，外部數據產品可以利用各種數據云服務作為其平臺的基礎，包括數據湖或數據倉庫。

然而，許多人會利用像 Snowflake這樣的解決方案，因為它能優化大規模存儲和查詢關系型數據的方式。這可能是你的團隊第一次討論多租戶架構。在為外部客戶服務時，這是一個很大的變化和決策點。

當利用數據倉庫作為產品的基礎時，Snowflake描述了三種多租戶設計選項：

• 多租戶表：將租戶集中在單個共享對象中，使租戶能夠有效地共享計算和其他資源。
• 每個租戶的對象：將租戶隔離到同一賬戶中的單獨表、模式、數據庫和倉庫中。
• 每個租戶的賬戶：將租戶隔離到單獨的Snowflake賬戶中。

每個選項都有優點和缺點，但總的來說，選擇取決于什么需要更有效地伸縮—共享計算/存儲還是基于角色的數據訪問 。

大多數內部產品都是在同一公司交付的，要遵守同樣的公司內部政策和法規。例如，如果營銷團隊的數據資產與法律團隊的數據資產在同一個倉庫中，他們不會感到不安。但外部客戶可能會更關心。

當然，你可以在你的堆棧中做出其他的架構選擇來減輕這些權衡。例如，Monte Carlo利用Snowflake的MTT多租戶架構，使用行業的最佳實踐，如標記化，從邏輯上分離客戶數據。此外，我們使用一個混合架構，將數據收集器嵌入客戶的環境中（但通常不總是作為自己的虛擬私有云）。

這意味著數據永遠不會離開其環境。PII和敏感數據被抽象化，我們提取的是非敏感日志和評估其數據系統健康狀況所需的指標聚合。

架構決策過程的另一部分，類似于內部數據產品，是了解用例和工作負載。頻率、規模和所需的時間表是多少？客戶會在設定的時間接收數據、能夠按需查詢數據、實時訪問數據，還是三者兼而有之？正如我們之前提到的，了解工作負載對于做出具有成本效益的架構選擇非常有幫助。然而，與外部產品不同的是，可能有更多種類的用例需要支持。

在構建Monte Carlo時，我們不僅要考慮我們的關鍵任務生產的工作負載，還要考慮我們的內部團隊如何訪問這些面向外部的數據。在這種情況下，進行內部分析和數據科學研究，作為開發我們的機器學習驅動的異常監視器的一部分。

用戶期望

假設你有一個數據產品，你的用戶通常可以信任它來幫助回答他們的一些問題。數據每天都會刷新，儀表板有一些可點擊的元素，他們可以在其中深入了解詳細信息。

這對一些內部用戶來說可能已經足夠了。他們可以完成他們的工作，表現要比沒有儀表板時更好。另一方面，你的外部用戶卻很生氣。他們想信任你的產品，想讓它實時地回答他們所有的問題。

他們憑什么不該生氣呢？畢竟，他們是為你的產品買單的，他們本可以選擇競爭對手的產品。

當數據是產品時，數據質量就是產品質量。這個簡單的事實就是為什么一些最熱衷于采用我們的數據觀察型平臺的人正在利用它來支持他們的數據應用。例如，多渠道數字廣告供應商Choozle，在推出大規模平臺升級到一流的數據可靠性時，采用了數據觀察能力。

Choozle公司首席技術官亞當-伍茲說：“如果沒有這樣的工具，我們可能會對最終結果的表格進行監控，但這可能會隱藏很多問題。”你可能看不到與表格中成千上萬的廣告活動中的一小部分相關的內容，但運行該活動的廣告商將會看到它。有了[數據可觀察性]，我們就無需妥協。我們可以對所有的3500個表進行監測。

當數據面向客戶或為面向客戶的應用程序提供動力時，質量差甚至會損壞產品。例如，創建具有相同主鍵的重復對象的數據問題實際上導致了Netflix的中斷。

在規模和速度方面，外部客戶從不想等待數據，他們想要更多的數據維度，以便他們可以切分和拼接到他們心中的內容。例如，我們的一位金融服務客戶不僅關注數據新鮮度，還關注數據延遲，換句話說，即在支持查詢的同時近乎實時地加載和更新數據的能力。

Snowflake數據共享和Snowpipe可以幫助減少數據延遲。Blackboard通過使用Snowpipe連續加載數據并從S3批量加載，解決了他們的延遲挑戰，并使ETL工作負載的運行速度比以前快400倍。

縮放數據維度也有助于區分。再次以Choozle為例，根據Adam的升級平臺：Snowflake使我們能夠將所有信息提供給我們的用戶。例如，我們可以顯示前20個郵政編碼的廣告活動效果，現在廣告商可以根據需要訪問美國所有 30,000個郵政編碼的數據。

最后，在數據安全和隱私方面，你的外部數據產品可能不僅需要在理論上考慮 PII，還需要通過SOC II等行業標準來實際證明有效的安全控制。

投資回報率

絕大多數的數據團隊都沒有根據硬性的投資回報率進行評估。事實上，具有諷刺意味的是，在談到業績時，往往缺乏指標，據數據平臺產品管理總監布蘭登-貝德爾（Brandon Beidel）說，最初在Red Ventures就是這種情況。

下一層是衡量性能。系統性能如何？如果有很多問題，那么也許我們沒有以有效的方式構建我們的系統。或者，它可以告訴我們在哪里優化我們的時間和資源......擁有記錄也能使數據團隊的評估從“我覺得團隊做得好/做得不好”的感覺演變為更基于數據的內容。

內部數據產品也是如此。通常情況下，成績是臨時獲得的，“由于我們的新客戶數據平臺，我們的廣告支出回報率增加了3倍”，而不是根據生產成本或每位用戶的成本進行衡量。當你構建一個外部數據產品時，這種好運就消失了。產品經理需要了解如何定價，而且它必須是盈利的（在某些時候）。他們需要知道構建產品的啟動成本，以及每個組件在提供服務時的成本（商品成本）。

這對那些沒有為其數據產品構建內部收費模式的數據團隊來說是具有挑戰性的，這些模式可以根據使用規模對客戶進行區分、跟蹤和收費。

自助服務

“啊哈!”你說，“我們的團隊已經允許內部用戶使用自助服務，這不是什么新鮮事。”這可能是對的，但自助服務和可用性的門檻也提高了。

你的外部客戶不能隨時問你關于數據的問題，也不知道你是如何得出這個客戶的流失可能性是：“5張皺眉臉中的3.5張”。數據產品不能是一個黑盒子，你需要展示你的工作。

UI必須是直觀的，相關性必須是直接的，背景必須是明顯的。

迭代

當你構建你的內部數據產品時，在收集需求、構建和與業務涉眾迭代時，最初通常進展緩慢 。

在這之后，團隊往往會開始運行，進入下一個項目。會有一些補丁和修復，以應對數據停機，或者也許是為了滿足內部SLA，但總的來說，你不是每季度都在重構這些儀表盤。

如前所述，付費客戶有更高的期望，他們也有更多的反饋。但是，你需要知道它即將到來并為其構建。例如，Toast非常注重其流程的效率：Toast數據工程師Angie Delatorre說：“我們不僅傾聽業務需求，并大力支持它們，而且我們還在內部尋找并解決可擴展性問題。”如果一項工作過去需要一個小時，而現在需要三個小時，我們總是需要回去看看這些實例，所以這也影響了我們的OKR。

在擴展運營方面，Snowflake產品管理總監Chris Child建議：首先，以最高的保真度把你的所有數據放在一個地方。只要把原始數據放在那里。第二，想出可重復的管道，將數據提供給數據分析人員。你不希望每次你想做什么的時候都要回到原始數據。

前Uber數據產品經理Atul Gupte討論了迭代數據產品時了解它的重要性：如何劃分產品路線圖的優先級，以及需要為誰(通常是工程師)構建和設計(日常平臺用戶，包括分析師)。

出師

雖然這個博客讀起來像是一個你不應該構建外部數據產品的理由清單，但我希望它有助于揭開與這項艱巨但值得的努力相關的挑戰的神秘面紗。

你不會在第一個沖刺就構建起完美的外部數據應用程序（沒有人會這樣做），但我鼓勵你構建、運送、迭代、沖洗和重復。

原文鏈接：https://dzone.com/articles/why-building-an-external-data-product-is-so-hard

譯者介紹

翟珂，51CTO社區編輯，目前在杭州從事軟件研發工作，做過電商、征信等方面的系統，享受分享知識的過程，充實自己的生活。