基于Spark+Redis的实时可视分析探究

本文主要是介绍基于Spark+Redis的实时可视分析探究，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

 

及“跑步点亮北京”的可视项目设计

 

 

目录

1.引言

2.大数据采集

2.1.大数据特征

2.2.采集方式

“跑步点亮北京”的数据采集方式

2.3.存储方式

a)Hadoop(HDFS)

b)Redis内存数据库（Geo）

2.4数据处理

(1) HDFS 列表

(2)数据添加

(3) 数据清洗

(4) 数据合并

(5) 数据类型管理

2.5.“跑步点亮北京”的数据存储方式

3.大数据分析和挖掘

3.1.计算框架

a)MapReduce

b)Spark

3.2.“跑步点亮北京”计算框架

4.大数据可视化

4.1可视化工具

4.2.可视分析

4.2.1科学可视化

4.2.2大数据可视化分析

4.3可视化平台搭建

4.6面向大数据主流应用的信息可视化技术

4.6.1 文本可视化

4.6.2 网络(图)可视化

4.6.3 时空数据可视化

4.6.4 多维数据可视化

4.7. 支持可视分析的人机交互技术

4.7.1 支持可视分析过程的界面隐喻与交互组件

4.7.2 多尺度、多焦点、多侧面交互技术

4.7..3 面向Post-WIMP的自然交互技术

4.8.“跑步点亮北京”的可视化方案

5.个人针对可视分析未来预测

6.个人学习规划

7.总结

参考文献

 

 

 

 

 

 

 

 

 

 

 

 

1.引言

     老师让我阐述对Spark和可视分析的技术理解，我认为实践便是最好的理解。所以，在自身对Redis数据库、PHP、Html5、Css3、JavaScript等web开发技术熟练使用的情况下，结合“跑步点亮北京”的可视产品设计，进一步阐述基于Spark+Redis的实时可视分析的技术理解。

     “跑步点亮北京”的灵感来自于两方面，一是“微博签到点亮中国”的可视分析应用；二是我们团队的自有体育项目，想要为当前热火朝天的跑步运动做一些有趣实用的产品应用。

     当前的人们跑步越来越喜欢组队跑步，从而出现了很多“跑团”，各个“跑团”的活动区域往往会趋于固定，且逐步缺乏趣味性，内部成员可能逐步趋于懈怠，如何解决这个问题，“跑步点亮北京”的可视分析应用将会解决这个问题。

     “跑步点亮北京”将各个跑团在虚拟地图上标记为不同的亮丽颜色，其成员跑过的区域将会用对应的亮丽颜色进行跑步轨迹的标记，跑的区域越广，虚拟地图上被团队颜色覆盖得越广，同一区域跑过的次数越多，轨迹将会叠加，从而在虚拟地图上的颜色标记将会更加显眼亮丽。

     不同“跑团”标记的颜色不同，跑过重叠的区域将会显示此区域跑过次数最多的团队标记颜色，从而不仅通过此可视分析应用激发跑友们跑步“占领”地图的热情，通时也通过互相“侵占”对方“跑团”领地的方式增加跑步锻炼过程中的趣味性，此应用也将是比较实用的、针对普通大众的可视分析应用。

图1-1 北京地区跑团轨迹图

     “跑步点亮北京”将海量的实时的跑友坐标和轨迹数据基于位置进行抽稀，按照事先机器学习自动设定的可能标记位置点的经过次数聚合,然后再使用百度Echart进行Web可视化。通过对城市里不同地点的可视化，可以清楚的看出人口、道路的空间分布与跑步轨迹等特征，研究“跑团”群体活动的地理空间分布、聚落规模、及活动范围具有一定的参考意义。

图1-2 北京邮电大学及北师跑团轨迹图

     我将会根据可视分析的四个基本步骤，分别阐述“跑步点亮北京”里所涉及到的技术理解和最佳的技术解决方案。

主要想解决以下几个问题：

(1) 如何对小而数量巨大的地理位置数据集进行采集、存储、管理

(2) 如何实现快速的海量数据分析、挖掘，以便可视化

(3) 如何可视化，怎样提高用户体验

(4) 响应时间、并发要求

     以下阐述，由于对Spark及可视分析理解尚浅，错误之处还望老师指正。

 

2.大数据采集

