幫助數據科學家更好地理解架構圖
> Photo by Jared Murray on Unsplash
介紹
在使用數據獲取業務價值的公司中，盡管您可能不會一直以數據科學技能為榮，但始終可以很好地管理數據基礎架構。 每個人都希望將數據存儲在可訪問的位置，妥善清理並定期更新。
在這些低調但穩定的需求的支持下，數據架構師的薪水與數據科學家的薪資同樣高，甚至更高。 實際上，根據PayScale進行的薪酬研究（https://www.payscale.com/research/US/Country=United_States/Salary），美國數據架構師的平均工資為121,816美元，而數據科學家的平均工資為96,089美元 。
並不是說所有數據科學家都應該換工作，至少了解數據架構的基礎知識對我們會有很多好處。 實際上，有一個簡單（但有意義）的框架可以幫助您了解各種現實世界的數據體系結構。
目錄
· 數據架構中的三個組件：Data Lake-> Data Warehouse-> Data Mart
· 每個組件中使用的工具
· 案例研究—構建從BigQuery（數據倉庫）到Google Sheets（數據集市）的計划和自動數據饋送
· 尾注
數據架構中的三個組件：Data Lake-> Data Warehouse-> Data Mart
"數據湖"，"數據倉庫"和"數據集市"是數據平台體系結構中的典型組件。 按照此順序，將處理業務中產生的數據並將其設置為創建另一個數據含義。
> Diagram the author crafted using materials from Irasuto-ya (https://www.irasutoya.com/)
三個組件負責三種不同的功能，例如：
· Data Lake：擁有業務中產生的數據的原始副本。 如果有的話，原始數據的處理應該最少。 否則，如果最終發現某些數據處理錯誤，將無法追溯修復該錯誤。
· 數據倉庫：保存由托管數據模型處理和結構化的數據，反映最終使用數據的全局（非特定）方向。 在許多情況下，數據采用表格格式。
· 數據集市：保存一個子部分和/或匯總的數據集，以使用特定的業務功能，例如 特定業務部門或特定地理區域。 一個典型的例子是，當我們准備針對特定業務線的KPI摘要時，然后在BI工具中進行可視化。 特別是，當用戶希望定期並頻繁地更新數據集市時，在倉庫之后准備這種獨立的組件是值得的。 相反，如果用戶只希望某些數據組進行一次即席分析，則可以跳過此部分。
> Summary of three data architecture components (exhibit created by author)
有關除僅裸機描述之外的更多實際示例，請使用Google搜索"數據架構"以查找大量數據架構圖。
> What you see when you image-google with "data architecture". (Image captured by author)
為什么我們需要分為這三個部分？
因為過程中的不同階段有不同的要求。
在數據湖階段，我們希望數據接近原始數據，而數據倉庫的目的是通過清晰的維護計划使數據集更結構化，可管理並擁有明確的所有權。 在數據倉庫中，我們還希望數據庫類型面向分析而不是面向事務。 另一方面，數據集市應該可以方便地訪問可能使用數據旅程最終輸出的非技術人員。
不同用途的系統組件往往在不同的時間進行重新設計。 然后，配置松散連接的組件在將來的維護和擴大規模方面具有優勢。
數據工程師和數據科學家如何處理這三個組成部分？
粗略地說，數據工程師涵蓋了從業務中提取的數據到數據湖，在數據倉庫中建立數據模型以及建立ETL管道的過程。 而數據科學家則負責從數據倉庫中提取數據，構建數據集市，並導致進一步的業務應用和價值創造。
當然，數據工程師和數據科學家之間的這種角色分配有些理想，並且許多公司都不只是為了符合這個定義而聘用這兩個人。 實際上，他們的職務描述往往會重疊。
三要素法之外的新趨勢
最后但並非最不重要的一點是，值得注意的是，這種由三部分組成的方法是存在超過二十年的傳統方法，並且新技術一直在不斷出現。 例如，"數據虛擬化"是一種允許針對數據源的一站式數據管理和操作界面的想法，而不管其格式和物理位置如何。
每個組件中使用的工具
現在，我們了解了三個數據平台組件的概念。 然后，人們使用什么工具？ 根據此"數據平台指南"（日語），這里有一些想法：
數據湖/倉庫
數據湖和數據倉庫有以下選項。
> Author crafted based on the "Data Platform Guide" (in Japanese)
ETL工具
ETL發生在數據到達數據湖並進行處理以適合數據倉庫的地方。 數據是實時到達的，因此ETL更喜歡事件驅動的消息傳遞工具。
> Author crafted based on the "Data Platform Guide" (in Japanese)
工作流程引擎
工作流引擎用於管理數據的整體流水線化，例如，通過流程圖可視化流程在何處進行，在出現錯誤的情況下觸發自動重試等。
> Author crafted based on the "Data Platform Guide" (in Japanese)
數據集市/ BI工具
以下工具可用作數據集市和/或BI解決方案。選擇將取決於業務背景，貴公司熟悉哪些工具（例如，您是Tableau人員還是Power BI人員？），聚合數據的大小（例如，如果數據大小很小，為什么基本不解決方案，例如Excel或Google Sheets等解決方案是否達到了目標？），您使用什么數據倉庫解決方案（例如，如果您的數據倉庫位於BigQuery上，則Google DataStudio是一個簡單的解決方案，因為它在Google圈子中具有自然的聯系），等等。
> Author crafted based on the "Data Platform Guide" (in Japanese)
案例研究—構建從BigQuery（數據倉庫）到Google Sheets（數據集市）的計划和自動數據饋送
當數據大小保持在數十兆字節左右或小於數十兆字節並且不依賴於其他大型數據集時，可以堅持使用基於電子表格的工具來存儲，處理和可視化數據，因為它的成本更低，而且每個人 可以使用它。
一旦數據變大並開始與其他數據表具有數據依存關系，從雲存儲作為一站式數據倉庫開始是有益的。 （當數據變得更大到數十兆字節時，使用本地解決方案可以提高成本效益和可管理性。）
在本章中，我將演示一種將數據作為數據倉庫存儲在Google BigQuery中的情況。 BigQuery數據可以實時或短時間處理和存儲。 最終用戶仍然希望在高度匯總的基礎上在電子表格中查看每日KPI。 這意味着數據集市可能很小，甚至適合電子表格解決方案。 讓我們在這里使用Google表格，而不是Excel，因為它可以與BigQuery中的數據源處於同一環境中。 哦，順便說一句，不要考慮每天手動運行查詢。 嘗試找到一種解決方案，使所有內容自動運行，而無需您采取任何措施。
> Data pipeline in case study (diagram created by author using materials from Irasuto-ya (https://ww
本案例研究中使用的數據
在本案例研究中，我將使用一個樣本表數據，該數據具有每次乘車紐約出租車乘客的記錄，包括以下數據字段：
· 車號
· 驅動程序ID
· 乘車日期
· 乘客人數
· 車費金額
· 等等
樣本數據作為數據倉庫存儲在BigQuery中。
Google表格可以從BigQuery表中提取數據嗎？
從技術上講是可以的，但是目前只能通過Connected Sheets使用，並且您需要一個G Suite Enterprise，Enterprise for Education或G Suite Enterprise Essentials帳戶。
> Diagram created by author.
Connected Sheets允許用戶操作BigQuery表數據，就像在電子表格上播放它們一樣。 請參閱本頁面" BenCollins"博客文章上的GIF演示。
> Example of the use of Google Sheets connected to BigQuery through Connected Sheets (Captured by au
連接工作表還允許自動調度和刷新工作表，這是數據集市的自然需求。
盡管它證明自己是一個不錯的選擇，但一個可能的問題是，欠缺G Suite帳戶並不常見。
有關設置的更多詳細信息，請參閱" BenCollins"中的此博客文章。
我們該怎么做才能將數據從BigQuery推送到Google表格？
要從BigQuery提取數據並將其推送到Google表格，僅靠BigQuery是不夠的，我們需要服務器功能的幫助來調用API以將查詢發布到BigQuery，接收數據並將其傳遞給Google表格。
> Diagram created by author.
服務器功能可以位於GCP外部或內部的服務器計算機上（例如，GCP上的" Compute Engine"實例；或AWS上的" EC2"實例）。 可以使用unix-cron作業計划代碼運行。 但是這里的一個缺點是，它花費了實例的維護工作和成本，並且對於一個小的程序而言，太多了。
" Google Cloud Functions"是所謂的"無服務器"解決方案，用於在不啟動服務器計算機的情況下運行代碼。 將代碼放入Cloud Functions並設置觸發事件（例如，在本案例研究中為預定時間，但也可以是某些互聯網用戶的HTML請求），GCP會自動管理代碼的運行。
我的案例研究中的設置
使用紐約出租車數據配置我的案例研究有兩個步驟。
步驟1：設置計划-設置Cloud Scheduler和Pub / Sub以觸發Cloud Function。
在這里，"發布/訂閱"是一項消息服務，將由Cloud Functions訂閱，並在每天的特定時間觸發其運行。 " Cloud Scheduler"是一種功能，它可以根據unix-cron格式以用戶定義的頻率啟動某些程序。 結合這兩者，我們可以創建常規消息以供Cloud Function訂閱。 有關如何執行的信息，請參見此官方說明。 這是我的GCP設置中的屏幕截圖。
> Set up in Cloud Scheduler (Captured by author)
> Set up in Pub/Sub (Captured by author)
第2步：設置代碼-在Cloud Functions上准備代碼以查詢BigQuery表並將其推送到Google表格。
下一步是設置雲功能。 在Cloud Functions中，您定義1）觸發器是什么（在本案例研究中，是從Pub / Sub發送的" cron-topic"，鏈接到Cloud Scheduler，該觸發器每隔早上6點拉動觸發器），並且2）代碼是 要在檢測到觸發器時運行。
有關更多詳細信息，請參見此官方說明，以下是我設置的屏幕截圖。
> Set up in Cloud Functions (Captured by author)
> Code input in Cloud Functions — here you can also set requirements.txt to use installable librari
要運行的代碼必須包含在一個您喜歡的函數中（在我的情況下為" nytaxi_pubsub"。）代碼內容包括兩部分：第一部分：在BigQuery上運行查詢以將原始BigQuery表簡化為KPI並保存 它作為BigQuery中的另一個數據表，並使其成為Pandas數據框架，第2部分將數據框架推入Sheets。
這是我實際使用的代碼。 重要的是，只要BigQuery與Cloud Function位於同一GCP項目中，它就會自動進行身份驗證（請參閱此頁面以獲取說明。）但是，對於Google表格而言，情況並非如此，它至少需要一個過程來共享 服務帳戶訪問目標表。 有關更多詳細信息，請參見gspread庫中的描述。
Google表格上的最終數據集市
最后，我在Google表格中獲得了匯總數據，如下所示：
> Automatically updated data mart after a long journey of the setup. (captured by author)
該表每天早晨自動更新，並且數據倉庫正在通過ETL從數據湖接收新數據時，我們可以每天第一天輕松地跟蹤NY出租車KPI。
尾注
在一家雇用數據工程師和/或數據架構師以及數據科學家的大公司中，數據科學家的主要作用不一定是准備數據基礎架構並將其部署到位，但是至少了解數據架構要點將是有益的 很了解我們在日常工作中的立場。
Data Lake-> Data Warehouse-> Data Mart是一個典型的平台框架，用於處理從源到用例的數據。 將過程分為三個系統組件對於維護和目標性有很多好處。
工具的選擇有很多選擇。 應根據數據環境（大小，類型等）和業務目標明智地選擇它們。