开发者学堂课程【HBase 入门与实战：物联网时代的数据挑战】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/808/detail/13902
物联网时代的数据挑战
内容介绍
一.了解物联网时代数据存储的市场及趋势
二.了解物联网时代数据存储的机会和挑战
三.了解 Lindorm 在物联网中的最佳实践
学习要点
物联网数据大多快重，loT 技术进入复苏期
物联网数据面临的挑战:数据协同，高并发的写入查询吞吐，数据量大存储成本敏感
Lindorm 面向物联网行业的产品特性:超融合，云原生，海量低成本存储
Lindorm 在物联网行业最佳实践:物联网平台，电网，车联网
一、物联网时代数据存储的市场及趋势
整体物联网时代国家政策，十四五规划很清晰的把物联网数据作为7大重点数值经济产业之一，深刻影响到公共设施基础的数字化改造，比如电网的智能化，孕育出车联网、物联网平台新市场的机会。
整体数据市场趋势，根据 IDC 预测2025年整体物联网设备的增加数据可以达到100ZB
在如此大的数据体量下，数据呈现量越来越大、种类越来越多、访问处理的速度要求越来越快、价值越来越重。 报告看到2021年 IoT 的技术从泡沫的破裂期到稳步爬升复苏期，IoT 相关技术 IoT 平台更多的厂商继承，数字孪生被更多数字生产部门快速进入商业模式。在好的政策趋势下，对于物联网时代存储传统数据能不能满足。
二、物联网时代数据存储的机会和挑战
1、数据协同
2、高并发吞吐
3、存储成本敏感
数据协同，运营治理复杂度高
风力发电例子
一个典型的风力数据集，从左向右分为3部分，设备关系数据、设备元数据、设备运行时数据。设备关系数据野外有很多风机组里面有很多风机，一组有10-20个，一组风机关系称为设备关系数据，每个风机有自己特殊的设备数据称为元数据，风机的厂商、型号、设备 ID都是设备数据。风机上有很多传感器，传感器采集附近的风速、转向，这些指标产生的状态称为运维时数据包括时间戳、数值、数据。
怎么去处理数据集，物联网时代下，一系列数据集需要具备哪些处理能力？
一个典型的物联网的数据集问题
设备关系 设备的事物服务 查看设备的最新状态 设备采集数据类型动态改变 查看设备的层次关系
不管是运营时、元数据用 MySQL，但有一天老板告诉你需要看一下除了整体的历史数据要实时看每一个风力的状态，检查设备的最新状态，这种能力非常适合设备存储。
将数据放到 HBase 中。新需求想看设备的层次关系，风机下有哪些东西，在元数据的信息中在 MySQL 中，随着时间越来越长，数据点越来越多，采集频率以前一天一次，想要排查故障更好变为分钟级别，数据点变得极其庞大，可放在时序数据库。这一类典型物联网数据集下面可总体概括
挑战1-物联网数据协同带来的运营治理复杂
元数据可以放在 MySQL 里，检查日志的能力，跟踪指标 Tracing HBase 中，运行时数据 Metrics 可以放到 InfluxDB 中，事件报警处理放到检索分析 ES。
整个系统搭出整体解决方案，真正在实施时发现面临及其大的问题，第一个问题系统运维成本非常高，每一个数据库类型部署一遍，产生非常大的部署成本，开源的数据库能部署。开发要学习各种接口、特性用不好会产生一些问题需要排查，对于开发有很大的使用门槛。数据成本，数据需要在不同的数据库引擎之间移动，带来了数据搬迁冗余，同一份数据在不同地方都要存一份数据冗余度高。用户体验差，做关联查询从不同数据库拿上来，开发新应用，上层应用关联起来，对于上层的开发非常繁琐。
挑战2-高并发的写入查询吞吐
从宏观上看 IoT 技术发展带来的爆炸设备的增长，引发数据规模效应，持续的产生监控指标，数据的读写、存储成本带来很大挑战
物联网平台
.10,000设备x200项监控指标
.每5秒10000点写入
.查询指定设备的部分监控指标
.监控指标按条件聚合查询
.监控异常设备分析，未来趋势预测
电网（工业互联网）
.90,000,000用户x20项监控指标，每月采集一次指 标，每年216亿测点
.查询所有用户每月用电量总和
.查询所有用户的指定指标
.查询各区域/线路总使用情况(按需聚合)
省域的电网流，电流设备之前每个月采集一次，过了一段时间业务升级，需要15分钟一次，这种情况下每秒的数据点由原来的几十万几百万膨胀到千万级别，数据集群规模由十台几十台变为几百台。随之而来集群需要扩展到百台的能力，对于元数据、集群的分片、集群数据的管理有很大挑战。物联网数据对于多模存储带来的分布式扩展。查询次数要做分析，一天或一个月常稳的场景。
典型的断面查询，一段时期内电量所有用户数据拿出来，对底层存储表的开销还是结果的开销都是能力上的挑战。需要扫的数据量很大结果，做完后返回的数据量大。数据处理需要具备流式处理、预计算能力，面向物联网场景下的特性。
挑战3-极高的存储成本
量上来后对成本有很大挑战
车联网
.20,000辆车x60项监控指标
.每秒1200,000点写入，每小时73.8GB数据
.查询20,000辆车最新的某个指标
.查询指定的10辆车，10个指标，1天、7天、1个月的平均值
20,000辆车每小时产出百GB级别的数据。如果看车辆的发展趋势，希望数据不要被篡改，保留历史去追踪，真正出现问题时，出现事故时，平台拿数据查询，数据拉长一年或更长，就会带来数据 PB 级别的存储规模。
数据规模上来后数据成本提成的要求变得非常高，这些问题需要技术特殊的能力，数据的冷热分层，热数据与冷数据的归档，计算存储规模，低成本的存储建设，实现编码的压缩建立数据的特征。数值性的数据算法压缩整体的存储成本降到极值。
机会-多模超融合
解决到挑战为技术带来新机会，多模超融合技术含量，DBMS未来物联网行业下持续数据关系配合越来越紧密。Top20 DBMS 流行数据，3分之2数据具备多模能力。
多模能力可以将设备的运维数据、设备关联数据、设备元数据多模能力不同的展现，这就是多模超融合。
物联网中将元数据的存储通过不同的数据模型统一存储，访问是通过统一接口从而达到统一模型规模。
机会：云原生+分布式
分布式 原生特征 资源池化 弹性
随着云计算大数据领域各种资源，存储资源、计算资源，编辑成本效应越来越低，任何业务包括物联网时代数据都是业务驱动技术的发展。物联网数据怎样结合整体云计算和资源成本降低的趋势来实现新的数据架构升级。
希望在超融的基础上统一存储多模应用架构，进一步介入云计算基础资源的能力，实现云原生+分布式，实现分布式的扩展，将数据扩展到上千台，达到千万级别的访问。
坚持物联网的特性可以实现原生的特征，存储和计算分离不停的将资源池化后，可以实现资源上的按量、按需访问。未来物联网时代及其多样性的特性，规模逐渐拉大趋势，一定要做到技术的弹性。通过 Serverless 技术形态从而要求可以做到规模从小到大的弹性。针对挑战机会阿里内部新的产品 Lindorm。
三.Lindorm 在物联网中的最佳实践
1.Lindorm 产品介绍
为了迎合物联网 AIoT 时代的挑战，将多模引擎包括宽表、时序、搜索、文件四类引擎统一处理，底层通过一个个存储上面统一接口，实现一整套云原生多模数据库 Lindorm。
主要解决海量数据物联网时代多种类型数据的低成本存储和处理问题，目标是实现存得起，看得见。可以广泛应用到物联网 AIoT 、大数据存储、数据湖存储中心、交互实时存储各个方面。实现只要第一个存储统一兼容开源接口，上层应用不用感知应用实现查询数据响应，数据可在高规格标准存储自动识别和转移。
第二个层面不同面向数据处理的宽表引擎，建立kv存储，时序特性指标数据的引擎，搜索关联引擎，在引擎之上实现一套 API 介入各种开源的 Open API 提供 Native SQL 结构。整体架构基础上产品具备了多个与物联网时代相吻合的产品，采用了 Lindorm 架构实现复杂业务，可以做多个 Serverless 形态数据资源的解耦后做池化做弹性存储。
2.Lindorm 面向物联网的产品特性
超融合
多个阶段实现，第一个阶段底层多模引擎原生看到了持续数据宽表、搜索、文件配合的越来越紧密的趋势，物联网下设备元数据、运维时数据、业务类型数据使用多模形式存储。通过不同引擎，不同数据访问模型，来实现多模引擎的统一。
数据访问可以通过同套的 SDK+SQL 的访问，进而降低复杂度，实现一套结构的访问。开发者从引擎的感知越来越低甚至无感知从而面向一个统一 SQL 的方式实现整个业务的逻辑。第三个阶段实现全链路生态融合，不仅是数据 Lindorm 的融合，整个 Lindorm 面向开源生态，不同生态下相关的平台无缝进行生态融合。
云原生+分布式 物联网原生特性 原生垂直引擎高吞吐 动态数据类型 多维检索 状态点查
流式预聚合
边云一体 云+分布式
水平扩展至千万级别规模
存储计算分离
loT云资源深度集成
serverless形态
物联网原生特性，物联网解决了多模数据库，真正适合物联网的产品特性。
原生垂直引擎高吞吐，采用了适合于物联网最佳系统，没有更新，批量删除或自动淘汰的结构化或半结构化数据。针对一系列数据特征采用了引擎，实现资源高效利用。对于物联网设备之间的关系，通过多维检索构建 search 索引内部的宽表、KV引擎，search 搜索引擎把数据的关系构建起来。
数据类型改变采集时，不同的数据类型带来的指标访问对结构化数据非常不友好不能承载的特性做了破功。实现动态数据的采集到展示，对于用户感知比较友好的体验。检查、流式聚合、边云一体化都是面向物联网原生的特性。
云的分布式管理，现在的分布式可以达到千万级别，使用机器并且实现动态的收缩，做资源 up 资源规格向上，不同节点之间爬行。提供了存储与计算的分离，计算层资源可以从GB 到 TB。静态资源和存储资源进而达到了资源池化，池化后带来了 Serverless 形态，按需使用，按量付费的 Serverless 形态。这种在业界非常适合物联网，既有小规模设备的使用到大的物联网平台，以及基础设施都能很好适应产品形态。云上除了基础设施应用或压榨存储计算，进一步对云上产品实现自动结合。云上阿里内部 LT 平台，规则引擎可以通过内部查询结果无缝浏览到 Lindorm 多模引擎。物联网平台可以把数据采一次在 LTP 单上实现数据到 Lindorm 里。
计算弹性：
宽表/KV引擎兼容 HBase， Cassandra
时序引擎兼容 OpenTSDB、influxDB
搜索引擎兼容 Soir 文件引擎
为了进一步降低云原生开发的成本，推出了云原生。
云原生架构高效低成本：
Lindorm Store(HDFS兼容)极致性价比的云原生存储引擎
本地盘
高效/SSD/ESSD云盘
OSS 低成本
随着物联网数据不断庞大带来存储成本问题，Lindorm 多模实际上由前面的架构决定了存储计算分离后，存储层可以做热数据、温数据、冷数据的分离。热数据将最新一个点放在内存中，在设备量有限的情况下最低的成本最高速度的实验方式。
温数据对于查询一些机器24小时、三天的数据持久化到 SD 性能型平台或标准型平台中，进一步长期不访问为了后面的合规要求、意识数据的价值挖掘，不访问的数据可自动归档到 OSS。分层的能力不需要感知，物联网大部分有实践可以进步将产品做的更加简单，查询时不需要感知分层只需要设置边界可以达到目的。物联网根据数据特点两个压缩编码能力，持续的压缩大部分数据或状态，各个类型都有特定的压缩算法。
冷热分层存储:内存、磁盘(本地盘、高效云盘、ESSD云盘)、OSS数据分层存储，降低存储成本
·热数据:近期热数据缓存在内存，保障高效访问;基于时序特性，一份 Cache同时用于读写。
·温数据:内存数据存储到磁盘持久化，根据应用场景，可选择标准型、容量型、性能型等不同特性的存储。
·冷数据:长期不访问的历史数据，支持自动归档到 OSS冷存储。
·高效压缩:定制化时序压缩算法，压缩比>10:1
·TTL:自定义数据保留策略，自动淘汰
物联网特性包括多模引擎的超融合、云原生、物联网云原生、分布式、弹性能力。
Lindorm 在物联网的最佳实践
物联网场景是非常大的概念，存值市场细分领域驱动，需要关注细分领域的应用，才能把握技术红利服务好物联网。
物联网分为三大类消费、商业、工业
物联网平台、车联网、电网三个领域做细分领域的探索得出最佳实践。
物联网平台场景中的数据
有很多采集，边缘上有硬件通过代理 Agents 将数字同步过去，由边缘测自动投入到云端实现分析应用的赋能以及数据管理，最后形成云端的决策下放到边缘间并且指导整体业务的应用做企业级的决策。
3.Lindorm 在物联网平台中的数据存储方案
物联网数据架构模块怎样做，在 Lindorm 多模实践如何做，将物联网数据端化的数据分在不同的存储云上存储，设备运行时数据放在时序 TSDB 里，设备元数据放在宽表 KV 里，设备数据检索放在搜索中，语音放在文件引擎中。通过云原生多模数据库管理各个数据。
物联网平台下高可用，内部做了通道做数据自动分移，在边缘和边缘测同步 IoT Edge 和 IoT Core 做多功能非常适合 Lindorm场景。将数据同步到云端指标、边缘测已经在 Lindorm 多模数据库中进一步实现。
工业互联网方案
工业互联网趋势是 IT 与OT 融合去指导企业资产评估、维护、修复整体流程。
电网方案（工业互联网）
需求疼点
多样化数据存储，多系统联合解决
多模融合能力，混合云为主，工业边缘化、边云数据融合
行业特征的计算能力，基于电网最新点，计算算子
车联网分为四大趴包括厂商、制造商、售后服务，厂家保险互联网生态应用，车内应用
Lindorm 主要在车载状态检测上
车联网中的数据存储方案
通过传感器接口采集进入实时数据，用引擎流感到 Lindorm 多模数据库中，从而实现设备实时追踪，运行状态的感知，实时安全的管控。