2.1.大数据特征

    大数据具有4V 特征[1],即:

(1)体量巨大(volume)

(2)类型繁多(variety)

(3)时效性高(velocity)

(4)价值密度低(value)

     而我们的项目“跑步点亮北京”所记录的跑友的抽样时刻的地理位置数据同样具有体量巨大、不同客户端类型可能不一致等大数据的特征。

2.2.采集方式

a)互联网网络

b)硬件传感器

c)其它特定方式

“跑步点亮北京”的数据采集方式

     我们采用的是基于移动端的GPS+网络定位（比如微信获取地理位置接口），甚至可以采集小米手环、华为手环等智能穿戴设备，不同设备及平台采集的数据格式多,且多来自于异构环境.即使获得数据源,得到的数据的完整性、一致性、准确性都难以保证,数据质量的不确定问题将直接影响可视分析的科学性和准确性。

 

2.3.存储方式

a)Hadoop(HDFS)

     HDFS是Hadoop的具有高度容错特性的分布式文件系统，它为Hadoop分布式计算提供高容错、高可扩展的存储服务[7]。

     HDFS架构由一个主节点(NameNode)和多个从节点(DataNode)构成NameNode负责整个HDFS的节点管理工作，它担当着管理文件系统名字空间和控制外部客户机的访问并将数据块映射到DataNode的角色。DataNode是HDFS的运行节点，每一个Hadoop的物理节点都部署着一个DataNode，它负责将数据块存储在文件中，并对文件读写、删除、复制块命令请求进行响应。NameNode和DataNode之间的通信协议采用TCP／IP，NameNode通过一个基于RPC的专有协议与DataNode通信，反之，DataNode和NameNode两者是靠一个基于块的专有协议进行通信。

b)Redis内存数据库（Geo）

   Redis是一个先进的key-value内存数据库

·异常快速：Redis的速度非常快，每秒能执行约11万集合，每秒约81000+条记录。

·支持丰富的数据类型：列表，集合，有序集合，散列数据类型。这使得它非常容易解决各种各样的问题，因为我们知道哪些问题是可以处理通过它的数据类型更好。

·操作都是原子性：所有Redis操作是原子的，这保证了如果两个客户端同时访问的Redis服务器将获得更新后的值。

·多功能实用工具：Redis是一个多实用的工具，可以在多个用例如缓存，消息，队列使用(Redis原生支持发布/订阅)，任何短暂的数据，应用程序，如Web应用程序会话，网页命中计数等。

     尤其是当前 Redis新增位置查询功能Geo，提供精准而且稳定的位置服务。例如添加经纬度、计算经纬度相似度、计算城市之间的包含关系等多种位置计算功能，该模块在Benchmark上运行的性能表现，每秒可达近5百万次编解码，能满足大部分位置服务应用的需求。

2.4数据处理

    由于要处理大量、非构化的数据，跑步时利用移动设备进行的采集来的位置数据，然后将位置数据进行预处理，剔除无用数据，留下有用数据，然后对数据进行映射，跟据处理模块要功能是把非构化据或者半构化据化构化据，把繁大的非结构化据转化成可以直接使用的数据。其中，数据处理模块功能点描述如下：

(1) HDFS 列表

     系统在数据存储方面使用Hadoop生态体系中的HDFS。HDFS文件系统下，有数据处理文件DataProcess。HDFS列表是DataProcess文件及其下目录的列表可视化，可以对文件文件夹进行管理。

(2)数据添加

   数据添加是指采集据并且导入到文件系统。可以采用两种方式，第一种是数据文件直接上到指定文件夹下；第二种是通配置据源，自动上 据文件， 数据源包括关系型数据库、日志服务器、TCP端口、UDP端口等。不管采用哪种方式，在上传数据文件，都需要上传数据文件的类型，以便于下面进行数据清洗、合并。

(3) 数据清洗

     数据清洗是指处理已经导入文件系统的数据，然后把处理后的有效据再次重新导入文件系统。采用Spark程模型， 针对不同类型的数据，对空数据、缺失数据进行补缺操作， 无效数据进行数据的替换，无法处理的做标记并进行删除；对正常数据进行数据处理。并将源数据抽取的数据格式转换成为便于进入仓库处理的目标数据格式。

