資料處理

資料處理 Technical Debt (1)

教學目標

初步了解導入機器學習系統進行後續維護作業所會面臨哪些技術債的問題。

重點概念

首先機器學習提供很強大的工具集透過很快速且便宜的方式建立實用且複雜的預測系統,但是當我們維護機器學習系統時,就會面臨軟體工程框架中技術債的問題,所謂技術債主要是在 1992 年 Ward Chunningham 提出,主要是協助我們理解由於在軟體工程中快速移成長而產生的長期成本,就像財政債務一樣,因此需要有合理的戰略承擔技術債,我們可以透過重構原始碼、改進單元測試、刪除無效程式碼、減少相依關係、重新評估 API、改善文件檔案、…等方式進行改善,請注意目標不是增加新的功能,而是為了減少錯誤的發生和提高可維護性,若是我們針對技術債視而不見,就會導致更危險的隱藏技術債發生產生維護上更嚴重的問題,尤其是資料處理時如何與資料進行整合,同時確保資料品質,若是我們忽略技術債將會導致資料品質不佳,資料不正確、遺失值過多,以致於造成機器學習系統的預測結果無法有效的應用於決策分析。

技術債

接著機器學習系統所產生技術債的問題通常很難被發現,因為它主要在於資料會影響機器學習系統行為無效。當我們導入機器學習系統時,資料輸入將會來自於其它系統,此時若是其它系統的資料品質不佳,就會立即影響機器學習的預測結果。一般來說,我們在軟體工程中會使用封裝和模組化的方式設計抽象方法,將有助於確保資訊輸入和輸出的內容和邏輯一致性,但是透過抽像方法很難應用於機器學習系統,因為當所需要的輸入資料無法透過外部資料和軟體邏輯被有效地的表達時,才會需要使用機器學習的方式,所以我們很難針對機器學習系統實施嚴格抽像介面確保資料輸入的品質。

相依債

再來機器學習系統除了產生技術債問題之外,還會產生相依債的問題,所謂依賴債主要是軟體工程中程式碼複雜性和技術債的關鍵因素。然而機器學習系統中資料的相依關係更為複雜,並且更難被發現。一般來說,我們在軟體工程中會使用編譯器和鏈結器的靜態分析工具識別程式碼相依關係,但是我們很難透過任何工具分析資料的相依關係。

分析債

此外機器學習系統除了技術債和相依債問題之外,還會產生分析債的問題,尤其是即時的機器學習系統其關鍵特性主要是隨時間更新影響分析行為,此時將會導致分析債,因為我們很難預測模型在發佈之前隨著時間的推移而逐漸發生的行為。

設定債

最後機器學習系統除了技術債、相依債和分析債之外,還會產生設定債的問題。任何大型機器學習系統皆有廣泛可設定的選項,包括使用哪些功能,如何選擇資料,不同演算法特定的學習設定、預先資料處理、後續資料處理、驗證方法、…等。一般來說,研究人員和工程師通常會認為驗證或測試的設定不是非常重要,但是任何設定若是發生錯誤,將會導致機器學習系統無法正常執行。

總結機器學習系統導入進行後續維護作業時將會面臨許多債需要償還,其中個人認為有四個債非常重要,分別為:

  1. 技術債
  2. 相依債
  3. 分析債
  4. 設定債

簡而言之,通常我們會以最快速且便宜的方式導入機器學習系統,此時就會產生技術債的問題、針對資料匯整若沒有分析專家或領域知識專家的合作將會面臨相依債的問題,並且若是進行採用多個機器學習模型進行即時分析將會面臨分析債的問題,以及企業導入機器學習系統需要與其它系統進行整合,此時就會面臨設定債的問題。因此若我們要導入機器學習系統時,可以考慮套裝軟體或雲端服務的解決方案,而非開放源碼的解決方案,避免在後續維護機器學習系統時發生更多的問題。

相關資源

資料處理 Apache Beam (1)

教學目標

初步了解 Apache Beam 資料處理相關開源專案之基本概念。

重點概念

