物联网云的存储与应用架构——Architecting IoT Cloud

存储框架

存储体系可以大分类为三种，分别是冷暖热存储。
冷存储表示存储空间巨大且可以存储不同结构的数据，但是调用缓慢，大部分数据需要进行转换处理才能被使用，存储数据的量最大，性能最低，安全性最高。
热存储则是表示经常被使用的数据，它们存在数据库中，这些数据因为经常被使用，在网络上传输次数也多，所以安全性相对最低，但是由于靠近内存，调用速度最快效率最高，因此性能最佳。内存造价高昂，因此存储数据的提及最小。
暖存储介于二者之间，各项属性相对均衡。
三种存储对应的数据存储结构分别是数据湖，数据仓库和数据库，这三类结构将在下文详细介绍。

数据类型

数据可以分为以下几类

• 结构数据[structured]：很容易找到的数据，在关系型数据库中存储，总是可以用表格（行和列）表达数据关系
• 非结构数据[unstructured]：关系型数据库很难描述的数据，如邮件文本，文本文档，音频影像等。
• 半结构数据[semi-structure]: 非结构数据的一些特别标示符，如邮件文本虽然是非结构数据，但是邮件的发送日期，发送人，收信人等确实可以用表格来表示关系，照片的拍摄日期，地点，PID等都属于非结构数据中的结构数据，也就是半结构数据。
• 多态数据[polymorphic]：数据的不同类型，如整数型，浮点数形，字符串等多种数据类型。

数据的存储系统-数据库

2个构成要素，数据库在硬盘上以文件的形式上存储并由操作系统调用数据库的数据。程序的执行需要在内存上执行。没有程序硬件上的数据无法被可视化，这里的acess指的是增删查改。 程序分为用户和系统程序(User/system)

SQL-传统的关系型数据库

传统关系型数据库，可以使用表格来表示其固有属性。为了方便称呼，我们将关系型数据库缩写RDB作为本文中的名称。RDBMS则是关系型数据库管理系统。

关系型数据库有一个表重要的概念——范式。将数据无冗余的存储在数据库中从而提高对数据操作的效率。
第一范式： 无重复的列，数据不可再分即可。即如果有一列名为人类，且数据库有男人和女人两属性，则该数据库不满足第一范式。
第二范式： 数据库本身是第一范式且列元素均从属于主键。
第三范式： P->Q->R，数据库关系存在传递性，不属于主键的所有属性全部依赖于主键且没有内部依赖。

事务的ACID：数据库的操作以事务的形式进行，事务有四个性质以保证数据库的正确性。
Atomicty: 原子性。事务要么执行，要么不执行，不能部分执行。如A给B转账一百元，完成这个操作需要从A的账户-100再给B的账户+100，这个事务不能存在A扣款了但是B的金额未增加，或者B增加了金额A未扣款。
Consistency： 一致性。 事务不论成功与否，执行后不影响事务的完全约束条件。即这稿操作无论如何，进行变动的总额度为0，即一个人-100一个人+100，其和为0，不会凭空出现数据的增减。
Isolation： 隔离性。一个事务的结果不会影响其他事务的执行的结果。很好理解，A和B的交易与D和C的交易是两个独立的事务，两个事务不会对彼此的事务产生影响。如果是A-B,B-C交易的两个事务，因为两个事务有访问共同资源，这是使用锁【lock】机制，保证当一个事务执行完成后才可以对另一个事务进行执行权的赋予。
Durability： 持续性。 事务完成后，不可回滚数据库。即当转账已经完成，不会因为网络原因，掉电事故等导致交易重置。

以上就是RDB的核心知识。DRB使用表格-行列的形式存储关系型数据，关系型数据均为结构数据。

NoSQL-新型数据库

NoSQL=Not Only SQL/ Not SQL，NOSQL是一个广泛的术语，涵盖了解决几个关键主题的各种技术，如非关系、分布式、开源和水平可伸缩。NoSQL数据库旨在满足大型、分布式数据存储需求，通常用于大数据和实时使用的web应用程序。NoSQL包含了多种数据库技术，可以容纳多态、非结构化、半结构化或结构化数据。