(4) 数据合并

    数据合并是指把清洗后的相同或者相似类型的据按照一定的合并规则合并成一组数据，数据规模可以是一个或者多个。数据清洗后的数据是按照一定规则拆分的， 不同类型的数据，采用Spark编程模型，使用不同的据操作类型进行数据文件合并，合并后数据文件重新导入文件系统。例如使用lookup操作类型进行数据文件关联，使用join操作类型进行数据文件相交。

(5) 数据类型管理

    数据类型管理是指数据类型进行创建、删除、更新、查找。系统处理分析的海量据基本都是公司部或者客户的数据，数据的种类容易区分和归类。不同的据类型需要不同的java或者scala程序进行数据清洗或者据合并，编写后的程序打成jar包。创建数据类型，需要上数据处理jar包。

 

2.5.“跑步点亮北京”的数据存储方式

         相比之下，我们决定采用Redis内存数据库存储最近一段时间的数据，现成动态实时的虚拟地图显示效果，同时定期将过去一段时间的地理位置数据分析统计，合并生成带有一定权值的特殊数据，写入HFDS中，在不影响其它，且最终表现出来的结果与原来一样的情况下，删除原来的大量过期的历史数据，减少Redis的内存占用，合理使用内存+磁盘存储的优势。并且通过数据处理，将接受到的数据进行清洗和合并，产生可以被用作可视分析的合格数据集，存储于Redis数据库中，以待Spark快速读取和操作。

    Spark和内存数据库Redis结合后可显著的提高Spark运行任务的性能，这源于Redis优秀的数据结构和执行过程，从而减小数据处理的复杂性和开销。Spark通过一个Redis连接器可以访问Redis的数据和API，加速Spark处理数据[6]。

   Spark和Redis结合使用到底有多大的性能提升呢?结合这两者来处理时序数据时可以提高46倍以上。

 

3.大数据分析和挖掘

3.1.计算框架

a)MapReduce

     MapReduce是一种Hadoop计算模式，也是Hadoop的核心所在，它可以将提交的任务自动分割，将大作业分割成若干个小作业，然后进行并行计算。MapReduce又可以分为两个阶段，即Map(映射)和Reduce(归结)。顾名思义，Map负责将数据分成若干个小数据块进行并行运算，Reduce将Map输出进行汇总，即对小数据块根据Key值合并，并将汇总结果输出。

     Hadoop任务调度控制模式

     Hadoop是一个Master-Slave架构模式，由一台主节点和若干台Slave节点组，其中，主节点负责管理和监控各个Slave节点的任务执行情况，包含一个master服务JobTracker(作业服务器)用于接收Job，它的任务是将作业分配给等待的节点，Slave节点负责具体的任务执行，包含一个Slave服务TaskTracker(任务服务器)，它负责与JobTracker通信并接收作业，再根据每个节点的拆分数据，进行Map和Reduce处理。每一个Slave节点都是并行执行，提高了计算效率。

Hadoop的任务调度控制模式主要依赖TaskTracker和JobTracker来完成，具体任务控制运行原理如下。

1．当Driver程序启动Hadoop时，就已自动启动了JobTracker，用户程序可以通过Job类的submit方法向JobTracker提交作业，也可以通过JobClient类的runJob方法将作业提交到JobTracker。另外JobClient根据InputFormat格式获得相应的InputSplit，以此确定Mapper时的任务数。

2．客户端将作业提交到任务服务器JobTracker，在作业服务器中会定义任务服务器TaskScheduler的成员变量，任务服务器调度作业是采用先进先出的调度算法实现的。

JobTracker中设有两个监听器：JobQueueJoblnprogressListener负责监听Job作业的运行情况；eagerTasklnitializationListener(任务初始化监听器)主要作用就是监视Job作业的初始化工作。

3．作业服务器JobTracker和任务服务器TaskTracker之间的通信是很频繁的，它们之间的通信是通过心跳检测实现的，任务服务器为了证实自己处于正常活跃状态(即可以接收任务状态)，每隔一段时间(可在程序中设定)向作业服务器发送一次心跳检测，作业服务器收到相应的请求，会根据当前任务的实际情况将任务发送给任务服务器。

4．JobTracker对任务根据程序进行指定的Map和Reduce操作，Map任务交给MapLauncher处理，Reduce任务由ReduceLaucher负责，进行相应的MapReduce处理后，把结果写到分布式文件系统HDFS中。

