Leo Yeh's Blog

📖 earlier posts 📖

AWS 機器學習 (1)

教學目標

初步了解 AWS 機器學習之基本概念。

重點概念

首先目前許多企業組織正在產生、儲存和分析比以往更多的資料,並且隨著機器學習最新的進展,讓我們能透過以大數據為基礎驅動建立業務成果,儘管機器學習演算法已經使用了二十幾年,但是最近幾年機器學習演算法的框架和用於執行演算法的基礎架構已經有非常大幅度的速度提升,也因此能夠透過多次的迭代自動在相對較短的時間內,有效率的將復雜的數學計算應用於大規模的數據集中,為機器學習分析帶來更多可能性,所以越來越多企業開始依賴機器學習來自動化任務,並且為最終客戶提供個人化的服務,同時透過收集和分析來自各種部署的設備和傳感器的資料提高營運效率。

接著資料是每個機器學習專案的基礎,不僅決定了什麼樣的機器學習方法,以及決定哪些基礎設施最適合,並且在專案開始之前我們需要先解決資料來源、資料更新、資料轉換、資料儲存、… 等資料管理相關問題。至於 AWS 雲端服務則主要提供 ETL 處理服務,以利能夠在此期間內提供預處理專案之各個階段的協助,而不同的機器學習演算法可能會有多種方式學習分析的過程,其中可能會擷取,轉換和載入資料,所以我們不同的工作流程階段,皆必須具有儲存基礎架構和資料管理工具。任何機器學習和深度學習預測演算法所需的資料量與建模應用程式和問題的複雜性成正比,為了確定資料集的大小是否足夠,許多數據科學家會落實學習曲線,像是採用 k-fold 交叉驗證資料集之抽樣方法,並且評估最終結果的信賴區間。此外機器學習應用程式需要的資料集通常會從物聯網輸入、資料湖和資料倉儲中取得,而許多客戶主要使用 Amazon Simple Storage 服務 (Amazon S3) 作為其訓練資料集的目標端點,而 Amazon Athena、AWS Glue 和 Amazon Redshift Spectrum 皆主要進行資料 ETL 的處理,並且彼此在功能上互補,將能夠設計為預處理儲存或目標的資料集,而為了提高機器學習演算法的處理速度,我們很直接的想到就是針對運算層的改善,其中包括更快的處理器和更多的內核,然而使用越來越複雜的演算法,將會需要處理更大量的資料工作負載,而導致 I/O 儲存處理時的瓶頸。而若我們需要擴展機器學習的學習工作量,則高效能平行檔案系統,其中中繼資料和 I/O 主要由多個或所有運算節點管理,可以緩解依賴於單個管理節點的文件系統引入的瓶頸,同時優化系統時分散式平行處理的檔案系統效能是最關鍵的決定因素,至於此外深度學習訓練的應用程式需要能夠在低延遲和高輸出量的儲存系統持續提供資料。此時 Amazon S3 就能夠滿足分散式平行處理的檔案系統的效能,如果業務需求不需要更快的訓練速度,則我們能夠以較慢的速度訓練模型,並使用符合這些效能要求的存儲位置,請參考下表。

檔案系統 相對速度
Amazon S3 <1.00
Amazon EFS 1
Amazon EBS 1.29
NVMe 1.4
RAMDisk 1.44
BeeGFS 1.6
Amazon FSx >1.60

但是如果需要高輸出量的大規模分散式平行處理的檔案系統,則建議選擇 Amazon Elastic File System (Amazon EFS)或 Amazon FSx for Lustre (Amazon FSx) 以利彈性擴展至需求。

再來如果將模型用於批次轉換,此時就會對於部署和資料需求高度依賴的問題,則建議透過 Amazon SageMaker Batch Transform 等工具來評估無服務器環境中的模型,此時,則可以提前準備資料,並且使用 Amazon S3 或其它檔案系統將其提供給模型,請注意目前 Amazon S3 單個物件上傳的上限為 5 GB 和檔案大小設定為高達 5 TB,所以我們需要考慮處理的資料大小以及處理速度的業務要求,以利確定要使用的檔案系統。除了將模型用於批次轉換之外,如果將模型用於即時推理,此時就會系統就會更複雜,因為它們僅在短時間內完成即時推理的任務,在這些情況下,我們可能必須分析和調整即時推理管線的每個步驟,以確保推理時間滿足要求,則建議透過 Amazon SageMaker Deployment,該伺服器位於負載平衡器的後方,該負載平衡器能夠自動調整以滿足 API 的請求,這些API 的請求將發送至模型端點,更進一步我們也能夠透過 Amazon SageMaker Neo 部署最主流的深度學習框架模型,以利優化訓練模型。請注意在極端情況下,SageMaker 部署可能會有太多延遲,在這些情況下,如果要找到瓶頸,則我們必須對推理的資料來源、模型路徑,執行模型的硬體以及回應路徑進行廣泛深入分析,才能評估部署模型的位置以及如何執行推理,以及在某些情況下,從不同的資料來源獲取所需的資料可能會受到限制,此時我們就必須重新建立資料存取的模式以利透過機器學習模型進行即時推理。

