IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:大数据

共 28 篇相关文章

IT 累计浏览 3,552

Spark性能优化——和shuffle搏斗

这篇讲的是Spark性能调优中一个最头疼的问题——shuffle。作者把shuffle比作必须击败的“大boss”,因为它会触发大量网络传输和序列化,让原本在内存中飞快的计算慢下来。 文章没有堆砌理论,而是直接切入实战技巧。比如,作者用一个从3小时缩短到20分钟的例子,说明“先各自去重,再合并”为何能大幅减少shuffle数据量;还对比了`mapValues`与`map`、`reduceByKey`与`groupByKey`,点明哪些操作会偷偷引发shuffle,而哪些能保持本地高效计算。 针对常见的大小表join,文章给出了一个巧妙思路:把小表广播出去,用`broadcast`加`filter`直接替代耗时的`join`操作,能完全避免shuffle。对于数据倾斜导致单节点过载的问题,作者也指出了改进key设计的解决方向。 整篇文章就像一位有经验的工程师在分享如何“避坑”,从原理到代码示例都很具体,最后还提醒了关于`collect`、避免RDD嵌套操作等容易忽略的细节。对于用Spark处理大数据的人来说,这些围绕shuffle的优化思路相当实用。

IT 累计浏览 2,623

事无巨细 Hadoop2.6.4 环境搭建步骤详解

这篇讲的是作者基于自己的Mac开发机,在CentOS 6.5服务器上从零搭建Hadoop 2.6.4环境的完整历程。作者事无巨细地记录了每一步操作和背后的思考,像一位耐心的向导。 摘要从最基础的环境准备开始,详细说明了如何配置SSH免密码连接以提升后续操作效率,并推荐了ssh-copy-id这一可靠方法。接着,文章阐述了如何创建独立的dps-hadoop用户和用户组,以及为其配置sudo权限,体现了规范的权限管理思路。在基础设施层面,作者分享了如何配置本地DNS服务器,并给出了修改网络配置文件以永久生效的具体位置。 核心的Hadoop安装部分,文章涵盖了JDK 8u77的下载、安装与环境变量配置,并特别指出了将JAVA_HOME写入~/.bashrc而非全局配置文件的重要性。最后,详细说明了如何下载并解压Hadoop 2.6.4,以及配置HADOOP_HOME的关键步骤。整篇记录覆盖了从连接、用户、环境到软件安装的全链条,对新手而言,这份笔记省去了大量摸索和试错的时间。

IT 累计浏览 2,491

Spark的性能调优

这篇文章从实战经验出发,汇总了Spark性能调优的多个关键方向。内容不仅涵盖基础配置,更深入到应用代码设计与任务执行策略。 开篇即点明,调优的第一步往往从数据序列化开始,对比了默认的Java序列化与更快更紧凑的Kryo方案。紧接着是内存管理,文章给出了具体的检测方法(如使用UI或SizeEstimator)和优化建议(如启用压缩指针)。GC调优部分尤为实用,解释了默认内存分配比例、Eden区设置,并分享了如何避免因大量对象创建导致的“GC overhead limit exceeded”错误。 对于影响性能的关键因素,文章详细阐述了并行度、Reduce Task内存使用以及Shuffle的优化。例如,通过广播变量减少大表shuffle是一个经典模式。数据本地性的五个层级及其调度策略也被清晰说明。文件存储与读取优化(如使用Parquet列存格式)和Speculation(推测执行)机制也被纳入考量。 最后,文章强调了合理设置分区数和减少不必要Shuffle的重要性,并给出了具体的代码示例指引。整篇文章既包含JVM级别的参数调整,也涉及Spark应用层的数据结构设计与API选择(如prefetchByKey vs groupByKey),是一份从理论公式到实战经验的综合性调优指南。

IT 累计浏览 1,730

我的移民故事

