top of page

一、工作環境介紹

部門

工作環境

  我所在的部門屬於遠傳IT-DAAS數據分析部門下的消費者暨通路大數據技術部(C&CBDT),工作範圍主要是負責遠傳所有與顧客有關的窗口,根據客戶不同的需求,建立專案進行數據工程,產出滿足顧客需求的資料或報表,以利公司賺取利潤或幫助決策

  我們Team的成員為九人,每個人都有自己專門負責的專案,我們Team每隔一段時間都會舉辦OCA Team Meeting,目的是為了讓主管和成員可以了解彼此的工作狀況,並且成員可提出問題讓大家一起討論工作上的問題,除了工作上的Team Meeting,每個月還會舉辦Team Sharing,利用每個月的其中一天,大家聚在一起吃午飯,交流分享除了工作以外的事情,增進成員彼此之間的感情。

遠傳電信的辦公大樓主要分為兩個地方,分別是台北市內湖與新北市板橋兩棟辦公大樓,而我們部門主要因為工作性質的不同在兩個地方都有Member駐紮,而我主要是在內湖辦公室辦公,但有時需要訓練或開會時,也會去板橋的大樓上班,無論是內湖辦公室還是板橋辦公室,基本的茶水間、會議室、餐廳等等具備,公司周圍的便利商店與餐廳數量也相當的多,可以說公司辦公大樓整體的工作環境非常不錯

​二、工作詳述

手機保險分析數據專案

手機保險為一個為期約半年的短期專案,工作內容主要是前台系統從各個保險公司蒐集所有與遠傳相關的手機保險資料,而由我們部門將蒐集後的資料,進行數據工程進行開發,最後產出可供產品經理業務使用的分析數據。 而在處理專案的過程中,我們也是遇到不少的問題,最大的問題就是關於Data Quality的問題,由於資料是從不同的保險公司匯入到前台系統的,而每一家保險公司的資料定義不相同,前台公司在匯入也沒有完全處理好,導致我們在清理資料與建立資料邏輯時,遇到很多資料為空值又或是資料定義不明確等等問題,這讓我們在處理的過程吃了不少苦頭,但是也讓我在處理數據工程的過程學習了不少。
負責工作:  驗證資料邏輯、報告每周專案進度、PMO會議紀錄、開發數據分析集的VIEW
我的工作內容包含上述幾項內容,因為要確認我們抓資料邏輯的正確性,因此在整個專案的過程中,我們最常做也做最多次就是資料邏輯驗證,因為可能當今天資料新增或欄位變動,那資料邏輯就必須重新驗證。我們手機保險的專案小組,每周都會固定舉辦PMO會議,向團隊成員與主管們報告專案進度,討論目前各自遇到問題,而我在PMO會議中負責報告我們團隊目前的工作進度,列出工作事項和目前遇到的問題,並在PMO會議的過程中做出會議記錄。

雖然手機保險的專案以八月底結束,但User能會根據不同的情況提出不同系統變更的需求,例如在九月初時,就有提過一次系統變更需求的SR,因為User需要能夠統計保險業績與觀察顧客合約狀況的欄位,那次的系統變更就新增了主Table的兩個欄位。

​而在11月初時,隨著保險代理公司的網路投保上線,從保險代理公司進到我們資料庫的資料,就不再僅僅是手機保險而已了,意外險、機車險等等資料都會進到資料庫中,我們必須觀察新資料進到資料庫的狀況,確認資料的正確性與品質,如果發現不正常的地方,可能又會是一次了SR開發了。

ETL JOB開發

我們Team的開發與維運基本上都是在Trinity這個ETL工具實行,透過Trinity可以很簡單輕鬆的實行JOB排程與自動化,因此Trinity可以說是我們平常最常使用的工具。 我們的資料抓進資料庫後可大致分為Stage、Data、Mart三層 Stage:為了保持來源資料的完整性,我們會將完整的來源資料先放入

Stage:保持來源資料的規格,基本上不會做任何動作,頂多重新命名資料表。
Data:從Stage層的各個資料表取得欄位資料,依照User的需求與商業邏輯進行欄位合併,建立新的資料表。
Mart:從Data層抓取資料表,開發成報表或是其他型態。