最後最適合深度學習訓練的架構應該包括 Amazon S3、Amazon EC2、Amazon Virtual Private Cloud (Amazon VPC)、Amazon EC2 Auto Scaling、Amazon CloudWatch、Amazon Elastic File System (Amazon EFS)、Amazon Elastic Kubernetes Service (Amazon EKS)、AWS Identity and Access Management (IAM)、AWS CloudFormation、… 等雲端服務,並且主要會整合使用 AWS CloudFormation 中範本自動建立相關的 AWS 服務能夠快速識別潛在的瓶頸和改進領域,以利提高靈活性、可靠性和透明度確保基礎架構的穩健,以及透過 Amazon EC2 Auto Scaling 將能夠讓應用程式從幾個節點動態擴展到一百多個節點,還能夠為副本集中的資源提供多區域覆蓋,此外當我們更能夠使用 Amazon EKS 上的 Kubernetes 控制容器和使用統一監視和日誌記錄框架建立隔離,以利提供分離作業系統和設備驅動程式層相依的關係。此外在進行大規模執行機器學習時,資料集通常需要預處理步驟來對資料進行分區以實現最佳處理,通常最佳實務的做法是分散至多台伺服器上分散式平行處理資料,至於用於建立機器學習模型的服務架構,則主要取決於資料集的大小和要執行的計算演算法的複雜性,通常建議透過 GPU 用於計算密集型工作負載,透過 FPGA 提供專門的硬體加速,以及建議透過 Memory 執行即時推理,以及針對機器學習工作負載進行優化,通常會限制要分析的資料與改善運算環境中服務彼此之間的延遲。

相關資源

AWS 企業架構 (1)

教學目標

初步了解 AWS 企業架構之基本概念。

重點概念

首先 AWS 在 Gartner 的雲端基礎架構即服務 (Infrastructure as a Service,IaaS) 魔力象限中連續第九年獲得領導者的認可,Amazon 致力於提供客戶現在所需的服務,並且盡最大努力預測明天將會需要什麼,並且以客戶為中心和以價值為導向的產品設計原則是其產品和服務具有強大實力的核心原因。同時 Amzon 更透過執行長期投資戰略來維持競爭優勢,將其積極的現金流量重新投資於基礎設施,並且透過從基於雲端的部署至以消費者為中心的設備,可以實現向專家團隊,開發人員以及日常業務人員和個人提供人工智慧服務,這使得 Amazon 可以在決定人工智慧如何影響其客戶,以及如何滿足其需求方面擁有廣泛的自由度。然而 Amazon 目前還是難以應對多個領域的問題,像是執行風險緩解計劃和應急選擇,以及僅被視為具有短期快速回報的戰術投資。

接著目前許多企業組織面臨的主要挑戰為提高 IT 資產所帶來的商業價值,此時企業架構旨在定義目標的 IT 環境,這也代表著實現商業願景,並且推動價值,而企業架構的主要目標有五個重點,分別為:

  1. 分析和發展企業組織的業務願景和戰略。
  2. 描述業務願景和戰略相關的業務功能和流程。
  3. 提供支援所有架構實現的治理工具、框架和規範。
  4. 定義為了實現目標,則 IT 環境所需要哪些程式和架構。
  5. 落實整個 IT 環境的可追溯性。

