大数据面试必备知识点：涵盖JVM、设计模式、数据库与并发

需积分: 4 115 浏览量更新于2024-07-22 1 收藏 1.96MB PDF 举报

"大数据面试宝典，内容涵盖大数据面试题、技术细节、面试经验与学习资源，不断更新，旨在帮助面试者准备阿里巴巴等公司的面试。" 本文档是关于大数据面试的综合指南，来源于about云大数据面试题板块，包含了多轮面试的经典问题及答案，涉及到Java基础、JVM内存管理、设计模式、并发编程、数据库设计、操作系统、服务器优化等多个方面。以下是对这些知识点的详细解释： 1. **JDK源码**：面试中可能会询问你阅读过哪些JDK源码，这涉及到对Java核心类库的理解，如集合框架、并发库等。 2. **HashMap与ConcurrentHashMap**：这两个集合类的实现原理是Java面试的常考点，特别是扩容机制和并发安全性。 3. **JVM内存模型与GC**：面试者需要理解堆、栈、方法区等内存区域，以及垃圾回收的工作原理。 4. **ClassLoader**：双亲委派模型是Java类加载机制的关键，面试中可能要求你解释为何不能自定义`java.lang.String`类。 5. **设计模式**：面试者需熟悉六大设计原则（单一职责、开闭原则、里氏替换、依赖倒置、接口隔离、迪米特法则）并能与具体设计模式关联。 6. **UML**：类图、对象图、序列图等UML图的应用和不同类之间的关系（继承、聚合、组合等）。 7. **性能测试与并发框架**：如使用过的并发库，性能优化的实践案例，以及OSGI框架的理解。 8. **JVM内存调优**：涉及调优工具（如JVisualVM）的使用，如何分析和优化内存分配。 9. **数据库设计**：主键ID设计的原则，比如唯一性、稳定性、无业务含义等。 10. **Servlet/Filter**：理解其工作原理和配置，以及在Web应用中的作用。 11. **Spring AOP**：基于切面编程，了解其自动注入配置和所用的设计原则。 12. **Session共享机制**：跨服务器的会话共享，如使用cookie、数据库或分布式缓存实现。 13. **应用服务器优化**：例如JVM参数调整，以及在实际项目中的应用。 14. **最新技术关注**：对新兴技术如Swift语言的看法，显示你是否跟进行业动态。这份面试宝典不仅适用于大数据岗位，也涵盖了广泛的Java后端开发知识。通过深入理解和掌握这些知识点，面试者能够更好地应对各类技术面试。同时，文档鼓励读者参与交流和学习，持续提升自己的技术水平。

www.aboutyun.com

4、大数据量（100s TB 级数据）且有快速随机访问的需求。

如：淘宝的交易历史记录。数据量巨大无容置疑，面向普通用户的请求必然要即时响应。

5、容量的优雅扩展

大数据的驱使，动态扩展系统容量的必须的。例如：webPage DB。

6、业务场景简单，不需要关系数据库中很多特性（例如交叉列、交叉表，事务，连接等等）

7、优化方面：合理设计 rowkey。因为 hbase 的查

6、hbase 的 rowkey 设计，影响 hbase 的性能有哪些。

由于使用 hbase 不多，hbase 的 rowkey 的设计就不多说了，哪位大神使用过，做一下补充。

1 hbase.hregion.max.filesize 应该设置多少合适。

默认是 256，HStoreFile 的最大值。如果任何一个 Column Family（或者说 HStore）的 HStoreFiles 的大

小超过这个值，那么，其所属的 HRegion 就会 Split 成两个。

众所周知 hbase 中数据一开始会写入 memstore，当 memstore 满 64MB 以后，会 flush 到 disk 上而成为

storefile。当 storefile 数量超过 3 时，会启动 compaction 过程将它们合并为一个 storefile。这个过程中会

删除一些 timestamp 过期的数据，比如 update 的数据。而当合并后的 storefile 大小大于 hfile 默认最大值

时，会触发 split 动作，将它切分成两个 region。

2、autoflush=false 的影响

无论是官方还是很多 blog 都提倡为了提高 hbase 的写入速度而在应用代码中设置 autoflush=false，然

后 lz 认为在在线应用中应该谨慎进行该设置原因如下：

2.1、autoflush=false 的原理是当客户端提交 delete 或 put 请求时，将该请求在客户端缓存，直到数据

超过 2M(hbase.client.write.buffer 决定)或用户执行了 hbase.flushcommits()时才向 regionserver 提交请求。

因此即使 htable.put()执行返回成功，也并非说明请求真的成功了。假如还没有达到该缓存而 client 崩溃，

该部分数据将由于未发送到 regionserver 而丢失。这对于零容忍的在线服务是不可接受的。

2.2、autoflush=true 虽然会让写入速度下降 2-3 倍，但是对于很多在线应用来说这都是必须打开的，

