思路很简单:Spark 可以通过 JDBC 读取 MySQL 上的数据,也可以执行 SQL 查询,因此我们可以直接连接到 MySQL 并执行查询。那么为什么速度会快呢?对一些需要运行很长时间的查询(如报表或者BI),由于 Spark 是一个大规模并行系统,因此查询会非常的快。MySQL 只能为每一个查询分配一个 CPU 核来处理,而 Spark 可以使用所有集群节点的所有核。在下面的例子中,我们会在 Spark 中执行 MySQL 查询,这个查询速度比直接在 MySQL 上执行速度要快 5 到 10 倍。
另外,Spark 可以增加“集群”级别的并行机制,在使用 MySQL 复制或者 Percona XtraDB Cluster 的情况下,Spark 可以把查询变成一组更小的查询(有点像使用了分区表时可以在每个分区都执行一个查询),然后在多个 Percona XtraDB Cluster 节点的多个从服务器上并行的执行这些小查询。最后它会使用map/reduce 方式将每个节点返回的结果聚合在一起形成完整的结果。针对普通客户端浏览和分析大数据困难的问题, 结合 Spark 和 LOD 技术, 以热图为例提出一种面向大数据可视化技术框架 首先利用 Spark 平台分层并以瓦片为单位并行计算, 然后将结果分布式存储在 HDFS 上, 最后通过web 服务器应用Ajax技术结合地理信息提供各种时空分析服务文中重点解决了数据点位置和地图之间的映射, 以及由于并行计算导致的热图瓦片之间边缘偏差这2个问题实验结果表明,该方法将数据交互 *** 作与数据绘制和计算任务分离, 为浏览器端大数据可视化提供了一个新的思路
目前大数据可视化面临的主要问题包括:
1) 数据复杂散乱 经常发生数据缺失、数据值不对、结构化程度不高
2) 迭代式分析成本高 在初次查询后如果发现结果不对, 改变查询条件重新查询代价高
3) 构建复杂工作流困难 从多数据源取得包含各种不同特征的原始数据,然后执行机器学习算法或者复杂查询, 探索过程漫长
4) 受到原有技术限制, 对小规模数据分析很难直接扩展到大数据分析
5) 数据点的规模超过普通显示器可能提供的有效像素点
Hadoop和Spark先后成为大数据分析工业界的研究热点,前者是一个能够对大量数据提供分布式处理的软件框架和文件系统(hadoopdistrib-utedfilesystem,HDFS);后者是一个通用大数据计算平台,可以解决大数据计算中的批处理、 交互查询及流式计算等核心问题Zeppelin可以作为Spark的解释器,进一步提供基于 Web 页面的数据分析和可视化协作可以输出表格、柱状图、折线图、饼状图、点图等,但是无法提供更为复杂的交互分析手段
相关工作
面向 web 的轻量级数据可视化工具主要是一些JavaScript库,利用canvas或者svg画散点,svg不能支持十亿以上的节点,使用 canvas 画布绘图的heatmapjs 在面对大数据量时也无能为力
热图是一种常用的基本数据可视化技术,通常用颜色编码数值大小,并以矩阵或方格形式整齐排列,在二维平面或者地图上呈现数据空间分布,被广泛应用在许多领域近年来,许多研究者成功地将热图应用在眼动数据可视分析上, 有效地概括并表达用户视觉注意力的累计分布
LOD针对数据可视化绘制速度慢、效率低等问题,孙敏等提出基于格网划分的LOD(levelsofdetail)分层方法, 实现对大数据集 DEM 数据的实时漫游
并行计算大数据热图
经纬度换算
并行计算
在 Spark 平台上实现热图的绘制,首先将经纬度坐标转换为对应不同瓦片上的像素坐标每个基站的辐射范围可近似认为相同, 即每个基站(收集数据的基站坐标)的初始影响力近似相同,因此可采用影响力叠加法将数据点绘制到画布上,然后做径向渐变,叠加出每个位置的影响大小,得到初始灰度图,如图2a所示然后将每一个像素点着色,根据每个像素的灰度值大小,以及调色板将灰度值映射成相对应的颜色 图 2b 是一个透明的PNG 格式, 调色板如图 2c 所示 本文中出现的热图均采用图 2c 调色板
image_1bv9vh4oqfatb5a12s4ui1sbe9png-1859kB
将计算出的热图结果存储在HDFS上,并与经纬度以及层级建立索引关系方便以后读取,拼接后的热图绘制效果如图 3 所示
image_1bv9vj0vb16um1pt91qrs17bh1jam9png-128kB
瓦片边缘问题
image_1bv9vno7315gi1l1r1gog1cdg1tdnmpng-346kB
边缘热点可能处于2片或者4片瓦片之间,因此需要通过2次或者4次重复计算通过本文提出的重叠计算方法可以解决热图分片计算的边缘问题。
实验
image_1bv9vr8311fe817tt11bb22qlr113png-2842kB
总结
本文提出的大数据热图可视化方法能够有效地解决前端绘制计算量大的问题,通过在Spark平台上以瓦片为单位分层次并行计算热图, 将生成的热图存储在HDFS上,然后通过web服务器提供浏览器交互服务, 用户可以通过在地图上拖动鼠标或放大/缩小等 *** 作选择感兴趣区域,再分析不同时间点用户行为差异或渐变过程 通过解决热图数据点和地图映射关系问题以及瓦片热图之间的边缘问题,提供大数据热图绘方法, 以满足用户交互、协同和共享等多方面需求该方法可以拓展到其他常用可视化方法,如ScatterPlot, Bar Chart,平行坐标等但绘制过程是基于Spark计算后得到的离线数据,在实时性上还不能得到保证, 在下一步工作中, 我们将着手利用 Spark Streaming 库来解决这一问题
1、解决问题的层面不一样
首先,Hadoop和Apache Spark两者都是大数据框架,但是各自存在的目的不尽相同。Hadoop实质上更多是一个分布式数据基础设施: 它将巨大的数据集分派到一个由普通计算机组成的集群中的多个节点进行存储,意味着您不需要购买和维护昂贵的服务器硬件。
同时,Hadoop还会索引和跟踪这些数据,让大数据处理和分析效率达到前所未有的高度。Spark,则是那么一个专门用来对那些分布式存储的大数据进行处理的工具,它并不会进行分布式数据的存储。
2、两者可合可分
Hadoop除了提供为大家所共识的HDFS分布式数据存储功能之外,还提供了叫做MapReduce的数据处理功能。所以这里我们完全可以抛开Spark,使用Hadoop自身的MapReduce来完成数据的处理。
相反,Spark也不是非要依附在Hadoop身上才能生存。但如上所述,毕竟它没有提供文件管理系统,所以,它必须和其他的分布式文件系统进行集成才能运作。这里我们可以选择Hadoop的HDFS,也可以选择其他的基于云的数据系统平台。但Spark默认来说还是被用在Hadoop上面的,毕竟,大家都认为它们的结合是最好的。
以下是从网上摘录的对MapReduce的最简洁明了的解析:
我们要数图书馆中的所有书。你数1号书架,我数2号书架。这就是“Map”。我们人越多,数书就更快。
现在我们到一起,把所有人的统计数加在一起。这就是“Reduce”。
3、Spark数据处理速度秒杀MapReduce
Spark因为其处理数据的方式不一样,会比MapReduce快上很多。MapReduce是分步对数据进行处理的: ”从集群中读取数据,进行一次处理,将结果写到集群,从集群中读取更新后的数据,进行下一次的处理,将结果写到集群,等等…“ Booz Allen Hamilton的数据科学家Kirk Borne如此解析。
反观Spark,它会在内存中以接近“实时”的时间完成所有的数据分析:“从集群中读取数据,完成所有必须的分析处理,将结果写回集群,完成,” Born说道。Spark的批处理速度比MapReduce快近10倍,内存中的数据分析速度则快近100倍。
如果需要处理的数据和结果需求大部分情况下是静态的,且你也有耐心等待批处理的完成的话,MapReduce的处理方式也是完全可以接受的。
但如果你需要对流数据进行分析,比如那些来自于工厂的传感器收集回来的数据,又或者说你的应用是需要多重数据处理的,那么你也许更应该使用Spark进行处理。
大部分机器学习算法都是需要多重数据处理的。此外,通常会用到Spark的应用场景有以下方面:实时的市场活动,在线产品推荐,网络安全分析,机器日记监控等。
4、灾难恢复
两者的灾难恢复方式迥异,但是都很不错。因为Hadoop将每次处理后的数据都写入到磁盘上,所以其天生就能很有d性的对系统错误进行处理。
Spark的数据对象存储在分布于数据集群中的叫做d性分布式数据集(RDD: Resilient Distributed Dataset)中。这些数据对象既可以放在内存,也可以放在磁盘,所以RDD同样也可以提供完成的灾难恢复功能。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)