至於成熟企業架構實務的關鍵價值主要為假設怎樣能夠做得更好,並且進行影響分析,同時更能夠識別哪些應用程式能夠實現哪些業務功能,以利實現企業組織的業務願景的決策,像是如果我們決定外包,則對於我們的 IT 環境中的哪些業務服務會有什麼影響?如果我們替換某個 IT 系統,則會影響哪些業務能力和流程嗎?實現我們業務願景這一方面的成本是多少呢?此外可追溯性的稽核記錄,以及擷取目前狀態主要是一個永久性的挑戰,供應商特定硬體和舊有系統的世界,通常根本就不是企業可以對其所有資產進行有效的管理,所以在這種情況下,其將無法確定 IT 環境所帶來的商業價值,此時若是搬到雲端環境將能夠讓企業有機會落實對於雲端 IT 資產的可追溯性。

再來所謂企業架構原則主要是通用的一般規則和指南,主要支援企業組織開始履行其使命的方式,其旨在持久和少次修改,並且我們皆應該使用原則來指導架構設計和導入雲端環境,而原則若用於應用程式設計,則應該指導應用程式治理和架構,並且有效管理工作負載將能夠幫助我們實現企業的願景,像是最大化企業的成本效益、業務連續性、敏捷性和靈活性、雲端優先戰略、安全優先功能以及所有使用者,服務和應用程式都屬於企業組織的單元。至於企業架構指導企業組織的業務、資訊、流程和技術決策,使其能夠執行其業務戰略,並且滿足客戶的需求,通常會有四個架構領域,分別為:

  1. 業務架構領域:主要描述企業組織所必需的架構和功能,以利提供商業願景,其中主要會問什麼是組織的業務願景,戰略和目標,以及主要由誰明確定義業務服務或功能?
  2. 應用程式架構領域:主要描述個別應用程式的互動方式,以及個別與企業組織核心業務流程之間的關係,其中主要說明如何實作之前所定義的業務功能和服務。
  3. 資料架構領域:主要描述企業組織的邏輯和實體資料資產和資料管理的結構,並且透過資料分析更進一步了解客戶,以利不斷改善發展業務流程。
  4. 技術架構領域:主要描述實作軟體、業務、資料和應用程式所需的基礎架構服務。

當然企業架構師必須專注於每個領域,以及彼此之間的相互關係,以利提供企業組織的戰略,此外企業架構的規劃更需要回答出資產位於何處,以及為什麼要改變?

最後 AWS 服務將能夠支援企業架構,主要有以下幾個關鍵服務,分別為:

  1. AWS Organizations
  2. AWS Identity & Access Management (IAM)
  3. AWS Service Catalog
  4. AWS CloudTrail
  5. Amazon CloudWatch
  6. AWS Config
  7. AWS Tagging and Resource Grouping

其中 AWS Organizations 主要允許我們將 AWS 帳號安排至特定組織單位中,並且產生業務組織模型,以及在這些組織單位內部之間,我們能夠定義集中管理的策略方式進行應用,像是在雲端環境中複製企業組織結構,並且在保持全球化的同時,為業務部門提供自主權治理,以及管理雲端環境環境中的帳號和相關支出成本。在通常情況下,企業組織有一個呈現公司中使用者和角色的目錄,像是 Active Directory,而在雲端環境中我們主要透過 AWS Identity & Access Management (IAM) 來呈現企業組織中使用者和角色之間的關係,以利更安全地控制針對 AWS 雲端服務和資源的存取權限。至於 AWS CloudTrail 主要追踪 AWS 雲端服務和資源的使用情況,而 Amazon CloudWatch 主要監控 AWS 雲端服務中應用程式的使用情況,當兩項服務整合使用,並且透過 AWS Config 和評估資源的配置,以及透過 AWS Service Catalog 確保企業組織使用的 AWS 雲端服務符合標準規範和限制,更進一步透過 AWS Tagging and Resource Grouping 將能夠針對企業組織中所使用的 AWS 雲端服務之資源和元件進行標記、收集和組織,將更有助於於企業架構的治理。

總結對於企業架構師來說,衡量目標是一項挑戰,此時若使用 AWS 服務來建立可追踪性,以利正確地追踪企業組織如何變化和改進,同時也更容易當發生問題時立即進行適當的變更,以利更輕鬆地執行和實現企業架構實務所帶來的價值。

相關資源

SAS Viya (113)

教學目標

初步了解 SAS Viya 平台中分送報表相關設定的基本概念。

重點概念

