Predix Asset Service深度分析

前言

在IIOT領域，面臨著保存海量數據的挑戰，具體到Asset層面，則要保存物理對象，邏輯對象，復雜的關系，并支持對象間的組合，分類，標簽和高效查詢。總結來說，可以歸納為如下幾種需求：

1. 靈活的建模風格：支持不同業務領域業務對象

2. 支持自定義屬性：可以是簡單的字符串，也可以是對象

3. 支持對象間關系：層次或圖關系

4. 支持對象間組合：如電機由線圈和轉子組成

5. 支持分類：對對象做宏觀分類并保存公共屬性

6. 支持標簽：方便用戶查詢

7. 支持靈活和高性能查詢：支持針對屬性，針對關系，層次等查詢。

8. 操作歷史：操作日志和審計

9. 業務能力擴展：腳本

架構

Predix架構如下所示：

• REST API layer

Client應用可以通過REST API服務獲取asset數據。這些接口提供了JSON形式的接口，用戶可以通過POST形式傳遞這些數據。為了使用這些API，應用程序發送HTTPS請求并解析響應。可以使用任何web端開發語言解析。

• Representation layer

Representation Layer將數據由JSON轉換為內部圖形式表示，也負責完成相反的過程。

• Query engine

Query engine允許開發者使用JSON AND Graph Expression(GEL)來獲取Asset Data Store中保存的任意對象或對象屬性的數據。

• Audit History Service

提供API用來獲取Asset Service庫中REST請求的歷史信息。

• Script engine

使用戶能夠將定制的業務邏輯綁定到Asset Service的REST API上。

• Cassandra graph database

Assert Service將數據保存于Apache Cassandra Nosql數據庫中

數據模型

asset

Asset模型可以理解為物理設備在虛擬世界的映射，Asset不但包含設備本身，也包含該設備如何組織和關聯的信息。

classification

對asset進行分類，并保存其公共信息。

custom modeling object

自定義的模型，用來進一步進行描述，如生產商等。

模型示例

Fleets Sample JSON

{

"uri":"/fleets/up-1",

"name":"Union Pacific Fleet 1",

"customer":"/customers/union-pacific"

},

Manufacturers Sample JSON

{ 

"uri":"/manufacturers/GE",

"name":"General Electric Transportation",

"year_founded":"1892",

"hqLatLng":{

        "lat":41.881138, 

        "lng":-87.640666}

}

Engines Sample Data

{

"uri":"/engines/v12-1",

"type":"7FDL",

"horsepower":"4400",

"stroke":"230",

"bore":"220",

"RPM":"2400",

"manufacturer":"/manufacturers/GE"

}

Locomotives Sample JSON

{

"uri":"/locomotives/1",

"type":"Diesel-electric",

"model":"ES44AC",

"serial_no":"001",

"emission_tier":"0+",

"fleet":"/fleets/up-1",

"manufacturer":"/manufacturers/GE",

"engine":"/engines/v12-1",

"installedOn":"01/12/2005",

"dateIso":"2005-12-01T13:15:31Z",

"hqLatLng":{

"lat":33.914605,

"lng":-117.253374

}

}

從上面的例子可以看出模型是如何組織的。

存儲分析

Asset的存儲要考慮兩個部分，json-schema和json。json-schema是json的校驗標準，任何對存儲系統的修改都需要使用json-schema校驗。更加抽象的思考，json-schema類似于面向對象的類，而json則是類的實現：對象。只是這種實例化是由RESTAPI觸發的，且合法性由json-schema保證。

由于工業領域需要面對海量對象，海量關系及多種結構的數據對象（blob value,,picture, log)等，傳統的SQL數據庫必然無法滿足這些需求，且對于JSON來說，最適合應用key-value數據庫類型，當然該數據庫需要提供良好的性能及可擴展性。

經過近些年的發展，cassandra與hbase在不同領域內的應用出現了分化，hbase紀玉hadoop，支持mapreduce，更加適合于大數據計算的場景；而cassandra除了在范圍查詢性能落后與hbase之外，在易用性，可擴展性，健壯性（無管理節點），以及在大多數的性能應用場景上對hbase存在優勢，因此考慮使用cassandra作為asset的存儲。

具體的，使用cassandra要滿足如下的要求：

• 良好的橫向擴展性

• 良好的可維護性

• 高性能

• 支持歷史記錄存儲

• 能夠擴展關系存儲及查詢

可擴展性

Predix提供了Javascript語言支持更多的自定義應用。

JS支持是JDK自帶的功能，而Predix將此功能應用在REST API上，能夠在REST API的執行前后運行JS腳本，實現功能的擴展。其中REST API既可以是資源的CRUD API，也可以是自定義API。其執行邏輯為：開始--->(JS代碼)--->REST API--->(JS代碼）-->系統通知

也即JS代碼可以選擇在REST API執行前后執行，如果JS代碼在REST API執行前，則可用于輸入數據校驗等，如果在REST API執行后，則可進行通知發送等應用。為了更加靈活的使用JS代碼，JS代碼中可以引用已經定義的工具方法（Predix提供），也可以調用其他REST API接口。

JS代碼執行時工業云應用必備的部分，如SCADA系統和Thingwrox均提供了JS代碼執行功能。但Thingwrox的JS執行依附于Thing本身（自定義方法）及訂閱，而Predix則基于對已有REST API的封裝（當然也支持自定義的REST API），總的來說Thingwrox實現的功能，predix也能實現。

例如：

        1. 調用系統方法（predix和thingwrox均提供了系統方法）

        2. 調用asset的屬性（均可，thingwrox可以在腳本中通過this.引用）

        3. 調用asset的方法（thingwrox可以，predix不明）

        4. 調用其他asset的屬性(predix通過restapi查詢）

        5. 調用其他asset的方法（可以實現，只要是REST API形式暴露）

        6. 執行結果返回（predix可以通過消息隊列返回數據）

關鍵技術

JSON-SCHEMA

http://json-schema.org/，

用以描述JSON的數據結構并做驗證，JSON-SCHEMA是靜態JSON描述，本身不具有任何約束力，需要在實現中加以限制：如執行新增操作時必須驗證SCHEMA。

CASSANDRA

CASSANDRA是一個key-value數據庫，具有高性能，高可靠性，去中心化等特性，并支持GRAPH擴展。

http://www.cnblogs.com/loveis715/p/5299495.html 

GEL

如果數據只能存儲而不能查詢，那就沒有任何意義。predix定義了GEL語言用于查詢Asset數據，該查詢語言是靈活的，支持分頁，過濾，正則表達式及關系查詢。Asset服務就是要存儲所有的模型數據，因此不能針對具體需求做針對性的開發。

在Asset  Service中，專門存在查詢引擎（Graph Expression Lanauge Query Engine）完成這一功能，這也是工業云平臺開發中所必須的。

業界比對

這里主要與Thingwrox做比對，Thingworx更是一個物聯網平臺，而Predix是工業云平臺，定位不同，決定了這兩個平臺在設計上的取舍不同。

從建模進行比較，Thingworx弱化了多租戶概念，并且基于對類-對象的抽象，給出了Thing-ThingTemplate-ThingShape的模型，能夠對每一物理/邏輯實體進行建模。如一個泵，或者是以datasource；而Predix更偏重與處理工業領域的物理實體映射，并不試圖建立一個包含一切的建模環境，這種取舍，在工業領域是可以理解的。