在物聯網設備，邊緣和雲上分配機器學習算法

在設計新的物聯網系統時，須要進行許多權衡，以肯定在系統的不一樣組件（設備，邊緣和雲）之間分配機器學習算法的最佳方法。電池壽命，物理尺寸，成本，實時鏈接需求，隱私問題以及調試/故障排除需求只是系統架構師在設計系統時須要考慮的一些問題。

典型的物聯網架構

典型的物聯網系統架構包括部署在物理空間中而且一般包括一個或多個傳感器的設備（或節點）; 在通訊協議之間橋接而且位於相對靠近設備的集線器（或網關或邊緣）; 存儲和處理數據的集中式雲環境，以及用戶能夠與之交互，探索數據和獲取通知的前端設備。顯然，有些設備直接與雲環境通訊，設備充當前端設備的場景，但從邏輯上講，這種架構描述了設置中的常見角色。

典型的物聯網系統架構

機器學習和信號處理算法

傳感器會生成大量數據。以16Khz採樣的高質量麥克風將產生256Kbps，若是以30幀/秒採樣，則640x480灰度相機可產生大約100Mbps。要實時計算設備的位置和方向，咱們須要每秒對加速度計進行100次採樣。

典型的物聯網系統可能包括數百甚至數千個設備，每一個設備都有多個傳感器，所以物聯網和大數據是兩個常常被一塊兒說起的流行語並不奇怪。

爲了從這個龐大的數據流中得到對用戶的相關看法，咱們一般須要使用機器學習和信號處理算法來處理數據。大多數時候，這些算法須要大量的計算資源，例如CPU，GPU和內存，它們既耗電又昂貴。能夠將計算資源放置在系統的每一個組件上：設備，集線器和雲，而後能夠處理經過或存儲在那裏的數據。所以，系統架構師決定如何在這些組件之間拆分/分配處理，以及如何根據權衡標準優化「成本」功能。

在物聯網設備，邊緣和雲上分配機器學習算法

設計注意事項

如下是影響有關如何跨設備，邊緣和雲分佈機器學習算法的決策的常見示例。

1. 物聯網設備電池壽命：源自電池容量，不一樣功耗模式（活動，待機，關閉）之間的佔空比以及傳感器，CPU和通訊接口的標稱功耗。將原始數據發送到雲將增長通訊接口的功耗，在本地處理數據將增長本地CPU的功耗。
2. 物聯網設備成本：源自傳感器，電池，CPU，通訊接口和機械部件的成本。
3. 物聯網設備尺寸和重量。
4. TCO（總擁有成本）：設備成本，雲成本，網絡成本，託管成本，安裝成本，支持成本等。
5. 實時需求：某些系統須要實時或近實時響應，而且不能容忍1-2秒延遲，這一般與將數據發送到雲並等待響應有關。例如，門鈴在兩秒鐘後沒法振鈴，這不是咱們指望的用戶體驗。
6. 加載通訊渠道：實時向雲端發送千兆位數據能夠阻止全部其餘流量，有時甚至是不可能的。
7. 對通訊鏈路服務質量的敏感性：算法的某些部分不能容忍通訊鏈路中斷。例如，即便沒有到互聯網的連接，警報系統也必須執行。
8. 算法需求：有時算法只須要訪問全部傳感器的全部原始數據以達到最佳性能。這種狀況的一個很好的例子是從多個視點對物體進行3D重建，其中來自多個（有時數百個）相機的實時饋送用於重建3D場景。
9. 爲多種平臺和多種語言開發：數據科學家一般使用Python，R或Matlab開發他們的算法並使用浮點計算。在分發機器學習算法時，極可能每一個環境都有不一樣的操做系統，不一樣的工具鏈和不一樣的軟件語言（Python，Scala，Javascript，C，C ++，定點......）。拆分算法並將其從一個環境遷移到另外一個環境是一個資源密集型過程，也是一個痛苦的過程，一般會影響算法的性能並引入錯誤和錯誤。
10. 調試/故障排除需求：機器學習算法永遠不會是靜態的。數據科學家將不斷面臨邊緣狀況和新算法，他們的算法失敗或須要改進其性能。爲了研究問題並提升準確性，數據科學家須要儘量多地訪問數據，有時甚至須要訪問原始數據。若是系統僅在設備級處理原始數據，而且原始數據不易被他們訪問，那麼他們將不得不作不少猜想來理解實際發生的事情。
11. 靈活性，靈活性和擴展性：一旦咱們決定了IoT設備的CPU和內存的大小並銷售/部署它們，它們就是固定的，沒法輕鬆擴展（咱們老是能夠替換物聯網設備並升級其計算資源，但相關的成本和複雜性是巨大的）。另外一方面，雲資源以及某種程度上的邊緣資源更加靈活。在雲環境中，性能和內存能夠在幾分之一秒內上下縮放，這使數據科學家能夠輕鬆地改進和升級那裏的機器學習算法。
12. 隱私，道德和安全問題：在某些狀況下，傳感器可能會收集咱們但願限制訪問的隱私數據或商業敏感數據。想象一下，基於攝像頭的佔用傳感器放置在會議室中，在會議室中呈現敏感材料。從理論上講，咱們能夠將視頻源發送到雲端並在那裏處理數據，但這會使系統面臨安全風險並可能引起道德問題。Alexa在本地檢測到「Alexa」這個詞，並無將咱們全部的對話都發送到雲端。只有在檢測到單詞Alexa時，纔會將如下請求流式傳輸到雲端。若是企業須要處理大量敏感數據，那麼邊緣多是雲和設備之間的中間位置，由於它位於企業內部而且還帶來了雲的一些好處。

