前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >学术大讲堂 |(七)如何应用大数据技术秒杀一个貌似不可能的任务

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

作者头像
灯塔大数据
发布于 2019-07-08 15:20:03
发布于 2019-07-08 15:20:03
7360
举报
文章被收录于专栏:灯塔大数据灯塔大数据

学术大讲堂

下面我介绍的是大范围高精度栅格可视化的方案,它是我们结合大数据技术解决实际应用问题的一个典型例子,看着有点标题党的味道,其实这里我们想强调的是,我们设计和实现这个方案时,一开始直接调用HBASE检索,看着要检索的数据量,多达数百万,还真是觉得不可能几秒内完成任务。所以这个技术难题,或者说是省公司的业务需求提出来以后很长时间以来我们迟迟没有解决。

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

我们所面临的任务,简单来说就是“基于电子地图的移动网络覆盖质量可视化”。

这里面需要用到的最关键最核心的数据,就是“基于位置的网络信号强度”。

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

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

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

好,任务的内容我们基本介绍清楚了,那么我们初始的解决方案是如何的呢?

首先,最基础的,就是我们的栅格划分,直接看代码,可以有最直观的理解。这是我们判断某个经纬度点归属哪一个栅格的函数。简单地说就是以某个点为原点,然后根据指定经纬度计算与原点的差值跨了多少个栅格,并且把经度方向的编码和纬度方向的编码串起来。

栅格的划分是整理栅格化展示的理论基础,有了它,我们就可以进行数据预处理了。后台的数据预处理包括以下步骤:

MR数据定位

分级汇总

按KEY排序(HBASE)

而前台进行实时展示的处理流程包括以下步骤:

计算关注区域的外接矩形

计算外接矩形内包含的所有栅格的KEY

剔除在关注区域外的栅格

从HBASE查询出所需栅格的数据

基于在线电子地图的Canvas渲染 (在Browser侧的处理)

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

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

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

3.关注范围较大时,栅格数据量庞大,服务端处理压力剧增,极易引起WEB服务端内存溢出故障一个营销服务中心,80多万栅格量,直接导致服务端OOM挂死

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

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

  • 优化1——重构栅格,提供象素级别的精细度

根据APGS的定位精度,确定最小栅格为20米(广东境内理论上多达4.5亿个)

栅格级别使用逐级倍增的设计,每个级别均可根据前一个级别直接汇总得到,减少计算量。

根据每个级别下的地图象素距离,选择对应栅格级别:取小于象素距离的最大值。

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

全高分辨率下,清象素量多达200多万(1920*1080=2,073,600)一般来说,栅格数据的存储结构可以有以下几种方式:

直接编码/链式编码/游程编码/块式编码/四叉树编码

我们对直接编码进行改进采用方阵64*64=4096个栅格合并到一个KEY的方式存储。设某栅格:[经度编号m][纬度编号n],其对应的KEY=(floor(m/64)+ m%64)*100000+(floor(n/64)+ m%64)

可以看出合并后,需要检索的KEY量大幅减少为:2,073,600/4096 = 506

  • 优化3——分布式栅格查询

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

  • 优化4——增加分区设计,提供更优的分布特性

增加KEY的分区设计,使用以下公式确保任意相邻的栅格组不会放在HBASE的同一个REGION SERVER。

栅格组的KEY设计为:[前缀P][经度编号M][纬度编号N]

其中前缀P=(N*j+M)%(j*k) (j,k为正整数),栅格组按P值进行分区存储。

HBASE分区具有以下特性:每一个P值对应一个分区,每一个分区被分配到集群上不同的主机。

所以此机制可保证任意一个小于或等于j*k的矩阵内,P值不会重复,实现良好的分布性。

右图:前缀P=(N*8+M)%64,即j=8,k=8的前缀分布示例。此时P的取值为00-63,共64种,在任意8*8矩阵内,P值不会重复。

  • 优化5——采用分布式并行处理实现图片的生成

支持透明度的PNG图片生成是计算密集型任务,比较耗时(所需处理时间大概是JPG的6-7倍)。

集群主机虽然是多核,但CPU主频不高。从图上可看出,调测集群为CUP为1.2G,而我们开发主机为则是3.6G)。

使用5个节点,每节点运行3个worker进程的分布式生成PNG图片(每个栅格组作为一张子图),耗时大幅减少。

栅格边长大于3个象素时,子图会比较少,需要把象素式渲染改为画笔式渲染。

  • 优化6——构建从经纬度到象素坐标的快速映射矩阵

经纬度到象素坐标的标准转换过程:

经纬度--》墨卡托投影坐标--》当前屏幕象素坐标,从转换公式可以看出,这是个非线性转换,需要比较复杂的计算。