NoSQL可以分为以下四类：

K-V：实现结构非常简单，旨在以无模式的方式存储由索引键和值组成的数据。
Document: 文档类，可以在DB中存储任意数据类型（多态数据），没有空列，可以存储半结构数据。每个文档都有一个检索特定文档所需的惟一键，该文档旨在存储、管理和检索半结构化的面向文档的数据

Column：宽列存储。这些数据库不是将数据存储在一行中，而是将数据表存储在垂直列中。虽然这听起来像是简单的水平和垂直调整，但列存储实际上提供了高质量的性能和极其可伸缩的架构
Graph：使用图论，设计数据表示为相互关联的元素之间的关系数目未定的图，更好的表达数据之间的关系。

所以，简单的总结一下SQL/NoSQL的取舍，如下图所示。

当数据出现非结构数据，不支持ACID,要求分布式系统处理等，使用NoSQL。而当数据是结构数据且想要高效快速处理数据，则使用SQL。

下面是几个NoSQL数据库的典例。

MongoDB

MongoDB是一个面向文档的跨平台数据库，提供高性能和数据可用性，同时易于扩展; MongoDB能够支持不同的模式、平衡负载、处理复制、索引、查询和归档。

如上图所示是RDB与MongoDB的一些术语差距。
Collection: 基本的数据存储单位集合。相当于RDB的表，数据的类型可以不同，但是需要相互之间存在关系。
Document： 基本的数据存储单位。
Relationship：在MongoDB中，数据有两种关联方式。一种是全加入，一种是引用。全加入是A文档全部加入B文档，所有数据存在一个文档内，这样当一个文档丢失另一个也会丢失，存在风险。引用则是在文档A的结尾追加一个连接到B的链接，然后通过链接访问文档B,文档AB在不同的地址保存，这样一个数据丢失另一个不会丢失，但是同时通过链接访问另一个数据对时间和CPU的开销要比全加入大得多。

总体来说，MongoDB的优点是具有无模式存储数据的灵活性，不需要在意存储数据的类型，并且有类似SQL语言的高效处理数据的能力，很便利。其次，水平扩展MongoDB非常简单，扩展性好。MongoDB是“面向对象的”，可以很容易地表示域中的任何对象结构。MongoDB使各种规模的组织能够更快地构建数据驱动的应用程序。不需要将数据分散到不同的关系表中，所有数据只能在一个地方找到。

Cassandra

Cassandra是一个存储高可用，无故障的大容量存储半结构数据的去中心化分布式数据库。它的数据存储单位是以列为单位的，行被视为列的值。有CQL数据操作语言，查询速度快，效率比SQL还要高。但是不支持RDB中的join，group by， Foreign key等形式的读写操作。

与DRB的基本构成等价关系如上图所示。
它的构成要素：

• key sapce： 数据存储的容器，至少也要有一个以上的基本单位（列）。

• column families： 列族。基本的数据存储单位的集合，行信息为其值，能表示带有顺序的数据，这些数据体现了数据的结构。

• column：列。数据的基本存储单位，可以存储的值有列名，对应值和时间戳。

• super column： 超级列。 超级列是惟一的，存储子列和键值的映射关系，有唯一的列名和数量。

综上所述，Cassandra的优点概括一下

可伸缩性：高可伸缩性，允许添加新的硬件，以适应更高的客户量和额外的数据。
Always On： 该结构不包含单点故障，并且可以持续地容纳不会失败的关键业务应用程序。 线性扩展性能随着集群节点数量的增加而提高吞吐量，保持快速响应时间。
可适应数据存储：存储非结构化、半结构化和结构化数据，并可以根据需要伸缩以适应数据结构中的更改。
分布数据：有效地跨多个数据节点复制数据，以便在需要的地方分布数据。
事务属性： 支持支持原子性、一致性、隔离性和持久性(ACID)事务。 高效写运行在低成本的商用硬件上，在存储数百tb数据的同时，写得惊人地快，而不降低读取能力。

总结即由于可追加硬件设备而扩张性强，分布式数据提供了高速处理能力和备份数据，低成本的商用硬件可以实现所有数据结构的存储，且满足ACID事务特点。

