首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >学术大讲堂 | (七)如何应用大数据技术秒杀一个貌似不可能的任务

学术大讲堂 | (七)如何应用大数据技术秒杀一个貌似不可能的任务

作者头像
灯塔大数据
修改2019-07-12 17:34:25
5280
修改2019-07-12 17:34:25
举报
文章被收录于专栏:灯塔大数据灯塔大数据

学术大讲堂

今天我将介绍大范围高精度栅格可视化方案。它是结合大数据技术解决实际应用问题的一个典型例子,我们给它起了个大标题,叫做“如何应用大数据技术秒杀一个貌似不可能的任务”。

看着有点标题党的味道,其实这里我们想强调的是,我们设计和实现这个方案时,一开始直接调用HBASE检索,看着要检索的数据量,多达数百万,还真是觉得不可能几秒内完成任务。所以对于这个技术难题,或者说是省公司的业务需求,提出来以后很长时间以来我们迟迟没有解决。

直到今年上半年,我们一点点地分析和优化,应用分布式处理的思路去逐步搭建了一个自主研发的可视化专用集群,才很好解决了问题。而在这个过程中,我们一方面对Map-Reduce原理、分布集群的管理等hadoop技术框架有了更深刻的理解,另一方面,也对大数据分布式技术所能提供的算力之强大,有相当震撼的感受。

我们所面临的任务,概括来说就是“基于电子地图的移动网络覆盖质量可视化”。这里面需要用到的最关键最核心的数据,就是“基于位置的网络信号强度”。

拿到数据后,我们要进行可视化展现。如果数据量少的话,那么,最直接的展现就是打点:在图上什么位置,指标是多少,就用不同的色系去着色。就像这张图,就是我们生产系统上对网络院旁边的华南师范大学校园的路测数据打点可视化。

当数据量多了之后,打点就解决不了问题了,大量的点会重叠在一起,看不出问题来,所以就引入我们今天要讨论的主角:栅格化展现,也就是在栅格内取数据的统计均值。

另外,关于可视化数据的处理,不管打点还是栅格化,理论上都可以采用两种不同的处理方式。一是预切图,就是预先基于数据生成图片,其优点是加载速度极快,另一种是实时生成,在需要展示时才去获取数据进行渲染,其优点是展示处理灵活,效果丰富多样。

那么我们初始的解决方案是如何的呢?

首先,最基础的,就是我们的栅格划分:地图上选定某个点为原点,然后根据指定经纬度计算与原点的差值跨了多少个栅格,分别作为栅格的经度编号和纬度编号,然后把两者拼接起来作为栅格编号(KEY)。

栅格的划分是整个栅格化展示的基础,有了它,我们就可以进行数据预处理了。后台的数据预处理包括以下步骤:1)MR数据定位;2)分级汇总;3)按KEY排序(写入HBASE)。

而前台进行实时展示的处理流程包括以下步骤:1)计算关注区域的外接矩形;2)计算外接矩形内包含的所有栅格的KEY;3)剔除在关注区域外的栅格;4)从HBASE查询出所需栅格的数据;5)基于在线电子地图的Canvas渲染。

上述方案存在着以下的不足之处:

1)栅格设计的粒度较粗,显示精度低。

2)采用KEY枚举的方式查询HBASE,效率较低。由于栅格数据进行了按栅格号排序方式存储,在查询小量栅格时性能还是比较高的,但查询数十万甚至数百万的大量栅格时,由于需要进行逐个栅格枚举检索,检索性能极其低下。

3)关注范围较大时,栅格数据量庞大,服务端处理压力剧增,极易引起数据查询服务端内存溢出故障。我们遇到过查询一个营销服务中心,涉及80多万栅格量,直接导致服务端内存溢出挂死。

4)栅格数据量大时,客户端处理压力大。实测表明,即使运用了canvas高效渲染技术,依靠客户端单机来大数据量依然十分耗时。一般情况下最多只可接受数万个栅格的可视化。

所以,归结的问题就是:能否/如何实现高精度(象素级)大范围(市、省) 的网络覆盖质量实时(3秒内)可视化?

围绕这个问题,我们进行了以下一系列的优化。