首先目前有許多企業客戶期望透過批次處理和 REST API 的方式來操作 SAS Visual Analytics 分析報表,同時用於自動化建立、多國語系、權限控管和報表分派,像是為不同部門自動化建立分析報表的任務,並且針對不同國家進行多國語系的呈現,以及針對不同部門的相關人員進行權限控管,更重要的是能夠每日重複安排時間自動分送分析報表至特定人員的電子郵件中,以及透過分送報告我們能夠在非高峰時段產生分析報表,所以我們能夠使用 SAS Visual Analytics 分送報告,其能夠自動完成向特定報表使用者提供最新的報表內容,並且能夠按照一次或每隔一段時間分送報告,像是每天,每週,每月或每年多次,至於要如何做到,請參考官方論文

接著我們也能夠手動和自動分送報表,僅需要開啟分析報表之後,在編輯模式下點選畫面左上方的「功能表」按鈕,按下「分送報表」選項,按下「新增」按鈕之後,就能夠設定「分送名稱」、「收件者」、「電子郵件主旨」、「電子郵件訊息」和「排程」等相關設定,並且當設定完成之後,按下「播放」就能夠立即分送報表,當然若是我們有進行排程設定,則就會在指定的特定時間自動收到分送報表的信件,請參考官方文件。但是在透過電子郵件分送報表之前,我們則需要先設定 SMTP 寄信伺服器,預設 SAS Viya 平台不會提供 SMTP 寄信伺服器,此時若是沒有 SMTP 寄信伺服器,則建議採用 Amazon SES 服務,僅需按照官方文件中的教學步驟就能夠簡單操作立即取得 SMTP 登入的使用者名稱和密碼,並且透過官方網站所提供各種程式設計語言的程式碼範例,以利測試使用透過 Amazon SES 服務中的 SMTP 伺服器來傳送電子郵件,個人建議使用 Python 進行測試,請參考官方文件。此外若出現以下錯誤訊息,則代表 Amazon SES 要求我們驗證電子郵件,以確認實際擁有,以防止未經授權的使用,請參考官方文件,大約一個工作天就會收到驗證的確認信,當確認完成之後,我們就能夠立即透過 Amazon SES 服務寄信。

1
Error:  (554, b'Message rejected: Email address is not verified. The following identities failed the check in region US-EAST-1: leoyeh.me@gmail.com, Sender Name <leoyeh.me@gmail.com>')

再來當我們完成確認能夠正常透過 Amazon SES 服務寄信之後,再來我們就需要設定 SAS Viya 平台中的電子郵件的服務,主要開啟 SAS Environment Manager 管理環境,點選「瀏覽列」中的「組態」,選取「所有的服務」,然後搜尋「Mail Service」之後,在「sas.mail」的區塊按下「編輯」鈕之後,進行以下設定,請注意以下設定僅供參考,實際需要根據不同區域的 Amazon SES 服務和寄信者進行設定,請注意 port 需要改為 587,而非 25,以及 username 和 password 不是 AWS 的使用者帳號和密碼,而是建立在 IAM 中的使用者認證憑證所提供的使用者帳號和密碼,當確認無誤之後,請按下「儲存」按鈕,並且登入至伺服器執行「sudo /etc/init.d/sas-viya-mail-default restart」指令重新啟動 Mail Service 的微服務,當重新啟動完成之後設定值才會生效。

設定名稱 設定值
fromAddress leoyeh.me@gmail.com
host email-smtp.us-east-1.amazonaws.com
port 587
username AKIAXETHP6TBMCOMN3RV
password xxxxxxxxxxxxxxxxxxxxxxx

至於所謂電子郵件寄伺服器主要使用 TCP 587 連接埠將電子郵件傳送給郵件伺服器,而大多數電子郵件提供商仍允許在傳統 TCP 25 連接埠傳送電子郵件,事實上 SMTP 當時設計時主要是用於伺服器和伺服器之間的資料交換,並且由於 TCP 25 連接埠目前已經經常被作為惡意攻擊的目標,所以很多服務商皆禁止使用 TCP 25 連接埠,而 TCP 587 連接埠的設計主要就是用於使用者和伺服器互動,並且在發送電子郵件時,必須連接至身份驗證的郵件伺服器 (Message Submission Agent,MSA) 進行自動登入認証,所以由於安全的原因目前大部分的 SMTP 設定皆選擇 TCP 587 連接埠,而不是 TCP 25 連接埠,至於 TCP 465 連接埠則是在通訊之後自動啟動 TLS/SSL 加密連線的 SMTP,即 SMTPS,至於 TCP 587 連接埠則是透過 STARTTLS 啟動安全連線。

