标签：HDFS

共 16 篇相关文章

IT 累计浏览 2,612

UMStor Hadapter：大数据与对象存储的柳暗花明

这篇讲的是大数据存储里一个经典矛盾的解决方案。作者从武侠江湖的比喻切入，指出数据湖架构也分“计算存储融合”（以HDFS为代表）与“计算存储分离”（以S3A+Ceph对象存储为代表）两大派系。前者有数据本地性优势，但NameNode易成瓶颈且弹性差；后者扩展灵活，但所有请求必须经过RGW网关，多了一跳，影响性能且不支持追加上传。文章的核心亮点在于提出了一条“柳暗花明”的路径。作者团队受NFS-Ganesha启发，利用Ceph提供的librgw函数库，绕过了RGW网关这一中间环节。据此开发的Hadapter插件，能让Hadoop客户端直接通过librados与OSD通信。这相当于在保留对象存储管理优势的同时，借鉴了HDFS直接交互的思路，在IO路径上少了一跳，理论上能获得更好的读写性能，并补齐了社区版S3A在追加上传上的短板。摘要最后可以简要提及Hadapter的部署便利性（一个jar包）和其作为Hadoop存储插件的定位，让读者对这个方案的具体形态有个直观了解。整篇文章的脉络是从问题拆解到方案融合，对架构选型有切实参考价值。

IT 累计浏览 1,599

解决HDFS磁盘扫描导致死亡结点的问题

这篇讲的是作者在升级Hadoop至2.0后，处理的一个棘手的生产故障：集群中磁盘数量多的DataNode会周期性地变为“死亡结点”，虽未立刻影响业务，但一次双副本DataNode同时死亡导致了数据丢失。问题排查的关键突破口在于“6小时”这个固定间隔。作者将它锁定为DataNode的周期性磁盘扫描任务，并通过jstack抓取堆栈发现了隐蔽的根因：在扫描过程中，数据块对比的步骤需要对核心的DataSet对象加锁，而该步骤中一个看似无害的`File.length()`方法调用，在底层会执行磁盘IO操作。在磁盘压力较大时，这个操作会耗时很长，导致DataSet锁被长时间持有，进而阻塞了心跳线程和所有数据传输线程，造成DataNode被NameNode误判为死亡。解决方法巧妙且高效：将引发IO操作的`getlength`提前到第二步异步的磁盘扫描任务中执行，从而将持锁时间从几十分钟大幅缩短至2秒左右。文章完整还原了从现象观察、假设推翻到利用工具（jstack）锁定真凶的全过程，对理解分布式系统中锁竞争、IO影响以及复杂故障排查思路很有启发。最终，他们将修复补丁提交至了Apache社区（HDFS-5341）。

IT 累计浏览 2,984

Impala：新一代开源大数据分析引擎

这篇讲的是Cloudera推出的Impala，一个旨在解决Hive查询速度瓶颈的开源大数据分析引擎。文章详细拆解了Impala如何借鉴Google Dremel的思想，采用列式存储（Parquet格式）和多层查询树架构，摆脱MapReduce的批处理束缚，从而在交互式查询上实现数量级的性能提升。作者将Impala与同期的Shark、Apache Drill进行了横向对比。Impala的优势在于相对成熟的工程实现和快速的查询响应，但其容错机制较弱，且开源生态初期主要绑定Cloudera自家发行版。相比之下，基于Spark的Shark在内存计算和容错性上更有优势，而Apache Drill则更具平台开放性，尽管当时开发进度稍慢。文章通过性能对比图表指出，尽管Impala和Shark都远超Hive，但与Amazon Redshift等商业MPP数据库仍有差距。文章的最终观点是，大数据分析的未来不在于某一技术的独胜，而在于Hadoop生态（如YARN）将兼容并包，让不同引擎各司其职——Impala这类系统擅长秒级交互查询，而MapReduce则继续处理大规模批处理任务。这场技术竞争正推动大数据分析变得更成熟、易用和普惠。

IT 累计浏览 3,762

Spark随谈——开发指南（译）

