电波卫士
1 引言
根据我中心现有的大数据平台技术架构，基于2016年频率使用评估工作中出现的系统响应速度较慢、存储空间不足等问题，我们希望通过对Hadoop 以及其他大数据生态环境中的最新技术进行研究，结合现存的体系架构，对系统就行改进，从而提高系统运行效率，改善系统计算性能。 2 目前架构
现有的频率使用评估平台主要采用了Hadoop2.0
大数据平台生态系统中的组件。数据存储方面采用HDFS+Kudu ，系统管理和调度采用YA R N ，实时计算方面采用Spark+Kaf ka ，数据查询采用Impala 等，相关的模块都是较为稳定的正式版本。随着Hadoop2.0的进一步发展，Hadoop3.0版本的推出，
在数据的存储，资源调度等方面陆续出现了一些系统平台开发评估
更加先进的模块，如用于进行数据存储的ORC 和Parquet 等。
除大数据平台的处理模块外，频率使用评估本身数据处理的过程中涉及到信道占用度、频段占用度、信号覆盖率等性能指标的计算和查询，涉及到大量和SQL 相关的操作。从平台优化的角度出发，我们也在考虑是否可以对这些相关的数据操作进行一定程度的优化，从而提高系统的响应速度。
3 现状分析
频谱使用评估分析与应用系统现由6台服务器
组成计算机集，提供共计84T 的存储容量。通过2016年频谱评估专项活动，各省上报原始监测数据约31T ，入库后数据量约为62T ，大约2亿条记录。采
作者简介：赵 哲，男，汉族，硕士研究生，毕业于美国佐治亚大学，获得计算机科学和技术专业硕士，现就职于国家无线电监测中心数据分析应用处。
谭光林，男，汉族，硕士研究生，毕业于北京邮电大学，获得计算机科学和技术专业硕士，现就职于国家无线电监测中心信息管理处。
频率评估平台系统优化的研究
赵 哲，谭光林
（国家无线电监测中心，北京 100037）
摘要：
随着Hadoop平台从2.0版本演进到3.0版本，更多的新技术被应用到了整个Hadoop生态圈内。本文的主要目的是在研究2.0版本和3.0版本的Hadoop架构中，是否存在比当前频率评估系统中已经应用的组件更加优化的新组件，并探索是否可以将这些新技术应用到未来的平台中。
关键词：
大数据；Hadoop；数据管理doi：
10.3969/J.ISSN.1672-7274.2018.02.018中图分类号：
TN915.03 文献标示码：A 文章编码：1672-7274（2018）02-0053-05Abstract: Along with the Hadoop system evolved from version 2.0 to 3.0, plenty of new technologies have
been developed and deployed. The purpose of this paper is to examine these new technologies, and discover if there are potential better solutions, which could improve the performance of the current platform.
Keywords: Big Data; Hadoop; Data Management
Zhao Zhe, Tan Guanglin
(The State Radio Monitoring Center, Beijing, 100037)
Radio Spectrum Utilization Evaluation System Optimization
用分布式存储技术、海量数据传输处理技术、海量数据交互式查询技术等构建系统的大数据支撑平台及各种业务应用。
通过数据校验、数据处理、数据分析以及数据应用及展示这四大子系统，实现原始监测数据从上报到入库，到计算、分析，再到数据展现全过程的信息化，同时根据专项活动中对公众移动通信频段的评估工作的要求，通过统计图表等方式，直观、准确地反映了频谱使用的实际情况，为频谱管理精细化提供决策支持。
综合频率评估平台软硬件构建方式，平台的优化可以从硬件配置、处理模块和相关算法等三个方面进行入手。
鉴于本身平台的硬件构架方式和硬件采购成本已经决定了当前的硬件能够继续升级，但系统处理能力无法持续线性增加，所以平台优化的主要集中在对大数据平台的模块和相关指标算法方面。
对于大数据平台的模块，目前的工作思路是考虑对相关的模块进行替换，搭建实验环境，进行样本数据运算，得出实验结果，从而得出是否有更适合频率使用评估工作采用的数据处理模块。如当前的存储模块采用的是Kudu，可通过使用ORC和Parquet进行相应的替换。
对于相关性能指标的算法，可以考虑通过对SQL语句和优化，以及对于算法本身的相关研究，实现性能的提高，具体需要研究的算法，会在随后的工作中具体明确的提出。
4 最新技术
从数据存储和数据计算两个方面入手，我们对Ha doop3.0生态圈中的最新技术进行了筛选和考察，从中挑选出了部分适合现有平台采用的技术。接下来重点介绍我们实验环境中会用到的相关技术手段，并进行初步的对比。
⊙在Hadoop3.0中实现的Integrating Erasure Coding备份方式在实现了传统Erasure Coding
备份的基础上，提高了磁盘空间的利用率。
例如：一个提供3倍冗余的的文件备份，假
如每个文件需要6个数据块进行存储的话，
那么需要6*3=18个磁盘块，而如果采用
Interating EC的方式，实现相同3倍冗余备
份，只需要9个磁盘块。
⊙ Kudu是Cloudera开发的存储系统，其整体应用模式和HBase比较接近，即支持行级别
的随机读写，并支持批量顺序检索功能。
⊙ Parquet是面向分析型业务的列式存储格式。
列存储可以跳过不符合条件的数据，只读取
需要的数据，降低IO数据量。压缩编码可以
降低磁盘存储空间。
⊙ ORC（OptimizedRC File）存储源自于RC （RecordColumnar File）这种存储格式，
RC是一种列式存储引擎，对s c h e m a演化
（修改schema需要重新生成数据）支持较
差，而ORC是对RC改进，但它仍对schema
演化支持较差，主要是在压缩编码，查询性
能方面做了优化。
⊙ Storm是一个免费并开源的分布式实时计算系统。利用Storm可以很容易做到可靠地处
理无限的数据流，像Hadoop批量处理大数
据一样，Storm可以实时处理数据。
⊙ Spark是一个基于内存计算的开源的集计算系统，目的是让数据分析更加快速。Spark
是一种与 Hadoop 相似的开源集计算环
境，但是两者之间还存在一些不同之处，这
些有用的不同之处使 Spark 在某些工作负
载方面表现得更加优越。换句话说，Spark
启用了内存分布数据集，除了能够提供交互
式查询外，它还可以优化迭代工作负载。
5 优化实验
接下来我们进行了三次模拟环境下的数据存储图1 Hadoop3.0生态系统
电波卫士
和计算实验。实验环境和实验流程如下：
实验环境：
⊙主机数量 10台，其中台式电脑8台，笔记本2台。
⊙所有主机统一接入到一台路由器，配置相应
的IP网段，进行互联互通。
实验流程：
⊙试验环境搭建。
⊙相应组件安装。
⊙测试数据导入。
⊙测试例执行。
⊙实验结果采集。
5.1 EC校验
目前我们的频率评估系统采用了主流的Hadoop2.0中R AID存储和备份方式，也就是在数据保护方面采取了传统的Erasure Coding的方式，我们希望通过本实验，可以达到未来能够将系统的存储备份方式升级提高到Integ rating Erasu re Coding的模式下，从而提高系统的存储备份率。
5.2 Parquet、Kudu和HBase等的对比实验
目前我们的频率评估系统采用了Kudu作为数据的存储系统，我们希望通过本实验，测试在相同数据条件下，是否可以通过ORC或者Parquet来进一步提高数据的查和计算速度，从而提高系统的整体性能。
5.3 Impala，Kudu，Presto和Spark的计算和
对比
目前我们的频率评估系统采用了Spark+Impala 的方式在进行上层的数据处理和任务分解。希望通过本实验，测试在相同数据条件下，未来如果数据的采集方式发生改变，是否可以通过Stream组件提供流式计算处理能力。
6 实验结果
6.1 EC实验分析：
经过实验测试，我们得到实验结果见表1：
EC技术的优势确实明显，但是它的使用也是需要一些代价的，一旦数据需要恢复，EC会造成两大资源的消耗。
⊙网络带宽的消耗，因为数据恢复需要去读其他的数据块和校验块。
⊙进行编码，解码计算需要消耗CPU资源。
综合考虑，在需要进行数据恢复时，EC既耗网络又耗CPU，从实际环境部署的角度来分
析，代价也较高。所以将此技术用于线上服
务可能会不够稳定，最好的选择是用于冷数
据集：
⊙冷数据集往往有大量的长期没有被访问的数据，体量确实很大，采用EC技术，可以
大大减少副本数。
⊙冷数据集基本稳定，耗资源量少，所以一旦进行数据恢复，将不会对集造成大的
影响。
出于上述二种原因，冷数据集无非是一个很好的选择。
6.2 Parquet、Kudu和HBase等的对比实验6.2.1 空间利用
根据测量结果，利用Kudu和Parquet编码的数据提供了最佳的压缩率。与使用MapFiles的原始数据集编码相比，使用类似Snappy或GZip之类的压缩算法可以进一步显著减少数据量达10倍。
由于HBase存储数据的方式是一个空间效率较低的解决方案，虽然HBase块的压缩给出相当好的比率，但是与Kudu和Parquet相比差距仍然较大。
6.2.2 提取速度
由于Apache Impala执行数据重构以串行写入单个HDFS目录（Hive分区），因此对于HDFS格式和HBase或Kudu的格式，可以直接比较单个数据分区撷取效率。使用Avro或Parquet编码写入的HDFS 文件比存储引擎（如HBase和Kudu）提供了更好的结果（至少5倍）。
使用Avro或Parquet编码写入的HDFS
文件比
表1 存储实验
存储引擎（例如HBase和Kudu）提供了更好的结果（至少5倍）。由于Avro具有最轻量的编码器，因此其实现了最好的撷取性能。
另一方面，在这个测试中H Base非常慢（性能比Kudu差）。这很可能是由于行键的长度（6个并置列）引起的，其平均约为60个字节。HBase必须为一行中的每一列分别编码一个键，这对于长记录（包含许多列）可能不是最佳的方法。
6.2.3 随机数据查延迟
当通过记录键访问数据时，因为使用了内置索引，Kudu和HBase的访问速度是最快的。图上的值都是基于冷缓存（cold cache）进行测量。
使用Apache I mpala进行随机查测试对于Kudu和HBase来说是次优选择，因为在真正执行查询（计划、代码生成等）之前耗费了大量的时间——通常大约是200ms。因此，对于低延迟数据访问，建议跳过Impala并使用专用API（我们也尝试过这种方法，Kudu和H Ba se的结果类似：冷缓存小于200ms，预热缓存小于80ms）。
与Kudu和HBase相反，检索以Avro格式存储的单个记录中的数据只能在对整个数据分区的强力扫描中完成（需要注意的是 – 数据由记录键的一部分进行分区，因此针对这种情况应用分区修剪技术）。平均分区的大小为GB级，因此获取所需的记录需要耗费几秒钟的时间（取决于IO吞吐量），并使用大量的集资源。这最终减少了必须在集上全速执行的并发查询的数量。
同样的问题也适用于Parquet，然而，Parquet格式的柱状特性允许相对快速地执行分区扫描。由于列投影和列谓词的下推，扫描输入集的大小最终从数GB减少到只有几MB（非常高效，56列经过扫描后只剩下3列）。
6.2.4 数据扫描速率
由于通过应用列投影输入集数量减少，Parquet 在此测试中胜过了Avro。Parquet不仅在每內核处理速率方面保持了最高效率，同时也在完成处理方面保持最快速度。
在Parquet和Avro的情况下，数据访问并行化的单位是HDFS文件块，其很容易在Hadoop集上的所有可用资源上均匀分布处理。
在扫描效率方面，Kudu（采用Snappy压缩）与Parquet相差不大。因为列投影，其受益匪浅。
由于数据访问并行化的单位是表分区，扫描存储在Kudu和HBase中的数据可能不平衡。因此，扫描中涉及的资源量取决于给定表分区的数量及其在集中的分布。
在这个测试案例中，因为Kudu不支持谓词，所以不可能使用Kudu的本地谓词下推功能。附加测试结果证明，当使用支持的谓词时，Kudu扫描速度比Parquet更快。
在使用HBase进行测试之前，扫描的列在专用HBase列族中被分离，这就提高了5倍的扫描效率。但仍然与Parquet或Kudu存在较大差距。
6.3 Impala，Kudu，Presto和Spark的计算和
对比实验分析
6.3.1 计算引擎速度对比
表2
计算速度实验一
表3 计算速度实验二
表4 计算速度实验三
表5 计算速度实验五
表6 计算速度实验六
电波卫士
6.3.2 存储格式速度对比
表7 存储速度实验一
参考文献
[1] Zikopoulos, Paul, and Chris Eaton. Understanding big data: Analytics for
enterprise class hadoop and streaming data. McGraw-Hill Osborne Media, 2011.
[2] White, Tom. Hadoop: The definitive guide. " O'Reilly Media, Inc.", 2012.
[3] Gray, S., et al. "IBM Big SQL 3.0: SQL-on-Hadoop without compromise."
(2014).
[4] Masur, Rohit G., and Suzanne K. Mcintosh. "Preliminary performance
analysis of Hadoop 3.0. 0-alpha3." Scientific Data Summit (NYSDS), 2017 New York. IEEE, 2017.
[5] Vidhyavathi, P. "A Review On Hadoop: Privacy For A Multi-Skyline
Queries With Map Reduce." IJSEAT 5.10 (2017): 1004-1007.
表8 存储速度实验二
表9 存储速度实验三
■
CCBN2018产品创新奖复评工作会议在京顺利召开
十九大报告明确提出“加快建设创新型国家”，要“倡导创新文化”。新时代当有新作为，媒体融合发展已经上升到国家战略高度，为适应未来信息化智能化发展需求，实现传统媒体和新兴媒体的融合，已经是第四届的“CCBN 产品创新奖”为新兴信息技术与广播影视产业的深度融合搭建了交流平台，为推动广电事业产业发展提供了技术支撑，积蓄了广电科技发展的后续力量。
从今年的申报情况以管窥豹，可以预见广播影视行业进入了一个全新时代“CCBN2018产品创新奖”整体报名、参评活动于2017年11月初正式启动，期间共收到各参展企业提交参评产品与技术方案超过150项。整个评奖过程采用无纸化，参评企业通过网络申报，专家评审会现场网上打分。在严格的资料审核、初评复审会议阶段，各参评企业均积极准备答辩资料，并在现场认真听取了专家的意见。这些意见不仅为各企业提供了很好的学习机会，更为广播影视行业的进一步发展明确了方向。
“CCBN2018产品创新奖”复评阶段参评产品及技术方案共计51件，按照制作与播出、传输与覆盖、业务平台与终端、融合媒体这四大类进行申报，内容涵盖节目制作与播出，有线、无线、卫星网络传输与覆盖，业务平台与终端设备，融合媒体等全产业链，充分展示了我国广播影视文化技术创新成果，展现广播影视行业的新优势，推动科技创新再上新台阶。
“CCBN2018产品创新奖”复评工
作会议由国家新闻出版广电总局科学技术委员会副主任，专家评审组组长杜百川主持，评审专家组由来自广电领域的22位行业专家组成。评审会入围各企业代表从产品创新、技术创新、市场前景等多方面对参评产品进行介绍。评审会本着公开、公平、公正的原则，最终评选出20项“CCBN2018产品创新奖”获奖产品和方案，其中包括“CCBN2018产品创新杰出奖”8项和“CCBN2018产品创新优秀奖”12项，
力图全方位、多角度对中国广播影视行业科技进步和产品创新进行全面的展示。最终获奖名单将于3月21日在北京国际会议中心“CCBN 主题报告会”期间揭晓，现场将举行颁奖典礼。欢迎行业各界人士共同关注CCBN2018，关注CCBN 不断创新服务的举措，共同推进中国广播影视行业的不断繁荣，推动行业融合创新发展。
大奖究竟花落谁家，敬请关注3月21日“CCBN2017年度创新奖”
颁奖典礼盛况。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议