介紹
在「快速變化的數據和人工智慧世界」中，了解數據和人工智慧的架構變得非常重要。然而，許多領導者往往忽略了數據團隊結構的重要性。
雖然許多人可能認為自己是數據團隊的一部分，但大多數人並不知道這種想法有多麼限制。
事實上，不同的團隊結構和技能需求會顯著影響組織實際使用數據和人工智慧來推動有意義的結果的能力。為了理解這一點，想像一個比喻會很有幫助。
想像一個兩口之家。約翰（John）在家工作，而簡（Jane）則去辦公室。簡依賴約翰處理很多家庭事務，因為他大部分時間都在家，這樣做會容易得多。
簡和約翰有孩子，當孩子們長大一點後，約翰需要做的事務翻倍！幸運的是，孩子們已經學會了基本的家務；他們可以洗碗、整理，甚至在一些催促下偶爾吸塵。
隨著孩子們長大，約翰的父母搬進來了。他們年紀大了，所以約翰照顧他們，但幸運的是，孩子們基本上已經能自理了。隨著時間的推移，約翰的角色發生了很大的變化！但他始終讓這個家庭保持快樂，這要歸功於約翰和簡。
回到數據上——約翰有點像數據團隊，而其他人則是領域專家。他們以不同的方式依賴約翰。這種情況隨著時間的推移發生了很大的變化，如果沒有這種變化，可能會造成災難。
在接下來的文章中，我們將探討約翰從集中式團隊到樞紐式團隊，再到平台網狀數據團隊的旅程。
集中式團隊
一個集中式團隊負責很多事情，這些事情對你來說應該很熟悉：
- 核心數據平台和架構：用於促進數據和人工智慧工作負載的框架和工具。
- 數據和人工智慧工程：集中和清理數據集；為人工智慧工作負載結構化非結構化數據。
- 商業智慧（BI）：建立儀表板以可視化見解。
- 人工智慧（AI）和機器學習（ML）：在上述清理過的數據上訓練和部署模型。
- 倡導數據的價值並培訓人們了解如何使用商業智慧工具。
這對少數人來說是一項艱巨的工作！事實上，幾乎不可能一次性完成所有這些工作。最好保持小而可管理，專注於幾個關鍵用例，並利用強大的工具早早取得進展。
你甚至可以請一個保姆或幫手來幫忙（在這種情況下——顧問）。
但這種模式有缺陷。很容易陷入孤島陷阱，這是一種情況，集中式團隊成為數據和人工智慧請求的巨大瓶頸。數據團隊還需要從領域專家那裡獲取領域知識，以有效回答請求，這也需要時間，並且很困難。
一種解決辦法是擴大團隊。更多的人意味著更多的產出。然而，還有更現代的方法可以讓事情進展得更快。
但約翰只有一個。他能做什麼呢？
部分去中心化或樞紐式
部分去中心化的設置對於中型組織或小型技術驅動的組織來說是一個有吸引力的模型，因為這些組織在數據團隊之外擁有技術技能。
最簡單的形式是數據團隊維護商業智慧基礎設施，但不負責內容本身。這留給「權力使用者」，他們自己動手建立商業智慧。
當然，這會遇到各種問題，例如孤島陷阱、數據發現、治理和混淆。當被告知要自助服務的人因缺乏對數據的理解而嘗試失敗時，混淆特別痛苦。
一種越來越受歡迎的方法是開放堆棧的額外層次。分析工程師的崛起和數據分析師越來越多地承擔更多責任，包括使用工具、進行數據建模、建立端到端管道，並向業務倡導。
這在實施不當時會導致巨大的問題。你不會讓你五歲的兒子照顧你的長輩和無人看管的房子。
具體來說，缺乏基本的數據建模原則和數據倉庫引擎會導致模型擴散和成本飆升。有兩個經典的例子。
一個例子是當多個人試圖定義相同的事物，例如收入。市場營銷、財務和產品部門都有不同的版本。這會導致在季度業務回顧時不可避免的爭論，因為每個部門報告的數字不同——分析癱瘓。
另一個例子是滾動計數。假設財務部門想要本月的收入，但產品部門想知道七天的滾動收入。「這很簡單，」分析師說。「我只需創建一些包含這些指標的物化視圖。」
正如任何數據工程師所知，這種滾動計數操作相當昂貴，特別是如果需要按天或小時進行細分，因為那樣你需要一個日曆來「展開」模型。你會發現有滾動_30天_銷售、滾動_7天_銷售、滾動_45天_銷售等等。這些模型的成本遠超過所需的。
簡單地要求最低所需的細分（每日），將其物化，並在下游創建視圖可以解決這個問題，但需要一些中央資源。
早期的樞紐式模型必須有明確的責任劃分，特別是當數據團隊外的知識還很年輕或不成熟時。
隨著團隊的成長，像 Apache Airflow 這樣的舊代碼框架也會帶來問題：缺乏可見性。希望了解發生了什麼的人將依賴額外的工具來理解端到端的過程，因為舊版用戶界面不會從不同來源聚合元數據。
必須將這些信息呈現給領域專家。你有多少次被告知「數據看起來不對」，卻在手動追蹤一切後才意識到問題出在數據生產者那一邊？
通過增加可見性，領域專家可以直接與數據或流程的擁有者聯繫，這樣可以更快地修復問題。這樣可以減少不必要的負擔、上下文切換和數據團隊的請求。
純樞紐式
純樞紐式就像將你的青少年孩子委派具體責任並設置清晰的界限。你不僅僅是給他們一些任務，比如倒垃圾和清理房間——你會告訴他們你想要什麼，比如「乾淨整潔的房間」，然後你信任他們去完成。激勵在這裡效果很好。
在純樞紐式方法中，數據團隊管理平台並讓其他人使用它。他們建立用於構建和部署人工智慧和數據管道的框架，並管理訪問控制。
領域專家如果需要，可以端到端地構建東西。這意味著他們可以移動數據、建模、協調管道，並根據需要啟用人工智慧或儀表板。
通常，中央團隊也會做一些這樣的事情。當跨領域的數據模型複雜且重疊時，他們幾乎總是應該負責提供核心數據模型。尾巴不應該搖動狗。
這開始類似於數據產品的思維方式——雖然財務團隊可以負責投資和清理 ERP 數據，但中央團隊則擁有重要的數據產品，例如客戶表或發票表。
這種結構非常強大，因為它非常協作。通常，只有當領域團隊具有相當高的技術能力時，這種模式才會有效。
這裡建議使用允許代碼和無代碼一起使用的平台，否則對中央團隊的強技術依賴將始終存在。
這種模式的另一個特徵是培訓和支持。中央團隊或樞紐會花一些時間支持和提升樞紐的技能，以便在界限內高效地構建人工智慧和數據工作流。
再次強調，使用舊的協調框架提供可見性是困難的。中央團隊將承擔保持元數據存儲最新的負擔，例如數據目錄，以便業務用戶可以理解發生了什麼。
另一種選擇是提升領域專家的 Python 專業知識，學習具有陡峭學習曲線的框架，這更難以實現。
平台網狀/數據產品
我們理論上家庭旅程的自然終點是受到廣泛批評的數據網狀或平台網狀方法。
在這個家庭中，每個人都被期望知道自己的責任。孩子們都長大了，可以信賴他們保持家庭秩序並照顧家庭成員。大家密切合作，無縫協作。
聽起來很理想，不是嗎！？
但在實踐中，這種情況很少如此簡單。允許衛星團隊使用自己的基礎設施並隨意構建東西是失去控制和拖慢進度的可靠方法。
即使你試圖在團隊之間標準化工具，最佳實踐仍然會受到影響。
我與許多大型組織（如零售連鎖店或航空公司）的團隊交談過，避免網狀結構不是選擇，因為多個業務部門相互依賴。
這些團隊使用不同的工具。有些利用 Airflow 實例和幾年前顧問建立的舊框架。其他人則使用最新技術和一整套臃腫的現代數據堆棧。
他們都面臨著相同的問題；協作、溝通和協調不同團隊之間的流程。
在這裡實施一個統一的平台來構建數據和人工智慧工作流可以有所幫助。一個統一的控制平面幾乎就像協調者的協調者，聚合來自不同地方的元數據，顯示跨領域的端到端血統。
這自然形成了一個有效的控制平面，任何人都可以聚集在一起調試失敗的管道、進行溝通和恢復——所有這些都不依賴於中央數據工程團隊，否則他們將成為瓶頸。
在軟體工程中有明確的類比。通常，代碼會生成日誌，這些日誌由單一工具（如 DataDog）彙總。這些平台提供一個單一的地方來查看所有發生的事情（或未發生的事情）、警報和事件解決的協作。
總結
組織就像家庭。儘管我們喜歡一個大家庭的想法，但通常有一些責任需要承擔，以便一開始能夠運作。
隨著他們的成熟，成員們變得更接近獨立，就像約翰的孩子們一樣。其他人則找到自己的位置，成為依賴但忠誠的利益相關者，就像約翰的父母。
組織也不例外。數據團隊正從集中式團隊中的執行者轉變為樞紐式架構中的促進者。最終，大多數組織將擁有數十甚至數百人，在自己的樞紐中開創數據和人工智慧工作流。
一旦這發生，數據和人工智慧在小型靈活組織中的使用方式可能會類似於更大型企業的複雜性，因為不同團隊之間的協作和協調是不可避免的。
了解組織在這些模式中的位置是至關重要的。試圖將數據作為產品的思維強加於一家不成熟的公司，或在一家大型成熟的組織中堅持大型中央團隊都會導致災難。
祝你好運 🍀
本文由 AI 台灣 運用 AI 技術編撰，內容僅供參考，請自行核實相關資訊。
歡迎加入我們的 AI TAIWAN 台灣人工智慧中心 FB 社團，
隨時掌握最新 AI 動態與實用資訊！
