问题导读： 1、项目中遇到过哪些问题？ 2、Kafka消息数据积压，Kafka消费能力不足怎么处理？ 3、Sqoop数据导出一致性问题？ 4、整体项目框架如何设计？

项目中遇到过哪些问题7.1 Hadoop宕机（1）如果MR造成系统宕机。此时要控制Yarn同时运行的任务数，和每个任务申请的最大内存。调整参数：yarn.scheduler.maximum-allocation-mb（单个任务可申请的最多物理内存量，默认是8192MB）（2）如果写入文件过量造成NameNode宕机。那么调高Kafka的存储大小，控制从Kafka到HDFS的写入速度。高峰期的时候用Kafka进行缓存，高峰期过去数据同步会自动跟上。7.2 Flume小文件Flume上传文件到HDFS时参数大量小文件?调整hdfs.rollInterval、hdfs.rollSize、hdfs.rollCount这三个参数的值。7.3 Kafka挂掉（1）Flume记录（2）日志有记录（3）短期没事7.4 Kafka消息数据积压，Kafka消费能力不足怎么处理？（1）如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）（2）如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间实现三个方法init(指定返回值的名称和类型)、process(处理字段一进多出)、close方法) -> 更加灵活以及方便定义bug7.8 Sqoop数据导出ParquetAds层数据用Sqoop往MySql中导入数据的时候，如果用了orc（Parquet）不能导入，需转化成text格式7.9 Sqoop数据导出控制Sqoop中导入导出Null存储一致性问题：   Hive中的Null在底层是以“\N”来存储，而MySQL中的Null在底层就是Null，为了保证数据两端的一致性。在导出数据时采用--input-null-string和--input-null-non-string两个参数。导入数据时采用--null-string和--null-non-string。7.10 Sqoop数据导出一致性问题当Sqoop导出数据到MySql时，使用4个map怎么保证数据的一致性因为在导出数据的过程中map任务可能会失败，可以使用—staging-table  –clear-staging

复制代码任务执行成功首先在tmp临时表中，然后将tmp表中的数据复制到目标表中（这个时候可以使用事务，保证事务的一致性）7.11 SparkStreaming优雅关闭如何优雅的关闭SparkStreaming任务（将写好的代码打包，Spark-Submit）Kill -9 xxx ?开启另外一个线程每5秒监听HDFS上一个文件是否存在。如果检测到存在，调用ssc.stop()方法关闭SparkStreaming任务（当你要关闭任务时，可以创建你自定义监控的文件目录）7.12 Spark OOM、数据倾斜解决项目经验9.1 框架经验9.1.1 Hadoop1）Hadoop集群基准测试（HDFS的读写性能、MapReduce的计算能力测试）2）一台服务器一般都有很多个硬盘插槽（插了几个插槽）如果不配置datanode.data.dir多目录，每次插入一块新的硬盘都需要重启服务器配置了即插即用3）Hdfs参数调优Namenode有一个工作线程池，用来处理与datanode的心跳（报告自身的健康状况和文件恢复请求）和元数据请求    dfs.namenode.handler.count=20 * log2(Cluster Size)4）编辑日志存储路径dfs.namenode.edits.dir设置与镜像文件存储路径dfs.namenode.name.dir尽量分开，达到最低写入延迟（提高写入的吞吐量）5）YARN参数调优yarn-site.xml（1）服务器节点上YARN可使用的物理内存总量，默认是8192（MB）（2）单个任务可申请的最多物理内存量，默认是8192（MB）。6）HDFS和硬盘空闲控制在70%以下。9.1.2 Flume1)    Flume内存配置为4G（flume-env.sh修改）2)    FileChannel优化通过配置dataDirs指向多个路径，每个路径对应不同的硬盘，增大Flume吞吐量。checkpointDir和backupCheckpointDir也尽量配置在不同硬盘对应的目录中，保证checkpoint坏掉后，可以快速使用backupCheckpointDir恢复数据3)    Sink：HDFS Sink小文件处理这三个参数配置写入HDFS后会产生小文件，hdfs.rollInterval、hdfs.rollSize、hdfs.rollCount9.1.3 Kafka1)    Kafka的吞吐量测试（测试生产速度和消费速度）2)    Kafka内存为6G（不能超过6G）3)    Kafka数量确定：2 * 峰值生产速度（m/s）* 副本数 / 100  + 1 = ?4)    Kafka中的数据量计算每天数据总量100g(1亿条)   10000万/24/60/60 = 1150条/s平均每秒钟：1150条低谷每秒：400条高峰每秒钟：1150 * 10 = 11000 条每条日志大小： 1K左右每秒多少数据量：20MB5)    Kafka消息数据积压，Kafka消费能力不足怎么处理？（1）如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）（2）如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间