前言
在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更偏重与处理工业领域的物理实体映射，并不试图建立一个包含一切的建模环境，这种取舍，在工业领域是可以理解的。
优秀实践
1. 使用URI定义资源，并天然具有REST API的证删改查能力
2. 使用JSON-SCHEMA定义数据结构，来代替表，并提供灵活扩展能力（虽然对已有数据无法进行处理，需要用户自己实现）
3. 提供了查询语言，避免陷入无穷无尽的业务开发中去
4. 提供了JS支持，给用户以最大的扩展性
5. 微服务扩展灵活支持多租户