5．当JobTracker获得最后一个Task的运行成功的报告后，将Job的状态改为成功。作业客户端想要获取任务的运行情况是通过向作业服务器轮询实现的，一旦发现作业成功完成，立即打印任务完成消息给用户，进而从运行作业的状态中返回。

 

 

 

b)Spark

     Spark是一个新型计算框架模型，是一种能够在集群上对大数据集进行交互式分析的并行计算框架，通过Scala脚本以高效的方式处理数据集，另外，它还提供了本地化的调度、容错和负载平衡机制。与在Hadoop MapReduce中的数据只能保存在HDFS中不同，Spark引入了内存计算的概念，提供persisit和cache方法将RDD缓存到内存中，避免了若在计算过程中想要重用数据，必须重新到HDFS上加载数据的IO过程，从而减轻了磁盘输入输出和序列化的负担，使系统开销减少，缩短了应用执行时间，提高了应用执行效率。

     Spark提出的最主要抽象概念是弹性分布式数据集（resilient distributed dataseUIDD)，它是一个元素集合，划分到集群的各个点上，可以被并行操作。 RDDs的建立可以从HDFS(或者任意其他支持Hadoop文件系统）上的一个文件开始，或者通过驱动程序（driver program)中已存在的Scala集合。用户也可以Spark保留一个RDD在内存中，使其能在并行操作中被有效的重复使用。 最后，RDD能自动从故障点中恢复。

     Spark的第二个抽象概念是共享变量（shared variables)，可以在并行操作中使用。在默认情况下，Spark连通不同点上的一系列任务运行一个函数，它每一个函中用到的变量的拷贝传递到每一个任务中。有时候，一个变置需要在任务之间，或任务与驱动程序之间被共享。Spark支持两种类型的共享变量：广播变量，可以在内存的所有的点上存变量；累加器：只能用于做加法的变量，例如计数或求和。

RDD与分布式共享内存对比图

RDD具有更高的容错性和数据处理的高效性。

1．高效性

     当任务处理必须在多个任务节点之间进行并行操作时，或者必须重复使用中间结果时，Hdoop MapReduee框架的缺陷也随之表现出来。MapReduce的数据只能保存在HDFS中，若在计算过程中想要重用数据，必须重新加载数据，从而加大磁盘输入输出和序列化的负担，从而对系统开销带来负担，严重影响了应用执行时间。RDD的出现，为其提供了一个数据重用抽象，提供粗粒度转换，支持基于内存的计算。Spark中最主要的抽象是将数据集抽象成RDD，这种数据集合分布在各个节点上，实现数据的并行处理。另外，RDD可以被缓存到内存上，这种将中间结果缓存在内存中的处理机制，使之在后续的数据处理中可以重用数据，从而改变了MapReduce中数据必须保存在HDFS的机制，极大的提升了数据的查询速度，有效的减少了系统开支，提高了应用的运行效率。

2．容错性

     提供的共享内存模型的只读特性有效的降低了容错开销。RDD的容错机制是建立在父RDD和子RDD的依赖关系的基础上的，在各个RDD之间的依赖关系中，窄依赖中RDD的每个partition依赖于常数个数的父RDD的partition，而宽依赖中子RDD的每一个partition依赖于所有父RDD的partition。窄依赖和窄依赖主要有以下两方面的区别：

1．子RDD获得：窄依赖是一个个体对个体的概念，子RDD不必等到父RDD中所有数据块计算完毕后再进行子RDD数据块的计算，而是可以通过直接计算与之对应的父RDD的partition，来得到子RDD所对应的partition。而宽依赖必须是一个整体对个体的概念，所有的子RDD必须等待父RDD的所有partition计算完毕并传入计算节点后，才可进行子RDD的计算工作。

2． 失效节点恢复：当数据丢失时，窄依赖可以通过重新计算所丢失的子RDD的partition对应的父RDD上的partition来进行相应的数据恢复操作。而宽依赖，则必须重新计算所有父RDD的数据块。由以上所述可知，窄依赖更加有利于失效节点的恢复。

 