这篇讲述的是一位俄罗斯程序员移民美国、并最终创业的真实历程。作者从2005年通过暑期工项目登陆华盛顿当救生员学英语开始,经历了远程实习、多次H-1b签证抽签失利,为维持合法身份而就读巴布森学院MBA。期间他先后在波士顿小公司、诺基亚和硅谷初创公司工作,始终在“为雇主工作”与“渴望创业”的移民政策夹缝中寻找出路。转折点出现在一次看似幸运的绿卡抽签中,但背景调查又与失业时间重叠,几乎将他推向绝境。最终在2012年,他抓住时间窗口创立了Datanyze。 文章不仅是一段个人奋斗史,更通过亲身经历揭示了美国移民制度与创新生态之间的矛盾——H-1b签证限制人才流动,缺乏企业家签证使得许多创业者无法在美开公司。作者在文末明确呼吁推出企业家签证,认为现行制度未能充分利用外来人才驱动经济。对于技术从业者而言,这个故事提供了关于职业规划、签证风险与创业时机的宝贵参考。

IT 累计浏览 3,927

Hermes:来自腾讯的实时检索分析平台

这篇讲的是腾讯数据平台部推出的实时检索分析平台Hermes。它瞄准的是一个非常具体的痛点:当数据量达到千亿级别、维度上万时,如何还能做到秒级响应的多维交互式分析。 Hermes为营销分析、系统运维监控、长期趋势分析以及探索性分析等场景提供了一套完整方案。它的核心思路在于,针对海量数据重新设计了存储和计算引擎。例如,通过嵌套列存储、位图计算、前缀压缩等技术,有效规避了传统数据库和早期搜索引擎在超大规模索引下内存消耗大、扩容困难、恢复慢的问题。文章特别将Hermes与Solr、ElasticSearch做了定位对比:后者更擅长小规模数据的全文检索,而Hermes则为亿级到万亿级的数据仓库提供索引支持与即席分析能力,旨在成为数据仓库的高效分析层。 本质上,Hermes是在大数据领域,为“即查即所见”的敏捷分析体验提供的一个经过生产验证的基础设施选型参考。

IT 累计浏览 5,083

百度是如何使用hadoop的

这篇文章讲的是百度如何将Hadoop深度应用于其海量中文搜索及数据处理场景。面对日志存储、网页挖掘、商业分析、在线反馈等复杂需求,百度不仅大规模部署了Hadoop(约700台机器,日均处理120TB数据),还针对实际运行中的效率与可靠性问题进行了系统性改造。 具体来看,百度在多个层面做了定制优化:在MapReduce策略上,通过限制作业并发、调整预测执行和基于节点内存调度来提升稳定性;对HDFS增强了权限控制与容错能力,比如让分区与节点解耦,避免单点故障影响全局。此外,他们还修改了推测执行(Speculative)策略,用速率倒数来更公平地触发备份任务,并引入资源控制机制,甚至修改Linux内核来限制进程内存使用。 文章也坦诚分享了百度在实践中遇到的痛点,包括MapReduce的I/O与排序效率、HDFS的随机访问延迟、内存管理压力以及作业调度精细化等问题,并针对如Streaming只能处理文本数据的局限,提出了自研的Bistreaming方案。这些细节揭示了在超大规模环境下,如何将开源框架“打磨”得更适合生产需求——不仅是使用,更是持续的调优与二次开发。

IT 累计浏览 2,990

数据可视化初体验(R语言)

这篇文章以作者初入数据可视化领域的体验为线索,分享了其核心理解与R语言实践。作者引用“图画最大价值在于迫使我们注意到从未预料到的内容”这一观点,强调可视化不仅是展示数据,更能通过图像残留增强思考,揭示隐藏规律,并以Twitter用户分布图为例加以印证。 在实践部分,作者以中国航空数据为例,展示了如何用R的ggplot包将“实体”与“联系”的逻辑转化为可视化步骤:从用直方图展示机场航线数量,到在地图上叠加点线图呈现地理位置与航线网络,最终生成GIF动画,层层递进。文章还简要提及了基于Knitr包实现可重复自动化统计报告的方法,对比了其相较于传统数据报表的优势。 整篇文章从感性认识到理性实践,结合了数据可视化的哲学思考与R语言的具体实现,为初学者提供了一个清晰的入门框架与案例。

IT 累计浏览 1,869

数据的游戏:冰与火

