大数据面试问题

GC的原理，算法及不同代使用的算法

 

hashmap、hashtable、concurrentmap原理，内部算法和逻辑

 

数据库的四大原则，缺少某一原则会有什么后果

 

数据库索引是什么数据结构

 

spark streaming如果出错怎么办

 

flume如果数据导入HDFS出错怎么办

 

flapmap是如何实现的，是否可以写一个

 

 

spark streaming的数据是谁读取的

 

流程是什么

 

windows窗体算子

 

有这些简单的

 

都觉得挺难的

 

还有就是 如果数据太多，kafka读不过来，怎么办

 

还会问 你处理过的数据量有多大？ 有没有遇到什么问题？

 

:

然后还会问服务器的问题, 他们说GB级别一些问题发现不了, 他们需要处理过TB以上级别的

Hadoop：    

    50070：HDFS WEB UI端口

    8020 ： 高可用的HDFS RPC端口

    9000 ： 非高可用的HDFS RPC端口

    8088 ： Yarn 的WEB UI 接口

    8485 ： JournalNode 的RPC端口

    8019 ： ZKFC端口

   19888：jobhistory WEB UI端口

Zookeeper:

    2181 ： 客户端连接zookeeper的端口

    2888 ： zookeeper集群内通讯使用，Leader监听此端口

    3888 ： zookeeper端口 用于选举leader

Hbase:

    60010：Hbase的master的WEB UI端口 （旧的） 新的是16010

    60030：Hbase的regionServer的WEB UI 管理端口    

Hive:

    9083  :  metastore服务默认监听端口

    10000：Hive 的JDBC端口

Spark：

    7077 ： spark 的master与worker进行通讯的端口  standalone集群提交Application的端口

    8080 ： master的WEB UI端口  资源调度

    8081 ： worker的WEB UI 端口  资源调度

    4040 ： Driver的WEB UI 端口  任务调度

    18080：Spark History Server的WEB UI 端口

Kafka：

    9092： Kafka集群节点之间通信的RPC端口

Redis：

    6379： Redis服务端口

CDH：

    7180： Cloudera Manager WebUI端口

    7182： Cloudera Manager Server 与 Agent 通讯端口

JVM优化

要查找和评估器性能瓶颈，首先要知道性能定义，对于jvm调优来说，我们需要知道以下三个定义属性，依作为评估基础:

吞吐量：重要指标之一，是指不考虑垃圾收集引起的停顿时间或内存消耗，垃圾收集器能支撑应用达到的最高性能指标。 

延迟：其度量标准是缩短由于垃圾啊收集引起的停顿时间或者完全消除因垃圾收集所引起的停顿，避免应用运行时发生抖动。 

内存占用：垃圾收集器流畅运行所需要 的内存数量。 

这三个属性中，其中一个任何一个属性性能的提高，几乎都是以另外一个或者两个属性性能的损失作代价，不可兼得，具体某一个属性或者两个属性的性能对应用来说比较重要，要基于应用的业务需求来确定。

 

调优总结

年轻代大小选择

• • 响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
  • 吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

年老代大小选择

• • 响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：