也正是 hbase 为什么让它默认值为 true 的原因。当该值为 true 时，每次请求都会发往 regionserver,而

regionserver 接收到请求后第一件事就是写 hlog，因此对 io 的要求是非常高的，为了提高 hbase 的写入速

度，应该尽可能高地提高 io 吞吐量，比如增加磁盘、使用 raid 卡、减少 replication 因子数等。

从性能的角度谈 table 中 family 和 qualifier 的设置

3、对于传统关系型数据库中的一张 table，在业务转换到 hbase 上建模时，从性能的角度应该如何设置 family

和 qualifier 呢？

最极端的，①每一列都设置成一个 family，②一个表仅有一个 family，所有列都是其中的一个 qualifier，

那么有什么区别呢？

从读的方面考虑：

family 越多，那么获取每一个 cell 数据的优势越明显，因为 io 和网络都减少了。

如果只有一个 family，那么每一次读都会读取当前 rowkey 的所有数据，网络和 io 上会有一些损失。

当然如果要获取的是固定的几列数据，那么把这几列写到一个 family 中比分别设置 family 要更好，因

为只需一次请求就能拿回所有数据。

从写的角度考虑：

首先，内存方面来说，对于一个Region，会为每一个表的每一个 Family 分配一个Store，而每一个 Store，

www.aboutyun.com

都会分配一个 MemStore，所以更多的 family 会消耗更多的内存。

其次，从 flush 和 compaction 方面说，目前版本的 hbase，在 flush 和 compaction 都是以 region 为单

位的，也就是说当一个 family 达到 flush 条件时，该 region 的所有 family 所属的 memstore 都会 flush 一

次，即使 memstore 中只有很少的数据也会触发 flush 而生成小文件。这样就增加了 compaction 发生的机

率，而 compaction 也是以 region 为单位的，这样就很容易发生 compaction 风暴从而降低系统的整体吞吐

量。

第三，从 split 方面考虑，由于 hfile 是以 family 为单位的，因此对于多个 family 来说，数据被分散到

了更多的 hfile 中，减小了 split 发生的机率。这是把双刃剑。更少的 split 会导致该 region 的体积比较大，

由于 balance 是以 region 的数目而不是大小为单位来进行的，因此可能会导致 balance 失效。而从好的方

面来说，更少的 split 会让系统提供更加稳定的在线服务。而坏处我们可以通过在请求的低谷时间进行人工

的 split 和 balance 来避免掉。

因此对于写比较多的系统，如果是离线应该，我们尽量只用一个 family 好了，但如果是在线应用，那还是

应该根据应用的情况合理地分配 family

7、storm 中如何实现统计 uv 的不重复。

storm 主要是通过 Transactional topology，确保每次 tuple 只被处理一次。给每个 tuple 按顺序加一个 id，

在处理过程中，将成功处理的 tuple id 和计算保存在数据库当中，但是这种机制使得系统一次只能处理一

个 tuple，无法实现分布式计算。

我们要保证一个 batch 只被处理一次，机制和上一节类似。只不过数据库中存储的是 batch id。batch 的中

间计算结果先存在局部变量中，当一个 batch 中的所有 tuple 都被处理完之后，判断 batch id，如果跟数据

库中的 id 不同，则将中间计算结果更新到数据库中。

Storm 提供的 Transactional Topology 将 batch 计算分为 process 和 commit 两个阶段。Process 阶段可以

同时处理多个 batch，不用保证顺序性；commit 阶段保证 batch 的强顺序性，并且一次只能处理一个 batch，

第 1 个 batch 成功提交之前，第 2 个 batch 不能被提交。这样就保证多线程情况下值能处理一个 batch。

8、redis 分布式实现原理。如何实现读写分离，在这个过程当中使用了哪些算法，有什么好处。

memcache 只能说是简单的 kv 内存数据结构,而 redis 支持的数据类型比较丰富。Redis 在 3.0 以后实现集

群机制。目前 Redis 实现集群的方法主要是采用一致性哈稀分片（Shard），将不同的 key 分配到不同的 redis

server 上，达到横向扩展的目的。

使用了一致性哈稀进行分片，那么不同的 key 分布到不同的 Redis-Server 上，当我们需要扩容时，需要增

加机器到分片列表中，这时候会使得同样的 key 算出来落到跟原来不同的机器上，这样如果要取某一个值，

会出现取不到的情况，对于这种情况，Redis 的提出了一种名为 Pre-Sharding 的方式：

使用了 redis 的集群模式：存在以下几个问题

A：扩容问题：

Pre-Sharding 方法是将每一个台物理机上，运行多个不同断口的 Redis 实例，假如有三个物理机，每个物

理机运行三个 Redis 实际，那么我们的分片列表中实际有 9 个 Redis 实例，当我们需要扩容时，增加一台

物理机，步骤如下：

1、在新的物理机上运行 Redis-Server；