Spark任务处理流程介绍

     Spark任务处理的核心机制是实现了将数据缓存在内存中。与Hadoop需要将所有计算数据(包括中间计算数据)写入HDFS，依赖于JobTracker和TaskTracker来完成Job作业的管理与执行，利用MapReduce负责大规模数据集的并行运算任务的任务处理不同。Spark利用RDD的一系列的粗粒度的任务来执行应用程序，并将RDD存在内存中，使用内存替代了使用HDFS存储中间结果，能有效

的在并行计算阶段实现共享资源。另外，Spark实现了DAGScheduler，DAGScheduler会根据RDD的dependency和dependency先后产生出不同的stageDAG，用于接收用户的Job作业，然后将其按类型划分为不同的stage，并将每一个stage分解成若干个Task，向TaskScheduler提交。HDFS文件作为输入RDD，Spark会将调用过persist的RDD存在内存中，减少了Hadoop中不断与HDFS交互所造成的IO开销，Spark提供了一个通用接口来抽象每个RDD，通过不同RDD之间的依赖关系进行划分。

简单的讲，Spark任务处理流程由以下步骤组成：首先进行集群的资源分配，通过任务资源调度将划分好的若干数据块分配到工作节点进行任务的并行处理，完成后将每个工作节点完成后的数据结果返回，最后，释放程序所占用的资源空间。

具体来说， Spark的任务处理流程由主要包括以下6个步骤：

第一步：环境搭建：提交应用程序Drive Manager来构建应用程序所需要的运行环境。由SparkContext进行指定执行平台为YARN、对程序执行过程中共享量的相关操作、生成RDD和进行RDD之间的转换、进行程序运行的各种action操作等平台相关公共控制操作[4]。

第二步：Spark根据生成的RDD的依赖关系，产生final Stage，然后再根据所产生的final Stage将其划分为若干个Stage。

第三步：根据Stage划分的依赖关系进行DAG调度处理。先提交没有依赖关系的Stage，待所有无依赖关系的Stage都完成提交任务后，再提交依赖关系已经完成的Stage，直到所有Stage都己提交完成。

第四步：将Stage转换成TaskSet，在TaskSet Manager中对TaskSet进行调度。

第五步：利用ResourceOffer机制，实现任务调度与资源管理分离工作，将TaskSet分解为若干个Task，再将Task与空闲worker node绑定并发起Task任务到worker node的ExecutorBackend，通过其中的Executor进行任务处理并将结果返回。

第六步：释放占用资源。

 

3.2.“跑步点亮北京”计算框架

     MpaReduce计算框架是一种简单通用的而且能够自动处理故障的批处理离线计算模型[4]，但是在迭代计算和交互式计算方面仍存在着不足之处。提出了基于Spark的虚拟地图可视化任务处理框架，形成多核多节点的向量场分布式并行计算框架，对具有海量小文件特性的地理位置数据进行大规模任务处理和并行计算，通过减少数据迁移量和增加本地化计算，弥补了Hadoop在交互式计算方面的缺陷，相比与原MapReduce计算模式，Spark提供了更为轻巧的DAG模型、中间数据都以RDD的形式存储在各节点内存中、并且通过Shuffle传递Stage间的数据，只需要读取和写入HDFS一次，提高了虚拟地图可视化的计算效率。

     内存迭代计算的引入， 极大地提高了计算效率和速度， 但是由于内存使用量较大， 资源占用需求较高， 对高并发的计算请求资源高效合理调度存在着较大问题[6]。

     Spark有两种任务调度方法，对应了两种不同类型的任务调度模式：FIFO模式和FAIR模式。先进先出（FIFO）模式直接管理TaskManager，任务执行的过程会根据StageID的顺序来调度ＴTaskManager；公平调度FAIR模式，基本原则是根据所管理的正在运行中的任务数量来判断优先级，并通过任务权重（weight）来调整任务集执行的优先程度，权值越高，越优先执行。

     采用以上两种调度模式进行各大预定节点的跑步流量计算，虽然能够一定程度上提高计算的效率，但是由于城区不同位置的的人口密度不同，计算复杂度差别较大，计算时间差距较大，无论使用先进先出调度还是公平模式调度，都可能出现由于个别节点计算任务太大，使得整个虚拟地图渲染计算过程的时间变长。

     基于节点计算能力的算法优化，通过设计合理的调度算法，使计算复杂度高的计算任务优先分配到计算能力强的节点上，使节点计算能力达到充分发挥，避免出现长时间等待其他任务结束的情况，避免Spark随机任务分配过程出现的任务节点分配不合理的情况

     具体技术实现

     根据上述优化算法，设计和实现基于Spark的虚拟地图跑步流量次数计算优化调度方案，具体技术实现方法如下：

     （１）建立Spark集群节点计算能力表，根据Spark集群实际计算能力添加信息，包括ＣＰＵ 计算能力、ＣＰＵ核心数、内存大小。在启动Spark集群之前创建好该表，并将该表的配置信息放到SparkConf中或者在Spark启动时候由Master进程读取。

     （２）建立选定位置计算跑步人数流量任务表，该表的主要作用是对计算每个区域不同跑团跑过的计算量进行定量表示，通过计算经过跑友次数来定量表示计算的复杂度，次数数目越多，计算越复杂。

     （３）描述表转化。根据节点计算能力描述表和计算任务描述表进行转化，转化成我们需要的数据结构，进而调用优化后的任务调度算法。

     （４）应用层读取任务分配结果：

          ①读取生成的ｘｍｌ，以host为key，以所有host相同的taskId及其描述信息构成的列表为value生成一个二元元组为元素的数组。

          ②将生成的数组通过parallelize方法生成一个rdd，并设置该rdd的partition为当前需要执行的taskId的总数。

          ③对该rdd进行foreach操作，获取当前处理二元元组的第二个元素，可得到在该节点上需要执行的任务列表。

          ④改写Spark中TaskSchedulerImpl中的resourceOffers

