•HBase的实现包括三个主要的功能组件:
–(1)库函数:链接到每个客户端
–(2)一个Master主服务器
–(3)许多个Region服务器
•主服务器Master负责管理和维护HBase表的分区信息,维护Region服务器列表,分配Region,负载均衡
•Region服务器负责存储和维护分配给自己的Region,处理来自客户端的读写请求
•客户端并不是直接从Master主服务器上读取数据,而是在获得Region的存储位置信息后,直接从Region服务器上读取数据
•客户端并不依赖Master,而是通过Zookeeper来获得Region位置信息,大多数客户端甚至从来不和Master通信,这种设计方式使得Master负载很小
流数据:实时产生的数据,并且实时不断地像流水一样到达。
流数据特征:
1、数据快速持续到达,潜在大小也许是无穷无尽的。
2、数据来源众多,格式复杂。
3、数据量大,但是不是十分关注存储,一旦经过处理,要么被丢弃,要么被归档存储。
4、注重数据的整体价值,不过分关注个别数据。
5、数据顺序颠倒,或者不完整,系统无法控制将要处理的新到达的数据元素的顺序。
大数据特征:
Volume(大数据量):90%的数据是过去两年产生
Velocity(速度快):数据增长速度快,时效性高
Variety(多样化):数据种类和来源多样化
结构化数据、半结构化数据、非结构化数据
Value(价值密度低):需要挖掘数据价值
使用Hadoop的优点:
高扩展性、可伸缩
高可靠性
多副本机制。容错高
低成本
无共享架构
灵活,可存储任意数据类型
开源,社区活跃
Hadoop HDFS分块抽象的好处
1 文件大小可以大于任意一个磁盘的容量,块并不需要存储在同一个磁盘上
2 抽象块作为存储单元,简化存储子系统的设计
1) datanode将块作为处理对象,能存储多少块也能计算出
2) namenode管理元数据
3 数据备份提高容错能力和可用性
一、HBase的体系结构:主从架构
1、主节点:HMaster 管理员
作用:
1、为Hregionserver分配region:区域
2、负责Hregionserver的负载均衡
3、发现失效的Hregionserver并重新分配其上的region
4、接收客户端的请求:对HBase表进行增删改查等操作
2、从节点:Hregionserver
作用:
1、保存region,处理用户对region的IO请求(增删改查)
2、向HDFS中读写数据
Hregionserver越多,HBase/hadoop的实时查询存储能力越大,查询速度越快
把HBase抽象成一个图书馆,Hregionserver抽象成书架
HBase和Hadoop属于横向扩展的开源组件
3、Zookeeper:分布式应用程序协调服务
作用:
1、保存HBase集群结构信息:HMaster、Hregionserver,表的信息(-ROOT-:保存所有Meta表的信息 .META.:保存region的元信息) region的元信息
2、实现HBase集群的HA(High Availability:高可用性)功能
Flink的特点
①同时支持高吞吐、低延迟、高性能
②支持事件时间概念(Event Time)
大多数窗口计算采用的都是系统时间(Process Time),也是事件传输到计算框架时,系统主机的当前时间。Flink能够支持基于时间事件时间(Event Time)语义进行窗口计算,也就是时间产生的时间。这种基于时间驱动的机制使得事件即使是乱序到达,流系统也能够计算出精确的结果,保持了时间原本产生的时序性。尽量避免网络传输或硬件系统影响。
③支持有状态计算
Flink在1.4版本中实现了状态管理,所谓的状态就是流式计算过程中将算子的中间结果数据保存在内存中或者是文件系统中,等下一个时间进入算子后可以从之前的状态中获取中间结果中计算当前的结果,从而无需每次都基于全部的原始数据来统计结果,这种方式极大提升了系统的性能,并降低了计算过程资源的消耗,对于数据量大且运算逻辑非常复杂的流式计算场景,有状态发挥了非常重要的作用。
④支持高度灵活的窗口(Window)操作
在流处理应用中,数据是连续不断的,需要通过窗口的方式对数据进行一定范围的聚合计算,例如统计在过去一分钟内多少用户点击某一网页,在这种情况下,我们必须定义一个窗口,用来收集最近一分钟的数据,并对窗口内的数据进行统计计算。Flink将窗口划分为基于Time,count,Session,以及Data-driven等类型的窗口操作,窗口可以用灵活的触发条件定制化达到对复杂的流传输模式的支持,用户可以定义不同窗口触发机制来满足不同的需求。
⑤基于轻量级分布式快照(CheckPoint)实现的容错
Flink能够分布式运行在上千个节点上,将一个大型计算任务的流程拆解成小的计算过程,然后将tesk分布到并行节点上进行处理,在执行任务过程中,能够自动发现事件处理过程中的错误而导致数据不一致的问题。比如:节点宕机、网路传输问题,或是由于用户因为升级或修复问题导致计算服务重启等。在这些情况下,通过基于分布式快照技术CheckPoints,将执行过程中的状态信息进行持久化存储,一但任务出现异常停止,Flink就能够从Checkpoint中进行任务的自动恢复,以确保数据在处理过程中的一致性(Exactly-ONCE)
⑥基于JVM实现独立的内存管理
内存管理是所有计算框架需要重点考虑的部分,尤其对于计算量比较大的计算场景,数据在内存中该如何进行管理显得至关重要,针对内存管理,Flink实现了自身管理内存机制,尽可能减少JVM GC对系统的影响,另外,Flink通过序列化/反序列化方法将所有的数据对象转化为二进制在内存中存储,降低GC带来的性能下降或任务异常的风险,因此Flink较其他分布式处理的框架显得更加稳定,不会因为JVM GC等问题而影响整个应用的运行
⑦Save Point(保存点)
对于7*24小时运行的流式运用,数据源源不断地接入,在一段时间内应用的终止有可能导致数据丢失或者计算结果不准确,例如进行集群版本的升级、停机运维操作等。值得一提的是,Flink通过Save Points技术将任务执行的快照保存在存储介质上,当任务重启的时候可以直接从事保存的Save Points恢复原有的计算状态,使得任务继续按照停机之前的状态运行,Sava Point技术可以让用户更好的管理和运维
Hadoop组件:hadoop组件通俗介绍 - 知乎
Mapreduce 工作流程:
Hadoop的缺点
1.小文件问题
Hadoop适用于处理相对较大的文件,但是涉及到处理大量小文件的时(小文件比Hadoop的块大小小得多的文件,默认情况下,该块大小可以为128MB或256MB),Hadoop效率不高。这些大量的小文件使Namenode过载,因为Namenode存储了系统的名称空间,并使Hadoop难以运行。
2.天生脆弱
Hadoop用Java编写,Java是一种广泛使用的编程语言,因此它容易被网络犯罪分子利用,这使得Hadoop容易受到安全漏洞的攻击。
3.处理费用
在Hadoop中,数据是从磁盘读取并写入磁盘的,这在我们处理兆兆字节和PB级数据时使读/写操作非常昂贵。Hadoop无法执行内存中计算,因此会增加处理开销。
4.仅支持批处理
Hadoop的核心是一个批处理引擎,该引擎在流处理方面效率不高。它不能以低延迟实时生成输出。它仅适用于我们在处理之前预先收集并存储在文件中的数据。
5.迭代处理
Hadoop本身无法进行迭代处理。机器学习 或迭代处理具有周期性的数据流,而Hadoop的数据是在多个阶段链中流动的,其中一个阶段的输出成为另一阶段的输入。
6.安全性
为了安全起见,Hadoop使用难以管理的Kerberos身份验证。它缺少存储和网络级别的加密,这是一个主要问题。
Hadoop的缺点
1、Hadoop不适用于低延迟数据访问。
2、Hadoop不能高效存储大量小文件。
3、Hadoop不支持多用户写入并任意修改文件
二、MapReduce的优缺点
1.MapReduce的优点
在大数据和人工智能时代,MapReduce如此受欢迎主要因为它具有以下几个优点。
● MapReduce 易于编程。通过简单接口完成分布式程序的编写,可运行在众多服务器组成的集群上。即编写一个分布式程序与编写一个简单的串行程序是一模一样的。也正是易于使用的特点使得
● 良好的扩展性。出现资源不足的情况,可以直接增加机器数量来扩展集群的计算能力这与HDFS通过增加机器扩展集群存储能力的道理是一样的。
● 高容错性。高容错性提现在MapReduce能使程序能够部署在廉价商用服务器上。如果其中一台机器故障,自动切换到其他节点,而且这个过程不需要人工参与,完全在
● MapReduce 适合PB级以上海量数据的离线处理。
2.MapReduce的缺点
MapReduce 虽然具有很多优势,但也有不适用的场景,即有些场景下并不适合 MapReduce 来处理,主要表现在以下几个方面。
不适合实时计算。MapReduce 无法毫秒级内返回结果。MapReduct 并不适合数据的在线处理。
不适合进行流式计算。MapReduce设计之初输入数据集是静态的,不适合输入动态数据,不适合即流式计算。
不适合程序之间的依赖性,MapReduce的处理方法是将使用后每个 MapReduce 作业的输出结果写入磁盘,这样会造成大量的磁盘 IO,导致性能非常低下。
Spark凭借以下的优点在众多的大数据分析处理平台中脱引而出
1、速度快。与Hadoop的MapReduce相比,Spark基于内存的运算要快100倍以上;而基于硬盘的运算也要快10倍以上。Spark实现了高效的DAG执行引擎,可以通过基于内存来高效处理数据流。
2、易用。Spark支持Java、Python和Scala的API,还支持超过80种高级算法,使得用户可以快速构建不同的应用。而且Spark支持交互式的Python和Scala的shell,这意味着可以非常方便地在这些shell中使用Spark集群来验证解决问题的方法,而不是像以前一样,需要打包、上传集群、验证等。这对于原型开发非常需要。
3、通用性。Spark提供了统一的解决方案,Spark可以用于批处理、交互式查询(通过Spark SQL)、实时流处理(通过Spark Streaming)、机器学习(通过Spark MLlib)和图计算(通过Spark GraphX)。这些不同类型的处理都可以在同一个应用中无缝使用。
4、可融合性。Spark可以非常方便地与其他的开源产品进行融合。比如,Spark可以使用Hadoop的YARN和Apache Mesos作为它的资源管理和调度器,并且可以处理所有Hadoop支持的数据,包括HDFS,HBase和Cassandra等。这对于已经部署Hadoop集群的用户特别重要,因为不需要做任何数据迁移就可以使用Spark强大的处理能力。Spark也可以不依赖于第三方的资源管理器和调度器,它实现了Standalone作为其内置的资源管理和调度框架,这样进一步降低了Spark的使用门槛。使所有人都可以非常容易地部署和使用Spark。此外,Spark还提供了在EC2上部署Standalone的Spark集群的工具。
5、打造全栈多计算范式的高效数据流水线
支持复杂查询与数据分析任务。在简单的“Map”及“Reduce”操作之外, Spark还支持 SQL 查询、流式计算、机器学习和图算法。同时,用户可以在同一个工作流中无缝搭配这些计算范式。
6、轻量级快速处理
Spark 代码量较小,这得益于 Scala 语言的简洁和丰富表达力,以及 Spark 通过External DataSource API 充分利用和集成 Hadoop 等其他第三方组件的能力。同时 Spark基于内存计算,可通过中间结果缓存在内存来减少磁盘 I/O 以达到性能的提升。
7、易于使用,支持多语言
Spark 支持通过 Scala、 Java 和 Python 编写程序,这允许开发者在自己熟悉的语言环境下进行工作。它自带了 80 多个算子,同时允许在 Shell 中进行交互式计算。用户可以利用 Spark 像书写单机程序一样书写分布式程序,轻松利用 Spark 搭建大数据内存计算平台并充分利用内存计算,实现海量数据的实时处理。
8、与 External Data Source 多数据源支持
Spark 可以独立运行,除了可以运行在当下的 Yarn 集群管理之外,它还可以读取已有的任何 Hadoop 数据。它可以运行多种数据源,比如 Parquet、 Hive、 HBase、 HDFS 等。这个特性让用户可以轻易迁移已有的持久化层数据。
9、社区活跃度高
Spark 起源于 2009 年,当下已有超过 600 多位工程师贡献过代码。开源系统的发展不应只看一时之快,更重要的是一个活跃的社区和强大的生态系统的支持。
Hadoop之HDFS优点
1. 支持超大文件
HDFS分布式文件系统具有很大的数据集,可以存储TB或PB级别的超大数据文件,能够提供比较高的数据传输带宽与数据访问吞吐量,相应的,HDFS开放了一些POSIX的必须接口,容许流式访问文件系统的数据。
2. 高容错性能
HDFS面向的是成百上千的服务器集群,每台服务器上存储着文件系统的部分数据,在集群的环境中,硬件故障是常见的问题,这就意味着总是有一部分硬件因各种原因而无法工作,因此,错误检测和快速、自动的恢复是HDFS最核心的架构目标,因此,HDFS具有高度的容错性。
3. 高数据吞吐量
HDFS采用的是“一次性写,多次读”这种简单的数据一致性模型,在HDFS中,一个文件一旦经过创建、写入、关闭后,一般就不需要修改了,这样简单的一致性模型,有利于提高吞吐量。
4. 流式数据访问
HDFS的数据处理规模比较大,应用一次需要访问大量的数据,同时这些应用一般都是批量处理,而不是用户交互式处理,应用程序能以流的形式访问数据集。
Hadoop已经迅速成长为首选的、适用于非结构化数据的大数据分析解决方案,HDFS分布式文件系统是Hadoop的核心组件之一,保证了大数据的可靠存储,与MapReduce配合使用,可以对结构化和复杂大数据进行快速、可靠分析,从而为企业做出更好的决策,促进收入增长,改善服务,降低成本提供有力支撑!
Spark流程图:
Srorm和flink以及spark的对比:
模型:Storm 和 Flink 是真正的一条一条处理数据;而 Trident(Storm 的封装框架)和 Spark Streaming 其实都是小批处理,一次处理一批数据(小批量)。
API:Storm 和 Trident 都使用基础 API 进行开发,比如实现一个简单的 sum 求和操作;而 Spark Streaming 和 Flink 中都提供封装后的高阶函数,可以直接拿来使用,这样就比较方便了。
保证次数:在数据处理方面,Storm 可以实现至少处理一次,但不能保证仅处理一次,这样就会导致数据重复处理问题,所以针对计数类的需求,可能会产生一些误差;Trident 通过事务可以保证对数据实现仅一次的处理,Spark Streaming和Flink也是
如此。
容错机制:Storm和Trident可以通过ACK机制实现数据的容错机制, 而Spark Streaming和 Flink 可以通过 CheckPoint 机制实现容错机制。状态管理:Storm 中没有实现状态管理,Spark Streaming 实现了基于 DStream 的状态管理,而 Trident 和 Flink 实现了基于操作的状态管理。
延时:表示数据处理的延时情况, 因此 Storm 和 Flink 接收到一条数据就处理一条数据,其数据处理的延时性是很低的;而 Trident 和 Spark Streaming 都是小型批处理,它们数据处理的延时性相对会偏高。
吞吐量:Storm 的吞吐量其实也不低,只是相对于其他几个框架而言较低;Trident 属于中等;而 Spark Streaming 和 Flink 的吞吐量是比较高的。
综上,主要是因为Flink的高吞吐、低延迟、高性能等特性优于其它同类产品,使得越来越多的公司更青睐它。