Hadoop遭遇瓶颈的七大危险信号

  大多数企业大数据应用案例尚处于实验和试点阶段,对于少数首次在生产环境部署Hadoop系统的用户来说,最常遇到的就是扩展问题,此类问题往往导致企业因噎废食,终止大数据应用项目。

  部署和扩展Hadoop系统是一件高度复杂的事情,如果用户能提前对Hadoop扩展可能会遇到的各种问题和危险信号有所了解,就能避免很多“救火”场面。

  以下是Altiscale的Raymie Stata为我们总结的Hadoop大数据系统出现扩展问题的七大危险信号:

  危险信号一: 永远进入不了生产阶段

  大数据应用从概念验证到生产环境是一个巨大的飞跃,Hadoop系统的可扩展性将面临巨大的挑战。生产环境的数据规模产生的一些问题实验环境很难碰到。另外数据本身也存在差异,概念验证阶段使用的测试数据集往往是不真实的,或者类型单一。

  在进入生产环境前,大数据团队需要对Hadoop系统进行模拟真实数据规模的压力测试,此类测试能够检验大数据应用的可扩展性和容错性能,还能帮你做出更加准确的性能(资源需求)规划模型。

  危险信号二: 分析计算任务不断超时

  当Hadoop集群中运行的大数据应用很少或者只有一个时,一切都行云流水,按部就班,但是随着Hadoop集群的增长,数据分析任务的运行时间变得难以预测起来。一开始,只是有零星的超时现象,问题容易被忽视,但随着时间增长,超时问题会越来越严重,最后导致危机。

  在危机爆发前,你必须提前采取行动,根据任务峰值调整计算性能规划模型。

  危险信号三: 你开始告诉人们不要保留所有数据

  危机出现的另一个征兆是数据保留时间窗口不断缩水。一开始你想保留13个月的数据进行年度分析。但是由于空间限制,你开始减少保留数据的月份数。到最后,你的Hadoop系统因为没有足够多的数据而不再是“大数据”系统。

  数据保留窗口的缩水是因为存储的扩展性遇到问题,这与前面的计算性能问题类似。当你的容量预测模型出现问题时,需要尽快调整。

  危险信号四: 数据科学家被“饿死”

  任务负荷过重的Hadoop集群会扼杀创新,因为数据科学家们将没有足够的计算资源来开展大型任务,也没有足够的空间来存储中间结果。

  性能和容量规划通常会忽略或者低估数据科学家的需求,在加之前面提到的对生产环境任务的估计不足,会严重限制数据科学家的开拓性和创新性工作。

  危险信号五:数据科学家们开始查看Stack Overflow

   在Hadoop系统部署的早期,你的运营团队与科学家紧密协作。运营团队随时为数据科学家提供支持。(编者按:类似串联的协作模式)但是当Hadoop 系统成功上线后,系统的运维和扩展任务就会让运营团队疲于奔命,这时候数据科学家遇到Hadoop问题就只好自己解决,例如经常去技术问答网站Stack Overflow查看问题帖子。

  危险信号六:数据中心越来越热

  数据中心服务器的电力都不是按服务器的功率峰值配置的,但是一个Hadoop集群运行任务的时候经常会连续“拷机”数小时,会烧坏功率不匹配的供电线路,同样的问题也存在于制冷系统中。部署Hadoop系统时请确保数据中心支持其长时间全速运行。

  危险信号七:费用超支

  基于IaaS的Hadoop部署,例如AWS,在支出上是失控的。一个月的费用很有可能是上个月的三倍,远远超出你的预算。

  性能规划对于基于IaaS的Hadoop部署来说也是非常重要的,但是好的性能规划只是开始,如果你需要扩展IaaS上的Hadoop系统,那么你需要学习Netflix在成本监控和优化系统上投入大量资金。