Redis

Redis可以处理所有数据类型的数据，如字符串，链表，无序集合，有序集合，哈希值等。字符串可以表示所有类型的数据，链表保留了数据的插入顺序，哈希值对于数据库操作很容易且保持映射关系。

优点是保证了所有的数据都在内存中，因此处理效率极高；作为持续的硬盘数据库，读写均可且写是可选择的。 原子的数据库操作方式保证了并发操作也可以保证精确度，这个数据库比起存储数据，作为工具在其他领域使用也是非常好的选择。

influxDB

是一个对IoT设备而言非常好的数据库。有效的存储时间序列从而帮助IoT设备传感器采集数据，有类SQL的专属操作语言可以对数据库进行高效操作。能够高速读写且扩张性很好。

构成如下：
Time：每个fluxdb数据库都包含一个时间列，该列存储与相应数据相关联的时间戳
Filed：字段是数据结构中负责记录真实数据值和元数据的键值对[ID]。字段由字段值和字段键组成。字段键是字符串并存储元数据。字段值可以是浮点数、字符串、布尔值或整数形式。作为一个时间序列数据库，inflxdb要求每个字段值与特定的时间戳相关联
Tag:标签由标签值和标签键组成。标签值和键被维护为字符串并表示元数据
Measurement：这也可以看作是一个SQL表，因为度量作为时间列、字段和标记的容器
Relation policy: 保留策略描述了一个inflxdb数据库存储数据的时间(持续时间)以及集群中保留的数据副本的数量(复制因子)。超过给定持续时间的数据将自动从数据库中删除。一般情况下，最小保持时间为1小时，最大保持时间为无限长。
Sharding： 分片是指数据的水平分区，每个分区称为一个分片。influxdb还利用分片来解决可伸缩性问题。每个分片保存特定系列集的压缩实际数据。

Elasticsearch

ES是一个面向文档的数据库，用于保存、管理和检索半结构化或面向文档的数据。同时也是一个非常流行的搜索引擎

它的结构如下：
Cluster： 集群。集群是服务器(节点)的集合，当它们连接在一起时，可以保存完整的数据集，并为所有连接的服务器提供联合索引和搜索功能。服务器的集合，用于联合计算和检索，提高处理效率，每个集群都有一个ID作为标识符
Node： 服务器的个体，带有整个集群的一部分数据。可以根据集群ID分配不同的节点给特定集群

• 主节点：负责构建或消除索引，添加或删除节点。每次集群状态发生变化时，主节点都会通知集群中的其他节点。每个集群一次只包含一个主节点
• 客户端节点：通过充当“智能路由器”，它处理向主节点发送与集群相关的请求，以及向数据节点发送与数据相关的请求。客户端节点不包含数据，无法成为主节点。.
• 数据节点： 每个节点都包含一个数据分片，并处理与数据相关的操作。集群中包含多个数据节点。如果集群中的一个数据节点应该停止，集群将继续操作，并在其他节点上重新排列该节点的数据。
• 摄取节点： 在实际索引之前，它处理文档的初步处理

Index： 索引是具有相似特征的文档的集合。索引由唯一的名称表示，该名称在执行操作时用于引用索引。一个集群可以包含任意多的索引。

Document： 文档只是以特定JSON格式组织的字段的集合。每个文档都属于一个类型，并存储在一个索引中，该索引与唯一标识符(UID)相关联。
Type/Mapping: 映射指的是在同一个索引中共享一组公共字段的文档集合。
Shard&Replica： 索引能够存储超出节点硬件能力的海量数据。

• 分片shard：可以水平分割或缩放内容体积。可以跨多个节点的分片分布和并行操作，从而提高性能和吞吐量
• Elasticsearch允许用户创建索引碎片的一个或多个副本，称为复制碎片或简单地称为“副本”，它在分片或节点故障的情况下提供了更高的可用性;因此，不应该将副本分配给创建它的原始分片的相同节点。它支持搜索量和吞吐量的可伸缩性，因为搜索可以同时在所有副本上执行
  Elasticsearch默认允许每个索引分配5个主碎片和1个副本，这意味着如果集群中有两个节点，该索引将有5个主碎片和5个后续副本(一个完整的副本)，每个索引总共10个碎片