这篇讲的是一位在Amazon和淘宝都有过实践的数据挖掘新人,在不到10个月里总结出的“冰与火”心得。作者开篇就点明,数据世界象征着权力与征服,但通往“王座”的道路布满荆棘。 文章的核心观点很明确:他从Amazon经验中提炼出数据团队的三大角色——苦累却至关重要的数据清洗员、技术含量最高的研究科学家、以及相对次要的软件开发工程师。作者强调“Garbage In, Garbage Out”,再牛的算法也敌不过一堆垃圾数据。 通过两个生动的案例,作者阐明了数据质量的重要性。一是像Amazon那样建立严格的商品ID(ASIN)作为数据标准;二是清洗海量但格式混乱、真假混杂的用户地址数据。他指出,数据不分大小,只分好坏,从80%的准确度提升到90%,所需成本远超过从60%到80%。 作者进一步讨论了业务场景对数据挖掘的制约。推荐系统在音乐和电商场景下逻辑截然不同,对书籍和服装的需求预测难度也有天壤之别。他提醒,数据挖掘远非人工智能,在特定业务场景下,资深从业者的经验甚至比机器学习更准。 最终,作者认为数据分析结果不能止步于统计呈现,必须能指导下一步行动。他抛出了数据挖掘中质量、场景与结果这三个关键问题,虽未给出标准答案,却为从业者揭示了被算法光环所掩盖的实践本质。

IT 累计浏览 6,585

大数据下的工行

这篇讲的是工行2013年那场著名的系统故障,作者从一条已消失的微博切入,还原了事件的全过程。故障发生在计划内数据库升级(DB2从V9升至V10)后的首个业务高峰,暴露出凌晨低负载测试无法完全模拟真实压力的问题。 文章的核心技术分析指出,问题可能源于IBM软件的内存清理缺陷,导致数据库主机CPU和内存迅速耗尽。作者站在DBA视角,还原了故障当时的决策困境:是冒险切换至未经充分验证的灾备中心(可能牺牲数据一致性),还是耗时更长但能保证数据完整地回退版本?理性选择了后者,这符合金融系统对CPA中一致性(C)的严格要求。 文中还穿插了作者亲历的2008年淘宝机房断电惊魂时刻,形成对比——成熟的容灾架构需通过定期实战演习来锻造,而非仅靠昂贵备库。最后,文章对工行将直接原因归咎于IBM软件缺陷的内部通报,留下了耐人寻味的评论。全文通过一个具体故障,探讨了大型系统运维中测试验证、灾备切换与故障复盘的真实逻辑。

IT 累计浏览 3,631

数据开发技术概述

这篇讲的是面向海量数据计算入门者的数据开发技术全景。作者冷川从淘宝数据平台及开发技术的演进过程出发,系统梳理了当前主流的数据开发技术栈。 文章的核心在于为我们呈现了一幅清晰的“目前主要的数据开发技术框架图”。它不仅仅罗列技术点,而是结合平台实际场景,讲解了这些技术如何被组织和应用。这对于想建立系统性认知、而非零散了解的同学非常有帮助。 在当前超海量数据的背景下,文章最后抛出了一个关键思路:数据同学不应被动使用技术,而要主动结合系统痛点去思考和推动技术应用。这从单纯的“技术介绍”提升到了“工程思维”的层面,给读者留下了具体的行动方向。

IT 累计浏览 2,306

搜狐的江山

这篇讲的是,搜狐创始人张朝阳在一次面向投资者的电话会议上,坦承搜狐微博业务遭遇了“失利”。尽管搜狐公关部门随后试图澄清,认为媒体有所误读,但文章的核心在于探讨一个更深层的问题:在新浪和腾讯已占据微博市场绝对优势的背景下,搜狐微博的落后已是不争的事实。 作者从这一公开表态出发,深入剖析了搜狐在微博战场上的战略困境。文章并未止步于复述事件,而是将焦点对准了“失利”背后的可能原因。它探讨了搜狐在社交媒体赛道上是否出现了战略摇摆,以及其产品定位与运营策略在激烈的市场竞争中是否显露出力不从心。这些分析使得事件本身超越了简单的业绩汇报,折射出中国互联网大公司在关键风口前的抉择与挑战。 对于读者而言,这篇文章的价值在于它提供了一个观察巨头博弈的切片。它促使我们思考:当一条赛道已成红海,后来者该如何寻找破局点?企业的公开表态与内部真实的业务状况之间,往往存在着怎样的解读空间?这对于所有关注互联网竞争动态和公司战略的人,都是一份颇具启发性的现实案例。