2、该 Redis-Server 从属于(slaveof)分片列表中的某一 Redis-Server（假设叫 RedisA）；

3、等主从复制(Replication)完成后，将客户端分片列表中 RedisA 的 IP 和端口改为新物理机上 Redis-Server

的 IP 和端口；

4、停止 RedisA.

B: 单点故障问题

www.aboutyun.com

将一个 Redis-Server 转移到了另外一台上。Prd-Sharding 实际上是一种在线扩容的办法，但还是很依赖

Redis 本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。

9、spark 如何保证宕机迅速恢复。

了解了 RDD，那么这个问题就迎刃而解了

RDD 的好处

RDD 只能从持久存储或通过 Transformations 操作产生，相比于分布式共享内存（DSM）可以更高效实现

容错，对于丢失部分数据分区只需根据它的 lineage 就可重新计算出来，而不需要做特定的 Checkpoint。

RDD 的不变性，可以实现类 Hadoop MapReduce 的推测式执行。

RDD 的数据分区特性，可以通过数据的本地性来提高性能，这与 Hadoop MapReduce 是一样的。

RDD 都是可序列化的，在内存不足时可自动降级为磁盘存储，把 RDD 存储于磁盘上，这时性能会有大的

下降但不会差于现在的 MapReduce。

RDD 的存储与分区

用户可以选择不同的存储级别存储 RDD 以便重用。

当前 RDD 默认是存储于内存，但当内存不足时，RDD 会 spill 到 disk。

RDD 在需要进行分区把数据分布于集群中时会根据每条记录 Key 进行分区（如 Hash 分区），以此保证两

个数据集在 Join 时能高效。

RDD 的内部表示

在 RDD 的内部实现中每个 RDD 都可以使用 5 个方面的特性来表示：

分区列表（数据块列表）

计算每个分片的函数（根据父 RDD 计算出此 RDD）

对父 RDD 的依赖列表

对 key-value RDD 的 Partitioner【可选】

每个数据分片的预定义地址列表(如 HDFS 上的数据块的地址)【可选】

10、hadoop 中两个大表实现 join 的操作，简单描述。

这个简单了。

10.1 map 读取两个表，分别标示一下，然后 context 输出。reduce 做笛卡尔积。

10.2 map 之前 setup 时先 DistributeCache，然后 map 阶段扫描大表。

www.aboutyun.com

机器学习、大数据面试问题及答题思路

自己的专业方向是机器学习、数据挖掘，就业意向是互联网行业与本专业相关的工作岗位。各个企业对这

类岗位的命名可能有所不同，比如数据挖掘/自然语言处理/机器学习算法工程师，或简称算法工程师，还

有的称为搜索/推荐算法工程师，甚至有的并入后台工程师的范畴，视岗位具体要求而定。

机器学习、大数据相关岗位的职责

自己参与面试的提供算法岗位的公司有 BAT、小米、360、飞维美地、宜信、猿题库等，根据业务的不同，

岗位职责大概分为：

1、平台搭建类

 数据计算平台搭建，基础算法实现，当然，要求支持大样本量、高维度数据，所以可能还需要底层

开发、并行计算、分布式计算等方面的知识；

2、算法研究类

 文本挖掘，如领域知识图谱构建、垃圾短信过滤等；

 推荐，广告推荐、APP 推荐、题目推荐、新闻推荐等；

 排序，搜索结果排序、广告排序等；

 广告投放效果分析；

 互联网信用评价；

 图像识别、理解。

3、数据挖掘类

 商业智能，如统计报表；

 用户体验分析，预测流失用户。

以上是根据本人求职季有限的接触所做的总结。有的应用方向比较成熟，业界有足够的技术积累，比如搜

索、推荐，也有的方向还有很多开放性问题等待探索，比如互联网金融、互联网教育。在面试的过程中，

一方面要尽力向企业展现自己的能力，另一方面也是在增进对行业发展现状与未来趋势的理解，特别是可

以从一些刚起步的企业和团队那里，了解到一些有价值的一手问题。

以下首先介绍面试中遇到的一些真实问题，然后谈一谈答题和面试准备上的建议。

面试问题

1、你在研究/项目/实习经历中主要用过哪些机器学习/数据挖掘的算法？

剩余177页未读，继续阅读

xstarcto

粉丝: 0
资源: 3

大数据面试必备知识点：涵盖JVM、设计模式、数据库与并发

"大数据面试宝典：Java基础-面向对象特征及封装的重要性

Java大数据面试宝典：核心知识与技术详解

大数据面试宝典： SecondaryNameNode详解与Flume数据处理策略

程序员大数据面试宝典

超全大数据面试宝典-大数据面试有这套就够了.pdf

大数据面试宝典2023整理

大数据面试宝典.rar

大数据面试宝典 .doc

大数据面试宝典.docx

大数据面试宝典 .docx

最新资源