Aggregation： 聚合。Elasticsearch能够支持聚合，使用户能够从数据中提取组或统计信息。在Elasticsearch中，用户可以执行生成点击的搜索，并同时返回聚合的结果，所有这些都在一个响应中

Logstach: 通常，Elasticsearch与Logstash一起使用，Logstash是一个开源的服务器端数据处理管道，它同时从大量数据源中获取数据，将其转换，然后将其传输到目标。分为三步，本别是数据获取，数据转换和数据传送。数据获取是以比特流的方式获取各种原数据，然后将难以操作的原数据进行数据转换，变为可方便操作的数据，然后将其传输给目的地，然后进行数据操作后，使用kibanna等工具将数据进行可视化处理 。

CAP理论

CAP理论指的是如上图所示的三种特性同时最多只能满足两种，另外一种必然无法满足的特性。
CAP分别是一致性，可用性，和容错性。一致性表示了节点的数据应该同步，一个数据操作完成后，分布式系统内的其他节点的对应数据也应该被更新。可用性表示每个请求必然有一个回应，不论成败都应有一个ACK，换言之服务一直是可用的。容错性表示即便出现了内部部分错误也应该继续提供服务。

CP： 没有A。不满足可用性，即允许每个请求可用无响应，则可用保证网络内节点高同步和容错性。即便网络出现故障，因为可用无视故障部分的相应，所以其他正常节点数据均可以同步且提供服务。
AP：没有C。NoSQL的代表，每个节点使用本地数据，不保证数据一致性则可用保证有求必应和容错。因为不要求同步数据，所以每一个节点可用无等待的处理对应事务从而满足有求必应，且网络故障时直接返回无法处理的结果。
CA：无P。数据要求高可用性和一致性数据，则此时网络故障时，除非整个网络无法运行不然无法提供部分服务。

数据仓库Data Warehouse

数据仓库的数据主要用于数据挖掘，数据分析，解决数据孤岛问题，为了帮助企业商用化政策决策而制定的数据库，只能处理结构数据。数据仓库的数据存储量大于数据库。

数据仓库与数据库的区别：
数据仓库存储的主要是历史数据，而数据库存储日常常用数据。RDB因为范式标准，冗余数据少，事务处理时间也少，实时作业性能高，主要处理当下数据；但是数据仓库的建立目的不是为了处理事务，而是根据历史进行数据分析，使用未范式的数据进行数据处理，用于历史数据分析维护。

数据湖 Data Lake

储存数据量最大，存储所有结构的数据，且是原数据。这些原数据可能存在不完整，有错误，或者价值未知，当下技术不可控等特点，这些数据在调用时需要消耗大量时间，要求使用ETL/ELT进行操作。有着足够的存储能力，相应 数据管理系统很重要，如果没有数据管理系统则会成为数据沼泽[swamp]。

上图是数据湖与其他RDB/数据仓库的比较图。

ETL/ELT

数据湖中的数据因为结构不一且数据的完整性和各种性质均不一致，导致这些数据无法直接用于分析或规范化处理。因此数据需要使用ETL/ELT操作来进行数据规范。
ELT分别是[Extract,Load,Transform]：数据提取，数据加载，数据传输。
整体过程如下：
E： 数据提取。从数据湖中提取目标数据集，该数据集数据杂乱不堪，无法直接处理。这一步需要确认源，数据湖数据量很大，确认源数据在哪并不容易，其次要定义接口，对数据提取的接口、源文件或者系统的数据存档进行说明。
L： 数据加载，将处理好的数据存储到目标容器，可以是数据库或者数据仓库。这一步内可以使用缓存来提高加载效率，如果是增量数据则使用MERGE。
T： 数据转换。该步骤内将原数据首先进行数据清洗[clean]，将不可用数据，重复数据，损坏数据等数据取出后，进行数据类型转换，转换成便于存储的结构数据，然后将结构数据进行关联[赋予关系]，并准备加载。