首先企業中若要建置大數據分析平台將會需要進行資料提取、資料處理、資料分析和資料視覺化四大流程式,此時企業將會面臨許多資料處理的問題,此時 Google 針對資料處理的管理提供 Cloud Dataflow 雲端服務進行全方位管理的資料處理服務,支援流程的串流與批次執行,同時 Google 也將 Cloud Dataflows 進行開源,也就是 Apache Beam。

接著 Apache Beam 主要是由 Google 主導的開源專案,主要有三大特色,分別為:

  1. 統一:主要是針對批次處理和串流處理的使用案例透過單一程式語言模型進行處理。
  2. 可攜:主要是在多個執行環境運作在一個資料管線。
  3. 擴展:主要是寫入和分享新的軟體開發工具、輸入和輸出連接器和轉換函式庫。

再來 Apache Beam 對於我們來說為何要使用呢?早在 2003 年開始 Google 發佈了三篇有關大數據的重要論文,分別為 Google File SystemMapReduceBigTable,但是當時並沒有專屬開源專案。所以 Hadoop 之父 Doug Cutting 根據這些論文發展出了 Apache Hadoop 專案,而今 Google 將 Cloud Dataflow 雲端服務進行開源,同時 Apache Beam 的主要負責人 Tyler Akidau 說明要建立易用且強大可以掌握批次處理和串流處理的模型。

最後 Apache Beam 有多個批次處理和串流處理的模式,一個資料流程模型和軟體開發工具的資料管線,以及許多執行環境,像是 Apache Flink、Apache Spark、Google Cloud Dataflow 或者本機端執行環境,至於不同執行環境的比較表可以參考官方部落格

總結隨著分散式資料處理不斷的發展,業界出現越來越多的分散式資料處理檻框架,從最早的 Apache Hadoop、Apache Spark、Apache Flink、…等,雖然新的分散式處理框架火來更高的效能,但是對於我們則需要學習一個新的資料處理框架,並重寫所有業務邏輯,因此為了解決二個問題,首先統一批次處理和串流處理的需求,其次產生分散式資料處理任務將能夠在每個分散式執行環境上執行,這時 Apache Beam 就能夠有效解決上述兩個問題,此外若想要了解運作原理則可以參考「No One at Google Uses MapReduce Anymore」官方簡報內容,至於若想要了解如何操作則可以參考「Apache Beam: Portable and Parallel Data Processing」官方影片內容。

相關資源

資料處理 Business Intelligence vs Big Data (2)

教學目標

初步了解商業智慧與大數據分析如何搭配應用為企業帶來價值。

重點概念

商業智慧最早是由 Gartner 研究機構的 Howard Dresner 在 1989 年所提出,簡單來說就是企業透過已知資料支援決策能力的概念或方法。而今比較多人談論的則是大數據分析,其所定義最基本的三個特性,資料產生的速度、資訊數量和多樣性,皆是傳統以資料倉儲為基礎的商業智慧應用所難以處理的問題。此時各行各業皆深信透過大數據分析就能為企業帶來價值,例如金融業擁有百萬客戶的大數據資料最常被應用於精準行銷的進階分析應用,但是往往會面臨客戶資料真實性的問題,以致於分析人員無法有效為企業帶來價值。

這時企業可以透過資料治理針對資料品質進行控管,以利解決客戶資料真實性的問題。最常見的解決方案就是以資料倉儲為基礎建立資料市集,讓業務單位了解資料的定義,接著就能透過商業智慧中的即席查詢和動態報表相關應用立即驗證資料的品質。當企業中提供高品質的資料之後,就能夠解決客戶資料真實性的問題,更進一步透過精準行銷為企業帶來價值。因此企業對於商業智慧和資料倉儲的應用因著重於資料治理的管理,況且企業中的資料整合是非常複雜,以金融業為例,資料倉儲的資料就來自於核心系統、開放系統和通路系統,要如何有效的與各系統有效進行高品質的資料整合將會是資訊人員能夠為企業帶來價值的最重要且最關鍵的工作職責。