这篇指南针对的是Spark 0.5.0版本，它翻译自官方的Spark Programming Guide，并结合了一些作者的补充说明。它不是泛泛的概念介绍，而是从实际编程出发，详细讲解了如何在Spark中编写应用程序。文章清晰地梳理了从初始化SparkContext、操作弹性分布式数据集（RDD），到进行转换（Transformation）和动作（Action）的完整流程。特别提到了RDD的两种创建方式、关键操作如`map`、`reduce`、`filter`以及持久化策略。这些细节对于刚接触Spark、希望快速上手编写的开发者来说，是很好的起点。虽然版本较早，但其阐述的核心编程模型——基于RDD的函数式操作和惰性求值原理——构成了后续Spark SQL、Streaming等模块的基础。对于想了解Spark底层设计哲学或处理历史代码的开发者，这份指南依然具有不错的参考价值。

IT 累计浏览 3,707

一个DBA眼中的HBase

这是一位一线DBA对流行技术的冷静思考。当HBase与NoSQL的光环铺天盖地时，作者从日常运维的视角，剖析了那些光鲜宣传背后的实际挑战。文章没有复述官方特性，而是直指几个核心痛点：比如高并发写入下的性能瓶颈、复杂查询的局限性，以及运维管理的复杂度。作者结合自身经验，点明了在特定业务场景下可能出现的“水土不服”，例如强一致性要求或复杂Join查询时的尴尬。其价值不在于否定技术，而是提供了一份来自“用户现场”的平衡报告。它提醒技术决策者，选型不能只看热度，必须紧扣业务特性与团队运维能力。对于正在评估或已深陷HBase运维的团队来说，这篇来自DBA的真诚复盘，或许能帮你避开一些理想的陷阱。

IT 累计浏览 3,918

分布式计算平台Hadoop 发展现状乱而稳定的解读

这篇讲的是Hadoop这个老牌分布式计算平台，在“乱”象纷呈的技术世界里，如何依然保持“稳定”的生存逻辑。作者从Hadoop十余年的技术演进路径出发，梳理了其生态系统内核心组件（如HDFS、MapReduce、YARN）的迭代如何从“大包大揽”转向“各司其职”。文章重点剖析了当前面临的现实：在Spark、Flink等新兴计算引擎的冲击下，Hadoop的传统批处理优势似乎不再耀眼。但它并未被淘汰，反而在特定领域——比如需要极致稳定性的超大规模离线数据仓库、以及作为云上对象存储之上的计算层——找到了不可替代的位置。作者通过对比不同计算框架的底层设计哲学（数据移动 vs 计算移动），清晰地揭示了Hadoop“稳”的根源在于其成熟的生态和经过验证的可靠性，而“乱”则源于社区版本分支、商业发行版博弈以及开发者注意力的迁移。最终，文章给出的启示是：技术选型不必追逐最新标签。对于追求海量历史数据分析、且对成本与长期维护有严格要求的场景，一个精心维护、与云原生工具结合得当的Hadoop集群，依然是那个沉稳的“压舱石”。这为在技术浪潮中感到迷茫的工程师，提供了一个回归理性与务实的视角。

IT 累计浏览 2,796

关于HBase的一些零碎事

这篇讲的是HBase这个分布式数据库如何从技术幕后走向前台，成为支撑大规模实时应用的关键选型之一。故事的起点是Facebook那个经典的决策：他们选择HBase来构建实时消息系统，以处理每秒数十万条消息、总计超过135亿用户的海量数据洪流。文章的作者没有停留在介绍HBase的基本概念，而是从这个标志性的工业案例出发，勾勒出HBase持续升温背后的技术逻辑。它抓住了HBase作为面向列存储、基于Hadoop生态的分布式数据库，在海量数据随机实时读写场景下不可替代的价值。这意味着，它解决了传统数据库在数据规模和并发能力上难以逾越的瓶颈。更进一步，文章通过Facebook的案例，延伸探讨了HBase在其他需要高可靠、高性能存储的互联网公司中的渗透与应用，展现了其生态的蓬勃发展。对于技术选型者而言，这不仅是一个工具的故事，更反映了数据规模驱动下存储架构演进的一个清晰切面。

IT 累计浏览 2,522

让代码取代你的配置文件吧