函数，将任务分配部分代码改写为按workOffer中的host绑定task，此时遍历任务列表将对应host的task绑定到对应的host上的executor即可。

     通过以上步骤，我们可以把具体任务分发下去，使任务能够根据元组的Host值将任务分发到对应节点，完成调度。

 

 

 

4.大数据可视化

4.1可视化工具

     主流编程工具包括以下三种类型[2]：从艺术的角度创作的数据可视

化，比较典型的工具是 Processing.js，它是为艺术家提供的编程

语言；从统计和数据处理的角度，R语言是一款典型的工具，它

本身既可以做数据分析，又可以做图形处理；介于两者之间的工

具，既要兼顾数据处理，又要兼顾展现效果，D3.js是一个不错的

选择，像D3.js这种基于Javascript的数据可视化工具更适合在互联

网上互动的展示数据。

 

4.2.可视分析

     可视分析(visual analytics)是科学/信息可视化、人机交互、认知科学、数据挖掘、信息论、决策理论等研究领域的交叉融合所产生的新的研究方向[1]。两条主线:可视化技术和自动化分析模型,即是面向大规模、动态、模糊、或者常常不一致的数据集来进行分析。此外,信息可视化可以理解为编码(encoding)和解码(decoding)两个映射过程[1]。

 

4.2.1科学可视化

     分布式并行可视化算法

   4.2.1.1并行图像合成算法

     传统的并行图像合成算法主要包括前分割算法、中间分割算法和后分割算法3种类型[3]，前分割算法主要分为如下3步骤：

     (1)将数据分割并分配到每个计算节点上；

     (2)每个计算节点独立绘制分配到的数据，在这一步，节点之间不需要数据交换；

     (3)将计算节点各自绘制的图形汇总，合成最终的完整图形。

由于节点之间可能需要大量的数据交换，尤其是步骤(3)可能成为算法的瓶颈。解决这个问题的关键是减少计算节点之间的通信开销，可以通过对数据进行划分并在各计算节点间进行分配来实现。划分和分配方案需要与数据的访问一致，原则是计算节点只使用驻留本计算节点的数据进行跟踪，从而减少数据交换。

   4.2.1.2并行颗粒跟踪算

     将二维的流场可视化方法直接应用在三维流的结构不可能都成功，每个颗粒虽然可以单独跟踪，但是可能出现在空间中的任何一个位置，这就需要计算节点之间通过通信交换颗粒[5]。同时，当大量的颗粒在空间移动时，每个计算节点可能处理不同数量的颗粒，从而造成计算量严重失衡。解决这些问题的关键是减少计算节点之间的通信开销，其基本思路同并行图像合成算法。

   4.2.1.3重要信息的提取与显示技术

     这一思想的两个技术是流场可视化的层次流线束技术和用于标量数据的基于距离场的可视化技术。

   4.2.1.4原位可视化

     现有的存储系统无法把所有的计算数据都保存下来。常用方法是采用空间或者时间上的采样方法。

 

