大数据

  • Hadoop环境部署

    Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下,开发分布式程序。充分利用集群的威力进行高速运算和存储。Hadoop的框架最核心的设计就是:HDFS和MapReduce。HDFS为海量的数据提供了存储,则MapReduce为海量的数据提供了计算。Hadoop的运行模式分为三种:单机模式、伪分布式模式、完全分布式模式。

  • HBase伪分布式模式部署

    HBase – Hadoop Database,是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。与FUJITSU Cliq等商用大数据产品不同,HBase是Google Bigtable的开源实现,类似Google Bigtable利用GFS作为其文件存储系统,HBase利用Hadoop HDFS作为其文件存储系统;Google运行MapReduce来处理Bigtable中的海量数据,HBase同样利用Hadoop MapReduce来处理HBase中的海量数据;Google Bigtable利用 Chubby作为协同服务,HBase利用Zookeeper作为对应。

  • HBase单机模式部署

    HBase – Hadoop Database,是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。与FUJITSU Cliq等商用大数据产品不同,HBase是Google Bigtable的开源实现,类似Google Bigtable利用GFS作为其文件存储系统,HBase利用Hadoop HDFS作为其文件存储系统;Google运行MapReduce来处理Bigtable中的海量数据,HBase同样利用Hadoop MapReduce来处理HBase中的海量数据;Google Bigtable利用 Chubby作为协同服务,HBase利用Zookeeper作为对应。

  • Storm 简介

    Hadoop(大数据分析领域无可争辩的王者)专注于批处理。这种模型对许多情形(比如为网页建立索引)已经足够,但还存在其他一些使用模型,它们需要来自高度动态的来源的实时信息。为了解决这个问题,就得借助 Nathan Marz 推出的 Storm(现在在 Twitter 中称为 BackType)。Storm 不处理静态数据,但它处理预计会连续的流数据。考虑到 Twitter 用户每天生成 1.4 亿条推文 (tweet),那么就很容易看到此技术的巨大用途。
    但 Storm 不只是一个传统的大数据分析系统:它是复杂事件处理 (CEP) 系统的一个示例。CEP 系统通常分类为计算和面向检测,其中每个系统都可通过用户定义的算法在 Storm 中实现。举例而言,CEP 可用于识别事件洪流中有意义的事件,然后实时地处理这些事件。
    Nathan Marz 提供了在 Twitter 中使用 Storm 的大量示例。一个最有趣的示例是生成趋势信息。Twitter 从海量的推文中提取所浮现的趋势,并在本地和国家级别维护它们。这意味着当一个案例开始浮现时,Twitter 的趋势主题算法就会实时识别该主题。这种实时算法在 Storm 中实现为 Twitter 数据的一种连续分析。

  • ZooKeeper安装部署

    ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。

  • ZooKeeper介绍及典型使用场景

    ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。

  • hadoop集群部署(yarn)

    伴随着各大互联网公司开源自己的大数据框架,大数据处理领域的框架已经比较完善。到现在所谓大数据的框架已经用过habase(后来换成了elasticsearch)、zookeeper、kafka、storm,根据项目计划,接下来还要使用spark。虽然在众多框架中仅仅几个,但是也是已经涉及多个方面:数据存储、分布式协调、消息、实时计算等。没有找到任何一个框架能够完美解决所有问题,也就应了那句话,开发领域根本就没有银色子弹。所以即使是比较年长的hadoop(2004年到现在已经12年了,年纪也比较大了),也有能够体现其价值的地方。

    最近用了storm,部署topology的时候总是感觉资源使用不平衡,于是想到了yarn能够对hadoop实现资源的协调,那是不是可以扩展一下,对storm也提供资源协调呢。google一下,果然yahho!已经开源了一个storm-yarn组件,于是学习一下,同时也把hadoop的部署复习了一遍。(关于hadoop的单机部署、伪分布式部署可以查看Hadoop环境部署

  • 使用QJM实现HDFS的HA

    本文是在hadoop集群部署(yarn)基础上增加的配置内容,因为那篇缺少HDFS的HA配置,在生产环境不够完整。

    hadoop官方提供了两种HDFS的HA配置方案,两种方案殊途同归,但是需要的钱、精力和技术不同。

    如果对HDFS架构熟悉的话(如果不熟悉,可以通过HDFS架构了解),就应该知道,NameNode通过FsImage和EditLog两个文件管理DataNode的数据,Secondary NameNode会定期合并EditLog,以减少NameNode启动时的安全检查。EditLog文件存储的是对文件的一条条的操作,也就是说,只要保证有另外一个NameNode的EditLog文件一直与当前正在运行的NameNode的EditLog文件是一样的,那就可以随时使用新的NameNode替换老的NameNode。官方目前给出的两种HA方案也大体是这样:

    • QJM:the Quorum Journal Manager,翻译是法定经济管理人,实在没法想象,所以大家都亲切的称之为QJM。这种方案是通过JournalNode共享EditLog的数据,使用的是Paxos算法(没错,zookeeper就是使用的这种算法),保证活跃的NameNode与备份的NameNode之间EditLog日志一致。
    • NFS:Network File System 或 Conventional Shared Storage,传统共享存储,其实就是在服务器挂载一个网络存储(比如NAS),活跃NameNode将EditLog的变化写到NFS,备份NameNode检查到修改就读取过来,是两个NameNode数据一致。

    客观的说,Secondary NameNode也算是对NameNode的备份,但是使用Secondary NameNode需要手动处理,不如QJM和NFS两种可以自动处理简单,所以没有被列入HA解决方案中。

    但是,这两种方案在部署方式上差别比较大。QJM需要启动几个JournalNode即可,NFS需要挂在一个共享存储。因为条件限制,我只能通过QJM的方式实现HDFS的HA,如果想看NFS方案,可以直接看官方文档

  • HDFS架构

    前段时间搭建了一套Hadoop集群的测试环境,因为服务器故障,废了。这几天闲来无事,想着把Storm用Yarn管理起来,于是再来一遍,同时也梳理下Hadoop组件中的一些概念。所谓书读百遍其义自见,不熟的系统多搭几遍,总会熟悉了,也就是所谓的刻意练习吧。

    先简单的说下。

    Hadoop文件存储的基础是HDFS(Hadoop Distributed File System),HDFS的实现依赖于NameNode和DataNode,DataNode用来存储具体数据,NameNode用来管理多个DataNode中分别存储的是什么。

    理解起来也不难,因为HDFS是分布式的文件系统,也就是有很多机器用来存储数据,一个大文件可能分布在多个机器上,也可能是一台机器上,具体分布在哪些或哪个机器上,每块数据块的副本在哪,得需要一个总管来管理,这个总管就是NameNode,具体存储机器的就是DataNode。

    简单的说完了,接下来就复杂的说。

  • ResourceManager HA 配置

    陆续的把Hadoop集群部署HDFS的HA配置)完成,把ResourceManager的HA配置好之后,Hadoop集群配置也算是完整了,可以满足小型中型生产环境Hadoop集群搭建的需要。如果真要搭建超大型的Hadoop集群,这些只能算是参考,还需要修改很多其他参数,使性能更好一些。

    ResourceManager(RM)负责跟踪集群中资源使用情况,调度应用程序(比如MapReduce作业)。在Hadoop 2.4之前,ResourceManager存在单点故障,需要通过其他方式实现HA。官方给出的HA方案是Active/Standby两种状态ResourceManager的冗余方式,类似于HDFS的HA方案,也就是通过冗余消除单点故障。

  • YARN架构

    对Hadoop有过了解的都知道,Hadoop经历过很长一段时间的版本号混乱和架构调整,YARN是Hadoop 2.0(或者早期的0.23.x)提出的资源管理、任务调度框架。解决了很多Hadoop 1.0(或者0.21.x、0.22.x)时代的痛点。

    随着发展,YARN不仅仅是Hadoop的资源调度框架,还成为一个通用的资源调度管理器,可以将各种各样的计算框架通过YARN管理起来,比如Strom、Spark等。

    YARN的基本思想是将资源管理和作业调度/监控的功能分为独立的守护进程。分别是一个全局的 ResourceManager(RM) 和每个应用程序的 ApplicationMaster(AM)。应用程序可以是一个job作业或者一组job作业的有向无环图(DAG)。

    ResourceManager负责系统中的所有应用程序的资源分配。NodeManager负责每台机器中容器代理、资源监控(cpu,内存,磁盘,网络),并将这些情况报告给ResourceManager或Scheduler。

    每个应用的ApplicationMaster是一个框架特定的库,从ResourceManager协商资源,并与NodeManager共同执行监听任务。

    从结构上看,YARN是主/从架构,一个ResourceManager,多个NodeManager,共同构成了数据计算框架。

  • storm笔记:Storm+Kafka简单应用

    这几天工作需要使用storm+kafka,基本场景是应用出现错误,发送日志到kafka的某个topic,storm订阅该topic,然后进行后续处理。场景非常简单,但是在学习过程中,遇到一个奇怪的异常情况:使用KafkaSpout读取topic数据时,没有向ZK写offset数据,致使每次都从头开始读取。纠结了两天,终于碰巧找到原因:应该使用BaseBasicBolt作为bolt的父类,而不是BaseRichBolt

    通过本文记录一下这种情况,后文中根据上述场景提供几个简单的例子。基础理论查看storm笔记:storm基本概念,或查看Storm 简介

  • storm笔记:Trident状态

    storm笔记:Trident应用中说了下Trident的使用,这里说下Trident几种状态的变化及其对应API的使用。

  • storm笔记:Trident应用

    本文内容部分来自Trident Tutorial

    Trident是基于Storm的实时计算模型的高级抽象。它可以实现高吞吐(每秒数百万条消息)的有状态流处理和低延迟分布式查询。如果以前使用过高级批处理工具(比如Pig或Cascading),则对Trident的概念会非常熟悉,比如连接、聚合、分组、功能处理和过滤等。除此之外,Trident还增加了用于在数据库或持久化存储上进行有状态的增量处理的原语。Trident具有一致性、一次性语义,所以很容易就能够推导出Trident拓扑结构。

    Trident的出现算是程序猿非常懒的又一个铁证。Strom是一个实时流处理工具,有很高的吞吐。在实际应用场景中,很多场景是借助这种实时处理能力,对实时数据进行统计,然后将统计结果实时推送到大屏或者其他可以实时浏览的地方,这样领导或者活动运营就可以实时查看销售或活动情况,比如,双十一时候的大屏,就可以使用Storm来做(我们现在就是这样做的,把全渠道的销售情况进行实时统计,然后显示在大屏上,据说领导会看)。然后,程序猿们就发现,很多统计功能非常类似,所以进行抽象,使用更加高级的功能代替一个一个的Spout、Bolt(当然,Trident拓扑结构运行的时候也是解析成Spout和Bolt运行)。

    然后又有人发现,Trident这种方式也是比较麻烦,即使程序猿们通过高级抽先的Trident省去了很多麻烦,但是还是架不住运维、运营、产品等不断改变的需求,所以就有很多SQL方式解析为Trident或普通Topology的工具产生。既然运维、运营、产品等不断修改需求,那就简单的通过SQL查询(不同的SQL解析为不同的拓扑结构,在Storm中运行,可以得出不同的结果)。比如:squall

    这些都是题外话,下面继续说Trident。

  • Zookeeper客户端错误:Packet len8854970 is out of range!

    这是一个生产环境使用zookeeper异常的情况,错误是java.io.IOException: Packet len8854970 is out of range!。然后就换了一个namespace,就没有在出错,以为是偶然发生,所以没有重视。但是年后居然又出现问题,才意识到严重性。分析之后发现,每隔一段时间,某一个znode节点下超过客户端所设置的大小,客户端连接会失败,zkCli.sh操作该节点也会失败。如果对于简单依赖zookeeper的系统,这种错误可以容忍(但是必须解决);如果是强依赖zookeeper的系统,这种错误可以说是灾难。