数据湖面临的挑战

如果没有描述性元数据和维护它的机制，数据湖就有变成数据沼泽的风险。
数据目录:数据目录使用户能够编译和审查元数据和索引数据，以便它们成为可搜索的。一个索引，用于检索数据湖的数据
数据质量:使用主数据管理(MDM)，这是一个基础过程，用于根据业务操作策略同步、分类、集中、组织、丰富或本地化主数据。它只兼容结构化数据。根据多种规则进行数据管理的标准
数据跟踪:数据跟踪指的是数据的来源、对它做了什么以及随着时间的推移它的位置。拥有完整的数据审计跟踪，包括原始数据、转换信息及其分析用途，是满足大多数组织目前面临的数据安全监管要求的必要条件数据溯源保证数据的安全性
数据安全：主要是三个方面。分别是端到端的加密通信，网络隔离和基于权限的访问控制。

数据湖的文件系统

据湖系统主要由可扩展的数据存储和分布式文件系统组成，这些文件系统通过将较大的文件划分为较小的块或通过跨数据服务器池(数据节点)分配的分区表来部署数据。此外，数据通常被复制到多个节点以提高容错性。在这样的分布式系统中，负载均衡器被用来增加可伸缩性。
例子： Hadoop分布式文件系统(HDFS) & Amazon S3存储服务(Amazon S3)

数据湖分层

强烈建议基于多层/多层(不少于两层)设计数据湖，其中一层为隔离区。还强烈建议基于特定的用例将第二层划分为几个区域。需要注意的是，数据湖各层/分区之间的数据传输需要一个计算资源来完成数据的转换和处理。
每个阶层有不同的作用，比如缓存，AI识别，数据转换，机械学习等。对应阶层的数据格式，类型，属性，用途都不相同。

物联网云应用 Microservice

数据结构

位于云中的物联网应用可以基于三种不同的架构进行设计。

当服务器创建一个应用时：所有的数据需求有四类。包括应用集成，DB访问逻辑控制，应用业务逻辑和连接准备。

• Presentation: 处理所有接口，管理和路由传入的请求到业务逻辑，并以特定的格式显示响应
• Application Business Logic: 执行与请求关联的特定业务规则，以准备响应。
• Database Access and Logic: 实现数据库所需的逻辑存储和检索数据。
• Application Integration：合并其他服务

单体架构(monnlithic architecture)

优点： 开发简单，测试容易，部署容易，可伸缩性是通过在负载平衡器后面运行多个应用程序副本来实现的。
缺点： 数据更新速度慢，应用更新后需要重新部署数据，必须手动测试，出现数据故障或bug时整个应用可能会全部崩溃，虽然扩展性好但有条件，如果构建块模块有不同的资源需求，扩展是困难的。

Microservice

解决了单体架构的问题点。使用多个小块分布式处理，分散一个大块的各项能力。小块一般存储在虚拟机或者容器（docker）中。有着负载均衡的优点，且开发独立、速度快且维护容易，有缓存时业务性能大幅增加，容易识别故障点并定点维护，维护时不妨碍其他小块的服务继续执行。可构建多功能战略应用多重服务需求。但是开发难度比较大，对团队技术要求比较高且对经济需求也相对较高。

SOA（service-oriented architecture）

不能完全解决单体构造的问题，仅部分解决。服务使用共享资源存储的方式，分区大小略大，每个块既可以提供服务也可以使用服务，使用P2P网络内部通信便利。

有ESB问题，由于使用共享资源，当ESB出现问题，服务整体性能将受到影响。ESB可以作为单点故障摧毁SOA性能，而Microservice对此的抗性要高得多。

特征	SOA	Micro
故障抗性	ESB是故障弱点，单一受损也会影响全局	单一节点受影响不会影响系统整体
共享资源	尽可能共享多的资源	尽可能独立处理各项事务
数据更新	更新后需要重新启动SOA	更新内部节点不需要重启整体网络
块大小	相对较大，联合计算	相对较小，独立计算
数据存储	共享资源	私有存储本地资源
Monolithic问题	部分解决	全部解决

API Gateway