4.2.2大数据可视化分析

4.2.2.1原位交互分析技术

4.2.2.2数据存储技术

4.2.2.3可视化分析算法

4.2.2.4不确定性的量化

4.2.2.5并行计算

4.2.2.7领域资源库、框架以及工具

4.2.2.8用户界面与交互设计，以人为中心的用户界面与交互设计

 

4.3可视化平台搭建

     跑友的移动终端将采集数据通过云计算WEB端口上传信息数据，服务器将数据存储和处理的请求传递给云计算平台，完成数据处理工作。另一方面，可视化用户通过浏览器、微信等入口浏览查看当前所在位置周边“占领区域”的可视化效果。

   “跑步点亮北京”可视化平台由1个主节点、1个备用节和N个从节点构成。主节点负责任务调度，它并不担任任务计算角色，是整个云平台的的管理者和调度者。备用主节点是为了防止主节点出现故障或者宕机而导致整个集群工作受阻的情况，它会在主节点出现故障时代替主节点执行对各节点的调度工作，相当于主节点的替补。在主节点和从节点的任务分配上，主节点负责接收客户端提交的作业请求，然后根据相应的算法将作业进行拆分，分配给从节点执行相应的计算，当从节点计算完分配的作业后，主节点负责将从节点的计算结果进行整

合，将最终结果返回给客户端。

 

4.6面向大数据主流应用的信息可视化技术

4.6.1 文本可视化

     文本信息是大数据时代非结构化数据类型的典型代,按照一定规律进行布局排列,用大小、颜色、字体等图形属性对关键词进行可视化.目前,大多用字体大小代表该关键词的重要性

4.6.2 网络(图)可视化

     网络关联关系是大数据中最常见的关系,例如互联网与社交网络.层次结构数据也属于网络信息的一种特殊情况.基于网络节点和连接的拓扑关系,直观地展示网络中潜在的模式关系,

规模图可视化的主要手段[5]:

• 一类简化是对边进行聚集处理 ,使得复杂网络可视化效果更为清晰

• 另一类简化是通过层次聚类与多尺度交互,将大规模图转化为层次化树结构,并通过多尺度交互来对不同层次的图进行可视化.

4.6.3 时空数据可视化

     时空数据是指带有地理位置与时间标签的数据.传感器与移动终端的迅速普及,使得时空数据成为大数据时代典型的数据类型.时空数据可视化与地理制图学相结合,重点对时间与空间维度以及与之相关的信息

对象属性建立可视化表征,对与时间和空间密切相关的模式及规律进行展示.大数据环境下时空数据的高维性、实时性等特点,也是时空数据可视化的重点.

4.6.4 多维数据可视化

多维数据指的是具有多个维度属性的数据变量,广泛存在于基于传统关系数据库以及数据仓库的应用中,例如企业信息系统以及商业智能系统.多维数据分析的目标是探索多维数据项的分布规律和模式,并揭示不同度属性之间的隐含关系

 

4.7. 支持可视分析的人机交互技术

     信息可视化中的人机交互技术主要可概括为5 类:动态过滤技术(dynamic queries)与动态过滤用户界面、整体+详细技术(overview+detail)与Overview+Detail 用户界面、平移+缩放技术(panning+zooming)与可缩放用户界面(ZUI)、焦点+上下文技术(focus+context)与Focus+Context 用户界面、多视图关联协调技术(multiple coordinated views)与关联多视图用户界面[8]

 

4.7.1 支持可视分析过程的界面隐喻与交互组件

4.7.2 多尺度、多焦点、多侧面交互技术

(1) 多尺度界面与语义缩放(semantic zooming)技术[8]