最後若還是無法正常發送分析報表,則請切換至「/var/log/sas/viya/mail/default/」目錄查看記錄檔,若是發現以下錯誤訊息,則代表「fyi@nowhere.com」電子郵件沒有被 Amazon SES 進行驗證,此時我們就必須開啟 SAS Environment Manager 管理環境,點選「瀏覽列」中的「組態」,選取「定義」,然後搜尋「sas.reportdistribution.mail」之後,並且編輯「defaultFromAddress」設定值為已經被 Amazon SES 所進行驗證的電子郵件,預設值為「fyi@nowhere.com」,當確認無誤之後,請按下「儲存」按鈕,並且登入至伺服器執行「sudo /etc/init.d/sas-viya-reportdistribution-default restart」指令重新啟動 Report Distribution Service 的微服務,當重新啟動完成之後設定值才會生效,此時 SAS Viya 平台就能夠透過 Amazon SES 分送分析報表,至於下一步則是更進一步能夠透過 SAS Viya 平台所提供的 REST API 整合自動化和批次處理執行所有相關視覺化分析報表的日常任務,其中包括報表建立、多國語系、權限控管和報表分派等機制。

1
2019-08-14 15:25:35.567 ERROR 12889 --- [o-auto-1-exec-2] com.sas.mail.MailController              : sas.reportDistribution [fc270aeb0eaa9edb] [controller.mail.failure.fmt.log] Mail Failure, Failed messages: com.sun.mail.smtp.SMTPSendFailedException: 554 Message rejected: Email address is not verified. The following identities failed the check in region US-EAST-1: fyi@nowhere.com...

相關資源

SAS Viya (112)

教學目標

初步了解 SAS Micro Analytic Service 的基本概念。

重點概念

首先即時分析系統的架構和和探索分析平台的架構不同,如果將分析內建至作業系統或業務流程中,就會產生許多潛在的影響,此時我們需要持續關注與業務相關應用程式的服務層級協議,所謂服務層級協議主要是服務提供商與客戶之間所定義的正式承諾,其中包括具體達成了承諾的服務指標,因此在建立平台時,我們需要考慮以下幾個方面,分別為:

  1. 高可用性的要求,主要針對端至端的工作流程操作。
  2. 系統回應的時間,主要針對即時分析系統低延遲回應。
  3. 使用整合的模式,主要針對異質平台透過 REST API 整合。
  4. 執行決策的流程,主要針對決策結果透過資料邏輯或模型分析即時產生。
  5. 管理模型的部署,主要針對模型管理是否符合軟體開發生命週期的要求。

接著 SAS Micro Analytic Service (MAS) 主要是提供以記憶體儲存為主的高效能服務,其包括在 SAS Decision Manager、SAS Event Streaming Process 和 SAS Model Manager,至於相關比較資訊,請參考下表。

功能 SAS Decision Manager SAS Event Streaming Process SAS Model Manager
提供 MAS 引擎
提供即時決策
提供串流分析
建立工作流程
管理分析模型
發行 MAS 服務

以及 SAS Micro Analytic Service 主要提供將業務規則和分析模型發行至正式環境中的功能,並且 MAS 主要能夠執行 SAS 程式和 Python 程式,同時支援一次編譯多次執行的使用模式,若我們要在 SAS Micro Analytic Service 中執行 Python 程式,則需要在以下四個設定檔中分別加入設定 MAS_PYPATH 和 MAS_M2PATH 的環境變數指令,並且重新啟動 SAS Viya 平台,或者 SAS Micro Analytic Service 服務,此外若是要透過 SAS StudioV 透過 DS2 的 PyMAS 套件執行 Python 程式,則需要將登入 SAS Stduio V 進行操作的使用者加入至 CASHostAccountRequired 自訂群組中。

1
2
3
4
sudo vi /opt/sas/viya/config/etc/cas/default/cas_usermods.settings
sudo vi /opt/sas/viya/config/etc/sysconfig/microanalyticservice.conf
sudo vi /opt/sas/viya/config/etc/sysconfig/compsrv/default/sas-compsrv
sudo vi /opt/sas/viya/config/etc/workspaceserver/default/workspaceserver_usermods.sh
1
2
export MAS_PYPATH=/usr/bin/python<Version>
export MAS_M2PATH=/opt/sas/viya/home/SASFoundation/misc/embscoreeng/mas2py.py

