邊緣計算急需解決的難題
目前邊緣計算已經得到了各行各業的廣泛重視，並且在很多應用場景下開花結果。根據邊緣計算領域特定的特點，本文認為6個方向是未來幾年迫切需要解決的問題：程式設計模型、軟硬體選型、基準程式與標準、動態排程、與垂直行業的緊密結合以及邊緣節點的落地。
1. 程式設計模型
程式設計模型可以使開發者快速上手開發應用產品，從而快速推動領域的發展.在雲端計算場景中，使用者程式在目標平臺上編寫和編譯，然後執行到雲伺服器，基礎設施對於使用者是透明的，例如亞馬遜基於此程式設計模型推出的 Lambda 計算服務，可使使用者無需預配置或者管理伺服器即可執行程式碼，極大地方便了使用者的使用.然而，邊緣計算模型與雲端計算模型存在較大的區別，從功能角度講，邊緣計算是一種分散式的計算系統，具有彈性管理、協同執行和環境異構的特點，如圖4所示：
從圖4可知，邊緣計算包含3個關鍵內容：
- 應用程式/服務功能可分割。邊緣計算中的一個任務可以遷移到不同的邊緣裝置去執行，任務可分割包括僅能分割其自身或將一個任務分割成子任務，任務的執行需要滿足可遷移性，即任務可遷移是實現在邊 緣裝置上進行資料處理的必要條件。
- 資料可分佈.資料可分佈既是邊緣計算的特徵也是邊緣計算模型對待處理資料集合的要求.邊緣資料的可分佈性是針對不同資料來源而言的，不同資料來源來源於資料生產者所產生的大量資料。
- 資源可分佈.邊緣計算模型中的資料具有一定的可分佈性，從而要求處理資料所需要的計算、儲存和通訊資源也具有可分佈性.只有當邊緣計算系統具備資料處理和計算所需要的資源，邊緣裝置才可以對資料進行處理。
因此，傳統的程式設計模型並不適合邊緣計算。邊緣計算中的裝置大多是異構計算平臺，每個裝置上的執行時環境、資料也不相同，且邊緣裝置的資源相對受限，在邊緣計算場景下部署使用者應用程式會有較大的困難。Li等人針對邊緣裝置資源受限的特性設計了一種輕量級的程式語言EveryLite，該工作將計算遷移任務中主體為介面呼叫的、時間和空間複雜度受限的計算任務稱為微任務(micro task)， EveryLite能夠在物端裝置上處理邊緣計算場景中微任務，經過實驗對比可以發現EveryLite的執行時間分別比JerryScript和Lua低77%和74%，編譯後記憶體佔用量分別是JerryScript和Lua的18. 9% 和1. 4%。因此，針對邊緣計算場景下的程式設計模型的研究具有非常大的空間，也十分緊迫。
2. 軟硬體選型
邊緣計算系統具有碎片化和異構性的特點。在硬體層面上，有CPU，GPU，FPGA，ASIC等各類計算單元，即便是基於同一類計算單元，也有不同的整機產品，例如基於英偉達GPU的邊緣硬體產品，既有計算能力較強的DRIVEPX2,又有計算能力較弱 的Jetson TX2 ;在軟體系統上，針對深度學習應用， 有 TensorFlow, Caffe, PyTorch 等各類框架.不同的軟硬體及其組合有各自擅長的應用場景，這帶來了一個問題：開發者不知道如何選用合適的軟硬體產品以滿足自身應用的需求。
在軟硬體選型時，既要對自身應用的計算特性做深人瞭解，從而找到計算能力滿足應用需求的硬體產品，又要找到合適的軟體框架進行開發，同時還要考慮到硬體的功耗和成本在可接受範圍內.因此，設計並實現一套能夠幫助使用者對邊緣計算平臺進行效能、功耗分析並提供軟硬體選型參考的工具十分重要。
3. 基準程式和標準
隨著邊緣計算的發展，學術界和工業界開始推出越來越多的針對不同邊緣計算場景設計的硬體或軟體系統平臺，那麼我們會面臨一個緊迫的問題，即如何對這些系統平臺進行全面並公平的評測.傳統的計算場景都有經典基準測試集(benchmark),例如平行計算場景中的PARSEC、高效能運算場景中的 HPCC、大資料計算場景中的BigDataBench。
由於邊緣計算仍然是較新的計算場景，業界仍然沒有一個比較權威的用於評測系統性能的Benchmark出現，但是學術界已經開始有了一些探索工作SD-VBS和MEVBench均是針對移動端裝置評測基於機器視覺負載的基準測試集. SD-VBS選取了28個機器視覺核心負載，並提供了C和Matlab的實現;MEVBench則提供了一些列特徵提取、特徵分類、物體檢測和物體追蹤相關的視覺演算法負責，並提供單執行緒核多執行緒的C++實現. SLAMBench是一個針對移動端機器人計算系統設計的基準測試集，其使用RG&D SLAM作為評測負載，並且針對不同異構硬體提供C++，OpenMP， OpenCL 和 CUDA 版本的實現.CAVBench是第1個針對智慧網聯車邊緣計算系統設計的基準測試集，其選擇6個智慧網聯車上的典型應用作為評測負責，並提供標準的輸人資料集和應用-系統匹配指標。
由於邊緣計算場景覆蓋面廣，短期來看不會出現一個統一的基準測試集可以適應所有場景下的邊緣計算平臺，而是針對每一類計算場景會出現一個經典的基準測試集，之後各個基準測試集互相融合借鑑，找出邊緣計算場景下的若干類核心負載，最終形成邊緣計算場景中的經典基準測試集。
4. 動態排程
在雲端計算場景下，任務排程的一般策略是將計算密集型任務遷移到資源充足的計算節點上執行. 但是在邊緣計算場景下，邊緣裝置產生的海量資料無法通過現有的頻寬資源傳輸到雲端計算中心進行集中式計算，且不同邊緣裝置的計算、儲存能力均不 相同，因此，邊緣計算系統需要根據任務型別和邊緣裝置的計算能力進行動態排程.排程包括2個層面：
- 雲端計算中心和邊緣裝置之前的排程;
- 邊緣裝置之間的排程。
雲端計算中心與邊緣裝置間的排程分為2種方式：自下而上和自上而下。自下而上是在網路邊緣處將邊緣裝置採集或者產生的資料進行部分或者全部的預處理，過濾無用資料，以此降低傳輸頻寬;自上而下是指將雲端計算中心所執行的複雜計算任務進行分割，然後分配給邊緣裝置執行，以此充分利用邊緣裝置的計算資源，減少整個計算系統的延遲和能耗. 2017年，Kang等人設計了一個輕量級的排程器 Neurosurgeon,它可以將深度神經網路不同層的計算任務在移動裝置和資料中心間自動分配，使得移動裝置功耗最多降低了 94.7%，系統延遲最多加快了40.7倍，並且資料中心的吞吐量最多增加了6. 7倍.邊緣裝置間也需要動態排程。邊緣裝置的計算、儲存能力本身是不同的，並且會隨著時間的變化而變化，而它們承擔的任務型別也是不一樣的，因此需要動態排程邊緣裝置上的任務，提高整體系統效能，防止出現計算任務排程到一個系統任務過載情況下的裝置.Zhang等人針對延遲敏感性的社會感知任務設計了一個邊緣任務排程框架C〇GTA，實驗證明該框架可以滿足應用和邊緣裝置的需求。
綜上所述，動態排程的目標是為應用程式排程邊緣裝置上的計算資源，以實現資料傳輸開銷最小化和應用程式執行效能的最大化.設計排程程式時應該考慮：任務是否可拆分可排程、排程應該採取什麼策略、哪些任務需要排程等.動態排程需要在邊緣裝置能耗、計算延時、傳輸資料量、頻寬等指標之間尋找最優平衡.根據目前的工作，如何設計和實現一種有效降低邊緣裝置任務執行延遲的動態排程策略是一個急需解決的問題。
5. 和垂直行業緊密合作
在雲端計算場景下，不同行業的使用者都可將資料傳送至雲端計算中心，然後交由計算機從業人員進行資料的儲存、管理和分析。雲端計算中心將資料抽象並提供訪問介面給使用者，這種模式下計算機從業人員與使用者行業解耦和，他們更專注資料本身，不需對使用者行業領域內知識做太多瞭解。
但是在邊緣計算的場景下，邊緣裝置更貼近資料生產者，與垂直行業的關係更為密切，設計與實現邊緣計算系統需要大量的領域專業知識。另一方面，垂直行業迫切需要利用邊緣計算技術提高自身的競爭力，卻面臨計算機專業技術不足的問題.因此計算 機從業人員必須與垂直行業緊密合作，才能更好地完成任務，設計出下沉可用的計算系統.在與垂直行業進行合作時，需要著重解決3個問題：
- 減少與行業標準間的隔閡。在不同行業內部有經過多年積累的經驗與標準，在邊緣計算系統的設計中，需要與行業標準靠近，減少隔閡。例如，在針對自動駕駛汽車的研究中，自動駕駛任務的完成需要使用到智慧演算法、嵌人式作業系統、車載計算硬體等各類計算機領域知識，這對於計算機從業人員而言是一個機遇，因此許多網際網路公司投人資源進行研究。然而，若想研製符合行業標準的汽車，僅應用計算機領域知識是完全不夠的，還需要對汽車領域專業知識有較好的理解，例如汽車動力系統、控制系統等，這就需要與傳統汽車廠商進行緊密合作。同樣，在智慧製造、工業物聯網等領域，同樣需要設計下沉到領域內、符合行業標準的邊緣計算系統。
- 完善資料保護和訪問機制。在邊緣計算中，需要與行業結合，在實現資料隱私保護的前提下設計統一、易用的資料共享和訪問機制.由於不同行業具有的特殊性，許多行業不希望將資料上傳至公有云，例如醫院、公安機構等。而邊緣計算的一大優勢是資料存放在靠近資料生產者的邊緣裝置上，從而保證了資料隱私.但是這也導致了資料儲存空間的多樣性，不利於資料共享和訪問.在傳統雲端計算中，資料傳輸到雲端 ，然後通過統一介面來訪問，極大地方便了使用者的使用.邊緣計算需要藉助這種優勢來設計資料防護和訪問機制。
- 提高互操作性。邊緣計算系統的設計需要易於結合行業內現有的系統，考慮到行業現狀並進行利用，不要與現實脫節。例如在視訊監控系統中，除了近些年出現的智慧計算功能的攝像頭，現實中仍然有大量的非智慧攝像頭，其每天仍然在採集大量的視訊資料，並將資料傳輸至資料中心。學術界設計了A3系統，它利用了商店或者加油站中已有的計算裝置。然而實際情況下，攝像頭周邊並不存在計算裝置。因此，在邊緣計算的研究中需要首先考慮如何部署在非智慧的攝像頭附近部署邊緣計算裝置. 在目前的解決方案中，多是採用建立更多的資料中心或AI—體機來進行處理，或者採用一些移動的裝置，如各種單兵作戰裝置，來進行資料的採集.前者耗費巨大，且從本質來說，仍然是雲端計算的模式;後者通常使用於移動情況下，僅作為臨時的計算中心，無法和雲端進行互動。在視訊監控領域，Luo等人提出了一個尚屬於前期探討的EdgeBox方案，其同時具備計算能力和通訊能力，可以作為中介軟體插人到攝像頭和資料中心之間，完成資料的預處理. 因此，如何與垂直行業緊密合作，設計出下沉可用的邊緣計算系統，實現計算機與不同行業間的雙贏是邊緣計算面臨的一個緊迫問題。
6. 邊緣節點落地問題
邊緣計算的發展引起了工業界的廣泛關注，但是在實際邊緣節點的落地部署過程中，也湧現出一些急需解決的問題，例如應該如何建立適用於邊緣計算的商業模式、如何選擇參與計算的邊緣節點和邊緣計算資料、如何保證邊緣節點的可靠性等。
1)新型商業模式.在雲端計算場景下，雲端計算公司是計算服務的提供者，它們收集、儲存、管理資料並且負責軟硬體、基礎設施的建設和維護，使用者付費購買服務，不需要關注計算節點本身的成本，也無需關注服務質量的升級換代過程.這種商業模式為使用者使用雲服務帶來了便利，也讓雲端計算公司具備盈利能力，從而更好地提高服務質量。
而在邊緣計算場景下，邊緣節點分佈在靠近資料生產者的位置，在地理位置上具有較強的離散性，這使得邊緣節點的統一性維護變得困難，同時也給軟硬體升級帶來了難度。例如提供安全服務的攝像頭，在使用過程中需要進行軟硬體的升級，軟體的升級可以通過網路統一進行，而硬體的升級需要親臨現場.依賴於服務提供者去為每一個邊緣節點(攝像頭)進行硬體的升級和維護會帶來巨大的成本開銷，而服務的使用者一般不關注也不熟悉硬體裝置的維護工作.又如，在CDN服務的應用中，需要考慮 CDN伺服器是以家庭為單位還是以園區為單位配置，不同的配置方式會帶來成本的變化，也為服務質量的穩定性增加了不確定因素，而維護CDN所需的開銷，需要考慮支付者是服務提供者還是使用者。
因此工業界需要尋求一種或多種新的商業模式來明確邊緣計算服務的提供者和使用者各自應該承擔什麼責任，例如誰來支付邊緣節點建立和維護所需的費用、誰來主導軟硬體升級的過程等。
2) 邊緣節點的選擇。邊緣計算是一個連續統，邊緣指從資料來源到雲端計算中心路徑之間的任意計算和網路資源。(在實際應用中，使用者可以選擇雲到端整個鏈路上任意的邊緣節點來降低延遲和頻寬.由於邊緣節點的計算能力、網路頻寬的差異性，不同邊緣節點的選擇會導致計算延遲差異很大.現有的基礎設施可以用作邊緣節點，例如使用手持裝置訪問進行通訊時，首先連線運營商基站，然後訪問主幹網路.這種以現有基礎設施當做邊緣節點的方式會加大延遲，如果手持裝置能夠繞過基站，直接訪問主幹網路的邊緣節點，將會降低延遲.因此，如何選擇合適的邊緣節點以降低通訊延遲和計算開銷是一個重要的問題.在此過程中，需要考慮現有的基礎設施如何與邊緣節點融合，邊緣計算技術會不會構建一個新興的生態環境，給現有的基礎設施發生革命性的變化?
3)邊緣資料選擇。邊緣節點眾多，產生的資料數量和型別也眾多，這些資料間互有交集，針對一個問題往往有多個可供選擇的解決方案.例如在路況實時監控應用中，既可以利用車上攝像頭獲得資料，也可以利用交通訊號燈的實時資料統計，還可以利用路邊計算單元進行車速計算。因此如何為特定應用合理地選擇不同資料來源的資料，以最大程度地降低延遲和頻寬，提高服務的可用性是一個重要問題。
4)邊緣節點的可靠性。邊緣計算中的資料儲存 和計算任務大多數依賴於邊緣節點，不像雲端計算中心有穩定的基礎設施保護，許多邊緣節點暴露於自 然環境下，保證邊緣節點的可靠性非常重要.例如， 基於計算機視覺的公共安全解決方案需要依賴智慧攝像頭進行儲存和計算，然而在極端天氣條件下，攝像頭容易在物理上收到損害，例如暴風天氣會改變攝像頭的角度，暴雪天氣會影響攝像頭的視覺範圍， 在此類場景中，需要藉助基礎設施的配合來保證邊緣節點的物理可靠性。同時，邊緣資料有時空特性，從而導致資料有較強的唯一性和不可恢復性，需要設計合理的多重備份機制來保證邊緣節點的資料可靠性.因此，如何藉助基礎設施來保障邊緣計算節點的物理可靠性和資料可靠性是一個重要的研究課題。
在邊緣節點落地過程中，已經有了不少嘗試，例如聯通提出了建設邊緣雲，其規劃至2020年建設6000~7000個邊緣節點，將高頻寬、低時延、本地化業務下沉到網路邊緣，進一步提高網路效率、增強服務能力.因此針對如何選擇邊緣節點，處理好邊緣節點與現有基礎設施的關係，保證邊緣節點的可靠性的研究非常緊迫。