当数据的规模超过了屏幕像素的总和,往往无法一次将所有的数据显示出来.多尺度界面(multi-scaleinterfaces是解决这一问题的有效方法,它使用不同级别的空间尺度(scale)组织信息,将尺度(scale)的层次与信息呈现的内容联系起来,将平移与缩放作为主要交互技术.各种信息可视化对象的外观随着尺度的大小进行语义缩放.

(2) 焦点+上下文(focus+context,简称F+C)技术Focus+Context 技术(F+C)的起源是广义鱼眼视图(generalized fisheye views)的提出,它将用户关注的焦点对象(focus)与整体上下文环境(context)同时显示在一个视图内,通过关注度函数(degree of interest function,简称

DOI Function)对视图中的对象进行选择性变形,突出焦点对象,而将周围环境上下文中的对象逐渐缩小

4.7..3 面向Post-WIMP的自然交互技术

Post-WIMP 交互技术极大地提升了交互方式的自然性,

例如多通道交互、触摸式交互、笔交互等,尤其适合可视分析的应用需求.

 

4.8.“跑步点亮北京”的可视化方案

     由于用户群体主要集中于移动端，如微信等平民应用，所以将以H5应用结合当前Css3在3D和更多新特性为“跑步点亮北京”提供基本的可视样式，同时借助百度Echarts等成熟的第三方js图标应用，快速地将我们虚拟地图的“占领”情况显示出来。

     如何进行web客户端和后台spark集群通信，正确的方案是，中间还有一个web服务器，客户端不与spark集群直接通信，由于为了不影响用户体验，数据的更新操作将采用后台异步的方式提交和获取数据。由于采用H5,所以可有如下两种比价好的方案：

     a)ajax长轮询

     b)websocket

每种方案在用户数量不同的阶段各有利弊，不过，建议采用websocket的方式，WebSocket 是 HTML5 一种新的协议。它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯，当用户数量较少，且web服务器还能够支持相应的并发量，可采用此种方式作为起步，较为简单。

 

5.个人针对可视分析未来预测

l移动化（移动端自由缩放、数据将实时更新、简易交互）

l3D多维化、全时空可视化、时空轨迹

l虚拟互动化（VR、MR）、人机交互

l多度关联化（人事物时空关联）

l高速化

l简易化（html5+css3+js）

l多屏互动，可视化的通信、沟通、协作、分享、存储

l服务衍生化（深度分析，预测决策，精准推荐）

l算法（可扩展性、减少搜索空间）

l实用平民化

 

6.个人学习规划

lhtml5+css3+js进阶

lPython进阶

lR语言

lScala语言+spark深入

l可视化算法、大数据分析算法

7.总结

     随着大数据时代的到来，人们越来越难以从海量的数据中提取出有用的价值，而可视分析不仅要更快更准确地把有价值的信息提取出来，更要以用户为中心的进行交互展示，认知、可视化、人机交互的深度融合.“跑步点亮北京”虽然只是一个简单的可视应用，通过不同跑团的跑步进行攻占与拓展区域，可视为简单的打卡游戏，激励人们跑步去认识彼此周遭的环境，更加积极往户外走走，认识一个全新的世界。

     通过大概一周的大量阅读各种Spark和可视分析的文章，虽然不能够对一些算法和机理有深刻的理解，可是已有了一个初步的认知，且已逐渐发现在计算机领域，很多知识是相通的，比如Spark中的任务调度和计算机的任务调度是一样的原理，所以，扎实的基础是必要的，我也喜欢这个方向，也想向这个方向做出更大的努力。

    

参考文献

[1] 任磊, 杜一, 马帅,等. 大数据可视分析综述[J]. 软件学报, 2014(9):1909-1936.

[2] 谢然. TOP50+5大数据可视化分析工具[J]. 互联网周刊, 2014(17):58-59.

[3] 陈明. 大数据可视化分析[J]. 计算机教育, 2015(5).

[4] 王鑫. 基于SPARK的流场可视化任务处理框架研究[D]. 中国海洋大学, 2015.

[5] 李爽. 基于Spark的数据处理分析系统的设计与实现[D]. 北京交通大学, 2015.

[6] 李文, 程华良, 彭耀,等. 基于Spark可视化大数据挖掘平台[C]// 系统仿真技术及其应用学术论文集. 2014.

[7] 秦勃, 朱勇, 秦雪. 基于Spark框架的乘潮水位计算与可视化平台[J]. 计算机工程与科学, 2015, 37(12):2216-2221.

[8] 兰红. 数据挖掘的数据准备与交互式可视化研究[D]. 江西理工大学, 2007.

这篇关于基于Spark+Redis的实时可视分析探究的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！