API网关是应用程序的接口，一般调用几个微服务实现APP功能，需要持续的开发和管理。API网关是作为系统入口点的应用程序/服务。API网关抽象了内部系统的体系结构，然后通过一组API来表示它。API网关还可以负责身份验证、负载平衡、监控、静态响应处理、缓存和请求整形或管理

服务调用[Invocation]

个应用程序的组件使用函数调用或语言级方法相互调用(调用)，而使用微服务体系结构功能的应用程序则使用许多机器和进程间通信进程作为分布式系统。
特性1:客户端交互样式[一对一/一对多]
特性2:通信是同步的还是异步的

当Micro服务使用分布式系统进行IPS进程间通信，调用App时使用。有几种方式
Request/Response：客户端等待及时的服务响应。有多种协议选项，但最受欢迎的两个是REST和Thrift
Notifaction： 不要求ACK，直接发送
Request/异步响应：等待ACK但不会进入阻塞状态
Publish/异步响应：等待指定时间，可以阻塞
Publish/Subscribe：客户端发布消息，该消息可被感兴趣的服务使用。
Representational State Transfer (REST)： 一个进程间通信
(IPC)机制，通常依赖于HTTP。资源是REST的主要概念。资源是表示应用程序中的业务对象(如产品、客户)或业务对象组合的概念。REST使用通过URL引用的谓词操作资源。例如,
GET请求返回一个资源表示，很可能以JSON对象或XML文档的形式，而POST请求实际上创建了一个可以通过PUT请求更新的新资源
Apache Thrift：用于编写跨语言远程过程调用(RPC)服务器和客户端的框架。Thrift提供了c风格的接口描述语言(IDL)定义api。接下来，编译器为各种编程语言创建代码，如Java、c++、PHP、Ruby、Python和Node.js。Thrift能够支持不同的消息格式，如二进制、紧凑二进制和JSON。请注意，二进制是一种更有效的选择，因为它占用更少的空间，比JSON更快地解码。

服务发现

尽管基础设施服务(例如消息代理)通常有一个通过操作系统环境变量确定的固定静态位置/地址，但由于应用程序服务使用动态分配的位置/地址，找到服务位置可能很困难。由于升级和自动伸缩，服务实例会发生变化，因此需要一个服务发现组件来定位每个服务。服务发现既可以由客户端驱动，也可以由服务器驱动。
方式： lient-Side Discovery/Server-Side Discovery
客户端在启动应用时，会通过服务寄存器记录当前的信息，而客户端可以通过检索寄存器来获取自己的当前信息。对于服务期而言，则通过负载平衡装置在启动服务时查询服务器寄存器的对应鹅湖段的信息，从而通过这些信息认证身份。
当服务器应用启动时，使用这些信息，当服务结束，从寄存器删除这些信息。

服务寄存器

服务注册中心是一种能够跟踪服务实例和网络位置信息的数据库。由于服务注册中心是服务发现的一个重要组成部分，因此它必须保持最新，并且必须具有高可用性

部署策略

建一个单片应用程序需要使用一个或多个相同的大型应用程序副本。
单个微服务是具有自己的监视、资源和扩展需求的迷你应用程序。此外，每个服务必须有适当的内存、CPU和I/O资源。因此，部署单片系统的过程比部署微服务应用程序的过程简单。

大体有以上四种方式。

1. MSIPH： 资源共有，部署快，效率高。但是不提供隔离服务
2. SSIPT-VM： 提供隔离，不抢占资源，可以管理微服务。但是部署速度慢，资源利用率低，开销巨大（因为每一个虚拟机有一个OS，每个OS都是CPU开销）
3. SSIPT-Container： 解决数据孤岛问题，能够进行预案管理，没有单独的OS所以开销小且启动快速。但是容器与宿主机直接相连且共享宿主机资源，安全性上而言攻击可能会破坏主机。且技术成熟度低于虚拟机
4. SD：又称FaaS。供应商处理具体的操作需求，用户只需要自己编码，处理速度快，因此整体使用最简单，可以方便管理微服务。但是不适合长期部署，AWS请求要在300s内完成，服务必须无模式（Schemaless）