优化一:重构栅格,提供象素级别的精细度。

根据APGS的定位精度,把最小栅格由原来的100米调整为20米(调整后广东境内理论上多达4.5亿个栅格)。栅格级别使用逐级倍增的设计,这样每个级别均可根据前一个级别直接汇总得到,减少计算量。根据每个级别下的地图象素距离,选择对应栅格级别:取小于象素距离的最大值。

优化二:重组栅格数据的存储结构,实现批量检索。

在全高分辨率下,象素量多达200多万个,涉及的栅格量非常大。为了提升查询效率,必须调整栅格只进行简单排序的方式,以实现批量检索数据。一般来说,栅格数据的存储结构包括:直接编码、链式编码、游程编码、块式编码、四叉树编码等。直接编码就相当于我们的简单排序方式。我们对直接编码进行改进,采用方阵64*64=4096个栅格(称为栅格组)合并到一个KEY的方式存储,可大幅度减少所需要检索的KEY量。

优化三:分布式栅格查询。当栅格量增加到一两百万时,HBASE批量查询耗时快速增长,所以,我们优化为使用分布式并行处理,查询两百万栅格,可在2秒内完成。

优化四:增加分区设计,提供更优的分布特性。KEY不分区时,按排序规划,我们所需检索的HBASE数据基本集中在一个Regionserver。增加KEY的分区设计,可以强制使地域上邻近的栅格组分布到不同的的Regionserver,避免BASE集群计算量分布不均衡的问题。

优化五:采用分布式并行处理实现图片的生成。支持透明度的PNG图片生成属于计算密集型任务,比较耗时(所需处理时间大概是JPG的6-7倍)。集群主机虽然是多核,但CPU主频一般不高。集群CPU主频为1.2G,而我们开发主机则多数可达3.6G。为此,我们调整为使用5个节点,每节点运行3个worker进程的分布式生成PNG图片(每个栅格组作为一张子图),耗时大幅减少。同时,需要特别注意,当地图放大到栅格边长大于3个象素时,子图会比较少,需要把象素式渲染调整为画笔式渲染。

优化六:构建从经纬度到象素坐标的快速映射矩阵。

经纬度到象素坐标的标准转换过程是:经纬度--》墨卡托投影坐标--》当前屏幕象素坐标,其转换公式是非线性的,需要比较复杂的计算。逐个点转换,全高清下涉及1920*1080=200多万个点,比较耗时(实测时间开销大约为2-3秒)。我们构建了纵向和横向映射矩阵,只需转换1920+1080=3000次,即可直接从映射矩阵检索出转换结果(时间开销可压缩为小于100ms)。

概括而言,我们大栅格可视化模块的优势为:

1)充分运用计算机集群算力,采用完全分布式的架构完成从数据检索到切片图生成的全过程,实现了全高清分辨率下象素级栅格图的高效可视化功能。

2)通过重构栅格数据组织结构,把栅格数据进行分组聚合和比邻分区,把数据检索效率提升了10倍以上。

3)PNG图片生成是计算密集型任务,而多数PC服务器的CPU主频并不高,执行图片生成任务比较耗时,通过分布式图片生成的方案有效解决两者的矛盾。

4)运用射线法实现了栅格是否在目标区域的快速判断

5)设计了X轴方向和Y轴方向两个映射矩阵,实现从栅格号到象素位置的精确而快速定位。

6)切片图实时生成,满足每个用户的个性化渲染需求。

7)自研的分布式集群整合到zookeeper统一管理,提供高可用性和易管理性。

最后,从这个组件的开发和优化过程,我们总结出以下经验:

1.基于大数据的前台应用设计,需要把前台和后台融会贯通,统筹设计。

2.尽可能地把处理任务放在客户端完成,减轻服务端的压力。

3.大数据高耗时的任务则转移到后台,以分布式地架构执行。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-07-08,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 融智未来 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
TDSQL MySQL 版
TDSQL MySQL 版(TDSQL for MySQL)是腾讯打造的一款分布式数据库产品,具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性,同时提供智能 DBA、自动化运营、监控告警等配套设施,为客户提供完整的分布式数据库解决方案。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档