Related items

  • 企业存储大数据的三种环境

      大数据的部署实施需要结合具体的应用场景。实际上,企业大数据的存储处理可以用 “三只小猪盖房子”(分别使用稻草、木头和砖头)的故事来说明,这个故事能更形象地反映数据存储环境下与交付服务(成本)相对应的不同保护级别(完整性和可靠性)。

      财务数据、对外报告和法规遵从性数据需在“砖房”(BRICKS)环境中存储处理。这些数据需要可靠的硬件基础设施,并与其原始来源保持一致。企业中多个职能部门使用产品服务定价决策、销售业绩及分析以及至关重要的员工/管理层薪酬激励机制计算等财务数据,这是很常见的情况。

      精心设计的“木房”(STICK)环境可确保存储数据牢固耐用。该环境专用于应用程序,而并非针对企业级使用和跨职能部门数据共享而设计。该数据类型可专门用于数据转换,通常包括大量营销数据集市。仅数据转换、协调及沿袭等必要功能即可满足特定商业用途。与上述“砖房”相比,“木房”从本质上讲,成本更低,速度更快。

      最后介绍“草房”(HAY)。“草房”实际上是指在需要使用数据的特定日期对数据进行转换、分组及汇总。其中,数据可能以原始来源的数据格式存在,几乎不需要任何数据结构。用户可任意调整数据格式。虽然 “草房”设计无法轻易复制或纵向扩展,却适用于应对非特定、非重复性商业问题。该方案对数据协调及复制的需求低。

      使用“三只小猪”的类比相当直观,但具体解决方案应参考数据管控(Data Governance)方针。如能应对自如,业务部门希望快速获得低成本解决方案;而IT部门则需要依托可靠的解决方案,提供健全、可靠的服务。这也是业务及IT部门大多数讨论中的固有矛盾。

      由于部署迅速、成本低且失败的代价低,“草房”解决方案备受关注。在新的经济机制下,特别是在自助式环境下用户对数据(包括大数据)价值的认可,是数据实验室和探索环境快速发展的原因。因此,业务部门选择快速、低成本的解决方案也不足为奇。

      但将“草房”方案升级为“木房”或“砖房”环境时,IT部门的成本令人非常震惊。“为什么他们不能使用我们两周内设计的解决方案?”他们可以。但在“草房”的基础上部署“砖房”甚至是“木房”方案都行不通。利用“草房”的设计方案部署“木房”及“砖房”方案,将浪费IT部门大量预算。

      其主要挑战是识别数据重要性的数据管控策略和过程。在“草房”环境中设计出的“创意”方案需迁移至更稳定的环境时,参与数据管理方式(草房、木房还是砖房)决策的相关负责人需要全面了解下游数据的重要性。

  • HBASE适用场景和成功案例

      有时候了解软件产品的最好方法是看看它是怎么用的。它可以解决什么问题和这些解决方案如何适用于大型应用架构,能够告诉你很多。因为HBase有许多公开的产品部署,我们正好可以这么做。本章节将详细介绍一些人们成功使用HBase的使用场景。

      注意:不要自我限制,认为HBase只能解决这些使用场景。它是一个初生的技术,根据使用场景进行创新正驱动着系统的发展。如果你有新想法,认为可以受益于HBase提供的功能,试试吧。社区很乐于帮助你,也会从你的经验中学习。这正是开源软件精神。

      HBase仿效了Google的BigTable,让我们开始探索典型的BigTable问题:存储互联网。

      典型互联网搜索问题:BigTable发明的原因

      搜索是一个定位你所关心的信息的行为:例如,搜索一本书的页码,其中含有你想读的主题,或者网页,其中含有你想找的信息。搜索含有特定词语的文档,需要查找索引,该索引提供了特定词语和包含该词语的所有文档的映射。为了能够搜索,首先必须建立索引。Google和其他搜索引擎正是这么做的。他们的文档库是整个互联网;搜索的特定词语就是你在搜索框里敲入的任何东西。

      BigTable,和模仿出来的HBase,为这种文档库提供存储,BigTable提供行级访问,所以爬虫可以插入和更新单个文档。搜索索引可以基于BigTable 通过MapReduce计算高效生成。如果结果是单个文档,可以直接从BigTable取出。支持各种访问模式是影响 BigTable设计的关键因素。

      建立互联网索引

      1 爬虫持续不断地抓取新页面,这些页面每页一行地存储到BigTable里。

      2 MapReduce计算作业运行在整张表上,生成索引,为网络搜索应用做准备。

      搜索互联网

      3 用户发起网络搜索请求。

      4 网络搜索应用查询建立好的索引,或者直接从BigTable直接得到单个文档。

      5 搜索结果提交给用户。

      讲完典型HBase使用场景以后,我们来看看其他使用HBase的地方。愿意使用HBase的用户数量在过去几年里迅猛增长。部分原因在于HBase产品变得更加可靠和性能更好,更多原因在于越来越多的公司开始投入大量资源来支持和使用它。随着越来越多的商业服务供应商提供支持,用户越发自信地把HBase应用于关键应用系统。一个设计初衷是用来存储互联网持续更新网页副本的技术,用在互联网相关的其他方面也很是合适的。例如,HBase 在社交网络公司内部和周围各种各样的需求中找到了用武之地。从存储个人之间的通信信息,到通信信息分析,HBase成为 Facebook,Twitter,和StumbleUpon等公司里的关键基础架构。

      在这个领域,HBase有三种主要使用场景,但不限于这些。为了保持本节简单明了,我们这里介绍主要的使用场景。

      捕获增量数据

      数据通常是细水长流,累加到已有数据库以备将来使用,例如分析,处理和服务。许多HBase使用场景属于这个类别——使用HBase作为数据存储,捕获来自于各种数据源的增量数据。例如,这种数据源可能是网页爬虫(我们讨论过的BigTable典型问题),可能是记录用户看了什么广告和多长时间的广告效果数据,也可能是记录各种参数的时间序列数据。我们讨论几个成功的使用场景和公司。

      捕获监控参数:OPENTSDB

      服务于数百万用户的WEB产品的后台基础架构一般都有数百或数千台服务器。这些服务器承担了各种功能——服务流量,捕获日志,存储数据,处理数据等等。为了保持产品正常运行,监控服务器和上面运行软件的健康状态是至关重要的(从OS到用户交互应用)。大规模监控整个环境需要能够采集和存储来自于不同数据源的各种参数的监控系统。每个公司有自己的办法。一些公司使用商业工具来收集和展示参数;而其他一些公司采用开源框架。

      StumbleUpon 创建了一个开源框架,用来收集服务器的各种监控参数。按照时间收集参数一般称之为时间序列数据:也就是说,按照时间顺序收集和记录数据。 StumbleUpon 的开源框架叫做OpenTSDB,其含义是开放时间序列数据库 Open Time Series Database 。这个框架使用HBase作为核心平台来存储和检索所收集的参数。创建这个框架的目的是为了拥有一个可扩展的监控数据收集系统,一方面能够存储和检索参数数据并保存很长时间,另一方面如果需要增加功能也可以添加各种新参数。StumbleUpon 使用OpenTSDB监控所有基础架构和软件,包括HBase机群自身。我们将在第7章作为建构在HBase之上的示例应用来详细介绍OpenTSDB。

      捕获用户交互数据:Facebook和StumbleUpon

      捕获监控数据是一种使用方式。还有一种是捕获用户交互数据。如何跟踪数百万用户在网站上的活动?怎么知道哪一个网站功能是最受欢迎的?怎样使得这一次的网页浏览直接影响到下一次?例如,谁看了什么?某个按钮被点击了多少次?还记得Facebook和Stumble 里的Like按钮和StumbleUpon 里的+1 按钮吗?是不是听起来像是一个计数问题?每次用户Like一个特定主题计数器增加一次。

      StumbleUpon 在开始阶段采用MySQL,但是随着网站服务越来越流行,这个技术选择遇到问题了。急剧增长的用户在线负载需求远远超过了MySQL机群的能力,最终 StumbleUpon 选择HBase来替换这些机群。当时,HBase产品不能直接提供必须的功能。StumbleUpon 在HBase上做了一些小的开发改动,后来这些开发工作贡献回了项目社区。

      FaceBook使用HBase的计数器来计量人们Like特定网页的次数。内容原创人和网页主人可以得到近乎实时的、多少用户Like 他们网页的数据信息。他们可以因此更敏捷地判断应该提供什么内容。Facebook 为此创建了一个叫Facebook Insight的系统,该系统需要一个可扩展的存储系统。公司考虑了很多种可能,包括关系型数据库、内存数据库、和Cassandra数据库,最后决定使用HBase。基于HBase,Facebook 可以很方便地横向扩展服务规模,提供给数百万用户,也可以继续使用他们已有的运行大规模HBase机群的经验。该系统每天处理数百亿条事件,记录数百个参数。

      TELEMETRY:MOZILLA 和 TREND MICRO

      软件运行数据和软件质量数据,不像监控参数数据那么简单。例如,软件崩溃报告是有用的软件运行数据,经常用来探究软件质量和规划软件开发路线图。HBase可以成功地用来捕获和存储用户计算机上生成的软件崩溃报告。这种使用场景不像前两种使用场景,和网络服务应用不一定有关系。

      Mozilla基金会负责FireFox网络浏览器和Thunderbird电邮客户端两个产品。这些工具安装在全世界数百万台计算机上,支持各种操作系统。当这些工具崩溃时,会以Bug报告的形式返回一个软件崩溃报告给Mozilla。Mozilla如何收集这些数据?收集后又是怎么使用呢?实际情况是这样的,一个叫做Socorro的系统收集了这些报告,用来指导研发部门研制更稳定的产品。Socorrade系统的数据存储和分析建构在HBase上。 [1]

      采用HBase使得基本分析可以用到比以前多得多的数据。这种分析用来指导Mozilla的开发人员,使其更为专注,研制出Bug最少的版本。

      Trend Micro为企业客户提供互联网安全和入侵管理服务。安全的重要环节是感知,日志收集和分析对于提供这种感知能力是至关重要的。Trend Micro使用HBase来管理网络信誉数据库,该数据库需要行级更新和支持MapReduce批处理。有点像Mozilla的Socorro系统,HBase也用来收集和分析日志活动,每天收集数十亿条记录。HBase中灵活的模式支持数据结构出现变化,当分析流程重新调整时Trend Micro可以增加新属性。

      广告效果和点击流

      过去的十年,在线广告成为互联网产品的一个主要收入来源。提供免费服务给用户,在用户使用服务的时侯投放广告给目标用户。这种精准投放需要针对用户交互数据做详细的捕获和分析,以便于理解用户的特征。基于这种特征,选择并投放广告。精细的用户交互数据带来更好的模型,进而导致更好的广告投放效果和更多的收入。但这类数据有两个特点:它以连续流的形式出现,它很容易按用户划分。理想情况下,这种数据一旦产生就能够马上使用,用户特征模型可以没有延迟地持续优化——也就是说,以在线方式使用。

      在线 VS 离线系统

      在线和离线的术语多次出现。对于初学者来说,这些术语描述了软件系统执行的条件。在线系统需要低延迟。某些情况下,系统哪怕给出没有答案的响应,也要比花了很长时间给出正确答案的响应好。你可以把在线系统想象为一个跳着脚的没有耐心的用户。离线系统不需要低延迟,用户可以等待答案,不期待马上给出响应。当实现应用系统时在线或者离线的目标影响着许多技术决策。HBase是一个在线系统。和Hadoop MapReduce的紧密结合又赋予它离线访问的能力。

      HBase非常适合收集这种用户交互数据,HBase已经成功地应用在这种场合,它可以增量捕获第一手点击流和用户交互数据,然后用不同处理方式(MapReduce是其中一种)来处理数据(清理、装饰、使用数据)。在这种公司,你会发现很多HBase案例。

      内容服务

      传统数据库的一个最大使用场合是为用户提供内容服务。各种各样的数据库支撑着提供各种内容服务的应用系统。多年来这些应用在发展,因此他们所依赖的数据库也在发展。用户希望使用和交互的内容种类越来越多。此外,由于互联网迅猛的增长以及终端设备更加迅猛的增长,对这些应用的连接方式提出了更高的要求。各种各样的终端设备带来了一个挑战:不同种类设备需要以不同格式使用同样的内容。

      一方面是用户使用内容 User Consuming Content,对应另一面是用户生成内容 User GenerateContent。Tweete、Facebook帖子、Instagram 图片和微博等都是这样的例子。

      他们相同的地方是使用和生成了许多内容。大量用户通过应用系统来使用和生成内容,而这些应用系统需要Hbase作为基础。

      集中的内容系统系统 CMS可以存储内容和提供服务。但是当用户越来越多,生成内容越来越多的时候,就需要一个更具扩展性的CMS解决方案。

      这种可扩展的CMS往往使用Hbase作为基础,再加上其他的开源框架,例如Solr,构成一个完整的功能组合。

      Salesforce提供托管CRM产品,这个产品通过网络浏览器界面提交给用户使用,显示出了丰富的关系型数据库功能。在Google 发表NoSQL原型概念论文之前很长一段时间,生产环境中使用的大型关键数据库最合理的选择就是商用关系型数据库。多年来,Salesforce通过数据库分库和尖端性能优化这些手段扩展系统,达到每天处理数亿事务的能力。

      当Salesforce看到分布式数据库这样的选择后,他们评测了所有NoSQL技术的产品,最后决定部署HBase。这个选择的主要原因是有来由的。BigTable类型的系统是唯一的可以无缝融合水平扩展能力和行级强一致性的结构方式。此外,Salesforce已经把Hadoop用于大型离线批处理任务,他们可以继续利用Hadoop上面积累的宝贵经验。

      URL短链

      最近一段时间URL短链非常流行,许多类似产品破土而出。StumbleUpon使用名字为su.pr.的短链产品,这个产品以HBase为基础。这个产品用来缩短URL,存储大量的短链以及和原始长链接的映射关系,HBase帮助产品实现扩展能力。

      用户模型服务

      经过HBase处理过的内容往往并不直接提交给用户使用,而是用来决定应该提交给用户什么内容。这种中间处理数据用来丰富用户的交互。还记得前面提到的广告服务场景里的用户模式吗?用户模式(或者说模型)就是来自于HBase。这种模型多种多样,可以用于多种不同场景,例如,针对特定用户投放什么广告的决定,用户在电商门户购物时实时报价的决定,用户在搜索引擎检索时增加背景信息和关联内容,等等。很多这种使用案例可能不便于公开讨论,说多了我们就麻烦了。

      当用户在电商网站上发生交易时,用户模型服务可以用来实时报价。这种模型需要基于不断产生的新用户数据持续优化。

       信息交换

      各种社交网络破土而出,世界变得越来越小。社叫网站的一个重要作用就是帮助人们进行交互。有时交互在群组内发生(小规模和大规模);有时交互在两个个人之见发生。想想看,数亿人通过社交网络进行对话的场面。只是和远处的人通话是不够的,人们还想看看和其他人通话的历史记录。社交网络公司感到幸运的是,存储很廉价,大数据领域的创新可以帮助他们充分利用廉价的存储。

      Facebook短信系统经常被公开讨论,他也可能极大地驱动了HBase的发展。当你使用Facebook时,某个时候你可能会收到或者发送短信给你的朋友。Facebook的这个特性完全依赖于HBase。用户读写的所有短信都存储在HBase里。支持Facebook短信的系统需要具备:高的写吞吐量,极大的表,数据中心内的强一致性。除了短信系统之外,使用HBase的其他应用系统另外要求:高的读吞吐量,计数器吞吐量,自动分库。工程师们发现HBase是个理想的解决方案,因为他支持所有这些要求,他拥有一个活跃的用户社区,Facebook运营团队在Hadoop部署上有丰富经验,等等。在“Hadoop goes realtime at Facebook”这篇文章里,Facebook工程师解释了这个决定背后的逻辑和显示了他们使用Hadoop和HBase建设在线系统的经验。

      Facebook工程师在HbaseCon 2012会议上分享了一些有趣的数据。在这个平台上每天交换数十亿条短信,每天带来大约750亿次操作。尖峰时刻,Facebook的HBase集群每秒发生150万次操作。从数据规模角度看,Facebook的集群每月增加250TB的新数据,这可能是已知的最大的HBase部署,无论是服务器的数量还是服务器所承载的用户量。