塑云科技基于 KafKa+OTS+MaxCompute 完成物联网系统技术重构

塑云科技：性能突破，基于KafKa+OTS+MaxCompute 完成了一次物联网系统技术重构

背景：创业团队，专注于氢能燃料电池生态链的运营支撑，当前主要的业务组成为新能源车整车实时运营监控分析，加氢站实时运营监控分析，车辆安全运营支撑。

系统面临的主要挑战：高频数据的实时解析、存储、分析。拿整车实时运营监控分析来讲，每辆车以每秒1K的原始报文上报，要求做到秒级延迟的解析应答以及入库。同时需要针对解析后的每车每秒33K的报文进行快速查询以及后继的分析。考虑到未来车辆接入的量，需要在考虑性能的基础上以最经济的方式进行系统设计。按照每车每秒33K的解析后报文，每车每月预计生成30G的报文数据（车辆按照每天运行10小时计算）。

原有系统存在的问题如下（罗列部分）：

1. 系统架构中未对OLAP和OLTP系统的范围进行清晰界定，使用JAVA程序对OTS的表定时进行任务统计，代码复杂并且性能极差并且影响到服务器上其他OLTP系统的正常运行。

2. 存储的解析后的报文数据，未针对OTS的计价规则进行针对性优化，一个大JSON串中冗余的KEY过多，KEY的长度超长（平均30个字符串）。

3. OTS（阿里云tablestore）按照公司进行分表设计，存在单个实例下表数量超过OTS限制（64表）的风险。

4. OTS以车月作为分区键，单个分区（30G）过大，超过OTS建议的1G推荐大小。

5. OTS单车的分区连续分布未做散列，不能在物理机器层面最优并发性能。

6. 没有针对最核心的读取场景（按天按车查询报文）进行编码层面的优化。

在做系统优化之前，首先要做的就是架构层面的梳理，对产品中需要使用到的中间件产品的适用范围进行了明确的界定。数据在各个环节的流转进行明确的定义如下：

这里主要的改进

一、引入KAFKA作为多个环节异步解耦的基础支撑，提升对终端的报文快速回复。

二、引入MaxCompute 作为OLAP系统的基础支撑。将复杂的业务分析转交给MaxCompute 来处理。

三、针对OTS的计价原则，对OTS的模型进行了重构（此文暂不讨论）

MaxCompute作为阿里云强大的数据分析利器，因为之前的经历相对比较熟悉。所以在这次的改造中特别针对性能、成本、可运维等方面做了较多的思考。

这里首先讲一讲基于成本的考虑。首先根据数据的使用频度将数据切分为在线、离线、归档三类。车辆终端上报的报文数据作为归档数据选择OSS的归档存储。在线数据设定N月的生命周期，主要包括报文解析之后需要实时查询的数据，离线数据主要包括基于解析的报文数据进行离线分析统计之后形成的各类中间结果、报表数据。

针对数据的使用场景界定数据类型之后，这里主要考虑离线数据使用OSS还是MaxCompute（ODPS）或者是OTS来存储的问题。根据三类产品的存储计算成本我做了一个粗略对比如下：

这里已经考虑通过压缩的方式存储OTS减少计价存储的情况。当然MaxCompute的计价是按照实际压缩存储之后的容量计算。MaxCompute官方文档介绍的是5:1的压缩比，而我们的数据因为本身的特点，实测可以到7~8 ：1的压缩比，所以最后数据方案反倒是MaxCompute直接存储离线数据性价比最高。同时也符合数据靠近计算的原则。

经过测试使用OTS外部表作为数据载体的计算性能一般（当前MaxCompute对OTS的外部表的Map Reduce计算直觉觉得是基于OTS的分片，并且缺少分区的概念，每次都是基于全表扫描，这点可以从MaxCompute的任务详情可以观测出来）。

技术选型确定以后，剩下的是如何利用MaxCompute为业务提供可靠、稳定数据服务。这里特别需要强调的是数仓的建模、数据集成、工作运维的使用。

数据集成主要这方面主要体现MYSQL跟MaxCompute的双向同步，这个不需要特别讲，主要是设计上需要考虑到数据的重复同步的设计即可。关于工作运维则是更多地体现在对任务的运行状况的监控以及重跑的支持。

