大數據與小數據測試器:趨勢、理論、我的故事

大家好,我叫 Alexander,是一名資料品質工程師,負責檢查資料的品質。 這篇文章將討論我是如何想到這一點的,以及為什麼在 2020 年這個測試領域正處於浪潮的頂峰。

大數據與小數據測試器:趨勢、理論、我的故事

全球趨勢

當今世界正在經歷另一場科技革命,其中一個面向就是各類公司利用累積的數據來推動自己的銷售、利潤和公關飛輪。 似乎良好(品質)數據的存在,以及可以從中賺錢的熟練大腦(正確處理、視覺化、建立機器學習模型等),已成為當今許多人成功的關鍵。 如果說 15-20 年前,大公司主要從事資料累積和貨幣化的密集工作,那麼今天幾乎所有理智的人都面臨這種情況。

在這方面,幾年前,世界各地所有致力於求職的入口網站都開始填補資料科學家的職缺,因為每個人都確信,僱用了這樣的專家,就有可能建立機器學習的超級模型,預測未來,為公司實現「質的飛躍」。 隨著時間的推移,人們意識到這種方法幾乎在任何地方都行不通,因為並非所有落入此類專家手中的資料都適合訓練模型。

來自數據科學家的請求開始:“讓我們從這些和那些中購買更多數據......”,“我們沒有足夠的數據......”,“我們需要更多的數據,最好是高品質的......」 。 基於這些請求,擁有一組或另一組資料的公司之間開始建立大量的互動。 當然,這需要這個過程的技術組織——連接到數據源、下載數據、檢查數據是否已完全加載等等。此類過程的數量開始增長,今天我們非常需要另一種專家- 數據質量工程師- 監視系統中的資料流(資料管道)、輸入和輸出的資料質量,並就其充分性、完整性和其他特徵得出結論的人員。

資料品質工程師的趨勢來自美國,在資本主義的洶湧時代,沒有人準備在資料之戰中失敗。 下面我提供了美國兩個最受歡迎的求職網站的螢幕截圖: www.monster.com и www.dice.com — 顯示截至 17 年 2020 月 XNUMX 日使用以下關鍵字收到的已發布職缺數量的資料:資料品質和資料科學家。

www.monster.com

資料科學家 – 21416 個職缺
資料品質 – 41104 個職缺

大數據與小數據測試器:趨勢、理論、我的故事
大數據與小數據測試器:趨勢、理論、我的故事

www.dice.com

資料科學家 – 404 個職缺
資料品質 – 2020 年職缺

大數據與小數據測試器:趨勢、理論、我的故事
大數據與小數據測試器:趨勢、理論、我的故事

顯然,這些職業之間絕不存在競爭。 我只是想用截圖來說明勞動市場對資料品質工程師的需求現狀,現在對資料品質工程師的需求比資料科學家多得多。

2019 年 XNUMX 月,EPAM 回應現代 IT 市場的需求,將資料品質分離為單獨的實踐。 數據品質工程師在日常工作過程中管理數據,檢查其在新條件和系統中的行為,監控數據的相關性、充分性和相關性。 儘管如此,從實際意義上講,資料品質工程師實際上很少花時間進行經典功能測試, 這很大程度上取決於項目(我將在下面舉一個例子)。

資料品質工程師的職責不僅限於對資料庫表中的「空值、計數和總和」進行例行手動/自動檢查,還需要深入了解客戶的業務需求,並相應地將可用資料轉換為有用的商業資訊。

數據品質理論

大數據與小數據測試器:趨勢、理論、我的故事

為了更全面地想像這樣一個工程師的角色,讓我們弄清楚理論上的資料品質是什麼。

數據質量 — 資料管理的階段之一(我們將留給您自己研究的整個世界),負責根據以下標準分析資料:

大數據與小數據測試器:趨勢、理論、我的故事
我認為沒有必要破解每一個點(理論上它們被稱為“數據維度”),它們在圖中描述得很好。 但測試過程本身並不意味著嚴格地將這些功能複製到測試案例中並檢查它們。 在資料品質中,與任何其他類型的測試一樣,首先有必要建立在與做出業務決策的專案參與者商定的資料品質要求的基礎上。

根據資料品質專案的不同,工程師可以執行不同的職能:從對資料品質進行膚淺評估的普通自動化測試人員,到根據上述標準對資料進行深入剖析的人員。

關於資料管理、資料品質和相關流程的非常詳細的描述在名為 “DAMA-DMBOK:資料管理知識體系:第二版”。 我強烈推薦這本書作為該主題的介紹(您將在文章末尾找到該主題的連結)。

我的歷史

在 IT 產業,我從產品公司的初級測試員一路晉升為 EPAM 的首席資料品質工程師。 經過大約兩年的測試員工作後,我堅信我已經完成了絕對所有類型的測試:回歸、功能、壓力、穩定性、安全性、UI 等 - 並嘗試了大量的測試工具,同時使用三種編程語言:Java、Scala、Python。

