51CTO电子杂志《Linux运维趋势》第18期_大数据

002 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 目录 Index 002 目录 人物·People 003 115网盘赖霖枫：从分享大文件的需求开始 交流·Interact 005 SSL正在保护我的网站……等等，你真的确定 吗？ 八卦·News 008 Apache 2.4发布 淘宝Metamorphosis开源 专题·Special 010 HAProxy+Hive构建高可用数据挖掘集群 012 HDFS小文件问题及解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 016 淘宝Fourinone介绍及与Hadoop的性能PK 018 淘宝海量数据库之十四：故障恢复 技巧·工具·脚本·DBA 020 在 CentOS 6.2 上安装 Puppet 配置管理工具 023 浅谈Squid在图片存储架构中的应用 026 轻量级HTTP服务器Nginx(Nginx性能优化技 巧) 030 使用LVM技术提升Xen虚拟机性能的实现 033 通过分布式及文件级数据缓存打造千万级别 WEB应用 003 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 人物 People 003 115网盘赖霖枫：从分享大文件的需求开始 （采访全文也涉及到产品方面，本期《趋势》仅截取赖霖枫在技术方 面的说明，完整内容可参考原文。） 51CTO ：霖枫你好，能否大致介绍一下 115 网盘在服务器端和客 户端都采用了哪些技术？ 赖霖枫 ：115 整体架构非常简单，主要是由访问终端层、后台服务 器端和底层存储端三部分组成。 终端访问层提供了各类接入方式的应用访问，如更多跨平台 PC 客 户端应用如 WIN/MAC 平台，移动端支撑 iOS/Android 等主流移动 OS，实现了 iPhone/iPAD/Android 主流机型的应用支撑。 WEB 应用采用主流分布式技术框架，表现层以 CSS、JS 为主， HTML5 的研发团队会随着更多浏览器的支撑提供给终端用户更佳 丰富的体验。 WEB 服务端则采用主流 PHP 相关开源技术 ：缓存、搜索以及尽可 能的异步设计和数据库分区分表、读写分离充分实现独立应用组件的 横向扩展来支撑海量数据，而组件间由于松散耦合架构又不会彼此干 扰，尽可能提高缓存命中以增强用户体验，部署 Nginx/Varnish 采用 了诸如 Redis、MongoDB 等更多分布式技术。 PC 客户端应用的开发采用 UI 和组件分离的策略，更多 COM 组 采访、整理／杨赛 雨林木风的名字，在中国网民当中有很多人听到过 ；也有很多人知 道，它的创始人赖霖枫是一个思维活泛的创业者，操作系统、论坛、网 址导航，什么都感兴趣，还特别喜欢购买域名。即使做了这么多年，互 联网业界发生了翻天覆地的变化，他的身上仍然保留很多上个世纪末 互联网刚刚兴起之时的那股子江湖气息 ：因为喜欢而做，从而聚集了 同样一批因为喜欢而加入的网友们，成为其忠实的用户群体。 115 网盘就是诞生在这样一个野战军的环境下，并在 2011 年发 展成为赖霖枫的第二个创业公司。说来网络硬盘也是一个从上世纪 末就开始存在的服务，只是近年来由于云计算等概念的风靡、Web 应用与移动互联网的成熟，让网盘的意义也产生了极大的变化。为 什么会有 115 网盘这个项目？赖霖枫对网盘服务是如何理解的？ 51CTO 有幸邀请到赖霖枫本人来为大家答疑。 004 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 人物 People 004 件实现了跨平台客户端内核功能的提供，极大降低了各类端应用的开 发成本。 后台服务端由各类 API、服务端应用组件构成以及统一消息处理 平台构成。WEB API 构筑了 PAAS 平台，为更多个人爱好者和站长 提供应用插件的开发与部署。服务端应用组件有业务类的诸如图片、 文本处理相关组件，也包含底层技术支撑类的如 P2SP 应用组件、分 布式日志组件、数据挖掘组件等。而统一消息处理平台日以继夜的处 理着各类后台消息队列，为支撑海量数据的用户体验默默无闻的工作 着。这些接口以 SOAP 或 RESTful 的形式对内外提供服务。更多 服务端应用组件采取与客户端通讯的方式处理，客户端以 COM 形态 出现。服务端应用大多采用 Linux C/C++ 开发。为此，115 打造 了一个封装好更多底层通讯机制的优化的服务器端应用开发框架，即 Framework，实现快速服务器端应用组件的开发，大大缩短了应用组 件的上线周期，实现了传统软件公司开发 1/5 的开发成本快速构筑服 务端应用。 115 形成了若干领域的技术攻坚和持续优化队伍，如 P2SP 应用 组件组，有专业团队和天才级的优秀工程师持续聚焦于 P4P 技术研 究、BT、电驴的 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 支持与优化，以及非完整资源支持等技术点，以为 用户提供最佳体验为核心。此外，同步组件优化组以及分布式存储组 结关注各自场景的优化提升。存储层设计以分布式对象存储为核心， 支撑各类场景的冷热数据需求，在数据压缩、内容分发与路由，重复数 据删除等方面具有一定的技术积累，对 PB 级海量数据存储与高吞吐、 高容错的同时，实现了多数据中心云容灾架构。 51CTO ：安全性方面有哪些措施？我们如何保护用户的隐私？ 赖霖枫 ：安全不仅仅是技术范畴，更是管理体系的实践。 （我们的）安全管理体系更多参考了 ISO27001 以及 ITIL V2/V3 等对于基础设施运维层面的管理，实现了严谨内控管理的同时，强调 SLA 体系的规范与达成……另一方面，115 运营团队在实施安全管 理体系中，全天候为客户（提供）安全隐患服务，后台的日志系统提供 跟踪、 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 、监控管理机制，全程记录后台管理帐户的所有操作，保障 用户的数据不被盗用 ；115 近期还将会推出手机绑定 115 帐号功能， 支持通过手机找回密码，手机验证码登录等更高级别的账户安全保护 机制。 在安全技术方面，我们做到每一份数据都在多个数据中心、多个机 柜拥有多重备份。在隐私保护方面，用户上传的数据都是经过多重加 密，特别是考虑到业界关于 MD5 加密破解问题，115 采用高强度加 密算法进行数据传输加密和数据库存储数据加密。而 115 安全体系 的快速反馈 流程 快递问题件怎么处理流程河南自建厂房流程下载关于规范招聘需求审批流程制作流程表下载邮件下载流程设计 则在业界第一时间内发送安全友情提示邮件，全力保 障用户隐私。115 采取分布式存储，即采用数据分块的方式，即使是 115 内部网络管理人员也无法查看用户存储的数据，而通用非对称机 密机制，数据的完整呈现只有在用户端才可以完整展现。 51CTO ：能否大致透露一下现在你们的用户数量到达什么级别 了？ 赖霖枫 ：115 网盘从成立至今一直没有做太多商业推广，仅凭用户 口碑宣传和分享邀请等方式，到今年 2 月份已经积累了 3000 万注册 用户。 原文 ：http://os.51cto.com/art/201203/321098.htm 005 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 交流 Interact 005 SSL正在保护我的网站……等等，你真的确定吗？ SSL 与 TLS，通常被统称为 SSL，广泛分布在网络世界的各个角 落，用以验证某个站点的实际内容到底是与其表述一致、抑或是由钓 鱼者及其它攻击者为了窃取机密数据而打造的一个虚假外壳。SSL 还同时还为我们提供了一套加密基础设施，这样共享数据的安全才有 保证。 “即使我们现在认定 SSL 自身存在严重缺陷并且已经濒临崩溃， 但不可否认它可能仍然是未来 10 年内我们所能依赖的最佳防御机 制 ；如果大家从今天开始努力，也许 10 年之后会有理想的替代品诞 生，”Trustwave 公司身份及验证管理业务副总裁 Brian Trzupek 表示。当下以 SSL 为基础的最新技术 TLS 1.2 已经解决了已知的所 有问题。至于其它漏洞，Trzupek 认为“完全是由 SSL 的不当部署 及使用所引发。” 诚然，SSL 的信任生态系统并不完美，但网站经营者们完全可以采 取一些步骤对其部署进行优化，以尽量避免可能危及公司数据及令客 户承担风险的失误。以下是四项步骤的具体内容 ： 使用最新版本的协议及密码套件 要得到充分的保护，网站必须采用最新版本的 SSL 协议及密码套 件，而且其服务器也需要得到正确配置。 “尽量选择规模最大、结构最复杂的加密密钥，它们能够有效地保护 我们身边需要保护的设备。”在理想状况下，企业应该使用 256 位甚 至强度更大的加密机制。 经过调查，Qualys 公司发现在使用 SSL 的网站中，SSL 普遍没有 被正确部署在应用层中。即使是那些对 SSL 进行了良好配置的网站， 也仅仅将着眼点放在协议层上。而对于 Web 应用程序与网站，则往 往“随意部署 SSL 了事。 举例来说，许多 Web 应用程序会在加密身份验证尚不完善的情况 下将产品交付用户使用。“人们常常以纯文本这种极不科学的形式输 入用户名与密码，而这对攻击者们而言无疑是绝好的机会。” 另一种常见的配置错误是未对所部署的会话 cookie 做出充分保 护，最终使攻击者很容易访问到这些敏感内容。Cookie 内部必须具 备“安全的”编码构造，以确保其免受恶意人士的窥探。 妥善管理加密密钥 加密机制总会给企业带来行政层面上的负担，其中最大的麻烦就是 管理用于信息在网站及用户之间流通时加密及解密所必需的公共及 私有密钥。终端用户利用公共密钥对传输至网站服务器的数据流进 行加密，而网站则采用一套私有密钥对信息解密，并在用户的浏览器 文 /Matt Prigge 编译 / 核子可乐 006 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 交流 Interact 006 端显示出他们希望看到的内容。 值得一提的是，私有密钥必须远离攻击者及机构内部的恶意人士。 任何打算访问私有密钥的人必须首先获得与之相匹配的授权认证 ；而 该认证则由第三方认证授权机构（简称 CA）进行核对，以了解来访网 站是否合法。因此，攻击者往往以盗窃手段获取私有密钥以及与之对 应的授权认证，这样他们就能将自己的假冒网站以合法的面貌摆上台 面，进而令访问者将其误认作真正的站点并最终导致个人信息泄露。 但是对私有密钥的保护往往令网站管理更加困难。SSL Web 服 务器需要能够在 IT 管理员完全不介入的情况下直接访问私有密钥， 而站点运营方则更希望走捷径，即尽量削弱密钥的安全保护机制，这 样终端用户才能更加顺畅地调用网络内容。 在大多数企业中，私有密钥都以未加密的形式保存在 Web 服务器 中，也就是说攻击者完全可以在不具备密码、智能卡或者其它需要以 密码登录的设备时轻松获取这些关键信息。 保护公共及私有密钥最显而易见、同时也是最有效的方法之一，就 是永远不要将它们保存在 Web 服务器中。作为安保机制的核心，私 有密钥更是应该加以妥善保管。同样，也不能将私有密钥保存在 FTP 服务器上，或是出于任何理由将其通过邮件方式发送给他人。 解决方案其实并不复杂，只要使用一款密钥管理工具，将公共及私 有密钥实施隔离，再确保 SSL 系统管理员无法接触到私有密钥即可。 网站管理员不应该同时扮演密钥管理员的角色。 保管好授权证书 除了不尽人意的加密密钥管理工作，SSL 网站运营者们往往对授 权证书本身的保护也很不到位。在拥有企业内部网络、大型电子商务 网站或者其它包含敏感数据站点的机构中，授权证书的数量可能多达 成千上万。在处理如此海量的授权证书时，企业往往会将其分散至各 服务器及网站管理者处，让他们各自负责。这种做法无疑会迅速导致 混乱及安全威胁，大型零售商及其它企业甚至常常不清楚自己手头到 底在使用多少套授权证书。 分布式证书管理领域的一大关键性问题在于，没有某个人或团队 专职跟踪审查证书的有效日期。也就是说，证书往往在到期之后企业 中仍然无人留意，如此一来客户或其它用户在访问时就会收到提示信 息，宣称证书可能存在问题。更严重的情况下，我们甚至可能因此而 无法访问需要的信息。 除了没有专人跟踪证书动态，许多企业还忽略了制定或是强制执行 证书的采购流程及政策。程序员们往往会在匆忙间随便打开某个 CA 机构的网站并直接进行购买，而没有考虑该 CA 机构是否在企业自身 的采购名单当中。事实上，从口碑不好的 CA 机构处随便弄来的授权 证书，在安全性方面根本无法与信誉良好的 CA 机构所提供的严格标 准相提并论。 要对证书管理流程做到彻底掌握，不妨考虑在企业内部引入自动化 跟踪流程。这类工具会对现有证书进行扫描并设置出对应的自动化 系统，保证在证书到期之前做出正确处理。只要这套体系落实到位， 大家只需利用证书管理平台将原本分散在诸多商务部门及服务器管 理者手中的证书进行集中，就可以通过一位专门的证书管理员实施集 中式管理 ；这样做的同时，企业所制定的证书采购政策也自然得到了 保障。 007 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 交流 Interact 007 避免混合型内容 经过对超过 25 万个 SSL 站点的调查，Qualys 公司发现超过五分 之一的受访对象在网站中部署了混合型内容。 混合型内容是指，当企业在网站的某个页面中使用 SSL 时，却同时 在该页面中提供不受 SSL 保护的内容。这种做法会留下易被利用的 安全漏洞。攻击者们能够将未被加密的内容拦截下来，进而按自己的 意愿对其进行修改。如果网站未经加密的部分能够运行脚本，攻击者 将有机会通过 DNS 感染等方式将网站流量引导至自己的站点处，这 无疑是一种相当危险的破坏手段。 混合型内容在扩展验证 SSL 证书（EV SSL）方面带来的问题尤为 严重。EV SSL 证书比目前使用较为广泛的域验证 SSL 证书更进一 步，后者能够利用最为简洁的手段判断出用户是否有权访问处于 SSL 证书保护之下的域。EV SSL 证书部署成本更高，并要求网站拥有者 为其打造一套扩展化装置以完善访问者的身份验证流程。使用 EV SSL 证书的网站会在浏览器的地址栏中显示出绿色提示条，以通知用 户该网站处于 EV SSL 的保护下。定期域验证 SSL 则在地址栏中以 挂锁图标表示。 如果大家在网站中引入 EV 证书机制，并将 JavaScript 资源也纳 入 SSL 的保护当中，那么页面在浏览器上的显示效果将远差于普通 SSL。 时刻保持警觉大概是解决混合型内容问题的惟一办法。企业必须 利用恰当的广泛测试与质量保障流程才能确保网站及应用程序开发 工作中不会掺杂混合型内容。 最后，让我们一起看看 10 大 SSL 常见错误 ： 1. 服务器、尤其是流量巨大的网站服务器缺乏补丁更新机制。 2. 敏感脚本及表格被托管于不安全的页面中。登入页面等关键性 内容一旦脱离了 SSL 的保护后果将不堪设想，因为用户名与密码等 信息都包含在其中。 3. 使用不具备最新加密技术的落后密码套件。 4. 对私有密钥的处理不够安全，包括系统管理之间通过邮件发送 密钥等不良习惯。 5. 在同一个 Web 页面中同时提供安全及不安全内容，这使得攻击 者很容易对不安全内容实施注入攻击。 6. 当心已经过期或无效的 SSL 证书，当用户反复看到失效信息之 后，往往会将此视为正常现象。 7. 在电子商务网站中使用域验证证书，在这类涉及资金交易的关 键性部分最好使用安全性更高的扩展验证证书。 8. 为 www.example.com 提供证书，却忽略了 example.com 这 样的形式。用户往往喜欢通过简短的地址进行登录。 9. 没有为 cookie 内容提供保护措施。 10. 将密钥与证书复制到多台服务器中，没有分别对每套副本进行 本地追踪，而且忽略了这些验证机制的有效期。 原文 ：Web Encryption That Works - Dark Reading 译文 ：http://os.51cto.com/art/201203/320976.htm 008 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 八卦 News 008 Apache 2.4发布 淘宝Metamorphosis开源 Apache HTTP Server 2.4 发布，大幅改进性能，支持更大流量、 更好地支持云计算、利用更少的内存处理更多的并发。 http://os.51cto.com/art/201202/319669.htm Ubuntu 10.04 发布第四个维护版本，10.04 相关更新和安全补 丁将持续提供到 2013 年 4 月。 http://os.51cto.com/art/201202/318090.htm 红帽发布企业虚拟化 3.0，评价其“实现了 Linux 和 Windows 负 载下新型企业虚拟化管理特性、性能和扩展能力方面的平衡，而且成 本远低于专有替代方案。” http://os.51cto.com/art/201202/317778.htm NASA 退役最后一台大型机 IBM Z9。最后一台大型机位于马歇 尔太空飞行中心，曾被用于计算和解决与太空飞行有关的复杂数值计 算问题，退役前大约有普通冰箱大小。 http://os.51cto.com/art/201202/317782.htm Canonical 宣 布 将 不 再 支 持 基 于 KDE 桌 面 的 Ubuntu 分 支， 但社区开发者承诺将一如既往的提供高水平的支持，称即将发布的 Kubuntu 12.04 的支持时间为五年。 http://os.51cto.com/art/201203/321352.htm ——八卦，新闻与数字 2012.02 - 2012.03 截至 2011 年年末，Zynga 公司已经将接近 80% 的日常活跃用 户交付自有基础设施进行托管 ；而就在 2011 年年初，同样比例的用 户群体还处于 Amazon 公共云之下。 http://os.51cto.com/art/201202/318126.htm 红帽企业级 Linux 5.8 正式版发布，支持电源管理 QoS，提供设备 级别的自动电源管理策略，新的 iotop 支持监控进程级别的 I/O 资 源使用情况，例如存储设备，用于解决一些潜在的性能问题。 http://os.51cto.com/art/201202/319280.htm 淘宝 Metamorphosis 开源，思路起源于 LinkedIn 的 Kafka，但 并不是 Kafka 的一个 Copy。具有消息存储顺序写、吞吐量大和支持 本地和 XA 事务等特性，适用于大吞吐量、顺序消息、广播和日志数据 传输等场景。 http://os.51cto.com/art/201203/322418.htm Wine 1.4 最终稳定版发布，16000 多个独立变更，支持新的 DIB 设备无关图形驱动 ( 更快的 2D 渲染速度 )、重新设计的音频堆栈、完 整支持双向造字、增加支持 XInput2。 http://os.51cto.com/art/201203/322806.htm 009 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 专题 Special 009 大数据存储系统初探 编者按 ： 大数据，面临的最大问题不仅是我们要如何储存大量的、不同格式 的数据，更具有挑战性的是如何在这庞大的数据中快速的检索，形成 最终用户想要的结果。 以往关注大数据的，比较多的是有着海量用户的互联网企业，如 Google、Yahoo、Facebook、百度，电商领域的 Amazon、Ebay、 淘宝等，还有 Youtube、Vimeo、优酷土豆这样的视频网站 ；而互联 网迅速发展的当下，很多规模不大或员工不多的“小”企业也会面临 大数据处理的需求，比如处理地理数据或 3D 模型的企业，Pinterest 这样的图片流网站等。当然，除了需求方以外，技术输出型的 IBM，存 储方向的 EMC 等企业，也都十分关注大数据这一方向。 面对这样的需求，Hadoop 可以说是当下最被推崇的解决方案，而 其技术也的确是目前比较成熟的，被普遍称之为“会跳舞的大象”。在 技术实力厚实的网站，则往往有自己的解决方法。下面分享的内容主 要围绕 Hadoop 和淘宝的方案，以供各位参考。 010 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 专题 Special 010 HAProxy+Hive构建高可用数据挖掘集群 Hive 是 facebook 开源的一个非常伟大的工具，可以将 hadoop 中的数据用 sql 方式进行查询，比自己写 map/reduce 程序要方便 很多。但是在实际使用中发现 hive 其实不够稳定，极少数情况会出 现端口不响应或者进程丢失的问题，所以考虑将 hive 做成负载均衡 的方式。或者更严格的说，叫做失效备份，避免出现某台个别的服务 器连接数过大造成的端口不响应或者服务器故障造成无法查询。 前提是有 2-3 台服务器作为 hive server，一台放置 HAProxy。 一、安装配置 HAProxy # w g e t h t t p : / / h a p r o x y . 1 w t . e u / d o w n l o a d / 1 . 4 / s r c / haproxy-1.4.20.tar.gz#tar zxf haproxy-1.4.20.tar.gz #mv haproxy-1.4.20 /opt/modules/haproxy #cd /opt/modules/haproxy #make TARGET=linux26 这样就编译完成了。 然后来配置 HAProxy 为四层代理，仅作为端口转发器使用。 global daemon nbproc 1 pidfile /var/run/haproxy.pid ulimit-n 65535 #################### defaults mode tcp #mode { tcp|http|health }，tcp 表示 4 层，http 表示 7 层 ( 对我们没用 )，health 仅作为健康检 查使用 retries 2 # 尝试 2 次失败则从集群摘除 option redispatch # 如果失效则强制转换其他服务器 option abortonclose # 连接数过大自动关闭 maxconn 1024 # 最大连接数 timeout connect 1d # 连接超时时间，重要，hive 查询 数据能返回结果的保证 timeout client 1d # 同上 timeout server 1d # 同上 timeout check 2000 # 健康检查时间 log 127.0.0.1 local0 err #[err warning info debug] ################ listen admin_stats # 定义管理界面 bind 0.0.0.0:1090 # 管理界面访问 IP 和端口 mode http # 管理界面所使用的协议 maxconn 10 # 最大连接数 stats refresh 30s #30 秒自动刷新 文 /Slaytanic 011 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 专题 Special 011 stats uri / # 访问 url stats realm Hive\ Haproxy # 验证窗口提示 stats auth admin:123456 #401 验证用户名密码 ########hive1################# listen hive #hive 后端定义 bind 0.0.0.0:10000 #ha 作为 proxy 所绑定的 IP 和端口 mode tcp # 以 4 层方式代理，重要 balance leastconn # 调度算法 'leastconn' 最少连 接数分配，或者 'roundrobin'，轮询分配 maxconn 1024 # 最大连接数 server hive_215 192.168.1.49:10000 check inter 1000 rise 1 fall 2 # 释义 ：server 主机代名 ( 你自己能看懂就行 )，IP: 端口 每 1000 毫秒检查一次。 server hive_216 192.168.1.50:10000 check inter 1000 rise 1 fall 2 # 同上，另外一台服务器。 用 haproxy -f haproxy.conf 启动。 比较重要的其实是 timeout 的前三个选项的时间定义，因为 hive 运算请求时间会比较长，通常都会超过一个 tcp 包正常的 session 响应时间。所以，hive 需要一个长连接来等待数据返回，在 TCP 里 面应该是 TIME_WAIT 我记得。如果设置太短了，SQL 可以提交成功， 但是你将不会获得任何返回值。因为被提交的 session 已经关闭了。 所以普通的 tcp 代理转发并不适合 hive 的应用。这点在做定时任务 的时候尤其重要，你可能会提交一个任务，但是不会获得任何返回，又 查不出任何结果，就很头疼。作为 hive 的任务开发者，不了解 tcp 协 议的工作情况，作为运维又不了解 hive，所以如果这里出了错误，会很 难发现。我写的 1d 是 1 天的意思，正常的话，当 hive 执行完毕，会 自己发送关闭 TCP 的指令。这点倒是不用太担心累计连接数超过限 定。 1d 标志 1 天，类似的还有 1h 表示 1 小时，1s 表示 1 秒，1ms 表 示 1ms。 另外配合我之前写过的 python daemon 程序，稍加修改，用来监 控 hive 的 server 进程，就基本可保证 hive server 集群的高可用了。 目前这个高可用方案在公司内部的 phpHiveAdmin 中已经可以 使用了，查询和结果获取正常无误，thrift 连接 IP 和端口只要指向到 Haproxy 的 IP 和端口就可以了。 二、hive 服务器端监控程序 python 只要检测到 hive 进程没有或者端口消失，均重新启动 hive #!/usr/bin/env python （代码略） 给可执行权限，然后用 ./daemon.py start 启动，每两秒检测一次 进程和端口。 原文 ：http://slaytanic.blog.51cto.com/2057708/803626 推荐阅读 ： XFS ：大数据环境下 Linux 文件系统的未来？ 除了 Hadoop ：带你了解更多大数据解决方案 012 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 专题 Special 012 HDFS小文件问题及解决方案 1、 概述 小文件是指文件 size 小于 HDFS 上 block 大小的文件。这样的 文件会给 hadoop 的扩展性和性能带来严重问题。首先，在 HDFS 中，任何 block，文件或者目录在内存中均以对象的形式存储，每个 对象约占 150byte，如果有 1000 0000 个小文件，每个文件占用 一个 block，则 namenode 大约需要 2G 空间。如果存储 1 亿个文 件，则 namenode 需 要 20G 空 间（见 参 考 资 料 [1][4][5]）。 这 样 namenode 内存容量严重制约了集群的扩展。 其次，访问大量小文 件速度远远小于访问几个大文件。HDFS 最初是为流式访问大文件 开发的，如果访问大量小文件，需要不断的从一个 datanode 跳到另 一个 datanode，严重影响性能。最后，处理大量小文件速度远远小 于处理同等大小的大文件的速度。每一个小文件要占用一个 slot，而 task 启动将耗费大量时间甚至大部分时间都耗费在启动 task 和释 放 task 上。 本 文 首 先 介 绍 了 hadoop 自 带 的 解 决 小 文 件 问 题 的 方 案（以 工 具 的 形 式 提 供），包 括 Hadoop Archive，Sequence file 和 CombineFileInputFormat ；然 后 介 绍 了 两 篇 从 系 统 层 面 解 决 HDFS 小文件的论文，一篇是中科院计算所 2009 年发表的，用以解 决 HDFS 上存储地理信息小文件的方案 ；另一篇是 IBM 于 2009 年 发表的，用以解决 HDFS 上存储 ppt 小文件的方案。 2、 HDFS 文件读写流程 在正式介绍 HDFS 小文件存储方案之前，我们先介绍一下当前 HDFS 上文件存取的基本流程。 (1) 读文件流程 1）client 端发送读文件请求给 namenode，如果文件不存在，返 回错误信息，否则，将该文件对应的 block 及其所在 datanode 位置 发送给 client 2） client 收到文件位置信息后，与不同 datanode 建立 socket 连接并行获取数据。 (2) 写文件流程 1） client 端 发 送 写 文 件 请 求，namenode 检 查 文 件 是 否 存 在，如果已存在，直接返回错误信息，否则，发送给 client 一些可用 namenode 节点 2） client 将文件分块，并行存储到不同节点上 datanode 上，发 文 /Dong 013 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 专题 Special 013 送完成后，client 同时发送信息给 namenode 和 datanode 3） namenode 收 到 的 client 信 息 后，发 送 确 信 信 息 给 datanode 4） datanode 同时收到 namenode 和 datanode 的确认信息 后，提交写操作。 3、 Hadoop 自带的解决方案 对于小文件问题，Hadoop 本身也提供了几个解决方案，分别为 ： Hadoop Archive，Sequence file 和 CombineFileInputFormat。 （1） Hadoop Archive Hadoop Archive 或者 HAR，是一个高效地将小文件放入 HDFS 块中的文件存档工具，它能够将多个小文件打包成一个 HAR 文件，这 样在减少 namenode 内存使用的同时，仍然允许对文件进行透明的 访问。 对某个目录 /foo/bar 下的所有小文件存档成 /outputdir/ zoo. har ： hadoop archive -archiveName zoo.har -p /foo/bar / outputdir 当然，也可以指定 HAR 的大小 ( 使用 -Dhar.block.size)。 HAR 是在 Hadoop file system 之上的一个文件系统，因此所有 fs shell 命令对 HAR 文件均可用，只不过是文件路径格式不一样， HAR 的访问路径可以是以下两种格式 ： har://scheme-hostname:port/archivepath/fileinarchive har:///archivepath/fileinarchive( 本节点 ) 可以这样查看 HAR 文件存档中的文件 ： hadoop dfs -ls har:///user/zoo/foo.har 输出 ： har:///user/zoo/foo.har/hadoop/dir1 har:///user/zoo/foo.har/hadoop/dir2 使用 HAR 时需要两点，第一，对小文件进行存档后，原文件并不会 自动被删除，需要用户自己删除 ；第二，创建 HAR 文件的过程实际上 是在运行一个 mapreduce 作业，因而需要有一个 hadoop 集群运 行此命令。 此外，HAR 还有一些缺陷 ：第一，一旦创建，Archives 便不可改变。 要增加或移除里面的文件，必须重新创建归档文件。第二，要归档的 文件名中不能有空格，否则会抛出异常，可以将空格用其他符号替换 ( 使用 -Dhar.space.replacement.enable=true 和 -Dhar.space. replacement 参数 )。 （2） Sequence file sequence file 由一系列的二进制 key/value 组成，如果为 key 小文件名，value 为文件内容，则可以将大批小文件合并成一个大文 件。 Hadoop-0.21.0 中 提 供 了 SequenceFile，包 括 Writer， 014 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 专题 Special 014 Reader 和 SequenceFileSorter 类进行写，读和排序操作。如果 hadoop 版本低于 0.21.0 的版本，实现方法可参见 [3]。 （3）CombineFileInputFormat CombineFileInputFormat 是一种新的 inputformat，用于将多 个文件合并成一个单独的 split，另外，它会考虑数据的存储位置。 4、 小文件问题解决方案 上一节中提到的方案均需要用户自己编写程序，每隔一段时间对小 文件进行 merge 以便减少小文件数量。那么能不能直接将小文件处 理模块嵌到 HDFS 中，以便自动识别用户上传的小文件，然后自动对 它们进行 merge 呢？ 本节介绍了两篇论文针试图在系统层面解决 HDFS 小文件问题。 这两篇论文对不同的应用提出了解决方案，实际上思路类似 ：在原有 HDFS 基础上添加一个小文件处理模块，当一个文件到达时，判断该 文件是否属于小文件，如果是，则交给小文件处理模块处理，否则，交 给通用文件处理模块处理。小文件处理模块的设计思想是，先将很多 小文件合并成一个大文件，然后为这些小文件建立索引，以便进行快 速存取和访问。 论文 [4] 针对 WebGIS 系统的特点提出了解决 HDFS 小文件存储 的方案。WebGIS 是结合 web 和地理信息系统 (GIS) 而诞生的一种 新系统。在 WebGIS 中，为了使浏览器和服务器之间传输的数据量 尽可能地少，数据通常被切分成 KB 的小文件存储在分布式文件系统 中。论文结合 WebGIS 中数据相关性特征，将保存相邻地理位置信 息的小文件合并成一个大的文件，并为这些小文件建立索引以便对小 文件进行存取。 该论文将 size 小于 16MB 的文件当做小文件，需将它们合并成 64MB( 默认的 block size)，并建立索引，索引结构和文件存储方式 见上图。索引方式是一般的定长 hash 索引。 论文 [5] 针对 Bluesky 系统 (http://www.bluesky.cn/) 的特点 提出了解决 HDFS 小文件存储的方案。Bluesky 是中国电子教学共 享系统，里面的 ppt 文件和视频均存放在 HDFS 上。该系统的每个 课件由一个 ppt 文件和几张该 ppt 文件的预览快照组成。当用户请 求某页 ppt 时，其他相关的 ppt 可能在接下来的时间内也会被查看， 因而文件的访问具有相关性和本地性。本文主要有 2 个 idea ：第一， 将属于同一个课件的文件合并成一个大文件，以提高小文件存储效 率。第二，提出了一种 two-level prefetching 机制以提高小文件读 取效率，即索引文件预取和数据文件预取。索引文件预取是指当用户 访问某个文件时，该文件所在的 block 对应的索引文件被加载到内存 中，这样，用户访问这些文件时不必再与 namenode 交互了。数据文 件预取是指用户访问某个文件时，将该文件所在课件中的所有文件加 015 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 专题 Special 015 载到内存中，这样，如果用户继续访问其他文件，速度会明显提高。 下图展示的是在 BlueSky 中上传文件的过程 ： 下图展示的是在 BlueSky 中阅览文件的过程 ： 5、 总结 Hadoop 目前还没有一个系统级的通用的解决 HDFS 小文件问 题的方案。它自带的三种方案，包括 Hadoop Archive，Sequence file 和 CombineFileInputFormat，需要用户根据自己的需要编写 程序解决小文件问题 ；而第四节提到的论文均是针对特殊应用提出的 解决方案，没有形成一个比较通用的技术方案。 6、 参考 资料 新概念英语资料下载李居明饿命改运学pdf成本会计期末资料社会工作导论资料工程结算所需资料清单 （1）有关小文件问题的表述 ： http://www.cloudera.com/blog/2009/02/the-small-files- problem/ （2）Hadoop Sequence file ： http://hadoop.apache.org/common/docs/current/api/ org/apache/hadoop/io/SequenceFile.html （3）英文书籍《Hadoop ：The Definitive Guide》，第七章 190 页 （4）Xuhui Liu, Jizhong Han, Yunqin Zhong, Chengde Han, Xubin He: Implementing WebGIS on Hadoop: A case study of improving small file I/O performance on HDFS. CLUSTER 2009: 1-8 （5）Bo Dong, Jie Qiu, Qinghua Zheng, Xiao Zhong, Jingwei Li, Ying Li. A Novel Approach to Improving the Efficiency of Storing and Accessing Small Fi les on Hadoop: A Case Study by PowerPoint Files. In Proceedings of IEEE SCC’2010. pp.65~72 原 文 ：http://dongxicheng.org/mapreduce/hdfs-small- files-solution/ 016 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 专题 Special 016 淘宝Fourinone介绍及与Hadoop的性能PK FourInOne（中文名字“四不像”）是一个四合一分布式计算框架， 在写这个框架之前，我对分布式计算进行了长时间的思考，也看了老 外写的其他开源框架 , 当我们把复杂的 hadoop 当作一门学科学习 时，似乎忘记了我们想解决问题的初衷 ：我们仅仅是想写个程序把几 台甚至更多的机器一起用起来计算，把更多的 cpu 和内存利用上，来 解决我们数量大和计算复杂的问题，当然这个过程中要考虑到分布式 的协同和故障处理。如果仅仅是为了实现这个简单的初衷，为什么一 切会那么复杂，我觉的自己可以写一个更简单的东西，它不需要过度 设计，只需要看上去更酷一点，更小巧一点，功能更强一点。于是我将 自己对分布式的理解融入到这个框架中，考虑到底层实现技术的相似 性，我将 Hadoop,Zookeeper,MQ, 分布式缓存四大主要的分布式 计算功能合为一个框架内，对复杂的分布式计算应用进行了大量简化 和归纳。 文 /Stone.Peng fourinone-1.11.09 hadoop-0.21.0 体积 82K 71M 依赖关系 就一个 jar, 没有依赖 约 12 项 jar 包依赖 配置 就一个配置文件 较多配置文件和复杂属性 集群搭建 简单，每台机器放一个 jar 和配置文件 复杂，需要 linux 操作基础和 ssh 等复杂配置，还需要较多配置文 件配置 计算模式 提供两种计算模式 ：包工头和工人直接交互方式，包工 头和工人通过消息中枢方式交互，后者不需要工人节点 可直接访问 计算更多倾向于文件数据的并行读取，而非计算过程的设计。 JobTracke 跟 TaskTracker 直接交互， 查询 NameNode 后， TaskTracker 直接从 Datanode 获取数据。 并行模式 N*N，支持单机并行，也支持多机并行，多机多实例并行 1*N，不支持单机并行，只支持多机单实例并行 内存方式 支持内存方式设计和开发应用，并内置完整的分布式缓 存功能 以 hdfs 文件方式进行数据处理，内存方式计算支持很弱 文件方式 自带文件适配器处理 io Hdfs 处理文件 io 计算数据要求 任意数据格式和任意数据来源，包括来自数据库，分布 式文件，分布式缓存等 Hdfs 内的文件数据，多倾向于带换行符的数据 017 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 杂志订阅 : http://os.51cto.com/art/201011/233915.htm 51CTO 系统频道 ：http://os.51cto.com 专题 Special 017 调度角色 包工头，可以有多个，支持链式处理，也支持大包工头对 小包工头的调度 JobTracke，通常与 NameNode 一起 任务执行角色 农民工，框架支持设计多种类型的工人用于拆分或者合 并任务 TaskTracker，通常与 Datanode 一起 中间结果数据保存 手工仓库，或者其他任意数据库存储设备 Hdfs 中间结果文件 拆分策略 自由设计，框架提供链式处理对于大的业务场景进行环 节拆分数据的存储和计算拆分根据业务场景自定义 以 64m 为拆分进行存储，以行为拆分进行计算 ；实现 map 接口， 按行处理数据进行计算 合并策略 自由设计，框架提供农民工节点之间的合并接口，可以 互相交互设计合并策略，也可以通过包工头进行合并 TaskTracker 不透明，较少提供程序控制，合并策略设计复杂 ；实 现 reduce 接口进行中间数据合并逻辑实现 内存耗用 无需要制定 JVM 内存，按默认即可，