再來透過 SAS Decision Manager 和 SAS Model Manager 發行至 MAS 引擎之後,MAS 將會自動提供有版本控管和模組管理的 REST API 與客戶端應用程式輕鬆進行整合,同時提供持久性和叢集架構,以利實現可擴展性和高可用性。如果我們透過 SAS Decision Manager 計定管線就能夠很簡單的方式將 Python 程式碼加入至管線的節點中,並且自動轉換為 SAS 程式碼,以利發行至 MAS 中將會自動提供有版本控管和模組管理的 REST API,但若是僅有 SAS Model Manager 則就需要客製轉換 Python 程式碼為 SAS 程式碼,以利發行至 MAS 中,此外針對 SAS Model Manager 中專案的模型屬性,則必須要將 SAS 程式碼檔案設定為「計分程式碼」的角色,並且設定「計分程式碼類型」為「DS2 套件」,以及設定「工具」為「Python3」,否則當發行至 MAS 時會一直出現「找不到計分程式碼」的錯誤資訊。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
ds2_options sas;
package myPkg /overwrite=yes;
method transfer( double X1, double X2, in_out double Y);
dcl package logger logr('App.tk.MAS');
dcl package pymas pm;
dcl int revision resultCode;
pm = _new_ pymas();
pm.appendSrcLine('def model(X1, X2):');
pm.appendSrcLine(' "Output: Y"');
pm.appendSrcLine(' if X1 == None:');
pm.appendSrcLine(' X1 = 0');
pm.appendSrcLine(' if X2 == None:');
pm.appendSrcLine(' X2 = 0');
pm.appendSrcLine(' Y = 0.5 + 1 * X1 + 2 * X2');
pm.appendSrcLine(' return Y');
revision = pm.publish(pm.getSource(), 'transfer_model');
rc = pm.useMethod('model');
rc = pm.setDouble('X1', X1);
rc = pm.setDouble('X2', X2);
Y = pm.getDouble('Y');
end;
end;
endpackage;

(註:此 SAS 程式碼主要是一個簡單 Y = 0.5 + 1 × X1 + 2 × X2 轉換的模型函數。)

當我們完成模型發行至 MAS 之後,此時 MAS 就會自動提供有版本控管和模組管理的 REST API,以利我們與客戶端應用程式輕鬆進行整合,以及透過 Jupyter Notebook 直接透過已發行的模型進行即時分析,若是結果一直有問題請先確認 MAS_PYPATH 和 MAS_M2PATH 的環境變數是否設定正確,若是設定不正確,則會無法正常在 MAS 中執行 Python 程式,此外在 MAS 中預設主要是採用 JSON Web Token (JWT) 認證協定搭配 OAuth 2.0 授權框架落實更佳安全且更有效率的 REST API 服務存取機制。

1
2
3
4
5
import requests, json
url = 'http://<SAS Viya URL>/SASLogon/oauth/clients/consul?callback=false&serviceId=app'
headers = {'X-Consul-Token': '<Consul Token>'}
r = requests.post(url, headers=headers)
access_token = json.loads(r.text)['access_token']
1
2
3
4
5
6
7
import requests, json
url = 'http://<SAS Viya URL>/microanalyticScore/modules/pymodel/steps/transfer'
headers = {'Content-Type': 'application/json;charset=utf-8','Authorization': 'Bearer ' + access_token}
data = {"version":2,"inputs":[{"name":"X1","value":1.0},{"name":"X2","value":2.0}]}
r = requests.post(url, headers=headers, json=data)
y = json.loads(r.text)['outputs'][0]['value']
print(y)

(註:其中 pymodel 為專案中模型的名稱,transfer 為執行 Python 模型函數的名稱。)

至於在 MAS 中主要是使用 Python C API 執行 Python 程式,其主要是透過 C 程式碼操作 Python 程式中的物件,並且在 MAS 中能夠將其工作執行緒池中的每個 TK 執行緒產生一個 Python 程序,每個程序皆有本身的 Python 全局解釋器 (GIL),以利消除執行緒安全的問題,同時 Python 程序的負載平衡不需要任何其他功能,因為 TK 工作執行緒池已經有負載平衡的功能,並且每個 Python 程序將與每個執行緒進行相關聯,此外 MAS 和Python 程序之間主要是透過 Socket 來進行通訊,所以透過 SAS Micro Analytics Services 將能夠更安全且更有效率的執行 Python 程式碼。