数仓的建模主要考虑的还是成本和模型的复用。首先针对海量、质量不高的底层数据进行分层建模。保证上层的业务模型只依赖中间结果。这里带来的直接效益就是计算成本的大幅下降（每每看到有些开发同事动不动就对着一个上百G的原始表做各种查询的时候，心是痛的…）.其次是中间模型为系统补数带来更快的性能，毕竟因为一些业务或者数据的原因需要重跑部分报表，这个时候如果需要重新扫描原始数据的时候，首先就是费钱，非常费钱。其次就是耗时，非常耗时。

在离线统计分析的重构完成之后，系统充分利用MaxCompute的并行计算能力，并且借助其强大的函数尤其是窗口函数的支持，我们实现比较不错的分析能力，客户的一个核心部件的数据统计分析，之前一个专业的工作人员分析一个部分需要耗时一天，还容易出错。借助平台的分析能力，可以在10分钟内计算完将近1000个部件的数据分析工作。类似下面的曲线图分析每次数据波动期间的均值，之前几乎无法人工计算，即便是JAVA编码也是一个非常复杂的编码工作，通过平台的支持，系统处理得游刃有余。

一次计流水账式的总结，且当做一次经验的沉淀

原文链接
本文为云栖社区原创内容，未经允许不得转载。

塑云科技基于 KafKa+OTS+MaxCompute 完成物联网系统技术重构相关推荐

【观察】站在亚马逊云科技re:Invent舞台看未来，释放技术创新澎湃力量
一年一度的re:Invent全球大会,是了解亚马逊云科技每年技术创新最好的机会和舞台,自2011年re:Invent大会举办以来,re:Invent已走过了10年,它如今更是成为了观察全球云计算技术发 ...
基于STM32F103移植华为LiteOS物联网系统
基于STM32F103移植华为LiteOS物联网系统本实验是通过学习野火的<物联网操作系统 LiteOS开发实战指南>参考学习的. 1.移植前的准备 LiteOS 的源码可从 LiteO ...
亚马逊云科技基于智能搜索，为企业打造知识库
知识库需求在各行各业中普遍存在,例如制造业中历史故障知识库.游戏社区平台的内容知识库.电商的商品推荐知识库和医疗健康领域的挂号推荐知识库系统等.亚马逊云科技为保证推荐系统的时效性和准确性,需要大量的数 ...
面向云环境基于属性加密的密文分享系统——简介
1.Abstract 随着互联网技术的发展,人们需要处理和存储的信息数据量也越来越大.云计算的来临,在满足人们对海量数据存储空间以及计算资源需求的同时,云存储本身带来的安全问题也不容忽视.数据的异地存 ...
基于 V2I/V2N 的感知融合系统技术及应用研究
来源:智能汽车开发者平台摘要随着智能驾驶技术的研究与发展,单车智能感知的局限性逐渐显现出来,基于 V2X 的感知技术解决了单车感知在遮挡等场景下的局限性.介绍一种基于 V2I/V2N 的感知融合 ...
可视化服务器集群管理与调度系统,一种基于Slurm作业管理的可视化调度系统技术方案...
[技术实现步骤摘要] 一种基于Slurm作业管理的可视化调度系统本专利技术涉及高性能集群作业调度领域,尤其涉及一种基于Slurm作业管理的可视化调度系统. 技术介绍高性能计算集群是一组通过网络连接 ...
亚马逊云科技在中国区域上线机器学习新服务，打造广泛而深入的人工智能与机器学习工具集
2021年5月11日,在完全托管的机器学习服务Amazon SageMaker落地中国区域一周年之际,亚马逊云科技宣布通过与光环新网和西云数据的紧密合作在中国区域进一步落地多项人工智能与机器学习的新服 ...
云上更安全？亚马逊云科技宣布将持续加大在中国区域安全合规领域投入
编辑 | 宋慧出品 | CSDN云计算新冠疫情对我们工作产生了深远的影响,远程在线的工作与交流愈加普及,国内更多公司在推出居家办公的"混合办公"模式.不过,这也给了网络攻击更多 ...
凌云驭势亚马逊云科技开启re:Invent中国行
‍ ‍数据智能产业创新服务媒体 --聚焦数智 · 改变商业近日,亚马逊云科技召开了2022 re:Invent全球大会.作为云计算的开创者,每年亚马逊云科技举办的re:Invent全球大会都会成为产 ...

塑云科技基于 KafKa+OTS+MaxCompute 完成物联网系统技术重构

塑云科技基于 KafKa+OTS+MaxCompute 完成物联网系统技术重构相关推荐

最新文章

热门文章