而為了避免不管是人為或是其他原因的失誤發生,我們在Trinity的資料夾與Teradata資料庫,都會分別建立正式環境與測試環境,基本上我們在進行開發時,都會先在測試環境先實行JOB,確認程式碼的正確性與抓取來源資料等等都沒問題後,JOB才會正式上到正式環境使用。

Trinity.jpg

​二、工作詳述

手機保險分析數據專案

手機保險為一個為期約半年的短期專案,工作內容主要是前台系統從各個保險公司蒐集所有與遠傳相關的手機保險資料,而由我們部門將蒐集後的資料,進行數據工程進行開發,最後產出可供產品經理業務使用的分析數據。 而在處理專案的過程中,我們也是遇到不少的問題,最大的問題就是關於Data Quality的問題,由於資料是從不同的保險公司匯入到前台系統的,而每一家保險公司的資料定義不相同,前台公司在匯入也沒有完全處理好,導致我們在清理資料與建立資料邏輯時,遇到很多資料為空值又或是資料定義不明確等等問題,這讓我們在處理的過程吃了不少苦頭,但是也讓我在處理數據工程的過程學習了不少。
負責工作:  驗證資料邏輯、報告每周專案進度、PMO會議紀錄、開發數據分析集的VIEW
我的工作內容包含上述幾項內容,因為要確認我們抓資料邏輯的正確性,因此在整個專案的過程中,我們最常做也做最多次就是資料邏輯驗證,因為可能當今天資料新增或欄位變動,那資料邏輯就必須重新驗證。我們手機保險的專案小組,每周都會固定舉辦PMO會議,向團隊成員與主管們報告專案進度,討論目前各自遇到問題,而我在PMO會議中負責報告我們團隊目前的工作進度,列出工作事項和目前遇到的問題,並在PMO會議的過程中做出會議記錄。

ETL JOB開發

我們Team的開發與維運基本上都是在Trinity這個ETL工具實行,透過Trinity可以很簡單輕鬆的實行JOB排程與自動化,因此Trinity可以說是我們平常最常使用的工具。 我們的資料抓進資料庫後可大致分為Stage、Data、Mart三層 Stage:為了保持來源資料的完整性,我們會將完整的來源資料先放入

Stage:保持來源資料的規格,基本上不會做任何動作,頂多重新命名資料表。
Data:從Stage層的各個資料表取得欄位資料,依照User的需求與商業邏輯進行欄位合併,建立新的資料表。
Mart:從Data層抓取資料表,開發成報表或是其他型態。


而為了避免不管是人為或是其他原因的失誤發生,我們在Trinity的資料夾與Teradata資料庫,都會分別建立正式環境與測試環境,基本上我們在進行開發時,都會先在測試環境先實行JOB,確認程式碼的正確性與抓取來源資料等等都沒問題後,JOB才會正式上到正式環境使用。

Trinity.jpg

​Metadata

Data About Data,有關資料的資料,此工具的目的是為了建立統一標準的資料目錄,便於尋找、辨識資源,有效的管理資料,Metadata類似於圖書館館藏目錄、博物館展覽資訊、音樂的基本資料等等。

Metadata.jpg

由於全球流行音樂在出版時並未有統一的標準紀錄,全球沒有關於音樂資料統一的Metadata,無法公正地確認歌曲的出版商、作曲者、作詞者等等的資訊,因此造成歌曲的實際收益分配不均。

TMS智能銷售平台

​此專案的目的是在原本外撥系統(TMS)的框架下,加入更多的銷售資訊,例如:主附約、折扣、庫存等等銷售資訊,並且增加商品類型與銷售方式的多樣性。由於這次的專案內容是前端系統的整合變動,前端系統欄位定義更動和增加新欄位,等於說這次的工作需要重新設計一個DataSet,DataSet的Key值與報表的產出都會與舊系統的DataSet不同。

由於目前此專案在暑期階段是屬於需求確認階段,每周幾乎都有2、3場的需求確認會議,雖然這些會議的內容與我們部份的工作沒有太直接的關係,但仍可從需求討論的過程中,更了解前端系統欄位定義與業務流程狀況,這些瞭解對於DataSet的數據工作有不小的幫助。這次專案算是我參與的第一個大型專案,每次需求會議的參加人數幾乎都超過20個,開會時的狀況也與之前參與過的會議都不太一樣,算是讓我累積了一個特別的工作經驗。

TMS.jpg
bottom of page