最後我們還需要考慮軟體開發生命週期的要求,以及正式環境的平台是否支持批次分析和即時分析,在 SAS Viya 平台主要有 CAS 和 MAS,CAS 全名為 Cloud Analytic Service 主要用於批次分析,而 MAS 全名為 Micro Analytic Service 主要用於即時分析,因此我們需要根據需求規劃 CAS 伺服器和 MAS 伺服器資源和部署架構。此外完整的 SAS Viya 平台將依賴於 CAS 和 MAS,CAS 伺服器將主要用於設計處理和模型開發,MAS 伺服器將主要來測試即時模型和整合開發,通常開發環境具有比 MAS 資源更多的 CAS 資源,因為大多數處理工作負載來自模型開發和批次互動,而不是即時事務,至於正式環境則是建議比 CAS 資源更多的 MAS 資源。此外 MAS 更能夠在使用者或業務環境中同時處理多個程式,其中上下文主要是 SAS Micro Analytic Service 執行模組程式的容器,它提供了一個獨立的執行環境,在一個上下文中執行的程式對任何其它上下文皆不可見,並且執行模組可能需要存取外部資料或網站服務,此時就會需進行稽核記錄以根據記錄進行追蹤,此時 SAS Viya 平台中就有提供符合資訊安全政策的完整稽核記錄功能。

相關資源

模型部署 Azure (1)

教學目標

初步了解有關 Azure 進行模型部署的基本概念。

重點概念

首先 Microsoft 在 2019 年所發佈的這篇「Software Engineering for Machine Learning: A Case Study」研究論文中提到機器學習工作流程主要有九個階段,其中有些階段是與資料相關,像是資料收集、資料清理和資料標籤,有些是與模型相關,像是模型需求,特徵工程,模型訓練,模型評估,模型部署和模型監控,此外工作流程中有許多反饋循環,並且模型評估和監控可以循環回任何階段。常見的機器學習工作流程已經在各行業中有許多標準,像是 CRISP-DM,其在資料科學和資料的上下文中定義具有共通性,儘管存在細微差別,但這些仍然存在共同的過程和以資料為中心的本質。而不同階段之間的多個反饋循環,在模型需求階段,模型設計師需要決定哪個機器學習模型和功能是可行的,並且對於給定的現有產品或對於給定的現有產品可能有用,最重要的是在這個階段我們也會做出決定什麼類型的模型最適合所給定的問題。在資料收集階段中,團隊將會尋找和整合可用的資料集,像是內部、開源或外部收集,資料清理階段主要涉及從中刪除不準確或雜訊的資料,資料標籤階段則為每筆記錄分配適當的標籤,大多數監督學習技術皆需要標籤才能夠訓練模型,特徵工程階段則是指執行提取和選擇機器學習的資訊功能的所有活動,對於某些模型在此階段就不是那麼明確,因為經常與下一個階段融為一體,像是卷積神經網路。在模型訓練階段則是針對模型需求、資料收集、資料清理、資料標籤和特徵工程的輸出對應至模型的輸入進行訓練產生模型,模型評估階段則主要是評估輸出模型,並且使用預先定義的指標測試或保護資料集進行人工評估之後,才會產生推理程式碼進行模型部署階段,以及在實際執行期間持續進行模型監控階段。

接著機器學習工作流程是高度非線性,並且包含許多反饋循環,像是如果工程師注意到訓練資料之間存在的分佈和現實世界中的資料是一樣時,則會需要回去收集更多有代表性的資料,並且重新執行工作流程。同樣也可能會重新審查建模的選擇。此外反饋循環不僅在敏捷性軟體開發中是常見的工作流程,更在機器學習的工作流程中將會是非常棒的應用,因為最佳模型需要不斷進行實驗,事實上工程師進行機器學習的日常工作涉及對所選模型的頻繁迭代,超參數和資料集細化,這些工作流程將能夠成為綜合的系統,其中包括更複雜的內容,並且將多個複雜的機器學習元件在一起進行意想不到的互動方式,至於建立應用程式和平台與訓練和部署機器學習模型主要有三個基本的差異,分別為:

  1. 機器學習模型與資料非常相關,所以在於資料來源、資料管理和版本控管方面相對更複雜。
  2. 機器學習模型比起軟體工程的模組更難以維護嚴格的模組之間的界限,導致在訓練期間造成影響。
  3. 機器學習模型需求需要可客製和可擴展,所以團隊不僅擁有軟件工程技能,並且需要有足夠深入的機器學習知識,以利從頭開始建立、評估和調整模型。