这篇讲的是，作者从团队维护复杂微服务配置的痛点出发，提出用代码来“生成”配置文件的实践方案。文章背景是，传统YAML或JSON配置在项目规模增大后，容易出现重复、难以校验和重构的困境。作者团队为此设计了一个轻量级的方案：用Python代码定义配置结构，并封装了环境变量注入、模板渲染和最终输出为标准配置文件的流程。核心思路在于，让配置也像代码一样可以模块化、复用和测试。比如，他们抽象出了基础配置类，不同服务只需继承并覆盖特定部分。文章还展示了如何通过简单的函数调用，就完成数据库连接字符串在不同环境（开发、生产）间的切换，同时保持类型安全。这种“配置即代码”的方法，显著减少了复制粘贴错误，让配置变更可以通过代码审查进行。作者指出，虽然引入了一层构建步骤，但对于配置逻辑复杂的系统，这种可控性的提升是值得的。

IT 累计浏览 2,749

关于HBase的一些零碎事

这篇讲的是Facebook如何用HBase搭建实时消息系统，以及这个案例如何推动了HBase技术的持续升温。文章从Facebook的实际应用出发，揭示了HBase作为基于Hadoop的面向列存储数据库，在应对海量、高并发数据写入时的独特优势。核心点在于HBase的列式结构和分布式架构，使其能够高效处理像消息这类需要快速写入、随机查询的非结构化数据，完美匹配了Facebook消息系统对低延迟和高吞吐量的苛刻要求。作者通过这个知名案例，向读者传递了一个明确的信号：当业务场景涉及超大规模数据且需要实时读写时，HBase是一个值得深入评估的坚实选项，而不仅仅是停留在理论层面的数据库技术。

IT 累计浏览 4,600

使用hadoop进行大规模数据的全局排序

这篇讲的是如何在Hadoop生态中，解决一个看似基础但实则棘手的问题：对PB级别的数据进行全局排序。作者直面MapReduce框架在直接应用`TotalOrderPartitioner`时，容易因采样不准导致数据倾斜、任务卡死的现实痛点。文章没有停留在理论层面，而是从一次真实的性能优化经历出发。作者详细拆解了核心方案：首先通过改进采样策略（例如对样本数据进行哈希抽样而非随机抽样），生成更均匀的分区边界文件；接着，在自定义`Partitioner`中，不仅考虑键值范围，还引入了负载均衡逻辑，确保每个Reducer处理的数据量大致相当；最后，通过预设`io.sort.mb`和`io.sort.factor`等关键参数，在Map端和Reduce端都优化了内存与磁盘的IO吞吐。作者给出了具体的配置细节和调试方法，比如如何通过日志观察各Reducer的实际数据分布，并动态调整分区数。在处理一份约1.2TB的日志数据时，这套优化方案将全局排序的耗时从不可预测缩短至稳定在2.5小时内完成，且各节点负载均衡。这种从问题到细节再到效果的完整叙述，为同样面临海量数据排序挑战的工程师提供了可复现的实践路径。

IT 累计浏览 1,906

一种oracle2hdfs的数据推送思路

这篇讲的是作者在迁移旧应用时，重新翻出了一个自己以前编写的、用于将Oracle数据库数据同步到Hadoop HDFS的程序，并决定将其核心思路分享出来。文章聚焦于一个具体的数据同步场景：如何稳定地将传统关系型数据库（Oracle）中的数据，批量或增量地推送到大数据平台（HDFS）上。作者没有空谈理论，而是基于自己生产环境中的实践，梳理了从数据源读取、可能的数据转换到最终写入HDFS的具体技术路径。分享的重点在于实现的思路和架构考虑，比如如何处理两边数据结构的差异，以及如何保证数据推送的可靠性。对于正在面临类似数据集成需求，尤其是需要将OLTP数据导入数据湖或离线数仓的团队来说，这种直接来自实践的一线经验，提供了比通用文档更具体的参考价值。

IT 累计浏览 4,737

Hadoop超级安装手册

这篇指南源于团队在实践中观察到新手安装Hadoop时频繁遇到的障碍，因此整理出这份覆盖从零到集群的“傻瓜版”手册。文章首先明确了Hadoop运行的前置条件，即确保SSH/SSHD服务正常与JDK安装到位。随后进入核心安装流程：从下载解压源码开始，逐步详解如何配置环境变量（如JAVA_HOME），并重点剖析了`core-site.xml`、`hdfs-site.xml`和`mapred-site.xml`三个关键配置文件的参数设置，例如文件系统地址与副本数。对于单节点部署，指南涵盖了SSH免密配置、格式化NameNode、启动与验证的全过程，并提供了具体的Web UI检查地址。进阶部分则扩展至多节点集群搭建，详细说明了跨主机SSH密钥分发、Masters/Slaves文件配置以及最终如何将配置同步至所有节点。整篇内容条理清晰，将复杂的安装过程拆解为可逐步执行的命令与配置，特别适合需要快速搭建起Hadoop环境进行实践的初学者。

