爬取好的数据为什么不适用python一次性的处理完成，进行展示
爬取的数据有两点，一数据量大，这就导致了使用python处理数据的难度非常大，异常缓慢，二数据内容杂，很多缺项的数据混进来，对我们的分析处理产生干扰，而python是难以筛选这些数据的，所以往往我们要通过集群进行大量数据的清洗，然后通过算法分析产生的结果进行展示
你们公司有多少个节点
10个
如果节点宕机，怎么做
下面的是一个集群宕机的案例
10月27日下午，机房中心交换机坏掉，导致HDFS集群和MR（YARN）集群宕掉。
当时的日志现在已查不到，只能推断整个集群宕掉的原因。
HDFS和YARN的集群，都是master/slave模式，其中处于master角色的组件有：NameNode，ResourceManager。某种角度，只要master没有挂掉，可以认为集群没有挂掉。
同时，我们的HDFS集群和YARN集群都配置了HA，所以master角色可以认为还包括standby NN和standby RMs。
在HDFS HA集群中，JournalNodes也是很重要的角色，因为JN group一旦挂掉或仅仅无法与NNs通信，NNs都不能正常工作。HDFS HA和YARN HA也都依赖Zookeeper集群。
10月27日下午，交换机坏掉后，active NN与其他所有机器都不能通信，包括JNs，这导致active NN shutdown。因为之前standby NN是stop的状态，所以无法进行HA切换。实际上，即使能切换，standby NN所在的机器与其他集群不能通信。所以，这导致HDFS集群整个挂掉。
一个相关的issue：https://issues.apache.org/jira/browse/HDFS-8298。
因为YARN集群配置了HA（实际之前ops没有配置完整，仅仅是相当于打开了RM HA的开关，其他必要的与RM Restart相关的配置都没有），当天下午交换机坏掉后，active RM与ZK失联，自动切换到standby RM，但由于配置不完善（这个很致命），同时standby RM与ZK也是失联的，导致没有RM可以正常工作，YARN集群整个挂掉。
这是当时ops收到的一条报警：Info:Critical! Yarn ResourceManager host 192.168.146.64 status have problem, status is ACTIVE! Time: Tue+Oct+27+19:06:41+CST+201。
当天下午交换机临时回复后，我们对Hadoop集群依次进行了以下操作：
1、启动active NN
2、启动DataNodes
3、启动active RM
4、启动standby NN
第一步active NN正常启动，但由于standby NN已经停了两个多月，active NN在启动时，对fsimage和edits进行checkpoint耗时过多，导致active NN启动时间过长。
第二步没有问题。
第三步基本没有问题，但由于没有配置RM Restart，导致所有未完成的jobs需要重新提交和执行。
第四步也是正常启动，但也由于standby NN已经停了两个多月，JNs上需要checkpoint的edits过多，导致启动时间超长，而且checkpoint占用大量时间。
什么是lambda函数？它有什么好处?
lambda 函数是一个可以接收任意多个参数(包括可选参数)并且返回单个表达式值的函数。 （注意：lambda 函数不能包含命令，它们所包含的表达式不能超过一个）
好处
1、lambda函数比较轻便，即用即仍，很适合需要完成一项功能，但是此功能只在此一处使用，连名字都很随意的情况下；
2、匿名函数，一般用来给filter，map这样的函数式编程服务;
3、作为回调函数，传递给某些应用，比如消息处理