但是何謂企業的價值呢?價值又要如何創造呢?根據德勤全球的企業價值地圖,其主要針對利益關係人的價值分為四大類,分別為營收成長、利潤提升、資產效率和期望,其中營收成長又可再分為營收量的成長和價格利益的實現。此時我們針對營收量的成長,其主要可以採取獲取新客戶、留存與增加現有客戶、…、等策略行動,再來我們可以透過產品或服務的創新達到上述的策略行動,一般對於企業來說就是做好客戶經營,針對行銷與業務進行分析,其中行銷的重點在於找出正確的目標群眾,以利進行精準行銷。然而現今因為行動裝置的普及使得企業必須考量全通路的應用情境,因此就會需要透過行銷自動化的解決方案根據不同通路產生行銷活動的名單之外,更進一步會針對不同通路的回應檔資訊進行進階分析,以利優化不同通路的行銷活動名單,除此之外為了因應法規規範和避免客訴的情況發生,此時資訊人員必須確保拒絕行銷名單的資料真實性,以確保分析人員能夠透過行銷活動名單的產出進行精準行銷為企業帶來價值。

總結商業智慧的解決方案已經非常成熟,然而大數據分析的解決方案相對較不成熟,所以商業智慧的未來最關鍵應用之一為資料治理,藉由資訊人員提供高品質的資料,讓分析人員透過大數據的解決方案在確保資料真實性的情況下進行進階分析,更進一步為企業帶來價值。

相關資源

資料處理 Report Requirement (2)

基本介紹

教學目標

初步了解有關商業分析的報表種類。

重點概念

在上一篇文章中「資料處理 Report Requirement (1)」雖然我們透過不同的問題,一步一步詢問出報表的需求,卻還是不清楚有關商業分析的報表種類究竟有哪些呢? 其實主要可以分為三大類報表臨時的報表 (Ad-Hoc Reports)、手動更新的報表 (Manually Updated Reports) 和自動化的報表 (Automated Reports)。

首先若我們所擁有商業事件、懷疑事項或關鍵問題必須被確認時,我們就必須提供包括相關資訊的臨時報表。接著若我們面臨需求不斷的變更、維度不斷的改變、較差的資料品質、分析人員可以新增一些領域知識、…等原因時,我們就必須採用手動更新的報表為解決方案。但是若需求和維度明確、同時擁有較佳的資料品質,以及沒有分析人員的介入調整時,我們就能夠連接資料倉儲實作基於使用者存取定期更新的大量資訊,就是隨選需求 (On Demand) 的自動化報表,最後針對使用者要何時閱讀報表呢? 此時觸發報表的事件就可過去的資料中已經超過一些關鍵門檻值的事實時,發出信件通知使用者定期閱讀,就是事件驅動的自動化報表。

因此在銀行工作時不外乎就是上述三大類型的報表,像是公職人員財產申報或政府機關交易明細的資料提供就屬於臨時的報表,或者在大數據的時代總行業務單位開始針對未知的需求透過 Tableau 工具進行自主分析的報表。總行營運單位各自透過 Microsoft Excel 軟體從不同的系統手動下載數字,再藉由公式和巨集,以及專業領域知識匯整出手動更新的報表檔案。總行資訊單位針對資料倉儲中的資料,導入全面性的商業智慧解決方案,例如: IBM Cognos Analytics 平台,提供隨選需求和事件驅動的自動化報表,其中存取效能、安全控管和集中管理將會是最大的優勢。

相關資源

資料處理 Information System (1)

基本介紹

教學目標

初步了解資訊系統如何在企業有助於進行資料處理。

重點概念

資訊系統主要為一組相互關聯的元件,主要負責蒐集、處理、儲存和傳播資訊,並且支援組織內的決策以及控制流程,其中資訊是指已經被匯整成有意義,並且能夠提供人類使用的資料,資料則是是一串原始的事實。接著資訊系統有三個主要的活動,分別為輸入、處理和輸出,簡單來說取得或者蒐集組織內部或者外部環境的原始資料為輸入,再將這些原始輸入轉化為有意義的格式為處理,最後再將處理後的資訊傳給要使用的人員或者要使用的活動。資訊系統主要能夠讓企業去發展新產品、服務,以及全新的企業模式,企業模式描述一間公司如何去生產、運送以及 生產、運送以及銷售一件產品或一項服務,以利創造財富。此時巨量資料的科技改變,對企業帶來的衝擊為必須以更合適的資料管理工具去取得、存取和分析大量資料意義,以及商業智慧應用加速的管理改變,對企業帶來的衝擊為必須以更合適的互動式儀表版和進階分析工具,針對管理者提供動態且即時的績效資訊,以利促進決策升級。

