玩linux系统十几年了，好长时间没有碰到过网络问题了。浪费一个小时去解决。挺怪的一个问题。
spark申请资源时，报错了，如下
2019-05-15 10:15:15 INFO BlockManagerInfo:54 - Added broadcast_0_piece0 in memory on namenode1:37836 (size: 83.1 KB, free: 6.2 GB)
2019-05-15 10:15:15 INFO SparkContext:54 - Created broadcast 0 from broadcast at DAGScheduler.scala:1161
2019-05-15 10:15:15 INFO DAGScheduler:54 - Submitting 2 missing tasks from ResultStage 0 (MapPartitionsRDD[1] at sql at run.scala:132) (first 15 tasks are for partitions Vector(0, 1))
2019-05-15 10:15:15 INFO YarnScheduler:54 - Adding task set 0.0 with 2 tasks
2019-05-15 10:15:30 WARN YarnScheduler:66 - Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient resources
提示已经很清楚了，资源不够。因资源不够报出来的错识，非常的多。以前写的博客里面有提到了一些。
一个topic创建了几个partition，启动consumer的时候，只会消费一个partition，消费完了后，会把这个consumer给关闭掉。再启动consumer时，还是只会消费上次消费的那个partition。中间没有任何报错。
删除topic后，在重新创建相同名字的topic，报错了。下面总结一套，可行的方案。
kafka设置了max.poll.records为50000条，但是只能读取到1400条左右，没有任何报错。估计应当是配置问题。
元数据换成mysql，请参考：hive mysql 安装配置，spark从kafka读取数据后，入库hdfs时，会连接mysql元数据库，spark采用的是长连接，当spark关闭时，连接会处于睡眠状态。长时间不处理，mysql的连接数就会被占满。
kafka topic的partitions为1时，存取的数据，只会在kafka集群中的一台机器上面，时间一长，必然会造成，资源不均衡。
auto.offset.reset关乎kafka数据的读取，是一个非常重要的设置。常用的二个值是latest和earliest，默认是latest。
如果实时的从kafka取数据，通过spark入hdfs，会产生很多的task，在hdfs上会产生非常多的小文件。浪费硬盘空间不说，在用spark进行数据分析的时间，非常耗spark节点的内存。
最好不要实时的入库，间断去运行。这样会尽量减少小文件的产生。但是不能根本上解决小问题，最终还是通过CombineFileInputFormat来解决，这个后面的文章，会单独说。
producter生产消息，基本上没有出现过问题，但是consumer遇到了不少问题。用是kafka2系列。