亞馬遜Alexa

Alexa的例子

咱們已經提到了爲何亞馬遜決定在設備上本地檢測「Alexa」這個詞而不是雲端的緣由。例如，他們能夠分析設備上的全部語音，或者在雲中運行全部語音和NLP處理。決定以這種方式拆分算法還有一些好處：

成本：經過完善和優化設備算法以準確檢測一個單詞，亞馬遜成功地大幅下降了設備成本。另外一方面，若是他們決定檢測設備自己的全部可能的短語，他們將須要更強大和更昂貴的CPU。

TCO：經過在多個Alexa設備之間共享雲計算資源，亞馬遜設法下降整個解決方案的TCO。從統計上來講，假設每一個設備天天只生成幾分鐘的錄音，一個雲NLP處理器能夠處理數百個Alexa設備。

性能改進，支持更多技能並避免設備固件升級：每次用戶向Alexa發出請求時，亞馬遜都會將原始語音數據發送到他們的雲（AWS），在那裏進行處理，而後將其存儲數月，多是永久性的（I我在這裏作一個假設...）。當亞馬遜的數據科學家添加更多技能或更新他們的NLP算法時，他們擁有運行新軟件對歷史數據所需的一切，並自動驗證他們沒有下降性能（使用某種CI / CD管道）。所以，咱們每隔兩週就會看到Alexa中集成了新技能，這讓他們本身很容易測試和部署軟件更新，並設法避免將數百萬臺設備的遠程固件升級複雜化，這並不奇怪。

設計師必須作出的權衡是：

• 實時：咱們必須等待1-2秒才能聽到回覆。
• 對通訊中斷的敏感性：沒有互聯網鏈接，Alexa就沒用了。

摘要

在如下狀況下，支持在設備上或邊緣運行機器學習算法：

• 實時（或延遲）很重要
• 系統沒法容忍鏈接問題。
• 數據隱私和安全性是一個問題。
• 因爲帶寬或功率限制，您但願減小設備與雲之間的流量。

在如下狀況下支持在雲上運行機器學習算法：

• 全部其餘狀況......

結論

雖然有時咱們的網絡和雲基礎架構能夠擴展並承受幾乎任何負載，但實際上，因爲許多緣由，咱們沒法將全部原始數據發送到雲並在那裏處理。根據個人經驗，每一個用例都有不一樣的挑戰，須要仔細分析（這是樂趣的一部分）。我見過系統設計人員在選擇無線協議或選擇物聯網設備的CPU時作出過快關鍵決策的狀況。幾個月後，當他們製造數百臺設備並投入建設他們的知識和技能時，他們意識到他們沒法向雲發送足夠的數據，沒法遠程升級他們的算法或達到預期的性能。

另外一個重要且相關的教訓是，若是您的物聯網設備上有強大的CPU，並不老是意味着您必須使用它。儘管使用它頗有吸引力，但遠程配置管理和相關功耗的額外開銷也會有其代價。

關於如何在整個系統中分發機器學習算法，沒有一個公式或啓發式方法。咱們老是會有相互矛盾的約束，咱們須要作出權衡，軟件工程很快就會變得容易，相反，它會變得更加困難。

英文原文：medium.com/digital-cat…

更多文章歡迎訪問 http://www.apexyun.com/

聯繫郵箱：public@space-explore.com

(未經贊成，請勿轉載)