当前位置:首页 > 专题范文 > 公文范文 > 电力大数据处理存储与分析的调研报告 【精选推荐】

电力大数据处理存储与分析的调研报告 【精选推荐】

发布时间:2023-01-20 19:25:02 来源:网友投稿

电力大数据处理存储与分析的调研报告 编号:SY-…….密级:受控电力大数据处理存储与分析的调研报告电力大数据处理下面是小编为大家整理的电力大数据处理存储与分析的调研报告 ,供大家参考。

电力大数据处理存储与分析的调研报告

  编号:SY-…….密级:受控

  电力大数据处理存储与分析的调研报告

  电力大数据处理、储备与分析

  的调研报告

  2020年12月

  目

  录

  1、什么是大数据..........................................................................................................51.1、Volume(体积)...........................................................................................51.2、Variety(多样)

  ............................................................................................51.3、Velocity(效率)..........................................................................................61.4、Veracity(价值)..........................................................................................62、大数据关键技术......................................................................................................62.1、大数据采集技术............................................................................................2.2、大数据预处理技术........................................................................................2.3、大数据储备及治理技术................................................................................2.4、大数据分析及挖掘技术................................................................................2.5、大数据展现与应用技术................................................................................3、数据处理与分析......................................................................................................3.1、传统方式......................................................................................................13.2、Hadoop大数据新方法

  ................................................................................113.3、大规模并行分析数据库..............................................................................123.4、大数据方法的互补......................................................................................133.5、大数据使用案例..........................................................................................144、展望电力大数据时代............................................................................................154.1、电力大数据价值分析..................................................................................154.2、电力大数据应用前景..................................................................................164.3、电力大数据进展与挑战..............................................................................15、迈向电力大数据时代............................................................................................15.1、电力大数据关健技术..................................................................................15.2、电力大数据进展策略..................................................................................16、电力大数据实践....................................................................................................16.1、实时海量数据是坚强智能电网的重要资产..............................................16.2、对实时数据的接入、储备与处理、监测与智能分析..............................16.3、电网实时数据调研现状..............................................................................16.4、大数据服务IT创新、提高生产效率

  ........................................................217、大数据技术实现....................................................................................................217.1、物理架构图..................................................................................................217.2、数据处理向大数据处理的过渡..................................................................227.3、大数据核心技术—Hadoop.........................................................................228、Hadoop介绍与案例分析

  .....................................................................................228.1、Hadoop介绍

  ................................................................................................238.2、Hadoop核心技术

  ........................................................................................238.2.1、HDFS..................................................................................................................238.2.2、MapReduce.........................................................................................................258.3、Hadoop优点和缺点

  ....................................................................................328.4、NoSQL数据库介绍....................................................................................338.4.1、MongoDB............................................................................................................348.4.2、CouchDB.............................................................................................................358.4.3、HBase..................................................................................................................368.4.4、Redis....................................................................................................................378.4.5、BaseX..................................................................................................................379、Hadoop数据储备—HBase..................................................................................39.1、HBase简介

  ..................................................................................................39.2、逻辑视图......................................................................................................39.3、物理储备......................................................................................................39.4、系统架构......................................................................................................439.5、关键算法\流程............................................................................................469.6、访问接口......................................................................................................510、Hadoop查询与分析工具

  ...................................................................................510.1、Hive............................................................................................................510.2、Mahout.......................................................................................................51、什么是大数据

  大数据几乎已成为所有商业领域共有的最新趋势,然而大数据怎么说是什么?事实上,大数据是个专门简单的术语——就像它所说的一样,是专门大的数据集。那么怎么说有大多?真实的答案确实是“如你所想的那么大”!

  那么什么缘故会产生如此之大的数据集?因为当今的数据差不多无所不在同时存在着庞大的回报:收集通信数据的RFID传感器,收集天气信息的传感器,移动设备给社交网站发送的GPRS数据包,图片视频,在线购物产生的交易记录,无奇不有!大数据是一个庞大的数据集,包含了任何数据源产生的信息,所往常提是这些信息是我们感爱好的。

  然而大数据的含义绝不只与体积相关,因为大数据还能够用于查找新的真知、形成新的数据和内容;我们能够使用从大数据中提取的真知、数据和内容去使商业更加灵活,以及回答那些之前被认为远超当前范畴的问题。这也是大数据被从以下4个方面定义的缘故:Volume(体积)、Variety(多样)、Velocity(效率)以及Veracity(Value,价值),也确实是大数据的4V。下面将简述每个特性以及所面临的挑战:

  1.1、Volume(体积)

  Volume说的是一个业务必须捕捉、储备及访问的数据量,仅仅在过去两年内就生产了世界上所有数据的90%。现今的机构已完全被数据的体积所埋住,轻易的就会产生TB甚至是PB级不同类型的数据,同时其中有些数据需要被组织、防护(窃取)以及分析。

  1.2、Variety(多样)

  世界上产生的数据有80%差不多上半结构化的,传感器、智能设备和社交媒体差不多上通过Web页面、网络日志文件、社交媒体论坛、音频、视频、点击流、电子邮件、文档、传感系统等生成这些数据。传统的分析方案往往只适合结构化数据,举个例子:储备在关系型数据库中的数据就有完整的结构模型。数据类型的多样化同样意味着为支持当下的决策制定及真知处理,我们需要在数据储存和分析上面进行全然的改变。Variety代表了在传统关系数据库中无法轻易捕捉和治理的数据类型,使用大数据技术却能够轻松的储存和分析。

  1.3、Velocity(效率)

  Velocity则需要对数据进行近实时的分析,亦称“sometimes2minutesistoolate!”。猎取竞争优势意味着你需要在几分钟,甚至是几秒内识别一个新的趋势或机遇,同样还需要尽可能的快于你竞争对手。另外一个例子是时刻敏锐性数据的处理,比如说捕捉罪犯,在那个地点数据必须被收集后就完成被分析,如此才能猎取最大价值。对时刻敏锐的数据保质期往往都专门短,这就需求组织或机构使用近实时的方式对其分析。

  1.4、Veracity(价值)

  通过分析数据我们得出如何的抓住机遇及收成价值,数据的重要性就在于对决策的支持;当你着眼于一个可能会对你企业产生重要阻碍的决策,你期望获得尽可能多的信息与用例相关。单单数据的体积并不能决定其是否对决策产生关心,数据的真实性和质量才是获得真知和思路最重要的因素,因此这才是制定成功决策最坚实的基础。

  2、大数据关键技术

  大数据技术,确实是从各种类型的数据中快速获得有价值信息的技术。大数据领域差不多涌现出了大量新的技术,它们成为大数据采集、储备、处理和出现的有力武器。

  大数据处理关键技术一样包括:大数据采集、大数据预处理、大数据储备及治理、大数据分析及挖掘、大数据展现和应用(大数据检索、大数据可视化、大数据应用、大数据安全等)。

  2.1、大数据采集技术

  数据是指通过RFID射频数据、传感器数据、社交网络交互数据及移动互联网数据等方式获得的各种类型的结构化、半结构化(或称之为弱结构化)及非结构化的海量数据,是大数据知识服务模型的全然。重点要突破分布式高速高可靠数据爬取或采集、高速数据全映像等大数据收集技术;突破高速数据解析、转换与装载等大数据整合技术;设计质量评估模型,开发数据质量技术。

  大数据采集一样分为大数据智能感知层:要紧包括数据传感体系、网络通信体系、传感适配体系、智能识别体系及软硬件资源接入系统,实现对结构化、半结构化、非结构化的海量数据的智能化识别、定位、跟踪、接入、传输、信号转换、监控、初步处理和治理等。必须着重攻克针对大数据源的智能识别、感知、适配、传输、接入等技术。基础支撑层:提供大数据服务平台所需的虚拟服务器,结构化、半结构化及非结构化数据的数据库及物联网络资源等基础支撑环境。重点攻克分布式虚拟储备技术,大数据猎取、储备、组织、分析和决策操作的可视化接口技术,大数据的网络传输与压缩技术,大数据隐私爱护技术等。

  2.2、大数据预处理技术

  要紧完成对已接收数据的辨析、抽取、清洗等操作。1)抽取:因猎取的数据可能具有多种结构和类型,数据抽取过程能够关心我们将这些复杂的数据转化为单一的或者便于处理

  的构型,以达到快速分析处理的目的。2)清洗:关于大数据,并不全是有价值的,有些数据并不是我们所关怀的内容,而另一些数据则是完全错误的干扰项,因此要对数据通过过滤“去噪”从而提取出有效数据。

  2.3、大数据储备及治理技术

  大数据储备与治理要用储备器把采集到的数据储备起来,建立相应的数据库,并进行治理和调用。重点解决复杂结构化、半结构化和非结构化大数据治理与处理技术。要紧解决大数据的可储备、可表示、可处理、可靠性及有效传输等几个关键问题。开发可靠的分布式文件系统(DFS)、能效优化的储备、运算融入储备、大数据的去冗余及高效低成本的大数据储备技术;突破分布式非关系型大数据治理与处理技术,异构数据的数据融合技术,数据组织技术,研究大数据建模技术;突破大数据索引技术;突破大数据移动、备份、复制等技术;开发大数据可视化技术。

  开发新型数据库技术,数据库分为关系型数据库、非关系型数据库以及数据库缓存系统。其中,非关系型数据库要紧指的是NoSQL数据库,分为:键值数据库、列存数据库、图存数据库以及文档数据库等类型。关系型数据库包含了传统关系数据库系统以及NewSQL数据库。

  开发大数据安全技术。改进数据销毁、透亮加解密、分布式访问操纵、数据审计等技术;突破隐私爱护和推理操纵、数据真伪识别和取证、数据持有完整性验证等技术。

  2.4、大数据分析及挖掘技术

  大数据分析技术。改进已有数据挖掘和机器学习技术;开发数据网络挖掘、特异群组挖掘、图挖掘等新型数据挖掘技术;突破基于对象的数据连接、相似性连接等大数据融合技术;突破用户爱好分析、网络行为分析、情感语义分析等面向领域的大数据挖掘技术。

  数据挖掘确实是从大量的、不完全的、有噪声的、模糊的、随机的实际应用数据中,提取隐含在其中的、人们事先不明白的、但又是潜在有用的信息和知识的过程。数据挖掘涉及的技术方法专门多,有多种分类法。依照挖掘任务可分为分类或推测模型发觉、数据总结、聚类、关联规则发觉、序列模式发觉、依靠关系或依靠模型发觉、专门和趋势发觉等等;依照挖掘对象可分为关系数据库、面向对象数据库、空间数据库、时态数据库、文本数据源、多媒体数据库、异质数据库、遗产数据库以及环球网Web;依照挖掘方法分,可粗分为:机

  器学习方法、统计方法、神经网络方法和数据库方法。机器学习中,可细分为:归纳学习方法(决策树、规则归纳等)、基于范例学习、遗传算法等。统计方法中,可细分为:回来分析(多元回来、自回来等)、判别分析(贝叶斯判别、费歇尔判别、非参数判别等)、聚类分析(系统聚类、动态聚类等)、探干脆分析(主元分析法、相关分析法等)等。神经网络方法中,可细分为:前向神经网络(BP算法等)、自组织神经网络(自组织特点映射、竞争学习等)等。数据库方法要紧是多维数据分析或OLAP方法,另外还有面向属性的归纳方法。

  从挖掘任务和挖掘方法的角度,着重突破:1.可视化分析。数据可视化不管关于一般用户或是数据分析专家,差不多上最差不多的功能。数据图像化能够让数据自己说话,让用户直观的感受到结果。2.数据挖掘算法。图像化是将机器语言翻译给人看,而数据挖掘确实是机器的母语。分割、集群、孤立点分析还有各种各样五花八门的算法让我们精炼数据,挖掘价值。这些算法一定要能够应对大数据的量,同时还具有专门高的处理速度。3.推测性分析。推测性分析能够让分析师依照图像化分析和数据挖掘的结果做出一些前瞻性判定。4.语义引擎。语义引擎需要设计到有足够的人工智能以足以从数据中主动地提取信息。语言处理技术包括机器翻译、情感分析、舆情分析、智能输入、问答系统等。5.数据质量和数据治理。数据质量与治理是治理的最佳实践,透过标准化流程和机器对数据进行处理能够确保获得一个预设质量的分析结果。

  2.5、大数据展现与应用技术

  大数据技术能够将隐藏于海量数据中的信息和知识挖掘出来,为人类的社会经济活动提供依据,从而提高各个领域的运行效率,大大提高整个社会经济的集约化程度。在我国,大数据将重点应用于以下三大领域:商业智能、政府决策、公共服务。例如:商业智能技术,政府决策技术,电信数据信息处理与挖掘技术,电网数据信息处理与挖掘技术,气象信息分析技术,环境监测技术,警务云应用系统(道路监控、视频监控、网络监控、智能交通、反电信诈骗、指挥调度等公安信息系统),大规模基因序列分析比对技术,Web信息挖掘技术,多媒体数据并行化处理技术,影视制作渲染技术,其他各种行业的云运算和海量数据处理应用技术等。

  3、数据处理与分析

  3.1、传统方式

  传统上,为了特定分析目的进行的数据处理差不多上基于相当静态的蓝图。通过常规的业务流程,企业通过CRM、ERP和财务系统等应用程序,创建基于稳固数据模型的结构化数据。数据集成工具用于从企业应用程序和事务型数据库中提取、转换和加载数据到一个临时区域,在那个临时区域进行数据质量检查和数据标准化,数据最终被模式化到整齐的行和表。这种模型化和清洗过的数据被加载到企业级数据仓库。那个过程会周期性发生,如每天或每周,有时会更频繁。

  (ETL,是英文

  Extract-Transform-Load的缩写,用来描述将数据从来源端通过抽取(extract)、转换(transform)、加载(load)至目的端的过程。ETL是构建数据仓库的重要一环,用户从数据源抽取出所需的数据,通过数据清洗,最终按照预先定义好的数据仓库模型,将数据加载到数据仓库中去。)

  在传统数据仓库中,数据仓库治理员创建打算,定期运算仓库中的标准化数据,并将产生的报告分配到各业务部门。他们还为治理人员创建外表板和其他功能有限的可视化工具。

  同时,业务分析师利用数据分析工具在数据仓库进行高级分析,或者通常情形下,由于数据量的限制,将样本数据导入到本地数据库中。非专业用户通过前端的商业智能工具对数据仓库进行基础的数据可视化和有限的分析。传统数据仓库的数据量专门少超过几TB,因为大容量的数据会占用数据仓库资源同时降低性能。

  从时刻或成本效益上看,传统的数据仓库等数据治理工具都无法实现大数据的处理和分析工作。也确实是说,必须将数据组织成关系表(整齐的行和列数据),传统的企业级数据仓库才能够处理。由于需要的时刻和人力成本,对海量的非结构化数据应用这种结构是不切实际的。此外,扩展传统的企业级数据仓库使其适应潜在的PB级数据需要在新的专用硬件上投资巨额资金。而由于数据加载这一个瓶颈,传统数据仓库性能也会受到阻碍。

  (1ZB=1024EB,1EB=1024PB,1PB=1024TB,1TB=1024GB)

  3.2、Hadoop大数据新方法

  在Hadoop显现之前,高性能运算和网格运算一直是处理大数据问题要紧的使用方法和工具,它们要紧采纳消息传递接口(MessagePassingInterface,MPI)提供的API来处理大数据。高性能运算的思想是将运算作业分散到集群机器上,集群运算节点访问储备区域网络SAN构成的共享文件系统猎取数据,这种设计比较适合运算密集型作业。当需要访问像PB级别的数据的时候,由于储备设备网络带宽的限制,专门多集群运算节点只能闲暇等待数据。而Hadoop却不存在这种问题,由于Hadoop使用专门为分布式运算设计的文件系统HDFS,运算的时候只需要将运算代码推送到储备节点上,即可在储备节点上完成数据本地化运算,Hadoop中的集群储备节点也是运算节点。在分布式编程方面,MPI是属于比较底层的开发库,它给予了程序员极大的操纵能力,然而却要程序员自己操纵程序的执行流程,容错功能,甚至底层的套接字通信、数据分析算法等底层细节都需要自己编程实现。这种要求无疑对开

  发分布式程序的程序员提出了较高的要求。相反,Hadoop的MapReduce却是一个高度抽象的并行编程模型,它将分布式并行编程抽象为两个原语操作,即map操作和reduce操作,开发人员只需要简单地实现相应的接口即可,完全不用考虑底层数据流、容错、程序的并行执行等细节。这种设计无疑大大降低了开发分布式并行程序的难度。

  Hadoop得以在大数据处理应用中广泛应用得益于其自身在数据提取、变形和加载(ETL)方面上的天然优势。Hadoop的分布式架构,将大数据处理引擎尽可能的靠近储备,对例如像ETL(Extract-Transform-Load)如此的批处理操作相对合适,因为类似如此操作的批处理结果能够直截了当走向储备。Hadoop的MapReduce功能实现了将单个任务打碎,并将碎片任务(Map)发送到多个节点上,之后再以单个数据集的形式加载(Reduce)到数据仓库里。

  3.3、大规模并行分析数据库

  不同于传统的数据仓库,大规模并行分析数据库能够以必需的最小的数据建模,快速猎取大量的结构化数据,能够向外扩展以容纳TB甚至PB级数据。

  对最终用户而言最重要的是,大规模并行分析数据库支持近乎实时的复杂SQL查询结果,也叫交互式查询功能,而这正是Hadoop显著缺失的能力。大规模并行分析数据库在某些情形下支持近实时的大数据应用。大规模并行分析数据库的差不多特性包括:

  大规模并行处理的能力:

  就像其名字说明的一样,大规模并行分析数据库采纳大规模并行处理同时支持多台机器上的数据采集、处理和查询。相对传统的数据仓库具有更快的性能,传统数据仓库运行在单一机器上,会受到数据采集那个单一瓶颈点的限制。

  无共享架构:

  无共享架构可确保分析数据库环境中没有单点故障。在这种架构下,每个节点独立于其他节点,因此假如一台机器显现故障,其他机器能够连续运行。对大规模并行处理环境而言,这点专门重要,数百台运算机并行处理数据,偶然显现一台或多台机器失败是不可幸免的。

  列储备结构:

  大多数大规模并行分析数据库采纳列储备结构,而大多数关系型数据库以行结构储备和处理数据。在列储备环境中,由包含必要数据的列决定查询语句的“答案”,而不是由整行的数据决定,从而导致查询结果瞬时能够得出。这也意味着数据不需要像传统的关系数据库那样构造成整齐的表格。

  强大的数据压缩功能:

  它们承诺分析数据库收集和储备更大量的数据,而且与传统数据库相比占用更少的硬件资源。例如,具有10比1的压缩功能的数据库,能够将10TB字

  节的数据压缩到1TB。数据编码(包括数据压缩以及相关的技术)是有效的扩展到海量数据的关键。

  商用硬件:

  像Hadoop集群一样,大多数(确信不是全部)大规模并行分析数据库运行在戴尔、IBM等厂商现成的商用硬件上,这使他们能够以具有成本效益的方式向外扩展。

  在内存中进行数据处理:

  有些(确信不是全部)大规模并行分析数据库使用动态RAM或闪存进行实时数据处理。有些(如SAPHANA)完全在内存中运行数据,而其他则采纳混合的方式,即用较廉价但低性能的磁盘内存处理“冷”数据,用动态RAM或闪存处理“热”数据。

  然而,大规模并行分析数据库确实有一些盲点。最值得注意的是,他们并非被设计用来储备、处理和分析大量的半结构化和非结构化数据。

  3.4、大数据方法的互补

  Hadoop,NoSQL和大规模并行分析数据库不是相互排斥的。相反的这三种方法是互补的,彼此能够而且应该共存于许多企业。Hadoop擅长处理和分析大量分布式的非结构化数据,以分批的方式进行历史分析。NoSQL数据库擅长为基于Web的大数据应用程序提供近实时地多结构化数据储备和处理。而大规模并行分析数据库最擅长对大容量的主流结构化数据提供接近实时的分析。

  例如,Hadoop完成的历史分析能够移植到分析数据库供进一步分析,或者与传统的企业数据仓库的结构化数据进行集成。从大数据分析得到的见解能够而且应该通过大数据应用实现产品化。企业的目标应该是实现一个灵活的大数据架构,在该架构中,三种技术能够尽可能无缝地共享数据和见解。

  专门多预建的连接器能够关心Hadoop开发者和治理员实现这种数据集成,同时也有专门多厂商提供大数据应用。这些大数据应用将Hadoop、分析数据库和预配置的硬件进行捆绑,能够达到以最小的调整实现快速部署的目的。另外一种情形,Hadapt提供了一个单一平台,那个平台在相同的集群上同时提供SQL和Hadoop/MapReduce的处理功能。Cloudera也在Impala和Hortonworks项目上通过开源倡议推行这一策略。

  然而,为了充分利用大数据,企业必须采取进一步措施。也确实是说,他们必须使用高级分析技术处理数据,并以此得出有意义的见解。数据科学家通过屈指可数的语言或方法执行这项复杂的工作。分析的结果能够通过工具可视化,也能够通过大数据应用程序进行操作,这些大数据应用程序包括自己开发的应用程序和现成的应用程序。

  3.5、大数据使用案例

  让Hadoop和其他大数据技术如此引人注目的部分缘故是,他们让企业找到问题的答案,而在此之前他们甚至不明白问题是什么。这可能会产生引出新产品的方法,或者关心确定改善运营效率的方法。只是,也有一些差不多明确的大数据用例,不管是互联网巨头如谷歌,Facebook和阿里巴巴依旧更多的传统企业。它们包括:

  举荐引擎:网络资源和在线零售商使用Hadoop依照用户的个人资料和行为数据匹配和举荐用户、产品和服务。LinkedIn使用此方法增强其“你可能认识的人”这一功能,而亚马逊利用该方法为网上消费者举荐相关产品。

  情感分析:Hadoop与先进的文本分析工具结合,分析社会化媒体和社交网络公布的非结构化的文本,包括Tweets和Facebook,以确定用户对特定公司,品牌或产品的情绪。分析既能够用心于宏观层面的情绪,也能够细分到个人用户的情绪。

  风险建模:

  财务公司、银行等公司使用Hadoop和下一代数据仓库分析大量交易数据,以确定金融资产的风险,模拟市场行为为潜在的“假设”方案做预备,并依照风险为潜在客户打分。

  欺诈检测:

  金融公司、零售商等使用大数据技术将客户行为与历史交易数据结合来检测欺诈行为。例如,信用卡公司使用大数据技术识别可能的被盗卡的交易行为。

  营销活动分析:各行业的营销部门长期使用技术手段监测和确定营销活动的有效性。大数据让营销团队拥有更大量的越来越精细的数据,如点击流数据和呼叫详情记录数据,以提高分析的准确性。

  客户流失分析:

  企业使用Hadoop和大数据技术分析客户行为数据并确定分析模型,该模型指出哪些客户最有可能流向存在竞争关系的供应商或服务商。企业就能采取最有效的措施挽留欲流失客户。

  社交图谱分析:Hadoop和下一代数据仓库相结合,通过挖掘社交网络数据,能够确定社交网络中哪些客户对其他客户产生最大的阻碍力。这有助于企业确定其“最重要”的客户,不总是那些购买最多产品或花最多钱的,而是那些最能够阻碍他人购买行为的客户。

  用户体验分析:

  面向消费者的企业使用Hadoop和其他大数据技术将之前单一

  客户互动渠道(如呼叫中心,网上谈天,微博等)数据整合在一起,,以获得对客户体验的完整

  视图。这使企业能够了解客户交互渠道之间的相互阻碍,从而优化整个客户生命周期的用户体验。

  网络监控:Hadoop和其他大数据技术被用来猎取,分析和显示来自服务器,储备设备和其他IT硬件的数据,使治理员能够监视网络活动,诊断瓶颈等问题。这种类型的分析,也可应用到交通网络,以提高燃料效率,因此也能够应用到其他网络。

  研究与进展:

  有些企业(如制药商)使用Hadoop技术进行大量文本及历史数据的研究,以协助新产品的开发。

  因此,上述这些都只是大数据用例的举例。事实上,在所有企业中大数据最引人注目的用例可能尚未被发觉。这确实是大数据的期望。

  4、展望电力大数据时代

  4.1、电力大数据价值分析

  电力系统作为经济进展和人类生活依靠的能量供给系统,也具有大数据的典型特点。电力系统是最复杂的人造系统之一,其具有地理位置分布广泛、发电用电实时平稳、传输能量数量庞大、电能传输光速可达、通讯调度高度可靠、实时运行从不停止、重大故障瞬时扩大等特点,这些特点决定了电力系统运行时产生的数据数量庞大、增长快速、类型丰富,完全符合大数据的所有特点,是典型的大数据。在智能电网深入推进的形势下,电力系统的数字化、信息化、智能化不断进展,带来了更多的数据源,例如智能电表从数以亿计的家庭和企业终端带来的数据,电力设备状态监测系统从数以万计的发电机、变压器、开关设备、架空线路、高压电缆等设备中猎取的高速增长的监测数据,光伏和风电功率推测所需的大量的历史运行数据、气象观测数据等。因此在电力系统数据爆炸式增长的新形势下,传统的数据处理技术遇到瓶颈,不能满足电力行业从海量数据中快速猎取知识与信息的分析需求,电力大数据技术的应用是电力行业信息化、智能化进展的必定要求。

  中国电机工程学会信息化专委会在2020年3月公布了《中国电力大数据进展白皮书》,将2020年定为“中国大数据元年”,掀起了电力大数据的研究热潮。依照白皮书描述,电力大数据的特点可概括为3V和3E。3V为体量大(Volume)、速度快(Velocity)和类型多(Variety);

  3E为数据即能量(Energy)、数据即交互(Exchange)和数据即共情(Empathy)。其3V的描述和其他行业的描述比较接近,3E的描述具有典型的电力行业特点,表达了大

  数据在电力系统应用中的庞大价值。数据即能量简而言之,确实是指通过大数据分析达到节能的目的,电力大数据应用的过程,确实是电力数据能量开释的过程;数据即交互是指电力大数据与国民经济其他领域数据进行交互融合,才能发挥其更大价值;数据即共情是指电力大数据紧密联系千家万户、厂矿企业,只有情系用电户,满足客户需求,电力企业方能以数据取胜。电力大数据贯穿发、输、变、配、用等电力生产及治理的各个环节,是能源变革中电力工业技术革新的必定过程,不仅是技术上的进步,更是涉及电力系统治理体制、进展理念和技术路线等方面的重大变革,是下一代电力系统在大数据时代下价值形状的跃升。对建设坚强智能电网而言,亟需开展大数据相关技术研究,为电力大数据时代的到来奠定理论基础和技术积存。

  4.2、电力大数据应用前景

  4.3、电力大数据进展与挑战

  5、迈向电力大数据时代

  5.1、电力大数据关健技术

  5.2、电力大数据进展策略

  6、电力大数据实践

  6.1、实时海量数据是坚强智能电网的重要资产

  6.2、对实时数据的接入、储备与处理、监测与智能分析

  6.3、电网实时数据调研现状

  (1)某省实时数据分布1(2)某省实时数据分布2(3)某市实时数据分布

  6.4、大数据服务IT创新、提高生产效率

  7、大数据技术实现

  7.1、物理架构图

  7.2、数据处理向大数据处理的过渡

  7.3、大数据核心技术—Hadoop

  8、Hadoop介绍与案例分析

  8.1、Hadoop介绍

  Hadoop是一个处理、储备和分析海量的分布式、非结构化数据的开源框架。最初由雅虎的DougCutting创建,Hadoop的灵感来自于

  MapReduce,MapReduce是谷歌在2000年代初期开发的用于网页索引的用户定义函数。它被设计用来处理分布在多个并行节点的PB级和EB级数据。

  Hadoop集群运行在廉价的商用硬件上,如此硬件扩展就不存在资金压力。Hadoop现在是Apache软件联盟(TheApacheSoftwareFoundation)的一个项目,数百名奉献者不断改进其核心技术。差不多概念:与将海量数据限定在一台机器运行的方式不同,Hadoop将大数据分成多个部分,如此每个部分都能够被同时处理和分析。

  8.2、Hadoop核心技术

  Hadoop的核心确实是HDFS和MapReduce,而两者只是理论基础,不是具体可使用的高级应用,Hadoop旗下有专门多经典子项目,比如HBase、Hive等,这些差不多上基于HDFS和MapReduce进展出来的。要想了解Hadoop,就必须明白HDFS和MapReduce是什么。

  8.2.1、HDFSHDFS(HadoopDistributedFileSystem,Hadoop分布式文件系统),它是一个高度容错性的系统,适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问,适合那些有着超大数据集(largedataset)的应用程序。

  HDFS的设计特点:

  (1)、大数据文件,专门适合上T级别的大文件或者一堆大数据文件的储备,假如文件只有几个G甚至更小就没啥意思了。

  (2)、文件分块储备,HDFS会将一个完整的大文件平均分块储备到不同运算器上,它的意义在于读取文件时能够同时从多个主机取不同区块的文件,多主机读取比单主机读取效率要高得多得都。

  (3)、流式数据访问,一次写入多次读写,这种模式跟传统文件不同,它不支持动态改变文件内容,而是要求让文件一次写入就不做变化,要变化也只能在文件末添加内容。

  (4)、廉价硬件,HDFS能够应用在一般PC机上,这种机制能够让给一些公司用几十

  台廉价的运算机就能够撑起一个大数据集群。

  (5)、硬件故障,HDFS认为所有运算机都可能会出问题,为了防止某个主机失效读取不到该主机的块文件,它将同一个文件块副本分配到其它某几个主机上,假如其中一台主机失效,能够迅速找另一块副本取文件。

  HDFS关键元素:

  Hadoop使用主/从(Master/Slave)架构,要紧角色有NameNode,DataNode,SecondaryNameNode,JobTracker,TaskTracker组成。

  NameNode节点作为Master服务器,有三部分功能。第一:处理来自客户端的文件访问。第二:治理文件系统的命名空间操作,如"打开"、"关闭"、"重命名"等。第三:负责数据块到数据节点之间的映射。从那个意义上说,它扮演中心服务器的角色。

  DataNode节点作为Slave服务器,同样有三部分功能。第一:治理挂载在节点上的储备设备。第二:响应客户端的读写要求。第三:从内部看,每个文件被分成一个或多个数据块,被存放到一组DataNode,在Namenode的统一调度下进行数据块的创建、删除和复制。

  (1)NameNodeNameNode是HDFS的守护程序,是

  Hadoop中的主服务器,它治理文件系统名称空间和对集群中储备的文件的访问

  (2)DataNode集群中每个从服务器都运行一个DataNode后台程序,后台程序负责把HDFS数据块读

  写到本地文件系统。需要读写数据时,由NameNode告诉客户端去哪个DataNode进行具体的读写操作。

  (3)Block将一个文件进行分块,通常是64M(4)SecondaryNameNodeSecondaryNameNode是一个用来监控HDFS状态的辅助后台程序,假如NameNode发生问题,能够使用SecondaryNameNode作为备用的NameNode。

  (5)JobTrackerJobTracker后台程序用来连接应用程序与Hadoop,用户应用提交到集群后,由JobTracker决定哪个文件处理哪个task执行,一旦某个task失败,JobTracker会自动开启那个task。

  (6)TaskTrackerTaskTracker负责储备数据的DataNode相结合,位于从节点,负责各自的task。

  在Hadoop的系统中,会有一台Master,要紧负责NameNode的工作以及JobTracker的工作。JobTracker的要紧职责确实是启动、跟踪和调度各个Slave的任务执行。还会有多台Slave,每一台Slave通常具有DataNode的功能并负责TaskTracker的工作。TaskTracker依照顾用要求来结合本地数据执行Map任务以及Reduce任务。

  8.2.2、MapReduceMapReduce介绍:

  MapReduce是一种编程模型,用于大规模数据集的并行运算。MapReduce的设计目标

  是方便编程人员在不熟悉分布式并行编程的情形下,将自己的程序运行在分布式系统上。

  MapReduce的命名规则由两个术语组成,分别是Map(映射)与Reduce(化简),是它们的要紧思想,差不多上从函数式编程语言里借来的。

  当前的软件实现是指定一个Map(映射)函数,用来把一组键值对映射成一组新的键值对,指定并发的Reduce(化简)函数,用来保证所有映射的键值对中的每一个共享相同的键组。

  MapReduce处理过程:

  (1)

  Input输入

  从文件中读取原始数据

  原始数据

  (2)Map映射

  将原始数据映射成用于Reduce的数据

  List<>(3)Reduce合并

  将相同Key值的中间数据合并成最终数据

  >(4)Output输出

  将最终处理结果输出到文件

  结果文件

  上述确实是MapReduce大致处理过程,在Map前还可能会对输入的数据有Split(分割)的过程,保证任务并行效率,在Map之后还会有Shuffle(混合)的过程,关于提高Reduce的效率以及减小数据传输的压力有专门大的关心。后面会具体提及这些部分的细节。

  MapReduce简单案例1:

  通俗说MapReduce是一套从海量·源数据提取分析元素最后返回结果集的编程模型,将文件分布式储备到硬盘是第一步,而从海量数据中提取分析我们需要的内容确实是MapReduce做的事了。

  下面以一个运算海量数据最大值为例:一个银行有上亿储户,银行期望找到储备金额最高的金额是多少,按照传统的运算方式,我们会如此:

  Java代码

  :

  Longmoneys[]...Longmax=0L;for(inti=0;imax){max=moneys[i];}}假如运算的数组长度少的话,如此实现是可不能有问题的,依旧面对海量数据的时候就会有问题。

  MapReduce会如此做:第一数字是分布储备在不同块中的,以某几个块为一个Map,运算出Map中最大的值,然后将每个Map中的最大值做Reduce操作,Reduce再取最大值给用户。

  MapReduce的差不多原理确实是:将大的数据分析分成小块逐个分析,最后再将提取出来的数据汇总分析,最终获得我们想要的内容。因此如何分块分析,如何做Reduce操作专门复杂,Hadoop差不多提供了数据分析的实现,我们只需要编写简单的需求命令即可达成我们想要的数据。

  MapReduce简单案例2:

  (1)从理论部分来进行讲解MapReduce下面是一个关于一个程序员是如何给妻子讲解什么是MapReduce.我问妻子:“你确实想要弄明白什么是MapReduce?”她专门坚决的回答说“是的”。

  因此我问道:

  我:

  你是如何预备洋葱辣椒酱的?(以下并非准确食谱,请勿在家尝试)

  妻子:

  我会取一个洋葱,把它切碎,然后拌入盐和水,最后放进混合研磨机里研磨。如此就能得到洋葱辣椒酱了。

  妻子:

  但这和MapReduce有什么关系?

  我:

  你等一下。让我来编一个完整的情节,如此你确信能够在15分钟内弄明白MapReduce.妻子:

  好吧。

  我:现在,假设你想用薄荷、洋葱、番茄、辣椒、大蒜弄一瓶混合辣椒酱。你会如何做呢?

  妻子:

  我会取薄荷叶一撮,洋葱一个,番茄一个,辣椒一根,大蒜一根,切碎后加入适量的盐和水,再放入混合研磨机里研磨,如此你就能够得到一瓶混合辣椒酱了。

  我:

  没错,让我们把MapReduce的概念应用到食谱上。Map和Reduce事实上是两种操作,我来给你详细讲解下。

  Map(映射):把洋葱、番茄、辣椒和大蒜切碎,是各自作用在这些物体上的一个Map操作。因此你给Map一个洋葱,Map就会把洋葱切碎。

  同样的,你把辣椒,大蒜和番茄一一地拿给Map,你也会得到各种碎块。

  因此,当你在切像洋葱如此的蔬菜时,你执行确实是一个Map操作。

  Map操作适用于每一种蔬菜,它会相应地生产出一种或多种碎块,在我们的例子中生产的是蔬菜块。在Map操作中可能会显现有个洋葱坏掉了的情形,你只要把坏洋葱丢了就行了。因此,假如显现坏洋葱了,Map操作就会过滤掉坏洋葱而可不能生产出任何的坏洋葱块。

  Reduce(化简):在这一时期,你将各种蔬菜碎都放入研磨机里进行研磨,你就能够得到一瓶辣椒酱了。这意味要制成一瓶辣椒酱,你得研磨所有的原料。因此,研磨机通常将map操作的蔬菜碎集合在了一起。

  妻子:

  因此,这确实是MapReduce?我:

  你能够说是,也能够说不是。

  事实上这只是MapReduce的一部分,MapReduce的强大在于分布式运算。

  妻子:

  分布式运算?

  那是什么?请给我说明下吧。

  我:

  没问题。

  我:

  假设你参加了一个辣椒酱竞赛同时你的食谱赢得了最佳辣椒酱奖。得奖之后,辣椒酱食谱大受欢迎,因此你想要开始出售自制品牌的辣椒酱。假设你每天需要生产10000瓶辣椒酱,你会如何办呢?

  妻子:

  我会找一个能为我大量提供原料的供应商。

  我:是的..确实是那样的。那你能否独自完成制作呢?也确实是说,独自将原料都切碎?

  仅仅一部研磨机又是否能满足需要?而且现在,我们还需要供应不同种类的辣椒酱,像洋葱辣椒酱、青椒辣椒酱、番茄辣椒酱等等。

  妻子:

  因此不能了,我会雇佣更多的工人来切蔬菜。我还需要更多的研磨机,如此我就能够更快地生产辣椒酱了。

  我:没错,因此现在你就不得不分配工作了,你将需要几个人一起切蔬菜。每个人都要处理满满一袋的蔬菜,而每一个人都相当于在执行一个简单的Map操作。每一个人都将不断的从袋子里拿出蔬菜来,同时每次只对一种蔬菜进行处理,也确实是将它们切碎,直到袋子空了为止。如此,当所有的工人都切完以后,工作台(每个人工作的地点)上就有了洋葱块、番茄块、和蒜蓉等等。

  妻子:然而我如何会制造出不同种类的番茄酱呢?

  我:现在你会看到MapReduce遗漏的时期—搅拌时期。MapReduce将所有输出的蔬菜碎都搅拌在了一起,这些蔬菜碎差不多上在以key为基础的map操作下产生的。搅拌将自动完成,你能够假设key是一种原料的名字,就像洋葱一样。

  因此全部的洋葱keys都会搅拌在一起,并转移到研磨洋葱的研磨器里。如此,你就能得到洋葱辣椒酱了。同样地,所有的番茄也会被转移到标记着番茄的研磨器里,并制造出番茄辣椒酱。

  (2)从MapReduce产生过程和代码的角度来讲解

  假如想统计过去10年运算机论文显现最多的几个单词,看看大伙儿都在研究些什么,那收集好论文后,该如何办呢?

  方法一:我能够写一个小程序,把所有论文按顺序遍历一遍,统计每一个遇到的单词的显现次数,最后就能够明白哪几个单词最热门了。

  这种方法在数据集比较小时,是专门有效的,而且实现最简单,用来解决那个问题专门合适。

  方法二:写一个多线程程序,并发遍历论文。

  那个问题理论上是能够高度并发的,因为统计一个文件时可不能阻碍统计另一个文件。当我们的机器是多核或者多处理器,方法二确信比方法一高效。然而写一个多线程程序要比方法一困难多了,我们必须自己同步共享数据,比如要防止两个线程重复统计文件。

  方法三:把作业交给多个运算机去完成。

  我们能够使用方法一的程序,部署到N台机器上去,然后把论文集分成N份,一台机器跑一个作业。那个方法跑得足够快,然而部署起来专门苦恼,我们要人工把程序copy到别的机器,要人工把论文集分开,最痛楚的是还要把N个运行结果进行整合(因此我们也能够再写一个程序)。

  方法四:让MapReduce来帮帮我们吧!

  MapReduce本质上确实是方法三,然而如何拆分文件集,如何copy程序,如何整合结果这些差不多上框架定义好的。我们只要定义好那个任务(用户程序),其它都交给MapReduce。map函数和reduce函数是交给用户实现的,这两个函数定义了任务本身。

  map函数:同意一个键值对(key-valuepair),产生一组中间键值对。MapReduce框架会将map函数产生的中间键值对里键相同的值传递给一个reduce函数。

  reduce函数:同意一个键,以及相关的一组值,将这组值进行合并产生一组规模更小的值(通常只有一个或零个值)。

  统计词频的MapReduce函数的核心代码专门简短,要紧确实是实现这两个函数。

  map(Stringkey,Stringvalue)://key:documentname//value:documentcontentsforeachwordwinvalue:

  EmitIntermediate(w,"1");reduce(Stringkey,Iteratorvalues)://key:aword

  //values:alistofcountsintresult=0;

  foreachvinvalues:result+=ParseInt(v);Emit(AsString(result));在统计词频的例子里,map函数同意的键是文件名,值是文件的内容,map逐个遍历单词,每遇到一个单词w,就产生一个中间键值对,这表示单词w咱又找到了一个;MapReduce将键相同(差不多上单词w)的键值对传给reduce函数,如此reduce函数同意的键确实是单词w,值是一串"1"(最差不多的实现是如此,但能够优化),个数等于键为w的键值的个数,然后将这些“1”累加就得到单词w的显现次数。最后这些单词的显现次数会被写到用户定义的位置,储备在底层的分布式储备系统(GFS或HDFS)。

  MapReduce简单案例3:

  1.第一,我们能确定我们有一份输入,而且他的数据量会专门大

  2.通过split之后,他变成了若干的分片,每个分片交给一个Map处理

  3.map处理完后,tasktracker会把数据进行复制和排序,然后通过输出的key和value进

  行

  partition的划分,并把partition相同的map输出,合并为相同的reduce的输入.4.ruducer通过处理,把数据输出,每个相同的key,一定在一个reduce中处理完,每一个reduce至少对应一份输出

  5.来看一个例子,如下图:(来自

  《hadoop权威指南》

  一书)

  说明几点:5.1输入的数据可能确实是一堆文本

  5.2mapper会解析每行数据,然后提取有效的数据,作为输出.那个地点的例子是

  从日志文件中提取每一年每天的气温,最后会运算每年的最高气温

  5.3map的输出确实是一条一条的key-value5.4通过shuffle之后,变成reduce的输入,这是相同的key对应的value被组合成了一个迭代器

  5.5reduce的任务是提取每一年的最高气温,然后输出

  8.3、Hadoop优点和缺点

  Hadoop是一个能够让用户轻松架构和使用的分布式运算平台。用户能够轻松地在Hadoop上开发和运行处理海量数据的应用程序。它要紧有以下几个优点:

  (1)高可靠性。Hadoop按位储备和处理数据的能力值得人们信任。

  (2)高扩展性。Hadoop是在可用的运算机集簇间分配数据并完成运算任务的,这些集簇能够方便地扩展到数以千计的节点中。

  (3)高效性。Hadoop能够在节点之间动态地移动数据,并保证各个节点的动态平稳,因此处理速度专门快。

  (4)高容错性。Hadoop能够自动储存数据的多个副本,同时能够自动将失败的任务重

  新分配。

  (5)低成本。与一体机、商用数据仓库以及QlikView、YonghongZ-Suite等数据集市相比,hadoop是开源的,项目的软件成本因此会大大降低。

  在实际使用中Hadoop的要紧好处是,它能够让企业以节约成本并高效的方式处理和分析大量的非结构化和半结构化数据,而这类数据迄今还没有其他处理方式。因为Hadoop集群能够扩展到PB级甚至EB级数据,企业不再必须依靠于样本数据集,而能够处理和分析所有相关数据。数据科学家能够采纳迭代的方法进行分析,不断改进和测试查询语句,从而发觉往常未知的见解。使用Hadoop的成本也专门廉价。开发者能够免费下载Apache的Hadoop分布式平台,同时在不到一天的时刻内开始体验Hadoop。

  Hadoop及其许多组件的不足之处是,他们还不成熟,仍处于进展时期。就像所有新的、原始的技术一样,实施和治理Hadoop集群,对大量非结构化数据进行高级分析,都需要大量的专业知识、技能和培训。不幸的是,目前Hadoop开发者和数据科学家的缺乏,使得众多企业坚持复杂的Hadoop集群并利用其优势变得专门不现实。此外,由于Hadoop的众多组件差不多上通过技术社区得到改善,同时新的组件不断被创建,因此作为不成熟的开源技术,也存在失败的风险。最后,Hadoop是一个面向批处理的框架,这意味着它不支持实时的数据处理和分析。

  好消息是,一些聪慧的IT人士不断对ApacheHadoop项目做出奉献,新一代的Hadoop开发者和数据科学家们正在走向成熟。因此,该技术的进展日新月异,逐步变得更加强大而且更易于实施和治理。供应商(包括Hadoop的初创企业Cloudera和Hortonworks)以及成熟的IT中坚企业(如IBM和微软)正在努力开发企业可用的商业Hadoop分布式平台、工具和服务,让部署和治理这项技术成为传统企业可用的实际现实。其他初创企业正在努力完善NoSQL(不仅仅是SQL)数据系统,结合Hadoop提供近实时的分析解决方案。

  8.4、NoSQL数据库介绍

  一种称为NoSQL的新形式的数据库(NotOnlySQL)差不多显现,像Hadoop一样,能够处理大量的多结构化数据。然而,假如说Hadoop擅长支持大规模、批量式的历史分析,在大多数情形下(尽管也有一些例外),NoSQL数据库的目的是为最终用户和自动化的大数据应用程序提供大量储备在多结构化数据中的离散数据。这种能力是关系型数据库欠缺的,它全然无法在大数据规模坚持差不多的性能水平。

  在某些情形下,NoSQL和Hadoop协同工作。例如,HBase是流行的NoSQL数据库,它仿照谷歌的BigTable,通常部署在HDFS(Hadoop分布式文件系统)之上,为Hadoop提供低延迟的快速查找功能。

  8.4.1、MongoDBMongoDB是一个基于分布式文件储备的数据库。由C++语言编写。要紧解决的是海量数据的访问效率问题,为WEB应用提供可扩展的高性能数据储备解决方案。当数据量达到50GB以上的时候,MongoDB的数据库访问速度是MySQL的10倍以上。MongoDB的并发读写效率不是专门杰出,依照官方提供的性能测试说明,大约每秒能够处理0.5万~1.5万次读写要求。MongoDB还自带了一个杰出的分布式文件系统GridFS,能够支持海量的数据储备。

  MongoDB也有一个Ruby的项目MongoMapper,是仿照Merb的DataMapper编写的MongoDB接口,使用起来专门简单,几乎和DataMapper一模一样,功能专门强大。

  MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。他支持的数据结构专门松散,是类似json的bjson格式,因此能够储备比较复杂的数据类型。Mongo最大的特点是他支持的查询语言专门强大,其语法有点类似于面向对象的查询语言,几乎能够实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。

  所谓“面向集合”(Collenction-Orented),意思是数据被分组储备在数据集中,被称为一个集合(Collenction)。每个集合在数据库中都有一个唯独的标识名,同时能够包含无限数目的文档。集合的概念类似关系型数据库(RDBMS)里的表(table),不同的是它不需要定义任何模式(schema)。模式自由(schema-free),意味着关于储备在MongoDB数据库中的文件,我们不需要明白它的任何结构定义。假如需要的话,你完全能够把不同结构的文件储备在同一个数据库里。储备在集合中的文档,被储备为键-值对的形式。键用于唯独标识一个文档,为字符串类型,而值则能够是各中复杂的文件类型。我们称这种储备形式为BSON(BinarySerializeddOcumentFormat)。

  MongoDB把数据储备在文件中(默认路径为:/data/db),为提高效率使用内存映射文件进行治理。

  它的特点是高性能、易部署、易使用,储备数据专门方便。要紧功能特性有:

  (1)面向集合储备,易储备对象类型的数据。

  (2)模式自由。

  (3)支持动态查询。

  (4)支持完全索引,包含内部对象。

  (5)支持查询。

  (6)支持复制和故障复原。

  (7)使用高效的二进制数据储备,包括大型对象(如视频等)。

  (8)自动处理碎片,以支持云运算层次的扩展性。

  (9)支持RUBY,PYTHON,JAVA,C++,PHP,C#等多种语言。

  (10)文件储备格式为BSON(一种JSON的扩展)。

  (11)可通过网络访问。

  8.4.2、CouchDBApacheCouchDB是一个面向文档的数据库治理系统。它提供以

  JSON作为数据格式的REST接口来对其进行操作,并能够通过视图来操纵文档的组织和出现。

  CouchDB是

  Apache基金会的顶级开源项目。

  CouchDB是用Erlang开发的面向文档的数据库系统,其数据储备方式类似Lucene的Index文件格式。CouchDB最大的意义在于它是一个面向Web应用的新一代储备系统,事实上,CouchDB的口号确实是:下一代的Web应用储备系统。

  要紧功能特性有:

  (1)CouchDB是分布式的数据库,他能够把储备系统分布到n台物理的节点上面,同时专门好的和谐和同步节点之间的数据读写一致性。这因此也得以于Erlang无与伦比的并发特性才能做到。关于基于web的大规模应用文档应用,然的分布式能够让它不必像传统的关系数据库那样分库拆表,在应用代码层进行大量的改动。

  (2)CouchDB是面向文档的数据库,储备半结构化的数据,比较类似lucene的index结构,专门适合储备文档,因此专门适合CMS,本,地址本等应用,在这些应用场合,文档数据库要比关系数据库更加方便,性能更好。

  (3)CouchDB支持RESTAPI,能够让用户使用JavaScript来操作CouchDB数据库,也能够用JavaScript编写查询语句,我们能够想像一下,用AJAX技术结合CouchDB开发

  出来的CMS系统会是多么的简单和方便。事实上CouchDB只是Erlang应用的冰山一角,在最近几年,基于Erlang的应用也得到的蓬勃的进展,专门是在基于web的大规模,分布式应用领域,几乎差不多上Erlang的优势项目。

  8.4.3、HBaseHBase是一个分布式的、面向列的开源数据库,该技术来源于

  FayChang所撰写的Google论文“Bigtable:一个结构化数据的分布式储备系统”。就像Bigtable利用了Google文件系统(FileSystem)所提供的分布式数据储备一样,HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一样的关系数据库,它是一个适合于非结构化数据储备的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

  HBase–HadoopDatabase,是一个高可靠性、高性能、面向列、可伸缩的分布式储备系统,利用HBase技术可在廉价PCServer上搭建起大规模结构化储备集群。

  HBase是GoogleBigtable的开源实现,类似GoogleBigtable利用GFS作为其文件储备系统,HBase利用HadoopHDFS作为其文件储备系统;Google运行MapReduce来处理Bigtable中的海量数据,HBase同样利用HadoopMapReduce来处理HBase中的海量数据;GoogleBigtable利用

  Chubby作为协同服务,HBase利用Zookeeper作为对应。

  HBase访问接口

  (1)NativeJavaAPI,最常规和高效的访问方式,适合HadoopMapReduceJob并行批处理HBase表数据

  (2)HBaseShell,HBase的命令行工具,最简单的接口,适合HBase治理使用

  (3)ThriftGateway,利用Thrift序列化技术,支持C++,PHP,Python等多种语言,适合其他异构系统在线访问HBase表数据

  (4)RESTGateway,支持REST风格的API访问HBase,解除了语言限制

  (5)Pig,能够使用PigLatin流式编程语言来操作HBase中的数据,和Hive类似,本质最终也是编译成MapReduceJob来处理HBase表数据,适合做数据统计

  (6)Hive,当前Hive的Release版本尚没有加入对HBase的支持,但在下一个版本Hive0.7.0中将会支持HBase,能够使用类似SQL语言来访问HBase要紧功能特性有:

  (1)支持数十亿行X上百万列

  (2)采纳分布式架构

  Map/reduce(3)对实时查询进行优化

  (4)高性能

  Thrift网关

  (5)通过在server端扫描及过滤实现对查询操作预判

  (6)支持

  XML,Protobuf,和binary的(7)基于

  Jruby(JIRB)的shell(8)对配置改变和较小的升级都会重新回滚

  (9)可不能显现单点故障

  (10)堪比MySQL的随机访问性能

  8.4.4、Redisredis是一个key-value储备系统。和Memcached类似,它支持储备的value类型相对更多,包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作差不多上原子性的。在此基础上,redis支持各种不同方式的排序。与memcached一样,为了保证效率,数据差不多上缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,同时在此基础上实现了master-slave(主从)同步。

  要紧功能特点:

  (1)安全性

  (2)主从复制

  (3)运行专门快

  (4)支持

  sets、list、hash(5)Redis支持事务

  (6)支持将数据设置成过期数据(类似快速缓冲区设计)

  (7)Pub/Sub承诺用户实现消息机制

  8.4.5、BaseXBaseX是一个XML数据库,用来储备紧缩的XML数据,提供了高效的XPath和

  XQuery的实现,还包括一个前端操作界面。

  特性:

  BaseX一个比较显著地优点是有了GUI,界面中有查询窗口,可采纳XQuery查询相关数据库中的XML文件;也有能够动态展现xml文件层次和节点关系的图。但我感受也就这点好处了,编程时和GUI无关了。

  和Xindice相比,BaseX更能支持大型XML文档的储备,而Xindice对大型xml没有专门好的支持,为治理中小型文档的集合而设计。

  BaseX是一个XML数据库,用来储备紧缩的XML数据,提供了高效的XPath和

  XQuery的实现,还包括一个前端操作界面。

  9、Hadoop数据储备—HBase

  9.1、HBase简介

  HBase是一个分布式的、面向列的开源数据库,该技术来源于FayChang所撰写的Google论文"Bigtable:一个结构化数据的分布式储备系统"。就像Bigtable利用了Google文件系统(FileSystem)所提供的分布式数据储备一样,HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一样的关系数据库,它是一个适合于非结构化数据储备的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

  HBase是Bigtable的开源山寨版本。是建立的HDFS之上,提供高可靠性、高性能、列储备、可伸缩、实时读写的数据库系统。

  它介于NOSQL和RDBMS之间,仅能通过主键(rowkey)和主键的range来检索数据,仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。要紧用来储备非结构化和半结构化的松散数据。

  与Hadoop一样,HBase目标要紧依靠横向扩展,通过不断增加廉价的商用服务器,来增加运算和储备能力。

  HBase中的表一样有如此的特点:

  (1)大:一个表能够有上亿行,上百万列

  (2)面向列:面向列(族)的储备和权限操纵,列(族)独立检索。

  (3)稀疏:关于为空(null)的列,并不占用储备空间,因此,表能够设计的专门稀疏。

  9.2、逻辑视图

  HBase以表的形式储备数据,表有行和列组成。HBase数据模型

  Table&ColumnFamily

  RowKey

  Timestamp

  t3r1t2t1t5r2t4RowKey:行键,Table的主键,Table中的记录按照RowKey排序

  Timestamp:时刻戳,每次数据操作对应的时刻戳,能够看作是数据的versionnumberColumnFamily:列簇,Table在水平方向有一个或者多个ColumnFamily组成,一个ColumnFamily中能够由任意多个Column组成,即ColumnFamily支持动态扩展,无需预先定义Column的数量以及类型,所有Column均以二进制格式储备,用户需要自行进行类型转换。

  ColumnFamily

  URI

  url=

  ://

  taobao

  host=taobao

  url=

  ://

  alibaba

  host=alibaba

  Parser

  title=天天特价

  content=每天…

  9.3、物理储备

  (1)差不多提到过,Table中的所有行都按照rowkey的字典序排列。

  (2)Table在行的方向上分割为多个Hregion。

  (3)region按大小分割的,每个表一开始只有一个region,随着数据不断插入表,region不断增大,当增大到一个阀值的时候,Hregion就会等分会两个新的Hregion。当table中的行不断增多,就会有越来越多的Hregion。

  (4)HRegion是HBase中分布式储备和负载均衡的最小单元。最小单元就表示不同的Hregion能够分布在不同的HRegionserver上。但一个Hregion是可不能拆分到多个server上的。

  (5)HRegion尽管是分布式储备的最小单元,但并不是储备的最小单元。事实上,HRegion由一个或者多个Store组成,每个store储存一个columnsfamily。每个Strore又由一个memStore和0至多个StoreFile组成。如图:

  StoreFile以HFile格式储存在HDFS上。

  HFile的格式为:

  StoreFile以HFile格式储存在HDFS上。HFile分为六个部分:

  (1)DataBlock段–储存表中的数据,这部分能够被压缩

  (2)MetaBlock段(可选的)–储存用户自定义的kv对,能够被压缩。

  (3)FileInfo段–Hfile的元信息,不被压缩,用户也能够在这一部分添加自己的元信息。

  (4)DataBlockIndex段–DataBlock的索引。每条索引的key是被索引的block的第一条记录的key。

  (5)MetaBlockIndex段(可选的)–MetaBlock的索引。

  (6)Trailer–这一段是定长的。储存了每一段的偏移量,读取一个HFile时,会第一

  读取Trailer,Trailer储存了每个段的起始位置(段的MagicNumber用来做安全check),然后,DataBlockIndex会被读取到内存中,如此,当检索某个key时,不需要扫描整个HFile,而只需从内存中找到key所在的block,通过一次磁盘io将整个block读取到内存中,再找到需要的key。DataBlockIndex采纳LRU机制剔除。

  HFile的DataBlock,MetaBlock通常采纳压缩方式储备,压缩之后能够大大减少网络IO和磁盘IO,随之而来的开销因此是需要花费cpu进行压缩和解压缩。

  目标Hfile的压缩支持两种方式:Gzip,Lzo。

  HLog(WALlog)WAL意为Writeaheadlog,类似mysql中的binlog,用来

  做灾难复原只用,Hlog记录数据的所有变更,一旦数据修改,就能够从log中进行复原。

  每个RegionServer爱护一个Hlog,而不是每个Region一个。如此不同region(来自不同table)的日志会混在一起,如此做的目的是不断追加单个

  文件相关于同时写多个文件而言,能够减少磁盘寻址次数,因此能够提高对table的写性能。带来的苦恼是,假如一台regionserver下线,为了复原其上的region,需要将regionserver上的log进行拆分,然后分发到其它regionserver上进行复原。

  HLog文件确实是一个一般的HadoopSequenceFile,SequenceFile的Key是HLogKey对象,HLogKey中记录了写入数据的归属信息,除了table和region名字外,同时还包括sequencenumber和timestamp,timestamp是"写入时刻",sequencenumber的起始值为0,或者是最近一次存入文件系统中sequencenumber。HLogSequeceFile的Value是HBase的KeyValue对象,即对应HFile中的KeyValue,可参见上文描述。

  9.4、系统架构

  ClientHBaseClient使用HBase的RPC机制与HMaster和HRegionServer进行通信,关于治理类操作,Client与HMaster进行RPC;关于数据读写类操作,Client与HRegionServer进行RPC(1)

  包含访问HBase的接口,client爱护着一些cache来加快对HBase的访问,比如regione的位置信息。

  Zookeeper(1)保证任何时候,集群中只有一个master(2)存贮所有Region的寻址入口。

  (3)实时监控RegionServer的状态,将Regionserver的上线和下线信息实时通知给Master(4)储备HBase的schema,包括有哪些table,每个table有哪些columnfamily

  Master(1)为Regionserver分配region(2)负责regionserver的负载均衡

  (3)发觉失效的regionserver并重新分配其上的region(4)GFS上的垃圾文件回收

  (5)处理schema更新要求

  RegionServer(1)Regionserver爱护Master分配给它的region,处理对这些region的IO要求

  (2)Regionserver负责切分在运行过程中变得过大的region能够看到,client访问HBase上数据的过程并不需要master参与(寻址访问zookeeper和regionserver,数据读写访问regioneserver),master仅仅爱护者table和region的元数据信息,负载专门低。

  9.5、关键算法\流程

  region定位

  系统如何找到某个rowkey(或者某个rowkeyrange)所在的regionbigtable使用三层类似B+树的结构来储存region位置。

  第一层是储存zookeeper里面的文件,它持有rootregion的位置。

  第二层rootregion是.META.表的第一个region其中储存了.META.z表其它region的位置。通过rootregion,我们就能够访问.META.表的数据。

  第三层

  META,它是一个专门的表,储存了HBase中所有数据表的region位置信息。

  (1)

  rootregion永久可不能被split,保证了最需要三次跳转,就能定位到任意region。

  (2)META.表每行储存一个region的位置信息,rowkey采纳表名+表的最后一样编码而成。

  (3)为了加快访问,.META.表的全部region都储存在内存中。

  假设,.META.表的一行在内存中大约占用1KB。同时每个region限制为128MB。

  那么上面的三层结构能够储存的region数目为:

  (128MB/1KB)*(128MB/1KB)==2(34)个region(4)client会将查询过的位置信息储存缓存起来,缓存可不能主动失效,因此假如client上的缓存全部失效,则需要进行6次网络来回,才能定位到正确的region(其中三次用来发觉缓存失效,另外三次用来猎取位置信息)。

  读写过程

  上文提到,HBase使用MemStore和StoreFile储备对表的更新。

  数据在更新时第一写入Log(WALlog)和内存(MemStore)中,MemStore中的数据是排序的,当MemStore累计到一定阈值时,就会创建一个新的MemStore,同时将老的MemStore添加到flush队列,由单独的线程flush到磁盘上,成为一个StoreFile。于此同时,系统会在zookeeper中记录一个redopoint,表示那个时刻之前的变更差不多持久化了。

  当系统显现意外时,可能导致内存(MemStore)中的数据丢失,现在使用Log(WALlog)来复原checkpoint之后的数据。

  前面提到过StoreFile是只读的,一旦创建后就不能够再修改。因此HBase的更新事实上是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后,就会进行一次合并(majorcompact),将对同一个key的修改合并到一起,形成一个大的StoreFile,当StoreFile的大小达到一定阈值后,又会对StoreFile进行split,等分为两个StoreFile。

  由于对表的更新是不断追加的,处理读要求时,需要访问Store中全部的StoreFile和MemStore,将他们的按照rowkey进行合并,由于StoreFile和MemStore差不多上通过排序的,同时StoreFile带有内存中索引,合并的过程依旧比较快。

  写要求处理过程

  (1)client向regionserver提交写要求

  (2)regionserver找到目标region(3)region检查数据是否与schema一致

  (4)假如客户端没有指定版本,则猎取当前系统时刻作为数据版本

  (5)将更新写入WALlog(6)将更新写入MemStore(7)判定MemStore的是否需要flush为Store文件。

  region分配

  任何时刻,一个region只能分配给一个regionserver。master记录了当前有哪些可用的regionserver。以及当前哪些region分配给了哪些regionserver,哪些region还没有分配。当存在未分配的region,同时有一个regionserver上有可用空间时,master就给那个regionserver发送一个装载要求,把region分配给那个regionserver。regionserver得到要求后,就开始对此region提供服务。

  regionserver上线

  master使用zookeeper来跟踪regionserver状态。当某个regionserver启动时,会第一在zookeeper上的server名目下建立代表自己的文件,并获得该文件的独占锁。由于master订阅了server名目上的变更消息,当server名目下的文件显现新增或删除操作时,master能够得到来自zookeeper的实时通知。因此一旦regionserver上线,master能赶忙得到消息。

  regionserver下线

  当regionserver下线时,它和zookeeper的会话断开,zookeeper而自动开释代表这台

  server的文件上的独占锁。而master不断轮询server名目下文件的锁状态。假如master发觉某个regionserver丢失了它自己的独占锁,(或者master连续几次和regionserver通信都无法成功),master确实是尝试去猎取代表那个regionserver的读写锁,一旦猎取成功,就能够确定:

  (1)regionserver和zookeeper之间的网络断开了。

  (2)regionserver挂了。

  的其中一种情形发生了,不管哪种情形,regionserver都无法连续为它的region提供服务了,现在master会删除server名目下代表这台regionserver的文件,并将这台regionserver的region分配给其它还活着的同志。

  假如网络短暂显现问题导致regionserver丢失了它的锁,那么regionserver重新连接到zookeeper之后,只要代表它的文件还在,它就会不断尝试猎取那个文件上的锁,一旦猎取到了,就能够连续提供服务。

  master上线

  master启动进行以下步骤:(1)从zookeeper上猎取唯独一个代码master的锁,用来阻止其它master成为master。

  (2)扫描zookeeper上的server名目,获得当前可用的regionserver列表。

  (3)和2中的每个regionserver通信,获得当前已分配的region和regionserver的对应关系。

  (4)扫描.META.region的集合,运算得到当前还未分配的region,将他们放入待分配region列表。

  master下线

  由于master只爱护表和region的元数据,而不参与表数据IO的过

  程,master下线仅导致所有元数据的修改被冻结(无法创建删除表,无法修改表的schema,无法进行region的负载均衡,无法处理region上下线,无法进行region的合并,唯独例外的是region的split能够正常进行,因为只有regionserver参与),表的数据读写还能够正常进行。因此master下线短时刻内对整个HBase集群没有阻碍。从上线过程能够看到,master储存的信息全是能够冗余信息(都能够从系统其它地点收集到或者运算出来),因此,一样HBase集群中总是有一个master在提供服务,还有一个以上的"master"在等待时机抢占它的位置。

  9.6、访问接口

  (1)NativeJavaAPI,最常规和高效的访问方式,适合HadoopMapReduceJob并行批处理HBase表数据

  (2)HBaseShell,HBase的命令行工具,最简单的接口,适合HBase治理使用

  (3)ThriftGateway,利用Thrift序列化技术,支持C++,PHP,Python等多种语言,适合其他异构系统在线访问HBase表数据

  (4)RESTGateway,支持REST风格的API访问HBase,解除了语言限制

  (5)Pig,能够使用PigLatin流式编程语言来操作HBase中的数据,和Hive类似,本质最终也是编译成MapReduceJob来处理HBase表数据,适合做数据统计

  (6)Hive,当前Hive的Release版本尚没有加入对HBase的支持,但在下一个版本Hive0.7.0中将会支持HBase,能够使用类似SQL语言来访问HBase10、Hadoop查询与分析工具

  10.1、HiveHive是基于Hadoop的一个数据仓库工具,能够将结构化的数据文件映射为一张数据库表,并提供简单的sql查询功能,能够将sql语句转换为MapReduce任务进行运行。

  其优点是学习成本低,能够通过类SQL语句快速实现简单的MapReduce统计,不必开发专门的MapReduce应用,十分适合数据仓库的统计分析。

  (1)Hive定义

  Hive是建立在

  Hadoop上的数据仓库基础构架。它提供了一系列的工具,能够用来进行数据提取转化加载(ETL),这是一种能够储备、查询和分析储备在

  Hadoop中的大规模数据的机制。Hive定义了简单的类

  SQL查询语言,称为

  HQL,它承诺熟悉

  SQL的用户查询数据。同时,那个语言也承诺熟悉

  MapReduce开发者的开发自定义的mapper和

  reducer来处理内建的mapper和

  reducer无法完成的复杂的分析工作。

  Hive没有专门的数据格式。

  Hive能够专门好的工作在

  Thrift之上,操纵分隔符,也承诺用户指定数据格式。

  (2)适用场景

推荐访问:大数据治理平台调研报告 电力大数据处理存储与分析的调研报告 数据处理 调研报告 电力

版权所有:袖书文档网 2002-2024 未经授权禁止复制或建立镜像[袖书文档网]所有资源完全免费共享

Powered by 袖书文档网 © All Rights Reserved.。备案号:鲁ICP备20026461号-1