IT 累计浏览 2,574

妄谈时间序列表格型大数据系统设计

这篇讲的是一位长期深耕分布式系统领域的工程师,如何鼓起勇气,将自己在时间序列表格型大数据系统设计上的一线实战心得分享出来。作者以“妄谈”为题,坦诚地回顾了自己从新人到承担重任的过程,在兴奋与懊恼中积累了那些“老手才懂”的经验。 文章并未提供某种完美的理论方案,而是真实展现了在应对海量、高吞吐的时序数据挑战时,从系统架构设计到细节实现中所经历的思考、权衡甚至失误。这些在真实业务中摸爬滚打得来的一手经验,恰恰是许多理论文章所缺乏的。对于同样需要处理时序数据的技术同行来说,文中的这些“醉人的课程”,或许能让你在构建自己的系统时,少踩一些坑,多一份从容。

IT 累计浏览 1,704

数据分享:2012年元旦,大家都在QQ空间说什么?

这篇讲的是ISUX团队如何从数据视角观察用户行为——他们通过分析2012年元旦当天QQ空间的公开说说,提取出那个时间节点下用户最真实的话题倾向与情绪图谱。 文章没有依赖传统用户访谈,而是转向后台统计数据,从整体层面捕捉大规模用户在特定时刻的集体表达。具体来说,团队聚焦于元旦这个具有仪式感的时间点,看大家在跨年之际更愿意分享什么:是祝福、回顾、还是展望?数据背后可能呈现出有趣的文化切片,比如节日话题的共性、社交平台上的集体情绪,甚至不同用户群体的表达差异。 这种基于真实行为数据的宏观分析,为我们提供了一个独特的窗口——不仅了解“用户说了什么”,更能洞察“在特定场景下用户选择说什么”。对从事用户研究或产品运营的人来说,这种数据驱动的观察视角,或许比单纯的定性访谈更能揭示广泛的行为模式,帮助我们在设计功能或内容策略时,更好地贴合真实的用户心理与社会语境。

IT 累计浏览 3,288

HBase在数据统计应用中的使用心得

这篇讲的是作者团队在实际项目中使用HBase作为数据统计存储系统后的经验沉淀。他们从项目对高性能写入和灵活查询的具体需求出发,选择HBase作为底层引擎,但在落地过程中遇到了不少挑战。 文章重点分享了针对统计应用特点的关键实践。例如,如何设计RowKey和预分区策略来避免热点,提升写入吞吐量;针对高频的聚合查询,如何权衡使用协处理器与客户端扫描来优化性能;以及在面对海量数据持续写入时,如何通过调整Compaction策略来平衡读写压力,保障服务稳定性。作者没有泛泛而谈,而是结合真实场景中的数据量和业务模式,给出了具体的配置思路和参数调整案例。 这些心得和解决问题的路径,对于同样面临海量数据统计存储与快速查询挑战的团队,提供了可参考的踩坑记录和调优方向。

IT 累计浏览 7,488

HBase随机写以及随机读性能测试

这篇讲的是作者团队基于生产环境实战,借助自动化测试平台对HBase进行的系统性性能测试。文章聚焦于两种核心操作:纯粹的随机写入和随机读取,并直接分享了测试得出的性能数据。 不同于一般的理论介绍,作者从实际项目应用的经验出发,不仅报告了测试结果,还重点分享了经过他们调整和优化后的关键配置参数。这对于正在或计划使用HBase,并关注其高并发场景下性能表现的工程师来说,提供了直接的参考数据和调优方向。 文章的核心价值在于将生产环境的复杂需求转化为可复现的测试场景,用数据揭示了在不同参数设置下,HBase随机读写性能的差异。这些来自一线的实测结论,比纯理论更能指导实际的集群配置与优化工作。

IT 累计浏览 7,903

淘宝数据魔方技术架构解析

