1. 基本概念
AbleCloud数据分析平台Inspire，无论在系统架构还是在API设计方面，均构建在事件数据模型（Event Data Model）基础之上。在移动互联网时代，在万物互联的IoT时代，网络上活跃着大量的用户和设备。无论用户浏览APP，使用APP控制设备所产生的行为数据，还是设备在运行过程中主动汇报的状态数据，都可以发掘规律，从而挖掘出商业价值。此外，更为重要的是用户或设备的业务数据，比如用户身体健康指标、设备检测值等这些数据，能让厂商更精准的理解其用户，硬件厂商也能更准确的进行各种测量数据的分析挖掘。这样的每一个独立操作、测量、汇报等等行为，均是一个事件，下面介绍几个相关的概念。
- 事件（Event）：基本的事件可定义为某个主体在某一时刻，发生了某件事、产生了某个动作或出现了某个状态
- 事件属性（Event Property）：发生某一事件的同时，除了事件必要的元素外，其它用于描述该事件的附加属性数据。后文简称为Property。
- 主体属性（Actor Profile）：用于描述主体基本固定不变的特征数据。后文简称为Profile。
2. 模型详解
2.1 事件（Event）
前面介绍了事件的基本定义：某个主体在某一时刻发生的一个行为。这里展开讲解Event的方方面面，包括Event的特点、Event的划分、Event的设计等。
2.1.1 事件关键要素
- 主体（Actor）：必要要素。一个事件不可能凭空发生，一定是由某一主体触发产生的。这里的主体是广义的概念，可以是自然人如APP用户，也可以是硬件设备如空气净化器甚至可以是传感器。当前Inspire支持三种类型Actor：User、Device和Phone，分别对应厂商的终端用户、销售除去的设备以及用户所使用的手机。在写入事件数据的时候平台对这三类Actor字段有要求，分别为uid、did和pid。考虑到用于标识各种主体的id类型可能不同，因此Inspire并没有限制各种id的类型，可以为整形，也可以为字符串类型。未来，我们会进一步开放Actor类型，可由厂商自定义所需的Actor。
- 时间（Timestamp）：必要要素。时间在事件模型中是很重要的要素。我们知道“历史是不可更改的”，事件也一样一旦发生便不可改变，Timestamp则是用于追溯历史事件的关键要素。当前Inspire支持的Timestamp为UTC时间，精确到微秒。如果厂商在写入事件的时候不指定Timestamp，Inspire会在收到事件数据的时候填充上平台服务器当前时间，因此我们建议该要素由厂商指定，特别是在导入历史数据的时候必须显示指定。
- 属性（Property）：可选要素。伴随这事件发生的一些附加属性，这些属性数据用于描述或补充事件。Inspire对事件属性没有限制，可以指定任意类型、任意多的事件属性。
- 地点（Location）：可选要素。在现实世界中，地点和时间一样，一定是必不可少的事件要素，但是对于数据分析来说，地点则不是必须的，某些厂商只想了解全局信息，不关注事件发生的地点。对于要按地域做精细化分析的厂商来说，Inspire支持将IP地址自动转换为具体的省市区。未来，我们还将支持经纬度的地址转换功能。
这里给一个简单json格式的事件示例：
{
"event": {
"timestamp": "2015-07-03 18:38:03.262649+0800",
"ip": "127.0.0.1"
},
"uid": 123,
"product": {
"type": "mobile phone",
"model": "iphone 6s",
"price": 5488
}
}
2.1.2 事件数据特点
内容丰富
事件数据通常用于描述一个具体的行为动作，我们将从这些事件中挖掘出行为模式或历史规律，因此我们期望用来描述事件的属性（Property）越多越好。用于描述事件的属性越多，未来可进行分析挖掘的维度也就越丰富。例如，用户通过APP操作设备这一事件，最基本的我们可以包含哪个用户在什么时间点操作了哪个设备。这一动作可定义为只包含三个属性的简单事件（timestamp，uid，did），虽然正确但是缺陷很大。例如，随着业务的发展，我们想按用户使用的手机终端类型（Android/iOS）查看用户行为，我们想按地域分析用户的情况，我们想分析设备操作的具体结果情况（如测量值、操作类型）等等，均没法实现。因此，很多有用信息可以用来描述一个具体的事件，我们建议在事件发生时尽可能全的采集事件属性。我们可以把这一简单的操作事件扩展成这样（timestamp，uid，did，ios_type，location，op_value，...）的内容。
我们可以看到，在上例事件中，我们包含了一个主体（Actor）uid和一个客体（Object）did。当然，事件也可以简单到只有两个属性：时间和主体，例如用户注册的时间可以是（timestamp，uid）。原则上可以继续在事件数据中扩充uid和did的属性，如用户性别、年龄，设备类型、型号等等，可做更详细的分析挖掘。但是Inspire提供了更为强大的Profile机制，避免在每个事件中重复出现基本固定的属性，后文会详细讲解Profile。
尽管事件数据越丰富越好，但是也不能任意堆砌事件属性，我们把有价值的保留下来，对于无用的信息尽量能去除掉。
数量巨大
事件模型一大特定是记录的粒度细，我们期望不放过任何一个有意义的动作，每发生一个动作或设备状态发生一次更改，我们都希望记录下来，除了能精细化分析外，还能做历史根源追溯。IoT行业除了有大量的用户群体外，整个网络中还活跃这海量的设备、传感器。人除了睡觉休息之外，在活动的过程中会不断产生事件数据，而设备、传感器无需休息，几乎是每时每刻都可以产生各种数据，因此事件数据规模巨大。
非规范化
与传统crm、erp的数据分析方式不同，crm或erp系统中的历史数据是可以更新的，而事件一旦发生后是不可更改的，所以数据的保存方式也不同。例如，对于销售人员来说，如果其在一个月内销售了10件商品，在crm系统中每销售一件商品则对该销售人员的销售额进行一次更新
非结构化
2.1.3 事件类型划分
2.1.4 事件数据设计
我们认为，大数据，除了数据量大之外，粒度细、维度全也是“大”的一种体现。