IT 累计浏览 10,502

GFS, HDFS, Blob File System架构对比

这篇讲的是如何在GFS、HDFS与Blob File System（包括TFS、QFS、Haystack）之间做出技术选型。作者从分布式架构的角度出发，梳理了三种主流文件系统的核心差异。文章首先点明，GFS和HDFS是两类基础而强大的分布式文件系统，分别奠定了Google和Hadoop生态的存储基石。随后，作者将焦点转向Blob FS这一类别，解释了它们为解决海量小文件存储（如相册、图片）这一特定问题而生的背景。关键对比在于：GFS/HDFS擅长处理大规模、大文件的批处理场景，强调高吞吐；而TFS、QFS这类Blob FS则通过扁平化结构、元数据分离等设计，优化了海量小对象的低延迟访问与高并发写入。读完这篇，能帮你快速厘清这些系统的设计哲学：当你面对的是日志、数据集等大文件时，传统架构更合适；而要应对海量用户生成的小文件时，Blob FS的针对性优化则是更高效的选择。

IT 累计浏览 2,903

NameNode优化笔记 (一)

这篇讲的是淘宝Hadoop集群在应对业务数据突增时，NameNode面临的特殊挑战与优化思考的开篇。作者从淘宝的实际业务场景出发，指出随着集群规模和作业量的增长，NameNode的性能瓶颈开始凸显。核心背景在于，淘宝的Hadoop数据性质与大型搜索公司存在显著差异：搜索公司处理的数据通常为TB级别以上，而淘宝的数据规模从数十MB到数百GB不等，颗粒度更细。这导致了作业特征的不同，也为NameNode的管理带来了独特的压力。文章首先清晰地描绘了这一问题背景，为后续具体的优化方案和笔记做了扎实的铺垫。

IT 累计浏览 2,266

namenode 内部关键数据结构简介

这篇讲的是HDFS NameNode内部那些支撑起整个HDFS元数据管理的核心数据结构。作者从FsImage与EditLog的协作机制入手，拆解了NameNode如何保证元数据的持久化与高可用，比如详解了SecondaryNameNode并非“第二NameNode”而是用于合并FsImage和EditLog的辅助角色。文章进一步剖析了BlockMap和INode这两者如何将抽象的文件逻辑视图映射到实际的物理块存储上。其中对INode树结构的分析很细致，展示了目录与文件是如何以树状组织在内存中的。作者还特别提到了在Hadoop 2.x引入HA（高可用）架构后，元数据操作日志（EditLog）变为多副本写入Quorum Journal Manager的设计，以及它如何与ZKFC配合实现故障自动切换。对于想理解HDFS为什么能高效管理海量文件元数据的读者来说，这篇文章提供了一个不错的内部视角。它把看似复杂的NameNode核心，拆解成了几个关键且清晰的组件，并说明了它们各自的职责与协作方式。

IT 累计浏览 2,312

Hive 随谈（三）

很多人初见Hive时，容易被它的HQL查询语言迷惑，以为它就是另一个数据库。但这篇随谈指出，除了表面上的SQL语法相似，Hive与传统数据库在结构和设计目标上几乎没有共同之处。文章从多个维度剖析了两者的根本差异。核心在于，数据库是为在线事务处理（OLTP）而生的，强调低延迟、高并发的实时读写，支撑着各类业务应用。而Hive诞生于大数据生态，其本质是构建在Hadoop之上的数据仓库工具，专为海量数据的离线分析（OLAP）而设计。它牺牲了实时性，换来了对PB级数据的批处理能力和高吞吐的查询性能。作者强调，认清这一点至关重要。这意味着我们不能将Hive直接用于需要即时响应的线上业务。理解它“为数据仓库而生”的基因，才能合理运用其特性，在合适的数据分析场景中发挥其分布式计算的优势，避免用错地方。