逐个点转换,1920*1080=200多万个点,比较耗时(实测开销大约为2-3秒)

我们构建纵向和横向映射矩阵,只需转换1920+1080=3000次,其他栅格直接从映射矩阵检索出转换结果(开销可压缩为小于100ms)。

这个图片以我们可视化的总体效果。

最后,小结一下我们大栅格可视化模块的优势:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
学术大讲堂 |(六)基于大数据的网络智慧运营应用研发
运营商的网络大数据具有实时性高、覆盖业务广、业务价值大等特点,利用网络大数据赋能网络运营智慧化是各运营商的迫切诉求,今天就给大家分享一下我们在利用网络大数据提升移动网智慧运营方面做过的一些实践活动。
灯塔大数据
2019/07/08
1.5K0
“基于大数据技术的网规网优”专题论文速递3篇
现在通信运营商已全面实现基于大数据的全生命周期优化,呈现从传统非智能的经验型优化向基于大数据进行关键分析的智能优化转变、从区域性质量优化向端到端感知优化转变、从项目型优化向平台产品型优化转变的趋势。例如通过实现场景栅格化,建立基于地理对象的数据仓库,依据业务需求进行分析、预测,从而支撑精准规划和优化。
灯塔大数据
2020/05/26
6410
基于Spark的大数据热图可视化方法
针对普通客户端浏览和分析大数据困难的问题, 结合 Spark 和 LOD 技术, 以热图为例提出一种面向大数据可视化技术框架. 首先利用 Spark 平台分层并以瓦片为单位并行计算, 然后将结果分布式存储在 HDFS 上, 最后通过web 服务器应用Ajax技术结合地理信息提供各种时空分析服务.文中重点解决了数据点位置和地图之间的映射, 以及由于并行计算导致的热图瓦片之间边缘偏差这2个问题.实验结果表明,该方法将数据交互操作与数据绘制和计算任务分离, 为浏览器端大数据可视化提供了一个新的思路.
ZONGLYN
2019/08/08
2.1K0
基于Spark的大数据热图可视化方法
干货,主流大数据技术总结
互联网技术的发展让大多数企业能够积累大量的数据,而企业需要灵活快速地从这些数据中提取出有价值的信息来服务用户或帮助企业自身决策。然而处理器的主频和散热遇到了瓶颈,CPU难以通过纵向优化来提升性能,所以多核这种横向扩展成为了主流。也因此,开发者需要利用多核甚至分布式架构技术来提高企业的大数据处理能力。这些技术随着开源软件的成功而在业界得到广泛应用。
数据社
2021/01/08
6830
干货,主流大数据技术总结
时空大数据云平台
为了解决当前数据中心运营过程中的数据管理组织混乱,无法深入数据本身,无法实现在线查看、浏览、分析计算等问题,我司推出了一款时空大数据云平台,能够实现数据的在线管理、在线可视化、在线计算以及在线代码编辑器等功能。
魏守峰
2020/01/18
5.7K0
大数据,怎么搞?
随着大数据的爆红,数据分析师这个职位也得到了越来越多的关注,千千万万懂些大数据技术的少年们都渴望成为高大上的“大数据科学家”,可是,你们真的准备好了吗? 1、最早的数据分析可能就报表
我是攻城师
2018/05/11
9250
大数据技术概述
大数据(Big Data):指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据合,是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。主要解决,海量数据的存储和海量数据的分析计算问题。
Francek Chen
2025/01/22
1K0
大数据技术概述
数据可视化大屏产品在滴滴的技术探索
导读:现代的数据可视化产品相较于之前的仪表盘应用,在数据方面呈现更加生动、数据实时性高、交互更为友好、效果更加震撼等特点,越来越多的人倾向于通过各类可视化产品使静态的数据“活”起来。基于此背景,我们结合滴滴的各业务线发展,打造了本文介绍的数据可视化大屏产品。
万能数据的小草
2021/06/24
2.9K0
数据可视化大屏产品在滴滴的技术探索
大数据采集架构
一般来说,当在Hadoop集群上,有足够数据处理的时候,通常会有很多生产数据的服务器。这些服务器的数量上百甚至成千上万。小的数据还可以直接从应用程序写入HDFS,但庞大数量的服务器试着将海量数据直接写入HDFS或者HBase集群,会因为多种原因导致重大问题。
全栈程序员站长
2022/07/05
8660
大数据采集架构
大数据技术原理与应用-林子雨版-课后习题答案
答:大数据时代的“数据爆炸”的特性是,人类社会产生的数据一致都以每年50%的速度增长,也就是说,每两年增加一倍。
全栈程序员站长
2022/08/25
2.8K0
大数据技术原理与应用-林子雨版-课后习题答案
【简介】大数据技术综述
首先,在学习大数据之前,需要了解什么是大数据?它是如何诞生的?它有哪些应用场景?只有了解了这些,才能窥视大数据的技术全貌。一个技术的诞生,是顺应时代的,是用于解决某些问题的,它的发展也一定是有内在逻辑的。接下来,一起去看看。
十里桃花舞丶
2021/09/10
2.3K0
基于Scrapy-Redis的分布式景点数据爬取与热力图生成
在旅游行业和城市规划中,热门景点的数据分析具有重要意义。通过爬取景点数据并生成热力图,可以直观展示游客分布、热门区域及人流趋势,为商业决策、景区管理及智慧城市建设提供数据支持。
小白学大数据
2025/05/16
390
大数据应用导论 Chapter1 | 大数据技术与应用概述
下面是一些机构的定义: 维基百科: 传统数据处理应用软件不足以处理的大型而复杂的数据集; 包含的数据大小超过了传统软件在可接受时间内处理的能力。 互联网数据中心(IDC): 为了能够更经济地从高频率、大容量、不同结构和类型的数据中获取价值而设计的新一代架构和技术。
不温卜火
2020/10/28
1.1K0
大数据应用导论 Chapter1 | 大数据技术与应用概述
基于Scrapy-Redis的分布式景点数据爬取与热力图生成
在旅游行业和城市规划中,热门景点的数据分析具有重要意义。通过爬取景点数据并生成热力图,可以直观展示游客分布、热门区域及人流趋势,为商业决策、景区管理及智慧城市建设提供数据支持。
小白学大数据
2025/05/17
980
WebGIS开发中一些常见的概念
地理坐标系(Geographic Coordinate System, 简称 GCS)是以地球椭球体面为参考面,以法线为依据,用经纬度表示地面点在椭球表面的位置的坐标系统。简单来说,地理坐标系就是用经纬度来表示地球表面物体的位置。不同的地理坐标系的区别在于用于拟合地球大地水准面的椭球大小和位置。常见的地理坐标系包括GCS_WGS_1984、GCS_CN_2000、GCS_Beijing_1954和GCS_Xian_1980等。
牛老师讲GIS
2024/12/30
2570
WebGIS开发中一些常见的概念
数据科学家成长指南(中)
大家新年好呀,在《 数据科学家成长指南(上) 》中已经介绍了基础原理、统计学、编程能力和机器学习的要点大纲,今天更新后续的第五、六、七条线路:自然语言处理、数据可视化、大数据。
Datawhale
2019/09/09
1.1K0
数据科学家成长指南(中)
大数据OLAP系统比较
至于clickhouse/druid/pinot三者的比较可以参见这篇文章:Comparison of the Open Source OLAP Systems for Big Data: ClickHouse, Druid, and Pinot,整体写的非常好而且有深度,对比表格翻译如下:
职场亮哥
2020/10/10
3.3K0
企业级大数据技术体系
Sqoop/Canal:关系型数据收集和导入工具,是连接关系型数据库和Hadoop的桥梁,Sqoop可将关系型数据库的数据全量导入Hadoop,反之亦然。而Canal可用于实时数据的增量导入
凹谷
2020/04/11
6870
交通时空大数据如何分析,我写了本书!
大数据时代到来,随着智能设备与物联网技术的普及,人在社会生产活动中会产生大量的数据。在我们的日常活动中,手机会记录下我们到访过的地点;在使用城市公交IC卡、共享单车等服务时,服务供应商会知道这些出行需求产生的时间与地点;公交车与出租车的定位信息,也可以告诉我们城市交通状态的具体情况。这些具备时间、空间与个体属性的数据能够为城市交通的智慧管控提供强有力的支持。
Datawhale
2022/10/31
2.3K0
交通时空大数据如何分析,我写了本书!
学废了系列 - WebGIS vs WebGL图形编程
目前工作中有不少涉及到地图的项目,我参加了几次技术评审,前端伙伴们在 WebGIS 方面的知识储备稍有不足,这次分享的主要目的是科普一些在前端领域比较常用的 WebGIS 知识。另外,我之前的工作中积攒了一些从零开始搭建 WebGL 地图引擎的微薄经验,虽然最终遗憾没有上线,但在其中学到的一些WebGL知识还是值得分享一下。WebGL 可以说是前端可视化技术领域难度最大的一项图形编程技术,所以今天就结合 WebGIS 这个话题顺带分享一些 WebGL 的相关知识,不会太深入,很细节的技术点在后续文章里再讲解。
寒月十八
2021/06/21
2K0
学废了系列 - WebGIS vs WebGL图形编程
相关推荐
学术大讲堂 |(六)基于大数据的网络智慧运营应用研发
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档