回顧過去,我明白為什麼我的技能如此多樣化——我參與了大大小小的數據驅動專案。 這讓我進入了一個充滿許多工具和成長機會的世界。

要了解獲得新知識和技能的各種工具和機會,只需查看下圖,其中顯示了「數據與人工智慧」世界中最受歡迎的工具和機會。

大數據與小數據測試器:趨勢、理論、我的故事
這類插圖每年由著名創投家之一馬特·圖爾克(Matt Turck)編寫,他出身於軟體開發行業。 這裡 鏈接 到他的博客和 創投公司,他在那裡擔任合夥人。

當我是專案中唯一的測試人員時,或至少在專案開始時,我的專業成長尤其快。 就是在這樣的時刻,你要對整個測試過程負責,你沒有退路的機會,只有前進。 起初這很可怕,但現在這種測試的所有優點對我來說都是顯而易見的:

  • 您開始以前所未有的方式與整個團隊進行溝通,因為沒有溝通代理人:既沒有測試經理也沒有其他測試人員。
  • 對專案的沉浸感變得異常深入,並且您可以獲得有關所有組件的一般資訊和詳細資訊。
  • 開發人員不會將你視為“那個不知道自己在做什麼的測試人員”,而是將你視為一個平等的人,通過他的自動化測試和對出現在特定組件中的錯誤的預期,為團隊帶來了令人難以置信的好處。產品。
  • 因此,您會變得更有效率、更合格且更受歡迎。

隨著專案的發展,在 100% 的情況下,我成為了新測試人員的導師,教導他們並傳授我自己學到的知識。 同時,根據專案的不同,我並不總是從管理層獲得最高水準的自動測試專家,並且需要對他們進行自動化培訓(對於有興趣的人)或創建在日常活動中使用的工具(工具)用於產生資料並將其加載到系統中的工具,“快速”執行負載測試/穩定性測試的工具等)。

具體項目範例

不幸的是,由於保密義務,我無法詳細談論我所從事的項目,但我將舉例說明資料品質工程師在其中一個專案中的典型任務。

該專案的本質是實現一個為基於它的訓練機器學習模型準備資料的平台。 客戶是一家來自美國的大型製藥公司。 從技術上講,它是一個集群 Kubernetes,上升到 AWS EC2 實例,具有多個微服務和 EPAM 的底層開源專案 - 軍團,適應特定客戶的需求(現在該專案已重生為 奧達胡)。 ETL 流程是使用以下方式組織的 阿帕奇氣流 並將數據從 SalesForce公司 客戶系統在 AWS S3 水桶。 接下來,將機器學習模型的 Docker 映像部署到平台上,該模型接受新資料的訓練,並使用 REST API 介面產生業務感興趣的預測並解決特定問題。

從視覺上看,一切看起來都是這樣的:

大數據與小數據測試器:趨勢、理論、我的故事
該專案進行了大量的功能測試,考慮到功能開發的速度以及保持發布週期節奏(兩週衝刺)的需要,有必要立即考慮對最關鍵組件進行自動化測試系統。 大多數基於 Kubernetes 的平臺本身都包含在以下實作的自動測試中: 機器人框架 + Python,但也有必要支援和擴展它們。 此外,為了方便客戶,還創建了一個 GUI 來管理部署到叢集的機器學習模型,以及指定需要傳輸資料以訓練模型的位置和位置的能力。 這種廣泛的添加需要擴展自動化功能測試,這主要是透過 REST API 呼叫和少量端到端 UI 測試來完成的。 在所有這些運動的赤道周圍,我們加入了一位手動測試員,他在產品版本的驗收測試以及與客戶就下一個版本的驗收進行溝通方面做得非常出色。 此外,由於新專家的到來,我們能夠記錄我們的工作並添加一些非常重要的手動檢查,這些檢查很難立即自動化。

最後,在我們實現平台和 GUI 插件的穩定性後,我們開始使用 Apache Airflow DAG 建立 ETL 管道。 透過編寫特殊的 Airflow DAG 來執行自動資料品質檢查,該 DAG 根據 ETL 過程的結果檢查資料。 作為該專案的一部分,我們很幸運,客戶允許我們存取我們測試的匿名資料集。 我們逐行檢查資料是否符合類型、是否有損壞的資料、前後的記錄總數、聚合 ETL 過程進行的轉換的比較、更改列名稱等。 此外,這些檢查還擴展到不同的資料來源,例如,除了 SalesForce 之外,還擴展到 MySQL。

最終資料品質檢查已在 S3 層級進行,資料儲存在其中並可隨時用於訓練機器學習模型。 為了從 S3 儲存桶上的最終 CSV 檔案獲取資料並驗證它,使用以下程式碼編寫了程式碼 boto3 用戶端.

