活動主辦單位:Taiwan Data Science Meetup 台灣資料科學社群
大綱
講者:Brenda Kao | 資深資料工程經理 Senior Data Engineering Manager @ 美國 DoorDash
講者背景
目前任職於美國最大的食品外賣外送公司、總部位於舊金山的DoorDash,職稱是資深資料工程經理。在資料工程領域工作了十多年。亦有 application development(應用開發)、infrastructure automation(基礎設施自動化)、 data warehousing (資料倉儲)等領域的經驗,在資訊工程(IT)業總共擁有二十年以上的經驗。
組織架構方面:
2. 第二種架構則是會把 Data Analytics 和 Data Science 和產品端放在一起,Data Engineering 還是屬於 Engineering 範疇。主要是因為數據的匯集到應用依照產品而不同,且希望能用數據來能改進產品功能或性質。這種架構的缺點,以講者所經歷的 Data Engineering 來說,因為使用者屬於不同部門,有應用部門或其他第三方單位等,對口單位非常多,在溝通協調、(產品的或是數據之間的)依存關係會比較複雜。
3. 第三種架構則分得更細,把 Data Engineering 裡的 Data Infrastructure(資料基礎建設)以及 Data Integration(資料整合)分出來,讓 Data Engineering 能完全配合 Data Aanalytics 工作,效率和第一種公司的效率比較接近;資料工程師能主要專注在處理以及分析資料,不用分心在資料基礎建設,或是當有新的資料進來,花時間去建立新的數據管道(data pipeline)。
工作內容一般分成三種,分別為 Data Engineering(資料工程)、Data Analytics(資料分析)和Data Science(資料科學)。
主要負責建立和維持公司內資料取得、轉換、儲存的自動化作業(ETL,Extract-Transform-Load) 。主要是把資料放到平台中,整理後,讓使用者可以取用、分析。另外在發展較為成熟的公司,會同時包含 Data Catalog(資料目錄),Data Management(資料管理)和 Data Governance(資料治理)部分;在規模小的公司也需要支援 Data Infrastructure(資料基建)的部分。
註: ETL 為 Extract-Transform-Load 的縮寫,為資料獲取管道之一,用以收集不同來源的資料,並且根據商務規則轉換資料,然後將其載入至目的地資料存放區的過程。
主要是對資料進行分析和產生報告。
主要是分析並建立模型,也可能涵蓋資料拮取。當一個產品上線前,會同時與 Data Engineering 部門一起產品化(Productionize), 以便上線後有問題時可隨時支援,例如產品及架構標準化、SLA(Service Level Agreement)設定等,SLA 包括輸入及輸出資料的更新頻率、資料更新完成時限、產品在線時間及績效要求等等。
註:Poductionize 是將原型產品轉換為可以更輕鬆地大量生產的過程。SLA 為Service Level Agreement 的縮寫,中文可譯為服務級別協定,是服務提供商與客戶之間定義的正式承諾。
一般來說工作內容包含建立 Data Platform(資料平台), 把資料從各種不同的 Data Sources(數據源)匯入這個平台並加以整理,讓使用者可以直接在此平台上分析和建立資料模型,不用再轉換到其它平台來完成工作。
Data Platform 的建立包含很多組件及步驟,並不是說直接買一個公司系統或服務就能完成,或用了 Hadoop 的開源碼套裝組件就可以一步解決。需要的組件例如 Computing Engine(運算引擎)、Data Storage(資料儲存設置)、 Data access tools (資料使用的工具) 、Security control tools(安全控制的工具 )、Job scheduler 等等。有了這些組件,還要定義資料處理的流程,資料儲存的格式、架構、保留期限及安全限制,Data sets (資料集) 的整理及展示的架構, 使用者群組及權限等等。
Big Data 一般講的就是 Data Lake,除了可以存結構化資料 ,也就是所謂Relational database (關聯式資料庫)外,還可以存 Semi-Structured Data(半結構化資料,常見的有 CSV、LOGS、 XML 和 JSON) ,及 Unstructured Data(非結構化資料,常見的有 Emails、PDFs、Audios和 Videos)。
一般是存結構化資料,因為容量較小,所以平常常用的資料才會放在這裡。
ETL:為 Extract(抽取)- Transform(轉置)- Load(載入)的縮寫,也有人說成 ELT (Extract-Load-Transform),描述取得 Data、處理 Data 以及把Data 放到目標位置的過程。
Google Analytics可以蒐集使用者在網站的足跡,基本訊息如所拜訪過的網頁、拜訪時間、使用者所在地點等等。我們也可以在程序及 GTM(Google Tag Manager,也就是所謂 Google 代碼管理工具)上設定想要客製追蹤的訊息。
Analytics team、Data Science team 及Machine Learning 團隊可以在 Data Platform 上使用這些資料去完成工作。第六步把這些資料輸出到 Enterprise Warehouse,可以方便 Analytics team 使用自己熟悉的工具,像是 Power BI 或 Tableau。
一開始公司內都叫 Data engineer,工具也只有 Hadoop,要負責自己的Infrastructure,只有很大的公司才有團隊專職負責 Infrastructure 部分,小的新創公司多半都在 Cloud 上完成。
然而,最近幾年 Data Engineering 有愈分愈細趨勢,現在有 Machine Leaning Engineer 的出現,可以說是從 Data Scientist 分出來的,因為我們資料的使用者是 Data Scientist,就要有人來處理兩種工作之間的落差。
其它細化後的工作分配像是:前端 Data Ingestion Engineer 只負責拿資料進來,後端可能有 Analytics Engineer 專門服務 Analytics team 的需求,Data Infrastructure team 則負責 Platform 及支援 Infrastructure。
對應 ETL Pipleline 各流程的角色如下:
需要的技能:
課程方面:
練習題目方面:
做題目的時候,不是以解決題目為目標,而是要想自己能解決甚麼問題、怎麼解決。以及留意在查詢資料過程中得到的解答,哪些是沒有想到、哪些只差一個概念的。
Q1:想從Data science領域轉職Data Engineering, 要如何累積Data Engineering的實戰經驗/練功? 兩者的技能有什麼差別?
A1:
Data scientist 也需要會寫程式,很多公司的Data Engineering也用Python,兩者一般都要會寫程式。
Data scientist 的結果論不是很明確,主因Data scientist一直在試不同的東西,沒有著重於特定項目,而Data Engineering不一樣,其結果論很明確,目標是把資料搬到一個地方,或者整理資料(根據用途或者資料庫不同而整理)。
從Data science領域轉職Data Engineering的話,可以應用原本的程式能力,不過思維要改變,思考如何優化重複的事情。
舉個例子: 以ETL pipeline來看,今天公司有10個Application Database, 從Application Data拿data到data lake裡。有個order的database,也有個payment的database,這兩個是不同的來源,可思考我不用建兩個pipeline,可以建一個framework,之後可以再配置,只要改幾個參數,就可以了。Brenda提及想辦法自動化及簡化重複做的事,以及提高自動化過程的穩定度 是很重要的。此外,除了考慮程式之外,還要考慮產線,出問題時需要很快可以偵測到哪裡出問題。
Q2: Define schema 通常是Data Engineer主導還是Data Scientist主導?
A2: Schema的主導一般是以Source data為base,拿進data來後根據schema來設計 ,以ETL pipeline的第三個階段Data derivation及第四個階段Data aggregation來說,都會和 Analytics team 及 Data Science team討論,根據其用途來設計。雖然一般來說,大部分的人在開始做之前,都不確定自己要什麼;而Data Engineer因為處理過比較多Data set,會比較有經驗,可以扮演帶領角色,總的說沒有誰是絕對主導,多是互相討論出來的。
Q3:身為一個Data Scientist要怎麼幫助Data Engineer更容易了解Data Scientist需要什麼樣的data?
A3: Data scientist 有時會用一些Featured data(特徵化資料),與直接使用data的情形不太一樣。例如data有個值1234,1234只表示這些數據不同,並不是說數據之間有大小或其他關係,這個時候Data Scientist就需要讓Data Engineer知道,如何把這1234標成Featured data set(特徵化資料集)。
Q4:請問DoorDash在ETL方面的使用場景為何?
A4:DoorDash把Data Ingestion、Data Infrastructure跟Data Engineering處理的過程分開,像Brenda現在的team要改schema都要透過Infrastructure team,她覺得好處是經過很多次Review,不會有人不小心改壞了等疏失,而壞處是turnaround的時間很長。根據觀察,DoorDash看起來像是大部分的資料使用都是直接使用從資料源 ingested 的 raw data;很多報告都是直接向這層資料下指令產出的 (query against this source)。
Q5:有什麼特殊的挑戰或特別的難題需要解決的?
A5:我的team是直接支援財務分析及會計,我們希望能有自己的ETL,也能按自己的方式來定義及整理這些data set,不需要和別的單位共用,這是目前的挑戰。不同的team面對的挑戰應該不同,有人專門做event 或experiment分析,也有人專門做merchant或subscription,不同的domain都有不同的組負責。
Q1:想問大部分公司 data engineering / data analytics 跟 data scientist 的人數比例?
A1:沒有一定的比例,就我的經驗,以人數來看,大致上 data analytics > data engineering > data science ,也有 data analytics > data science > data engineering。
Q2:請問在 versioning data 方面的經驗:使用什麼工具?在什麼情況下最好要做好 data versioning?
A2:目前使用 GitHub。只要 production use 的 code 都應該要做 versioning control。用途很多,像是備份、考古、提供審計資料、控制 in production 的 version等等。
Q3:請問 data-warehouse 可以理解成,把處理過的 report metrics 再塞回資料庫嗎?
A3:不是。data warehouse 是把不同來源的資料匯集、整合、整理成需要用的資料集。 可用作 report metrics 的資料源,但未必是唯一用途。
Q4:請問 DoorDash 會提供工作簽證嗎?謝謝!
A4:會的。
Q5:在 pipeline 的過程中,資料會重複很多次,資料數量也倍數增加。在資料量的管理上會不會是一個挑戰?
A5:是很大的挑戰,對於資料本身的瞭解及其應用需求有所掌握才能夠設計出有效率的 pipeline,避免重複儲存、重複計算以節省時間及金錢成本。
Q6:請問具備什麼個性或人格特質的人,比較適合當 Data Engineer 呢?
A6:細心、有條理、有好奇心、喜歡探索、不怕挑戰、愛好解決問題、精益求精。
Q7:Doordash 接受不在美國上班的遠距工作嗎?
A7:DoorDash 有很多國際據點,包括日本、德國、澳洲、加拿大等等,至於能不能長期遠端工作,由部門主管決定。目前公司政策是到今年年底前都可以在家上班。
Q8:如果有不同 schema,想轉成一個統一的schema,技術上、溝通上與實際 ETL 時有什麼建議?
A8:如果在上游的 scheme 設計時就可以考慮資料在 data warehouse 及 data lake 如何使用,而不單就 app 方面考慮的話,維護 pipeline會比較容易。但現實中經常脫勾,建議是處理原始資料時,維持和來源相同的schema(For raw data ingestion keep the schema as-is from the source),在 pipeline 的下一個階段再轉換成統一的 schema,則使用者在 data platform 上就可以使用統一的 schema。
Q9:請問 Analytics engineer 和 BI engineer 具體是做什麼呢?
A9:建立及維護數據處理流程(Build and maintain ETL pipelines),支援報告系統(Support reporting system)、分析數據及報告(Data analysis and reporting)。
筆手:Danielle Wu、Mark Wang
校稿:Brenda Kao
👉 歡迎加入台灣資料科學社群,有豐富的新知分享以及最新活動資訊喔!
Copyright 2020-2024 資料科學協會 All Rights Reserved.
本網站由 資料科學協會 維護