1. 2015年前后的技术大背景笔试命题的隐藏逻辑很多准备面试的朋友喜欢刷题、背答案但忽略了一个本质问题笔试题目不是凭空出的它一定踩着公司当时的技术痛点。2015年这个时间节点很特殊整个互联网圈正处于大数据从能用到用好的转型期云计算则是从概念炒作落向基础设施的关键阶段。百度在2015年对大数据和云计算研发岗位的考察放在今天回看很多题目其实是当年内部技术演进的真实缩影。先说大数据这边。2015年Hadoop生态在国内已经不算新鲜词了大量业务开始从传统的Oracle、MySQL往HDFS和Hive上迁移。但迁移过程中暴露的问题非常多集群规模大了之后NameNode的压力怎么扛MapReduce跑批任务动不动几个小时有没有更快的计算引擎实时性要求高的场景怎么办所以你会发现笔试中凡是涉及Hadoop生态的问题几乎不会只问是什么而是直接往原理怎么实现和遇到瓶颈怎么优化这两个方向扎。再说云计算这边。2015年百度的云计算业务正处于蓄力期对研发的要求不是会调用OpenStack API就行而是对虚拟化技术、分布式存储、资源调度、集群高可用这些底层能力有实打实的理解。很多候选人觉得云计算就是运维的事其实大错特错。笔试里一旦出现虚拟化、容器、负载均衡相关的题目考察的是你有没有从物理资源到逻辑资源的抽象思维。我整理过几份那个年代的真题回忆版也跟不少当年参加过面试的工程师聊过。大家一致的感受是这套卷子不温不火题目看着都认识但答起来想拿高分特别难。原因在于它不考记忆考的是你有没有真正动手搭过集群、写过MapReduce、被线上故障虐过。也就是说命题人默认你具备基础他要区分的是用过和懂原理之间的差距。理解了这层逻辑再去看具体题目思路会清晰很多。1.1 百度当时的技术栈决定了笔试的考察方向一个公司的笔试风格往往跟它的技术栈强相关。2015年百度内部大量业务跑在Hadoop 2.x上YARN已经逐步接管资源调度Spark正处于从实验走向生产的关键阶段很多团队在尝试用Spark替代部分跑批任务实时计算这边Kafka加上Storm是主流组合Flink还不像后来那样普及。存储层面HBase承载了众多在线业务Redis已经被广泛用于缓存MySQL的分库分表方案也相当成熟。云计算这边百度当时在IaaS层投入很大虚拟化主要基于KVMOpenStack被用作云管理平台对象存储、块存储、负载均衡这些基础服务都在快速迭代。对内百度有大规模的集群管理系统对外云产品需要稳定的虚拟化隔离能力和弹性伸缩能力。所以笔试题目会覆盖KVM虚拟化的基本原理、OpenStack的核心组件协作流程、分布式存储的一致性模型这些都不是偶然。如果当时你只盯着Java集合框架和设计模式去准备笔试大概率会吃大亏。百度2015年那套卷子的侧重点非常明确分布式、大数据处理框架、云计算底层架构。它不是普通的后端开发卷而是实实在在贴着大数据云计算研发这几个字命名的。所以准备方向错了再努力都白搭。1.2 这场笔试真正想筛选出来的人我个人的观点是笔试筛选的不是知识点最多的人而是具备分布式系统直觉的人。什么叫做分布式系统的直觉比如说看到海量日志统计你能立刻想到用MapReduce还是Spark看到TB级别的去重你能判断Bloom Filter够不够用看到系统要求高可用你能想到ZooKeeper选主加副本机制的组合。这种直觉靠背题培养不出来只能靠长年累月地跟分布式系统打交道踩过坑、看过源码、调过参才慢慢内化成条件反射。那套笔试还有很多开放性问题没有标准答案。比如如何设计一个支持海量小文件存储的系统如何优化一个数据倾斜严重的MapReduce作业。这些问题考察的就是系统设计能力和经验积累。一个只背过HDFS原理的人和小文件问题实战过的人答出来的深度完全不一样。所以如果你现在也在准备类似的岗位笔试我建议你从技术史和技术演进的视角去理解题目背后的动机。每道题都问自己为什么公司要考这个当前的业务场景会遇到什么问题解决这个问题有哪些常见的坑这样备考比单纯刷题高效得多。2. Hadoop体系HDFS与MapReduce的深度问答Hadoop生态几乎是每一份大数据笔试绕不开的关卡。2015年这套卷子关于HDFS和MapReduce的题目占比不低而且问得相当细。很多候选人能答出HDFS是分布式文件系统MapReduce是分布式计算框架这种一句话定义但深入一问就哑火。这里我来还原一下当时最有区分度的几类问题以及什么样的回答能拿高分。2.1 HDFS的读写链路是追着问的基础笔试里最常见的HDFS题目是这样的请描述HDFS写文件的过程。这道题看似基础但想答完整并不容易。合格的回答至少要覆盖这几层客户端向NameNode发起写请求NameNode检查权限和路径合法性然后返回可用的DataNode列表。注意这个列表不是随便给的它遵循机架感知策略——通常情况下第一个副本放在客户端所在节点第二个副本放在同机架的不同节点第三个副本放在不同机架。这样做是为了在容错和写性能之间取得平衡。拿到DataNode列表后客户端开始建立Pipeline。数据按块默认128MB切分客户端以64KB的packet为单位往第一个DataNode推数据第一个DataNode边接收边转发给第二个第二个再转发给第三个。每写一个packet都会有ack回传机制确保数据真正落盘后才算成功。这里有个容易被忽略的点HDFS的写是流式的不是等一个块完全写完再写下一个。客户端会维护一个DataStreamer线程持续发送数据同时还有一个ResponseProcessor线程接收ack。只有所有副本都确认写入成功客户端才关闭输出流并通知NameNode提交块信息。面试官如果继续追问写过程中DataNode挂了怎么办那就进入了更深的层次。答案要点是管道会重建客户端会跟NameNode重新申请新的DataNode继续写但已经写入成功的副本不需要重写。NameNode会通过块报告机制发现副本数不足然后启动额外复制来补副本。这种问题考察的是候选人对故障处理流程的熟悉程度只看过书没实操过的人往往答不到这一层。读文件的过程同样值得深挖。客户端先向NameNode拿文件的块位置信息NameNode返回每个块所在的DataNode列表优先返回距离近的节点然后客户端直接从DataNode拉取数据。如果某一个DataNode读取失败客户端会切换到列表中的下一个节点继续读。读到最后一个块时还有校验和验证——验证失败会换副本重读。读写的细节讲清楚之后题目往往会自然过渡到为什么HDFS不适合存小文件这一关。答案的核心在于元数据的压力每个文件、目录、块都要在NameNode内存中占一条记录一个小文件占一个块意味着NameNode要维护大量的文件元数据而NameNode的内存是有限的。这个问题的延伸考点是NameNode的高可用方案也就是Active/Standby热备加JournalNodes共享编辑日志的机制。能把这些串起来讲HDFS这一块基本就稳了。2.2 MapReduce的Shuffle笔试答到这个程度才算过关MapReduce相关的题目中Shuffle是永远绕不开的考点。2015年那套卷子里的问法是MapReduce作业执行过程中Map端和Reduce端的数据传输是怎么实现的这个问题看起来具体其实考察的是整个Shuffle机制的理解深度。我从Map端开始梳理。Map的输出不是直接写到磁盘的它会先写入一个内存环形缓冲区默认大小100MB阈值是80%。当缓冲区的数据量达到阈值后台线程会启动溢写spill流程先对数据做分区partition确定每条记录要发给哪个Reducer然后在分区内做排序sort默认按key排序如果配置了Combiner还会先做一次局部合并减少磁盘IO和网络传输。溢写产生的临时文件会保存在本地磁盘多个临时文件最后会合并成一个大的溢写文件。Reduce端则分三个阶段。第一阶段是拉取fetch——Reduce任务启动后会启动多个线程从各个Map任务节点拉取属于自己的分区数据。第二阶段是合并merge——拉到的数据会先缓存在内存中超过阈值就落盘并合并最终把所有数据合并成一个有序的大文件。第三阶段是reduce函数的执行——把同一个key的所有value传给reduce函数处理。为什么面试官这么爱问Shuffle因为Shuffle是整个MapReduce作业中最耗时、最容易被优化也最容易出问题的环节。数据倾斜、网络拥塞、磁盘IO瓶颈、GC压力这些线上真实的故障大多发生在Shuffle阶段。如果你能在笔试中不仅说出流程还能补充Shuffle调优通常从哪些参数入手比如调节mapreduce.reduce.shuffle.parallelcopies提高并发拉取数、开启mapreduce.map.output.compress减少网络传输量那这道题的高分就稳了。另外2015年的笔试卷里还有一道很典型的MapReduce设计题两个大文件A和BA有10亿条记录B有5亿条记录现在要对两个文件做Join怎么设计这题没有唯一答案但考察的核心是Reduce端Join和Map端Join的取舍。常规做法是Reduce端Join把两个文件都map出来join key作为输出key用一个tag标记数据来源比如A文件的数据value前加A_B文件加B_到了reduce端再根据tag区分并完成join。这个方法通用但性能差因为所有数据都要经过Shuffle一个key对应的所有value都会进同一个Reducer可能导致数据倾斜。更好的方案是Map端Join。如果两个文件中有一个足够小可以加载到内存可以在Map任务初始化阶段用DistributedCache把小的那个文件加载到本地然后直接在map函数里做查询匹配。这样省掉了整个Shuffle过程速度极快。再进阶一点还可以用Bloom Filter提前过滤掉不可能匹配上的记录进一步减少网络和计算开销。在笔试中能把这几种方案的优劣和适用场景都说清楚说明你真的动手做过Join优化而不是只会背概念。2.3 让面试官眼前一亮的数据倾斜解答思路数据倾斜是大数据笔试中必然出现内容2015年那套卷子也不例外。典型的题目描述是你的MapReduce作业跑得很慢发现大部分Reduce任务几分钟就完成了但有一个Reduce任务跑了一两个小时怎么排查和解决很多候选人的第一反应是加机器这显然不是命题人想要的答案。正确的排查思路应该是这样的先要定位是不是数据倾斜导致的。看Counter里map和reduce处理的数据量如果某个reduce的输入记录数远超平均大概率就是倾斜如果数据量平均但某个reduce特别慢那可能是计算复杂度过高或者发生了GC。定位到倾斜之后解决方案要分情况讨论。最简单的一种是空key或者特定值过多导致的问题——比如按某个字段做聚合大量数据都落在同一个key上。处理方式是在key中加入随机前缀让原本聚集在一个reduce的数据分散到多个reduce完成第一轮局部聚合然后再去掉前缀做第二轮全局聚合。这个方案实施简单效果明显。另一种情况是join操作中一个大表和一个小表join小表虽然能放进内存但大表的某些key特别多。这时可以考虑把倾斜的key单独拎出来做Map端Join或者给倾斜key的值加上随机前缀做打散再用两个job分别处理非倾斜部分和倾斜部分。如果你在笔试中不仅能给出方案还能分析各种方案的代价——比如打散方案会带来额外的聚合步骤随机前缀的范围选多大也直接影响性能——那说明你踩过数据倾斜的坑。我后来面试别人的时候最喜欢问数据倾斜的变种问题能当场给出完整思路的候选人动手能力一般都很强。3. Spark与流式计算新旧计算范式交替的关键考察点2015年刚好是Spark从新玩具走向生产主力的转折期。百度这套笔试卷里Spark相关题目虽然占比不如Hadoop高但考察的深度和区分度都很强。命题人很清楚Hadoop是存量技术Spark才是增量方向一个合格的大数据研发不能只会写MapReduce。3.1 Spark RDD与MapReduce的对比逻辑有一道典型的笔试题是Spark相比MapReduce有哪些优势为什么Spark跑批任务比MapReduce快很多很多人的回答是Spark基于内存计算但这个答案太表面了。面试官想听的是更深层的机制差异。MapReduce之所以慢根本原因在于每个Map和Reduce阶段都要落盘一次Shuffle过程伴随大量磁盘IO一个复杂的作业往往需要多个MR任务串联每个阶段都要重新读写HDFS。而Spark的核心抽象RDD弹性分布式数据集支持在内存中缓存中间计算结果迭代计算时不需要反复读写磁盘。但Spark比MapReduce快并不是绝对的真理。我当时特意整理过一个对比表笔试和面试中用到过很多次这里也分享出来对比维度MapReduceSpark计算模型有向无环图DAG由多个MR阶段串联每阶段落盘DAG由多个Stage构成优先内存计算必要时才落盘数据共享只能通过HDFS或外部存储系统共享数据RDD支持缓存、持久化级别灵活配置容错机制重算整个阶段通过血统Lineage机制重建RDD实时性秒到分钟级的启动和调度开销秒级任务调度更适合交互式查询适用场景简单批处理、超大作业的稳定性要求高迭代计算、交互式查询、图计算、流处理这里面有一个关键概念值得展开——Spark的DAG调度器。一个Spark作业会被拆成多个StageStage以宽依赖Shuffle依赖为边界。窄依赖窄依赖的操作如map、filter可以在同一个Stage内完成流水线处理遇到宽依赖的shuffle操作才划分新的Stage。这种调度机制使得Spark在执行过程中花费的网络和磁盘开销远低于MapReduce。笔试里还会接着问Spark的宽依赖和窄依赖有什么区别为什么Stage划分以宽依赖为界窄依赖是指父RDD的每个分区最多被一个子RDD分区使用比如map、filter这种依赖下如果某个分区数据丢失只需要重算对应分区即可不需要整个Stage重算。宽依赖是指父RDD的每个分区可能被多个子RDD分区使用比如groupByKey、reduceByKey这种依赖必须等所有父分区数据准备好才能进行Shuffle因此天然是Stage划分的边界。能把这几个概念串成一个完整的逻辑回答出来的候选人说明真的理解Spark的设计思路而不是背了一堆名词。3.2 Kafka与流式处理的时序问题除了Spark批处理2015年笔试卷还涉及流式计算。当时最主流的组合是Kafka加Storm一些题目会问如何保证消息不丢失、不重复或者如何设计实时计算作业的容错机制。Kafka的存储模型是理解流式计算的基础。Kafka将消息按主题Topic存储每个Topic包含多个分区Partition每个分区内消息是有序的、不可变的通过偏移量Offset来标记消费位置。Kafka的高吞吐来自顺序追加写磁盘和页缓存机制——写入操作是append-only不需要随机寻址读操作大量命中Page Cache因此即便在高吞吐下延迟依然很低。笔试中关于Kafka的常见陷阱题是:如何保证Kafka消费不丢数据正确的思路是三个层面都要覆盖。生产者端设置acksall保证分区副本全部写成功才返回Broker端设置replication.factor1并配置min.insync.replicas确保至少有一个副本同步成功消费者端不要用自动提交offset应该先处理完消息再手动提交offset避免消息处理失败但offset已提交导致的数据丢失。如果题目再深入一层问如何保证exactly-once答案就要区分版本和方案。2015年那会儿Kafka的exactly-once能力还比较弱通常的做法是用幂等性下游处理设计成幂等操作——比如写入数据库时通过唯一索引去重或者用Redis setnx这类机制保证不重复写入。后来Kafka引入事务API和幂等生产者之后exactly-once才有了更完整的原生支持。这部分如果能在笔试中延展出来绝对是一个加分项。流式处理本身的容错也是一个高频考点。Storm的Acker机制就是典型的可靠性设计每个消息都会生成一个64位的校验值任务完成时通过异或操作向Acker汇报Acker校验值归零即认为消息被完整处理。Spark Streaming则使用预写日志Write-Ahead LogWAL加RDD血缘关系来实现故障恢复——收到的数据先写入WAL再做计算这样即使节点崩溃也能从WAL中恢复数据避免因内存数据丢失导致的计算结果缺失。4. NoSQL与分布式存储数据一致性才是真正的分水岭分布式存储和NoSQL是百度这类海量数据业务的核心基础设施笔试中这一块分量不轻。2015年那套卷子涉及HBase、Redis和一致性原理的题目相当多这三个方向恰恰是大数据研发日常打交道最多的组件。4.1 HBase的读写路径与Region分裂HBase相关题目常考的是描述HBase的一张表数据从写入到查询的完整过程。这题考察的是对HBase架构的整体理解能答好的人不多。先写流程。客户端发来put请求先通过ZooKeeper获取hbase:meta表所在RegionServer的地址再从这个RegionServer获取目标表的meta信息找到要写入的Region所在的RegionServer。然后客户端直接跟那个RegionServer通信数据先写入WALWrite Ahead Log再写入内存中的MemStore。当MemStore达到阈值默认128MB或者满足其他刷写条件时会形成HFile刷写到HDFS上。多次刷写会产生多个HFile文件后台的Compaction机制会定期把它们合并成更大的文件提升读取效率。读流程类似但增加了BlockCache的检查。客户端定位到RegionServer后先查BlockCache缓存未命中再去查询MemStore和HFile。HFile内部通过布隆过滤器和块索引来加速查找——布隆过滤器快速判断key是否存在块索引定位key可能所在的块这样避免了全文件扫描。为什么HBase的随机读写性能比HDFS好关键在于HBase把随机写转换成了顺序写。数据先写WALWAL是顺序追加写在MemStore里按key排序后再刷盘成HFileHFile内部也是有序的。这就把随机IO问题转化成了顺序IO问题极大提升了写入性能。这一点如果能在答题中主动说出来分数会高很多。Region的分裂和负载均衡也是笔试的常客。Region大小超过阈值HBase 1.x默认是10GB时会自动分裂成两个Region。分裂后Meta表需要更新这个过程由RegionServer的Split事务管理。生产环境中Region分裂期间业务会经历短暂的服务抖动所以有条件的话会预先规划好rowkey的设计减少分裂导致的性能波动。Rowkey设计是HBase笔试中最常见的开放题之一。如何设计一个微博关系表的rowkey这类问题的核心原则是避免热点。最简单的做法是反转手机号13900001111反转成11110000931这样一个Region承受的写入压力就均衡了。或者加盐给原始rowkey加随机前缀让数据散列到多个Region。设计rowkey时还要考虑查询模式——如果经常按用户ID查那用户ID应该放前面按时间范围查时间戳前缀配合反转也是经典方案。能讲清楚这些设计约束相权衡取舍就是面试官想看到的能力。4.2 CAP定理在笔试中的正确打开方式CAP定理几乎是大数据笔试的必考题但多数人的回答停留在一致性、可用性、分区容忍性三者不可兼得这个层面。2015年那套笔试卷真正想考察的是你能否把CAP理论和实际系统设计结合起来。先讲清楚CAP的概念。一致性Consistency指所有节点同一时刻看到的数据是一致的可用性Availability指系统在有限时间内一定能返回结果分区容忍性Partition Tolerance指网络分区故障时系统仍能继续工作。在分布式环境中P是必须保证的——网络分区是不可避免的物理事实。所以在P必须保证的前提下取舍发生在C和A之间选择CP还是AP。回答这道题的关键是给例子。HBase是典型的CP系统当RegionServer故障时ZooKeeper会触发Master重新分配Region在分配完成前这个Region的读写请求会失败系统对外表现为不可用但保证了数据一致性。而Cassandra更偏AP它在节点故障时依然接受写入但可能出现短时间内读到旧数据属于最终一致性。再深入一步笔试还会问分布式系统怎么实现数据一致性。这里要谈的协议有几个层次两阶段提交2PC适合跨库事务但性能差Raft和Paxos适合做主节点选举和日志复制最终一致性可以通过多副本异步复制加版本号或向量时钟来实现。Raft协议尤其值得深入研究因为ZooKeeper的ZAB协议、etcd的共识模块都跟Raft有千丝万缕的联系是面试答题非常有用的积累。我看过那份卷子的回忆版CAP的题甚至还会和Redis关联考Redis Cluster是高可用的吗它如何应对网络分区这题其实很微妙。Redis Cluster在部分网络分区时会根据大多数原则选举主节点少数分区会拒绝写入这本质上是一种CP倾向但Redis Cluster的副本同步是异步的所以故障切换时可能丢失部分数据这又违背了严格的一致性。所以更准确的回答是Redis Cluster在分区的场景下表现得像CP在正常场景下它追求的是高可用和低延迟并不保证强一致。5. 云计算与集群运维从虚拟机到资源调度的题目逻辑云计算部分的题目很多纯后端背景的候选人会觉得陌生。百度2015年的云计算笔试并不要求你写过完整的云平台但对底层原理的要求相当硬核。操作系统、网络、存储、虚拟化这些基础知识在云计算的框架里重新出题考察的是举一反三的能力。5.1 虚拟化技术的考点范围虚拟化是云计算笔试的基石。KVM相关的常见题目包括KVM的虚拟化原理是什么回答要点是KVM基于Linux内核的虚拟化模块利用硬件辅助虚拟化技术Intel VT-x或AMD-V让每个虚拟机都是一个普通的Linux进程通过/dev/kvm接口创建虚拟机。CPU虚拟化通过VMCS虚拟机控制结构实现非根模式和根模式的切换内存虚拟化通过EPT扩展页表减少虚拟机内存访问的开销设备虚拟化则通过virtio框架让虚拟机使用高性能的虚拟设备。如果笔试题目问容器和虚拟机的区别就不能只回答KVM是硬件级隔离容器是进程级隔离。更深入的回答要谈隔离维度虚拟机隔离的是整个操作系统每个VM有独立的kernel隔离边界清晰容器共享宿主机的kernel通过namespaces做资源隔离通过cgroups做资源限制隔离级别更轻量但也更脆弱。安全场景下多租户隔离要求高一般需要VM如果追求资源利用率和启动速度容器更适合。OpenStack的核心组件有哪些这道题在2015年的云计算笔试中几乎必考。标准答案要覆盖五个核心服务Nova负责计算资源的生命周期管理Neutron负责网络服务Cinder负责块存储Swift负责对象存储Keystone负责身份认证。再进阶一点可以说说它们之间如何协作创建一台虚拟机的流程是——用户通过Horizon或API发起请求Keystone校验身份Nova调度器选一台计算节点调用该节点的Hypervisor创建VMNeutron为VM分配网络和IPCinder提供云硬盘挂载。笔答题能把这条调用链路画完整面试官就知道你是真的了解过OpenStack的。5.2 高可用架构设计的常见问法云计算研发笔试中经常出现设计类题目比如一个在线服务集群单机故障率1%设计集群方案使服务可用性达到99.99%需要几台机器这道题其实考察的是对可用性数学模型的掌握和系统设计能力。计算方法是这样单机故障率1%可用性就是99%。两台机器同时故障的概率是0.01乘以0.01等于0.0001所以两台机器至少一台可用的概率是99.99%刚好达到目标。如果业务要求停摆时间更短比如99.999%那需要三台机器同时故障才导致不可用三台故障概率是十的负六次方可用性为99.9999%。但这是纯数学层面真实设计高可用时还要考虑软件层面的故障——比如两台机器部署同一个应用如果应用有bug同时崩溃再多的副本也没用。所以高可用设计一定是冗余加故障隔离的组合多副本解决硬件故障多可用区解决机房级别故障熔断限流解决系统过载优雅降级解决依赖故障。资源调度类的题目同样常见包括如何设计一个任务调度系统支持每天百万级别的任务定时执行。可行的方案是用ZooKeeper选主主节点从数据库或消息队列拉取到点的任务按时间排序后交给worker执行。任务执行状态需要持久化失败要重试重试次数要有限制同时要处理任务幂等性问题——不允许同一个任务在故障恢复后被重复执行两次。负载均衡也是云计算笔试的高频考点。LVS、Nginx、HAProxy的区别要能说清楚LVS工作在网络层转发性能最强支持DR、TUN、NAT三种模式Nginx工作在应用层支持HTTP反向代理和HTTP七层负载均衡能处理长连接和WebSocketHAProxy更专注于四层负载均衡对TCP和HTTP都支持得很好自带健康检查和管理统计页面。实际选型时大型集群通常采用LVSKeepalived做入口的高可用和四层转发后面挂Nginx做七层路由和反向代理再往后才是真正的应用服务。6. 算法与系统设计题笔试最后一道开卷题的答题思路除了技术原理百度2015年那套笔试卷一定会有算法题和系统设计题。算法题偏经典系统设计题开放性极强。这两个方向恰恰是拉分的关键而且对后续面试也有非常大的帮助。6.1 海量数据题目的通用解题套路给定一个包含100亿个整数的文件找出出现次数最多的前10个数这类海量数据处理题在笔试中出现的频率极高。它的核心考察点是位图和哈希分治的应用。最常见的解法是哈希分治。100亿个数太大一次性加载不现实所以先用哈希函数把数据映射到100个小文件中比如hash(x) % 100。相同的数必然进入同一个小文件不相同的数也可能哈希冲突进同一个文件但冲突概率是均匀的。然后对每个小文件分别统计词频用哈希表或者Trie树最后得到每个文件的Top10再归并所有文件的Top10得到全局Top10。另一个常用思路是分而治之加堆排序。统计完每个文件的词频后用小顶堆维护当前最小的Top10——每次遇到比堆顶大的元素就把堆顶替换掉这样一轮遍历下来就拿到Top10。这样设计的优势是内存占用极小无论数据多大堆的大小恒定。如果是找到所有数中只出现一次的这种去重查询任务布隆过滤器就可以用上。布隆过滤器是一种空间效率极高的概率数据结构用多个哈希函数将数据映射到一个bit数组判断不存在是准确的判断存在可能有小概率误判。需要精确结果时可以用bitmap加计数比如2-bitmap两个bit表示四种状态不存在、出现一次、出现两次及以上、已删除。大数据场景下还有一类常见题是位图排序。如果数据是10亿个不重复的正整数范围在0到20亿之间可以用一个20亿bit的bitmap标记哪些数字出现过然后按顺序扫描bitmap就能得到排序结果。20亿bit换算成内存是250MB比存原始数据省了差不多10倍的空间。这种解法在笔试里答出来非常加分因为它体现了对空间复杂度的敏感和创造性思维。6.2 系统设计题的答题结构系统设计题没有标准答案但有通用的答题框架。我的经验是无论题目是什么——设计一个微博Feed流系统设计一个短链接服务设计一个秒杀系统——都要按以下几个层次依次展开回答。第一层明确需求。先问清楚功能需求和非功能需求。比如设计Feed流功能上要支持发Feed、关注、拉取关注人的Feed非功能上要关注延迟、可用性、扩展性。很多候选人上来就画架构图这是最大的误区。笔试中没法和人交互确认需求所以要在答题开头主动列出自己的假设这本身就是一种能力展示。第二层估算容量。根据用户规模和交互频率估算QPS、存储量。比如100万日活用户每个用户平均每天刷50次Feed那就是5000万次请求平均QPS约为578峰值可能到3000到5000。存储方面如果用户平均关注200人用Redis存关注关系和Feed一天的Feed数据量大致可以算出来。第三层设计核心流程。把关键链路的数据结构和模块划分讲清楚。Feed流系统的经典方案是推拉结合发Feed时先把Feed写入发件箱同时推送给活跃粉丝的收件箱队列不活跃的粉丝采用拉模式登录时从关注人的发件箱拉取最新的Feed再聚合。这样在推的实时性和拉的成本之间取得平衡。热点问题比如大V发Feed需要用拉模式避免粉丝量过大导致的写放大。第四层讨论瓶颈和优化。Redis缓存命中率怎么提升消息队列削峰怎么做数据库主从复制延迟怎么解决故障切换和数据一致性怎么权衡这些内容才是系统设计题真正的得分点前面几层所有人都能想到最后一层的深度直接拉卡差距。我见过很多候选人在系统设计这一关翻车不是知识储备不够而是没有形成结构化的表达习惯。答题时先画需求-架构-流程-瓶颈的框架再往框架里填细节无论题目多开放都能行云流水地展开。写在最后的几点备考心得回过头来看百度2015年大数据云计算研发的笔试题最核心的考察逻辑其实是三个关键词原理理解、动手能力、系统思维。原理理解看的是你有没有读过源码理解组件背后的设计哲学动手能力看的是你有没有真的在大规模集群上处理过问题背结论的人遇到变式题很容易露馅系统思维看的是你能否把分散的知识点串成一张网用体系化的方式去解答开放性问题。我本人经历过那个阶段的笔试和面试也面试过不少候选人最大的感受是准备这类笔试千万不能抱着把知识点背完的的心态。你背得完HDFS的流程但你背不完网络上无穷无尽的变化题。正确的备考姿势是拿到一个题目先理解它背后的场景和动机再顺着技术演进的脉络把相关知识体系铺开最后回到实际项目中去验证和深化。这样学到的内容才是真正属于自己的也才能在未来遇到陌生问题时举一反三。现在再回头看我当年备考时亲手整理的笔记那个时期的很多命令和配置已经过时了但背后分布式系统的设计原则和解决大规模数据问题的思维方式到今天依然在指导我的工作。技术迭代很快框架换了一茬又一茬但那些底层的东西——一致性、容错、性能调优、架构权衡——永远不会过时。希望这篇复盘对你的备考有所帮助祝顺利。