客戶還要求將部分資料儲存在一個 S3 儲存桶中,並將部分資料儲存在另一個 SXNUMX 儲存桶中。 這還需要編寫額外的檢查來檢查此類排序的可靠性。

其他項目的一般經驗

資料品質工程師最常見的活動清單範例:

  • 透過自動化工具準備測試資料(有效無效大小)。
  • 將準備好的資料集上傳到原始來源並檢查是否可以使用。
  • 啟動 ETL 進程,使用一組特定設定(如果可能,為 ETL 任務設定可設定參數)處理從來源儲存到最終或中間儲存的一組資料。
  • 驗證 ETL 流程處理的資料的品質以及是否符合業務要求。

同時,檢查的主要重點不應僅在於系統中的資料流原則上已工作並完成(這是功能測試的一部分),而應主要檢查和驗證資料符合預期要求、識別異常等。

工具

這種資料控制的技術之一可以是在資料處理的每個階段組織鍊式檢查,即文獻中所謂的「資料鏈」——對資料從源頭到最終使用點的控制。 這些類型的檢查通常透過編寫檢查 SQL 查詢來實現。 顯然,此類查詢應盡可能輕量級,並檢查各個資料品質(表元資料、空白行、NULL、語法錯誤 - 檢查所需的其他屬性)。

在迴歸測試中,使用現成的(不可更改的、稍微可更改的)資料集,自動測試程式碼可以儲存現成的模板,用於檢查資料是否符合品質(預期表元資料的描述;可以是的行樣本對象)。測試期間隨機選擇等)。

另外,在測試過程中,你必須使用Apache Airflow等框架來編寫ETL測試流程, Apache Spark 甚至是黑盒雲類型的工具 GCP 資料準備, GCP 資料流 等等。 這種情況迫使測試工程師必須沉浸在上述工具的操作原理中,甚至更有效地進行功能測試(例如專案上現有的ETL流程)並使用它們來檢查資料。 特別是,Apache Airflow 擁有現成的運算符,可用於處理流行的分析資料庫,例如 GCP BigQuery。 其最基本的使用範例已經概述 這裡,所以我就不再重複了。

除了現成的解決方案之外,沒有人禁止您實施自己的技術和工具。 這不僅有利於項目,也有利於資料品質工程師本人,從而提高他的技術視野和編碼技能。

它如何在實際項目中發揮作用

以下來自一個真實專案的過程很好地說明了最後幾段有關「資料鏈」、ETL 和無處不在的檢查的情況:

大數據與小數據測試器:趨勢、理論、我的故事

在這裡,各種數據(自然是我們準備的)進入我們系統的輸入“漏斗”:有效、無效、混合等,然後它們被過濾並最終進入中間存儲,然後它們再次經歷一系列轉換並放置在最終儲存中,依序進行分析、建構資料集市和搜尋業務洞察。 在這樣的系統中,我們無需對 ETL 流程的操作進行功能檢查,而是專注於轉換前後的資料品質以及分析的輸出。

綜上所述,無論我在哪裡工作,我所參與的數據項目都具有以下特徵:

  • 只有透過自動化,你才能測試一些案例並達到業務可以接受的發布週期。
  • 這類專案的測試人員是團隊中最受尊敬的成員之一,因為它為每位參與者帶來了巨大的好處(加速測試、資料科學家提供的良好資料、早期階段的缺陷識別)。
  • 無論您是在自己的硬體上還是在雲端中工作,所有資源都被抽像到一個叢集中,例如 Hortonworks、Cloudera、Mesos、Kubernetes 等。
  • 專案基於微服務方法構建,分散式和平行計算占主導地位。

我想指出的是,在資料品質領域進行測試時,測試專家將其專業重點轉移到產品的程式碼和所使用的工具。

數據品質測試的顯著特徵

此外,就我自己而言,我已經確定了以下(我將立即保留它們非常籠統且完全主觀)在數據(大數據)項目(系統)和其他領域測試的顯著特徵:

大數據與小數據測試器:趨勢、理論、我的故事

有用的鏈接

  1. 理論: DAMA-DMBOK:資料管理知識體系:第二版.
  2. 培訓中心 EPAM 
  3. 為初級資料品質工程師推薦的資料:
    1. Stepik 上的免費課程: 數據庫簡介
    2. LinkedIn 學習課程: 資料科學基礎:資料工程.
    3. 文章:
    4. 視頻:

結論

數據質量 這是一個非常年輕、有前途的方向,成為其中的一部分意味著成為新創公司的一部分。 一旦進入數據質量,您將沉浸在大量現代、急需的技術中,但最重要的是,將為您提供產生和實施您的想法的巨大機會。 您不僅可以在專案上使用持續改進方法,還可以為自己使用持續改進方法,並不斷發展為專家。

來源: www.habr.com

添加評論