接著商業智慧是指組織與分析資料的工具,主要幫助決策人員做出更明智的企業決策。基本上又可再分為管理資訊系統、決策支援系統和行政管理支援系統,首先導入管理資訊系統主要匯整交易處理系統的資料,提供組織績效報表,簡單來說就是針對例行性,或是已經預先定義問題解答的處理流程產生適當的報表,以利中階管理主管獲取例行性的資訊,例如:銀行業務單位會定期透過防偽冒偵測系統針對申請信貸人員進行評估,或者透過財產申報系統匯整公務人員相關存款、放款、特定金錢信託投資基金和其他金融商品等資訊給警政署、法務部、監察院、…等機構,然而卻缺乏彈性和分析能力。所以為了進行分析,就需要導入決策支援系統,主要匯整交易處理系統的資料,同時整合其它管理資訊系統的內、外部資料,以利中階管理主管獲取非例行性的資訊,並且又可再分為模型驅動或資料驅動的決策支援系統,例如:銀行業務單位會定期透過防偽冒偵測系統針對申請信貸人員以模型驅動為主進行客戶分析,或者透過行銷活動管理系統以資料驅動為主進行客戶分析,然而對於高階管理長官還是太複雜,需要同時包容外部事件,例如,新法規和競爭對手的資料,以及從內部的管理資訊系統和決策支援系統提取摘要資訊。因此就需要行政管理支援系統,主要提供互動式儀表版顯示出公司管理之關鍵績效指標和視覺化圖表。

再來維護資訊系統時最重要的關鍵則在於若能設定參數來解決問題就不要客製開發來解決問題,許多企業目前資訊系統主要有兩大類,一是套裝系統,主要藉由設定參數的方式解決企業所面臨的問題,例如: IBM Cognos BI、SAS Visual Analytics、…、等系統平台,二是開發系統,主要藉由客製開發解決問題,其中又以 .NET 和 Java 技術占很大的比例,接著若是開發套裝系統的客製程式主要會以 Java 技術為主,例如:行銷活動管理系統客製程式以利活動規劃,而開發管理資訊系統則主要會以 .NET 技術為主。然而許多企業內部需要維護的管理資訊系統大部份皆以 ASP.NET Webform 進行開發,是由微軟以 .NET Framework 框架為基礎開發網站應用程式,事實若是內部必要但非重要系統,例如: 財產申報系統目的在於作業流程優化,所以建議採用 ASP.NET Webform ,主要原因在於優點為對應用程式開發工作而言一般較不複雜,因為元件 (頁面類別、控制項等) 彼此緊密整合,通常需要的程式碼也比 MVC 模型少,所以問題的 80% 僅要設定參數,再針對問題 20% 進行客製開發就能夠解決問題。但若是內、外部必要且重要的系統,則建議採用 ASP.NET MVC,主要原因在於優點為劃分應用程式工作 (輸入邏輯、商務邏輯和使用者介面邏輯)、測試能力及測試為導向的開發工作,例如:防偽冒偵測系統未來能與大數據整合應用,理應是必要且重要的內部系統,所以建議採用 ASP.NET MVC。

最後資訊系統導入是否能夠成功重要關鍵在於維護工作,當業務單位使用資訊系統發生問題時會先打給資訊人員解決,此時資訊人員應該先將問題進行分類,並且記錄至問題清單中,接著根據歷史的問題清單找出對應標準處理流程,若能夠順利透過設定解決就分類為事件管理,一般資訊人員皆可處理。但是若找不到標準處理流程,此時就分類為問題處理,需要請專業資訊人員進行處理。接著若發現無法透過設定參數就能解決問題時,就必須分類為變更管理,透過客製開發的方式解決問題,但是當需求過大時,就必須分類為專案管理,藉由專安管理的方式解決問題。總結完善的資訊系統規劃將有助於資料處理,其中包括輸入、處理和輸出等過程。

相關資源