當我們確定了機器學習系統架構和需求的各個方面,需要在此期間加以考慮系統設計,避免日後的技術債,其中一些方面包括隱藏的模型反饋循環、模型元件整合、模型品質狀態、現實世界與評估資料集之間對應不適當、… 等問題,同時最近討論了基於機器學習軟體對風險和安全性有何影響,在過去的五年裡產業界已經多次努力使這一過程自動化,透過建立框架和環境來支持機器學習的工作流程及其實驗性質。此時當建立大規模機器學習應用程式和平台,我們需要有在軟體工程領域有關機器學習的最佳實務,主要有七大項目,分別為:

  1. 端到端管線支援。
  2. 資料可用性、收集、清理和管理。
  3. 教育和培訓。
  4. 模型調整和解釋。
  5. 模型評估和部署。
  6. 法規遵循。
  7. 各種感知服務。

其中我們針對第一項目端到端管線支援更進一步深入了解,所謂端到端管線支援主要指隨著機器學習元件變得更加成熟,並且整合至更大的軟體系統時,則需要具有無縫的開發經驗能夠包括所描述的所有不同階段,此外自動化就會變得非常重要,然而為實現此目標,傳統機器學習模型和軟體工程模組相比具有不同的特性,因此軟體元件的整合程度將會具有挑戰,像是發現內在不確定性的變化或錯誤,以資料驅動的學習演算法和復雜隱藏反饋循環將引起的元件彼此的影響,即使在特定階段,將也可能會發生重大的影響,以及由於更多的迭代實驗是機器學習開發的本質,因此統一和自動化軟體將會有效減少日常工作流程所花費的時間,並且促進該領域的發展,此時企業需要利用內部基礎設施,或者建立專門自動化的機器學習管線支援,主要支援模型需求、訓練、評估、監控和部署,並且提供儀表板資訊即時顯示對於模型生命周期有價值的資訊,有助於團隊在發生問題時的第一時間進行的有效模型管理,避免造成重大的影響。

再來 Microsoft 針對模型管理則是提出使用 Azure Machine Learning 服務來管理模型的生命週期,並且使用機器學習服務作業 (MLOps) 的方法,更進一步改善機器學習解決方案的品質和一致性,並且提供從任何地方部署機器學習專案、監視機器學習應用程式的操作和相關問題、擷取建立機器學習生命週期的端對端稽核記錄所需的資料以及自動化使用 Azure Machine Learning 和 Azure DevOps 的端對端 ML 生命週期持續更新模型和測試新的模型,以利用於其它應用程式整合應用。其中從任何地方部署機器學習專案主要會先將訓練程式轉換成可重現的管線之後,註冊和追蹤機器學習模型,已註冊的模型是透過名稱和版本來識別,每次註冊與現有模型名稱相同的模型時,登錄都會遞加版本,並且能夠使用程式碼解析判斷要部署模型時使用適當的 CPU 和記憶體設定,以及使用所提供的資料進行模型評估,此外若轉換模型為 ONNX 格式的模型將能夠改善效能,平均而言將能夠產生二倍的效能提升,當完成模型評估之後會將最佳模型部署到生產環境,它會封裝成 Docker 容器映像檔,在大部分情況下建立的容器映像檔會自動在背景中進行模型部署。

最後 Microsoft 更有提供有關模型管理生命週期的解決方案的參考架構主要說明如何實作持續整合和交付 (CI / CD) 以及使用 Azure DevOps 和 Azure Machine Learning 的應用程式的重新訓練機器學習模型的管線。此解決方案建主要基於建立管線、重新訓練管線和發行管線。所謂建立管線主要當每次程式碼簽入,則取得觸發持續整合的管線,並且會進行單元測試和測試資料,所謂重新訓練管線會協調以非同步方式重新訓練模型、評估模型和註冊模型,所謂發行管線主要會執行評分的映像檔,並且安全地跨不同環境進行容器執行環境的部署,以及進行簡單的 API 測試可確保成功部署的容器映像檔,更進一步能夠將容器映像檔部署至正式環境的容器管理平台 Azure Kubernetes Service ,以利提供高效能、可擴展性和高可用性的評分服務。

相關資源

📖 more posts 📖