前言
在IIOT领域，面临着保存海量数据的挑战，具体到Asset层面，则要保存物理对象，逻辑对象，复杂的关系，并支持对象间的组合，分类，标签和高效查询。总结来说，可以归纳为如下几种需求：
灵活的建模风格：支持不同业务领域业务对象
支持自定义属性：可以是简单的字符串，也可以是对象
支持对象间关系：层次或图关系
支持对象间组合：如电机由线圈和转子组成
支持分类：对对象做宏观分类并保存公共属性
支持标签：方便用户查询
支持灵活和高性能查询：支持针对属性，针对关系，层次等查询。
操作历史：操作日志和审计
业务能力扩展：脚本
架构
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
自定义的模型，用来进一步进行描述，如生产商等。
| API Category | Description |
|---|---|
| Assets | 典型的，我们采用层次结构定义asset，由parent asset和一个或多个child asset组成。我们可以将asset与一个classification或任意数目的custom modeling object关联。Asset可以包含任意多个用户自定义属性（custom-defined attribute）。 一个asset也可独立存在于系统中，不与任何的其他建模元素关联。 |
| Classifications | 采用树状结构组织，并了一种对asset进行分组和跟踪公共属性的手段。一个classification可以指向多个asset。classification的任意层次上均可以指定attribute。 |
| Custom modeling objects | 定制模型对象（custom modeling object）是层次化的，我们可以使用它为asset提供更多的信息。例如，我们可以为asset location，manufactureer等创建单独的对象。一个location可以与多个asset关联，类似的，一个asset也可以关联多个location。 |
模型示例
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更偏重与处理工业领域的物理实体映射，并不试图建立一个包含一切的建模环境，这种取舍，在工业领域是可以理解的。
本文转自zsdnr 51CTO博客，原文链接：http://blog.51cto.com/12942149/1932740，如需转载请自行联系原作者