这篇深度剖析了淘宝数据魔方——一个为运营和商家提供自助式多维数据分析的平台——背后的技术挑战与架构演进。文章从电商大促场景下,海量数据实时分析与低延迟查询的业务压力切入,展现了团队如何构建一套兼顾灵活性、高性能与成本效益的系统。 核心方案围绕一个流批一体的Lambda架构展开。在数据处理层,它巧妙地结合了离线计算(Hadoop)的准确性与实时计算(Storm)的时效性;在数据存储与查询层,则重点解析了如何通过构建高效的OLAP引擎(如基于Druid的优化),实现亿级数据下秒级的多维聚合分析响应。文章没有停留在组件选型,更深入到了数据模型设计、预聚合策略、缓存机制等具体实现细节,揭示了如何通过预计算与动态查询优化来平衡查询灵活性与性能。 最终,这套架构成功支撑了“双11”等大促场景下的数据洪峰,将数据延迟从小时级缩短至秒级,极大提升了运营决策效率。它清晰地展示了面对特定业务场景,一个可演进的技术架构是如何从“能用”到“好用”逐步打磨出来的。

IT 累计浏览 4,461

Hadoop集群间Hadoop方案探讨

这篇讲的是在多个Hadoop集群间进行数据迁移时,如何用好`distcp`这个工具。作者从实际工作场景出发,直面一个常见痛点:集群版本不一致、不同机房的ACL策略各异,这些都让看似简单的跨集群拷贝变得复杂。 文章没有泛泛而谈,而是系统整理了作者遇到的各种具体需求与挑战。核心思路是围绕`distcp`展开,探讨在不同约束条件下(比如权限、网络、数据量)的可行方案与配置要点。通过分享这些实战案例,文章旨在为遇到相似问题的同行提供一套可参考的“问题-方案”映射思路,帮你快速判断自己的场景该如何处理。 文章最后归类总结了多种情况,其价值不在于给出唯一答案,而在于呈现了解决这类异构集群数据流通问题时,需要考虑的关键维度和常见排障路径。

IT 累计浏览 3,901

Hadoop安装端口已经被占用问题的解决方法

这篇文章针对的是Hadoop初学者或运维人员在部署时常遇到的一个棘手问题:在多台机器共享的环境中安装Hadoop时,由于端口被提前占用导致安装失败。 问题的根源在于,当多人或多个服务共用一批机器时,某些Hadoop默认或配置的端口可能已被其他进程或之前未完全清理的服务占用,使得新的Hadoop进程无法正常启动。文章没有停留在描述问题上,而是详细给出了排查思路和解决方法。它引导读者一步步定位到底是哪个端口、被哪个进程所占用,并提供了相应的终止进程或修改Hadoop配置端口的具体操作步骤。 这种从实际故障场景出发,直接提供可操作性解决方案的写法,对于正在为安装报错而头疼的读者来说非常实用。它让读者明白,遇到类似端口冲突时,不必慌张,可以通过系统化的排查来解决问题,从而顺利完成部署。

IT 累计浏览 4,434

菜鸟谈HBase之写速度篇

这篇讲的是HBase写性能的实测与分析。作者从Facebook选择HBase作为消息存储系统的核心原因——高性能写——切入,通过实际的性能测试数据,带大家看看HBase在写入速度上的真实表现。 测试不仅揭示了HBase在不同场景下的写入吞吐量水平,更分享了团队在测试过程中碰到的若干实际问题。比如,如何设计合理的测试用例、在并发写入时可能遇到的瓶颈,以及数据最终对测试结果的影响。这些来自一线实践的细节,让性能数字变得更有说服力。 对于正在评估或已经使用HBase的开发者来说,这篇文章的价值在于它提供了超越理论值的实测参考,尤其是对测试方法的坦诚分享。它帮助读者更客观地理解HBase的写入能力边界,并在自己的架构决策中,能更准确地预估性能与定位问题。

IT 累计浏览 5,675

Hive源码解析-之-语法解析器

这篇讲的是Hive SQL引擎中语法解析器的具体实现。作者从上次分析的词法分析成果出发,揭示了语法解析器如何以生成的语法树为基础,承担起将Token流转化为具体查询结构的重任。 文章的核心在于剖析其设计:解析器根据遇到的语法Token情况,具体实现了五种不同的解析器。这种设计巧妙地应对了Hive SQL语法的多样性和复杂性。通过深入源码,文章清晰地展示了每种解析器所对应的具体语法结构(如DDL、DML、事务语句等)以及它们的分工逻辑。 对于想理解SQL引擎内部工作机制或Hive源码的同学,这篇文章提供了一个清晰的切入口,展现了如何将语法理论具体化为模块化的工程代码。