1、Operation category READ is not supported in state standby是什麼原因導致的
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.ipc.StandbyException): Operation category READ is not supported in state standby 答：此時請登錄Hadoop的管理界面查看運行節點是否處於standby
如登錄地址是：http://xx.xx.xx.xx:50070/dfshealth.html#tab-overview
如果是，則不可在處於StandBy機器運行spark計算，因爲該臺機器爲備分機器
2、不配置spark.deploy.recoveryMode選項爲ZOOKEEPER，會有什麼不好的地方
如果不設置spark.deploy.recoveryMode的話，那麼集羣的所有運行數據在Master重啓是都會丟失，可參考BlackHolePersistenceEngine的實現。
3、多Master如何配置
因爲涉及到多個Master，所以對於應用程序的提交就有了一點變化，因爲應用程序需要知道當前的Master的IP地址和端口。這種HA方案處理這種情況很簡單，只需要在SparkContext指向一個Master列表就可以了，如spark://host1:port1,host2:port2,host3:port3，應用程序會輪詢列表。
4、No Space Left on the device（Shuffle臨時文件過多）
由於Spark在計算的時候會將中間結果存儲到/tmp目錄，而目前linux又都支持tmpfs，其實就是將/tmp目錄掛載到內存當中。
那麼這裏就存在一個問題，中間結果過多導致/tmp目錄寫滿而出現如下錯誤
No Space Left on the device
解決辦法
第一種：修改配置文件spark-env.sh,把臨時文件引入到一個自定義的目錄中去即可
export SPARK_LOCAL_DIRS=/home/utoken/datadir/spark/tmp
第二種：偷懶方式，針對tmp目錄不啓用tmpfs,直接修改/etc/fstab
5、java.lang.OutOfMemory, unable to create new native thread
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:640)
上面這段錯誤提示的本質是Linux操作系統無法創建更多進程，導致出錯，並不是系統的內存不足。因此要解決這個問題需要修改Linux允許創建更多的進程，就需要修改Linux最大進程數。
[utoken@nn1 ~]$ulimit -a
臨時修改允許打開的最大進程數
[utoken@nn1 ~]$ulimit -u 65535
臨時修改允許打開的文件句柄
[utoken@nn1 ~]$ulimit -n 65535
永久修改Linux最大進程數量
[utoken@nn1 ~]$ vim /etc/security/limits.d/90-nproc.conf
soft nproc 60000
root soft nproc unlimited
永久修改用戶打開文件的最大句柄數，該值默認1024，一般都會不夠，常見錯誤就是not open file
[utoken@nn1 ~]$ vim /etc/security/limits.conf
bdata soft nofile 65536
bdata hard nofile 65536
6、Worker節點中的work目錄佔用許多磁盤空間
目錄地址：/home/utoken/software/spark-1.3.0-bin-hadoop2.4/work
這些是Driver上傳到worker的文件，需要定時做手工清理，否則會佔用許多磁盤空間
7、spark-shell提交Spark Application如何解決依賴庫
spark-shell的話，利用–driver-class-path選項來指定所依賴的jar文件，注意的是–driver-class-path後如果需要跟着多個jar文件的話，jar文件之間使用冒號(:)來分割。
8、Spark在發佈應用的時候，出現連接不上master問題，如下
15/11/19 11:35:50 INFO AppClient$ClientEndpoint: Connecting to master spark://s1:7077…
15/11/19 11:35:50 WARN ReliableDeliverySupervisor: Association with remote system [akka.tcp://sparkMaster@s1:7077] has failed, address is now gated for [5000] ms. Reason: [Disassociated]
解決方式
檢查所有機器時間是否一致、hosts是否都配置了映射、客戶端和服務器端的Scala版本是否一致、Scala版本是否和Spark兼容
檢查是否兼容問題請參考官方網站介紹：
9、開發spark應用程序（和Flume-NG結合時）發佈應用時可能出現
org.jboss.netty.channel.ChannelException: Failed to bind to: /192.168.10.156:1880015/11/27 10:33:44 ERROR ReceiverSupervisorImpl: Stopped receiver with error: org.jboss.netty.channel.ChannelException: Failed to bind to: /192.168.10.156:18800
15/11/27 10:33:44 ERROR Executor: Exception in task 0.0 in stage 2.0 (TID 70)
org.jboss.netty.channel.ChannelException: Failed to bind to: /192.168.10.156:18800
at org.jboss.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:272)
Caused by: java.net.BindException: Cannot assign requested address
由於spark通過Master發佈的時候，會自動選取發送到某一臺的worker節點上，所以這裏綁定端口的時候，需要選擇相應的worker服務器，但是由於我們無法事先瞭解到，spark發佈到哪一臺服務器的，所以這裏啓動報錯，是因爲在 192.168.10.156:18800的機器上面沒有啓動Driver程序，而是發佈到了其他服務器去啓動了，所以無法監聽到該機器出現問題，所以我們需要設置spark分發包時，發佈到所有worker節點機器，或者發佈後，我們去尋找發佈到了哪一臺機器，重新修改綁定IP，重新發布，有一定機率發佈成功。詳情可見《印象筆記-戰5渣系列——Spark Streaming啓動問題 - 推酷》
10、spark-shell 找不到hadoop so問題解決
[main] WARN org.apache.hadoop.util.NativeCodeLoader - Unable to load native-hadoop library for your platform… using builtin-java classes where applicable
在Spark的conf目錄下，修改spark-env.sh文件，加入LD_LIBRARY_PATH環境變量，值爲HADOOP的native庫路徑即可.
11、ERROR XSDB6: Another instance of Derby may have already booted the database /home/bdata/data/metastore_db.
在使用Hive on Spark模式操作hive裏面的數據時，報以上錯誤，原因是因爲HIVE採用了derby這個內嵌數據庫作爲數據庫，它不支持多用戶同時訪問,解決辦法就是把derby數據庫換成mysql數據庫即可
變更方式
12、java.lang.IllegalArgumentException: java.net.UnknownHostException: dfscluster
解決辦法：
找不到hdfs集羣名字dfscluster,這個文件在HADOOP的etc/hadoop下面，有個文件hdfs-site.xml，複製到Spark的conf下，重啓即可
如：執行腳本，分發到所有的Spark集羣機器中，
[bdata@bdata4 hadoop]foriin34,35,36,37,38;doscphdfs−site.xml192.168.10.i:/u01/spark-1.5.1/conf/ ; done
13、Exception in thread “main” java.lang.Exception: When running with master ‘yarn-client’ either HADOOP_CONF_DIR or
YARN_CONF_DIR must be set in the environment.
問題：在執行yarn集羣或者客戶端時，報以上錯誤，
[bdata@bdata4 bin]$ ./spark-sql –master yarn-client
Exception in thread “main” java.lang.Exception: When running with master ‘yarn-client’ either HADOOP_CONF_DIR or YARN_CONF_DIR must be set in the environment.
解決辦法
根據提示，配置HADOOP_CONF_DIR or YARN_CONF_DIR的環境變量即可
export HADOOP_HOME=/u01/hadoop-2.6.1
export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop
PATH=PATH:HOME/.local/bin:HOME/bin:SQOOP_HOME/bin:HIVEHOME/bin:HADOOP_HOME/bin
14、Job aborted due to stage failure: Task 3 in stage 0.0 failed 4 times, most recent failure: Lost task 3.3 in
[Stage 0:> (0 + 4) / 42]2016-01-15 11:28:16,512 [org.apache.spark.scheduler.TaskSchedulerImpl]-[ERROR] Lost executor 0 on 192.168.10.38: remote Rpc client disassociated
[Stage 0:> (0 + 4) / 42]2016-01-15 11:28:23,188 [org.apache.spark.scheduler.TaskSchedulerImpl]-[ERROR] Lost executor 1 on 192.168.10.38: remote Rpc client disassociated
[Stage 0:> (0 + 4) / 42]2016-01-15 11:28:29,203 [org.apache.spark.scheduler.TaskSchedulerImpl]-[ERROR] Lost executor 2 on 192.168.10.38: remote Rpc client disassociated
[Stage 0:> (0 + 4) / 42]2016-01-15 11:28:36,319 [org.apache.spark.scheduler.TaskSchedulerImpl]-[ERROR] Lost executor 3 on 192.168.10.38: remote Rpc client disassociated
2016-01-15 11:28:36,321 [org.apache.spark.scheduler.TaskSetManager]-[ERROR] Task 3 in stage 0.0 failed 4 times; aborting job
Exception in thread “main” org.apache.spark.SparkException : Job aborted due to stage failure: Task 3 in stage 0.0 failed 4 times, most recent failure: Lost task 3.3 in stage 0.0 (TID 14, 192.168.10.38): ExecutorLostFailure (executor 3 lost)
Driver stacktrace:
at org.apache.spark.scheduler.DAGScheduler.org$apache$spark$scheduler$DAGScheduler$$failJobAndIndependentStages(DAGScheduler.scala:1283)
解決方案
這裏遇到的問題主要是因爲數據源數據量過大，而機器的內存無法滿足需求，導致長時間執行超時斷開的情況，數據無法有效進行交互計算，因此有必要增加內存
15、長時間等待無反應，並且看到服務器上面的web界面有內存和核心數，但是沒有分配，如下圖
[Stage 0:> (0 + 0) / 42]
或者日誌信息顯示：
16/01/15 14:18:56 WARN TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient resources
解決方案
出現上面的問題主要原因是因爲我們通過參數spark.executor.memory設置的內存過大，已經超過了實際機器擁有的內存，故無法執行，需要等待機器擁有足夠的內存後，才能執行任務，可以減少任務執行內存，設置小一些即可
16、內存不足或數據傾斜導致Executor Lost（spark-submit提交）
TaskSetManager: Lost task 1.0 in stage 6.0 (TID 100, 192.168.10.37): java.lang.OutOfMemoryError: Java heap space
16/01/15 14:29:51 INFO BlockManagerInfo: Added broadcast_8_piece0 in memory on 192.168.10.37:57139 (size: 42.0 KB, free: 24.2 MB)
16/01/15 14:29:53 INFO BlockManagerInfo: Added broadcast_8_piece0 in memory on 192.168.10.38:53816 (size: 42.0 KB, free: 24.2 MB)
16/01/15 14:29:55 INFO TaskSetManager: Starting task 3.0 in stage 6.0 (TID 102, 192.168.10.37, ANY, 2152 bytes)
16/01/15 14:29:55 WARN TaskSetManager: Lost task 1.0 in stage 6.0 (TID 100, 192.168.10.37): java.lang.OutOfMemoryError: Java heap space
at java.io.BufferedOutputStream.(BufferedOutputStream.java:76)
at java.io.BufferedOutputStream.(BufferedOutputStream.java:59)
…….
org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in stage 6.0 failed 4 times, most recent failure: Lost task 0.3 in stage 6.0 (TID 142, 192.168.10.36): ExecutorLostFailure (executor 4 lost)
……
WARN TaskSetManager: Lost task 4.1 in stage 6.0 (TID 137, 192.168.10.38): java.lang.OutOfMemoryError: GC overhead limit exceeded
解決辦法：
由於我們在執行Spark任務是，讀取所需要的原數據，數據量太大，導致在Worker上面分配的任務執行數據時所需要的內存不夠，直接導致內存溢出了，所以我們有必要增加Worker上面的內存來滿足程序運行需要。
在Spark Streaming或者其他spark任務中，會遇到在Spark中常見的問題，典型如Executor Lost 相關的問題(shuffle fetch 失敗，Task失敗重試等)。這就意味着發生了內存不足或者數據傾斜的問題。這個目前需要考慮如下幾個點以獲得解決方案：
A、相同資源下，增加partition數可以減少內存問題。 原因如下：通過增加partition數，每個task要處理的數據少了，同一時間內，所有正在運行的task要處理的數量少了很多，所有Executor佔用的內存也變小了。這可以緩解數據傾斜以及內存不足的壓力。
B、關注shuffle read 階段的並行數。例如reduce,group 之類的函數，其實他們都有第二個參數，並行度(partition數)，只是大家一般都不設置。不過出了問題再設置一下，也不錯。
C、給一個Executor 核數設置的太多，也就意味着同一時刻，在該Executor 的內存壓力會更大，GC也會更頻繁。我一般會控制在3個左右。然後通過提高Executor數量來保持資源的總量不變。
17、 Spark Streaming 和kafka整合後讀取消息報錯：OffsetOutOfRangeException
解決方案：如果和kafka消息中間件結合使用，請檢查消息體是否大於默認設置1m，如果大於，則需要設置fetch.message.max.bytes=1m，這裏需要把值設置大些
18、java.io.IOException : Could not locate executable null\bin\winutils.exe in the Hadoop binaries.（spark sql on hive 任務引發HiveContext NullPointerException）
解決辦法
在開發hive和Spark整合的時候，如果是Windows系統，並且沒有配置HADOOP_HOME的環境變量，那麼可能找不到winutils.exe這個工具，由於使用hive時，對該命令有依賴，所以不要忽視該錯誤，否則將無法創建HiveContext，一直報Exception in thread “main” java.lang.RuntimeException: java.lang.NullPointerException
因此，解決該辦法有兩個方式
A、把任務打包成jar，上傳到服務器上面，服務器是配置過HADOOP_HOME環境變量的，並且不需要依賴winutils,所以只需要通過spark-submit方式提交即可，如：
[bdata@bdata4 app]$ spark-submit –class com.pride.hive.HiveOnSparkTest –master spark://bdata4:7077 spark-simple-1.0.jar
B、解決winutils.exe命令不可用問題，配置Windows上面HADOOP_HOME的環境變量，或者在程序最開始的地方設置HADOOP_HOME的屬性配置,這裏需要注意，由於最新版本已經沒有winutils這些exe命令了，我們需要在其他地方下載該命令放入HADOOP的bin目錄下，當然也可以直接配置下載項目的環境變量，變量名一定要是HADOOP_HOME才行
下載地址：https://github.com/srccodes/hadoop-common-2.2.0-bin/archive/master.zip （記得翻牆哦）
任何項目都生效，需要配置Windows的環境變量，如果只在程序中生效可在程序中配置即可，如
//用於解決Windows下找不到winutils.exe命令
System. setProperty(“hadoop.home.dir”, “E:\Software\hadoop-common-2.2.0-bin” );
19、The root scratch dir: /tmp/hive on HDFS should be writable. Current permissions are: rwx
解決辦法
1、程序中設置環境變量：System.setProperty(“HADOOP_USER_NAME”, “bdata”)
2、修改HDFS的目錄權限
Update the permission of your /tmp/hive HDFS directory using the following command
hadoop dfs -chmod 777 /tmp/hive
此問題暫未解決，估計是17點解決winutils有問題，建議最好把任務程序發佈到服務器上面解決
20、Exception in thread “main” org.apache.hadoop.security.AccessControlException : Permission denied: user=Administrator,access=WRITE, inode=”/data”:bdata:supergroup:drwxr-xr-x
解決辦法
1、在系統的環境變量或java JVM變量裏面添加HADOOP_USER_NAME，如程序中添加System.setProperty(“HADOOP_USER_NAME”, “bdata”);，這裏的值就是以後會運行HADOOP上的Linux的用戶名，如果是eclipse，則修改完重啓eclipse，不然可能不生效
2、hdfs dfs -chmod 777 修改相應權限地址
21、運行Spark-SQL報錯：org.apache.spark.sql.AnalysisException: unresolved operator ‘Project
解決辦法：
在Spark-sql和hive結合時或者單獨Spark-sql，運行某些sql語句時，偶爾出現上面錯誤，那麼我們可以檢查一下sql的問題，這裏遇到的問題是嵌套語句太多，導致spark無法解析，所以需要修改sql或者改用其他方式處理；特別注意該語句可能在hive裏面沒有錯誤，spark纔會出現的一種錯誤。
22、在$SPARK_HOME/conf/spark-env.sh中設置這些變量好像也只是在terminal中的shell環境中才有效JAVA_HOME is not set Exception: Java gateway process exited before sending the driver its port number
但是在命令行中是有的
pipi@pipicmp:~$ echo $JAVA_HOME
/home/pipi/ENV/jdk
解決方法1：在py代碼中加入JAVA_HOME到os中
JAVA_HOME = /home/pipi/ENV/jdk
os.environ['JAVA_HOME'] = conf.get(SECTION, 'JAVA_HOME')
解決方法2：或者在hadoop中配置好JAVA_HOME
hadoop中配置JAVA_HOME
23、ValueError: Cannot run multiple SparkContexts at once
Welcome to
____ __
/ __/__ ___ _____/ /__
_\ \/ _ \/ _ `/ __/ '_/
/__ / .__/\_,_/_/ /_/\_\ version 2.0.1
/_/
Using Python version 3.5.2 (default, Sep 10 2016 08:21:44)
SparkSession available as 'spark'.
ValueError: Cannot run multiple SparkContexts at once; existing SparkContext(app=pyspark-shell, master=local) created by <module> at <frozen importlib._bootstrap>:222
原因是：from pyspark.shell import sqlContext
引入的包中也定義了一個sc = spark.sparkContext導致和本代碼中定義重複了。
24、spark輸出太多warning messages
調試log時候發現問題解決了
在簡略Spark輸出設置時[Spark安裝和配置 ]修改過$SPARK_HOME/conf/log4j.properties.template文件只輸出WARN信息，就算改成了ERROR，信息也還是會自動修改成WARN輸出出來，不過多了一條提示：
Setting default log level to "WARN". To adjust logging level use sc.setLogLevel(newLevel).
就在這時發現了一個解決方案：
根據提示在代碼中加入sc.setLogLevel('ERROR')就可以解決了！
25、org.apache.spark.shuffle.FetchFailedException
一般發生在有大量shuffle操作的時候,task不斷的failed,然後又重執行，一直循環下去，非常的耗時一般遇到這種問題提高executor內存即可,同時增加每個executor的cpu,這樣不會減少task並行度。
26、Executor&Task Lost因爲網絡或者gc的原因,worker或executor沒有接收到executor或task的心跳反饋WARN
TaskSetManager:
Lost task 1.0 in stage 0.0 (TID 1, aa.local): ExecutorLostFailure (executor lost)
提高 spark.network.timeout 的值，根據情況改成300(5min)或更高。
默認爲 120(120s),配置所有網絡傳輸的延時，如果沒有主動設置以下參數，默認覆蓋其屬性
spark.core.connection.ack.wait.timeout
spark.akka.timeout
spark.storage.blockManagerSlaveTimeoutMs
spark.shuffle.io.connectionTimeout
spark.rpc.askTimeout or spark.rpc.lookupTimeout
27、Master掛掉,standby重啓也失效
如Master默認使用512M內存，當集羣中運行的任務特別多時，就會掛掉，原因是master會讀取每個task的event log日誌去生成spark ui，內存不足自然會OOM，可以在master的運行日誌中看到，通過HA啓動的master自然也會因爲這個原因失敗。
1）.增加Master的內存佔用，在Master節點spark-env.sh 中設置：
export SPARK_DAEMON_MEMORY 10g # 根據你的實際情況
2）.減少保存在Master內存中的作業信息
spark.ui.retainedJobs 500 # 默認都是1000 spark.ui.retainedStages 500
28、worker掛掉或假死有時候我們還會在web ui中看到worker節點消失或處於dead狀態
在該節點運行的任務則會報各種 lost worker 的錯誤，引發原因和上述大體相同，worker內存中保存了大量的ui信息導致gc時失去和master之間的心跳。
解決
1）增加Master的內存佔用，在Worker節點spark-env.sh 中設置：
export SPARK_DAEMON_MEMORY 2g # 根據你的實際情況
2）減少保存在Worker內存中的Driver,Executor信息
spark.worker.ui.retainedExecutors 200 # 默認都是1000 spark.worker.ui.retainedDrivers 200
29、報錯：
ERROR storage.DiskBlockObjectWriter: Uncaught exception while reverting partial writes to file /hadoop/application_1415632483774_448143/spark-local-20141127115224-9ca8/04/shuffle_1_1562_27
java.io.FileNotFoundException: /hadoop/application_1415632483774_448143/spark-local-20141127115224-9ca8/04/shuffle_1_1562_27 (No such file or directory)
表面上看是因爲shuffle沒有地方寫了，如果後面的stack是local space 的問題，那麼清一下磁盤就好了。上面這種問題，是因爲一個excutor給分配的內存不夠，此時，減少excutor-core的數量，加大excutor-memory的值應該就沒有問題。
30、報錯：
ERROR executor.CoarseGrainedExecutorBackend: Driver Disassociated [akka.tcp://sparkExecutor@pc-jfqdfx31:48586] -> [akka.tcp://sparkDriver@pc-jfqdfx30:41656] disassociated! Shutting down.
15/07/23 10:50:56 ERROR executor.CoarseGrainedExecutorBackend: RECEIVED SIGNAL 15: SIGTERM
這個錯誤比較隱晦，從信息上看來不知道是什麼問題，但是歸根結底還是內存的問題，有兩個方法可以解決這個錯誤，一是，如上面所說，加大excutor-memory的值，減少executor-cores的數量，問題可以解決。二是，加大executor.overhead的值，但是這樣其實並沒有解決掉根本的問題。所以如果集羣的資源是支持的話，就用1的辦法吧。
另外，這個錯誤也出現在partitionBy(new HashPartition(partiton-num))時，如果partiton-num太大或者太小的時候會報這種錯誤，說白了也是內存的原因，不過這個時候增加內存和overhead沒有什麼用，得去調整這個partiton-num的值。
31、給定a、b兩個文件，各存放50億個url，每個url各佔64字節，內存限制是4G，讓你找出a、b文件共同的url?
方案1：可以估計每個文件安的大小爲5G×64=320G，遠遠大於內存限制的4G。所以不可能將其完全加載到內存中處理。考慮採取分而治之的方法。
遍歷文件a，對每個url求取hash(url)%1000，然後根據所取得的值將url分別存儲到1000個小文件(記爲a0,a1,…,a999)中。這樣每個小文件的大約爲300M。
遍歷文件b，採取和a相同的方式將url分別存儲到1000小文件(記爲b0,b1,…,b999)。這樣處理後，所有可能相同的url都在對應的小文件(a0vsb0,a1vsb1,…,a999vsb999)中，不對應的小文件不可能有相同的url。然後我們只要求出1000對小文件中相同的url即可。
求每對小文件中相同的url時，可以把其中一個小文件的url存儲到hash_set中。然後遍歷另一個小文件的每個url，看其是否在剛纔構建的hash_set中，如果是，那麼就是共同的url，存到文件裏面就可以了。
方案2：如果允許有一定的錯誤率，可以使用Bloomfilter，4G內存大概可以表示340億bit。將其中一個文件中的url使用Bloomfilter映射爲這340億bit，然後挨個讀取另外一個文件的url，檢查是否與Bloomfilter，如果是，那麼該url應該是共同的url(注意會有一定的錯誤率)。
Bloomfilter日後會在本BLOG內詳細闡述。補充：另外一種思路，是將url通過算法轉爲數字類型，轉換後的連接就是比較數值是否相等了。
32、有一個1G大小的一個文件，裏面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M，要求返回頻數最高的100個詞。
Step1：順序讀文件中，對於每個詞x，取hash(x)%5000，然後按照該值存到5000個小文件(記爲f0,f1,...,f4999)中，這樣每個文件大概是200k左右，如果其中的有的文件超過了1M大小，還可以按照類似的方法繼續往下分，直到分解得到的小文件的大小都不超過1M;
Step2：對每個小文件，統計每個文件中出現的詞以及相應的頻率(可以採用trie樹/hash_map等)，並取出出現頻率最大的100個詞(可以用含100個結點的最小堆)，並把100詞及相應的頻率存入文件，這樣又得到了5000個文件;
Step3：把這5000個文件進行歸併(類似與歸併排序);
草圖如下(分割大問題，求解小問題，歸併)：
33、現有海量日誌數據保存在一個超級大的文件中，該文件無法直接讀入內存，要求從中提取某天出訪問百度次數最多的那個IP。
Step1：從這一天的日誌數據中把訪問百度的IP取出來，逐個寫入到一個大文件中;
Step2：注意到IP是32位的，最多有2^32個IP。同樣可以採用映射的方法，比如模1000，把整個大文件映射爲1000個小文件;
Step3：找出每個小文中出現頻率最大的IP(可以採用hash_map進行頻率統計，然後再找出頻率最大的幾個)及相應的頻率;
Step4：在這1000個最大的IP中，找出那個頻率最大的IP，即爲所求。
34、LVS和HAProxy相比，它的缺點是什麼?
之前，的確是用LVS進行過MySQL集羣的負載均衡，對HAProxy也有過了解，但是將這兩者放在眼前進行比較，還真沒試着瞭解過。面試中出現了這麼一題，面試官給予的答案是LVS的配置相當繁瑣，後來查找了相關資料，對這兩種負載均衡方案有了更進一步的瞭解。LVS的負載均衡性能之強悍已經達到硬件負載均衡的F5的百分之60了，而HAproxy的負載均衡和Nginx負載均衡，均爲硬件負載均衡的百分之十左右。由此可見，配置複雜，相應的效果也是顯而易見的。在查找資料的過程中，試着將LVS的10種調度算法瞭解了一下，看似數量挺多的10種算法其實在不同的算法之間，有些只是有着一些細微的差別。在這10種調度算法中，靜態調度算法有四種，動態調度算法有6種。
靜態調度算法：
①RR輪詢調度算法
這種調度算法不考慮服務器的狀態，所以是無狀態的，同時也不考慮每個服務器的性能，比如我有1-N臺服務器，來N個請求了，第一個請求給第一臺，第二個請求給第二臺，，，第N個請求給第N臺服務器，就醬紫。
②加權輪詢
這種調度算法是考慮到服務器的性能的，你可以根據不同服務器的性能，加上權重進行分配相應的請求。
③基於目的地址的hash散列
這種調度算法和基於源地址的hash散列異曲同工，都是爲了維持一個session，基於目的地址的hash散列，將記住同一請求的目的地址，將這類請求發往同一臺目的服務器。簡而言之，就是發往這個目的地址的請求都發往同一臺服務器。而基於源地址的hash散列，就是來自同一源地址的請求都發往同一臺服務器。
④基於源地址的hash散列
上述已講，不再贅述。
動態調度
①最少連接調度算法
這種調度算法會記錄響應請求的服務器上所建立的連接數，每接收到一個請求會相應的將該服務器的所建立連接數加1，同時將新來的請求分配到當前連接數最少的那臺機器上。
②加權最少連接調度算法
這種調度算法在最少連接調度算法的基礎上考慮到服務器的性能。當然，做這樣子的考慮是有其合理性存在的，如果是同一規格的服務器，那麼建立的連接數越多，必然越增加其負載，那麼僅僅根據最少連接數的調度算法，必然可以實現合理的負載均衡。但如果，服務器的性能不一樣呢?比如我有一臺服務器，最多隻能處理10個連接，現在建立了3個，還有一臺服務器最多能處理1000條連接，現在建立了5個，如果單純地按照上述的最少連接調度算法，妥妥的前者嘛，但前者已經建立了百分之三十的連接了，而後者連百分之一的連接還沒有建立，試問，這合理嗎?顯然不合理。所以加上權重，纔算合理。相應的公式也相當簡單：active*256/weight。
③最短期望調度算法
這種算法，是避免出現上述加權最少連接調度算法中的一種特殊情況，導致即使加上權重，調度器也無差別對待了，舉個栗子：
假設有三臺服務器ABC，其當前所建立的連接數相應地爲1,2,3，而權重也是1,2,3。那麼如果按照加權最少連接調度算法的話，算出來是這樣子的：
A:1256/1=256
B:2256/2=256
C:3256/3=256
我們會發現，即便加上權重，A、B、C，經過計算還是一樣的，這樣子調度器會無差別的在A、B、C中任選一臺，將請求發過去。
而最短期望將active256/weight的算法改進爲(active+1)256/weight
那麼還是之前的例子：
A:(1+1)256/1=2/1256=2256
B:(2+1)256/2=3/2256=1.5256
C:(3+1)256、3=4/3256≈1.3256
顯然C
④永不排隊算法
將請求發給當前連接數爲0的服務器上。
⑤基於局部的最少連接調度算法
這種調度算法應用於Cache系統，維持一個請求到一臺服務器的映射，其實我們仔細想想哈，之前做的一系列最少連接相關的調度算法。考慮到的是服務器的狀態與性能，但是一次請求並不是單向的，就像有一個從未合作過的大牛，他很閒，你讓他去解決一個之前碰到過的一個問題，未必有找一個之前已經跟你合作過哪怕現在不怎麼閒的臭皮匠效果好哦~，所以基於局部的最少連接調度算法，維持的這種映射的作用是，如果來了一個請求，相對應的映射的那臺服務器，沒有超載，ok交給老夥伴完事吧，俺放心，如果那臺服務器不存在，或者是超載的狀態且有其他服務器工作在一半的負載狀態，則按最少連接調度算法在集羣其餘的服務器中找一臺將請求分配給它。
⑥基於複製的局部最少連接調度算法
這種調度算法同樣應用於cache系統，但它維持的不是到一臺服務器的映射而是到一組服務器的映射，當有新的請求到來，根據最小連接原則，從該映射的服務器組中選擇一臺服務器，如果它沒有超載則交給它去處理這個請求，如果發現它超載，則從服務器組外的集羣中，按最少連接原則拉一臺機器加入服務器組，並且在服務器組有一段時間未修改後，將最忙的那臺服務器從服務器組中剔除。
35、Sqoop用起來感覺怎樣?
說實話，Sqoop在導入數據的速度上確實十分感人，通過進一步瞭解，發現Sqoop1和Sqoop2在架構上還是有明顯不同的，無論是從數據類型上還是從安全權限，密碼暴露方面，Sqoop2都有了明顯的改進，同時同一些其他的異構數據同步工具比較,如淘寶的DataX或者Kettle相比，Sqoop無論是從導入數據的效率上還是從支持插件的豐富程度上，Sqoop還是相當不錯滴!!
36、ZooKeeper的角色以及相應的Zookepper工作原理?
果然，人的記憶力是有衰減曲線的，當面試官拋出這個問題後，前者角色，我只答出了兩種(leader和follower)，後者原理壓根就模糊至忘記了。所以惡補了一下，涉及到Zookeeper的角色大概有如下四種：leader、learner(follower)、observer、client。其中leader主要用來決策和調度，follower和observer的區別僅僅在於後者沒有寫的職能，但都有將client請求提交給leader的職能，而observer的出現是爲了應對當投票壓力過大這種情形的，client就是用來發起請求的。而Zookeeper所用的分佈式一致性算法包括leader的選舉其實和-原始部落的獲得神器爲酋長，或者得玉璽者爲皇帝類似，誰id最小，誰爲leader，會根據你所配置的相應的文件在相應的節點機下生成id，然後相應的節點會通過getchildren()這個函數獲取之前設置的節點下生成的id，誰最小，誰是leader。並且如果萬一這個leader掛掉了或者墮落了，則由次小的頂上。而且在配置相應的zookeeper文件的時候回有類似於如下字樣的信息：Server.x=AAAA:BBBB:CCCC。其中的x即爲你的節點號哈，AAAA對應你所部屬zookeeper所在的ip地址，BBBB爲接收client請求的端口，CCCC爲重新選舉leader端口。
37、HBase的Insert與Update的區別?
這個題目是就着最近的一次項目問的，當時實現的與hbase交互的三個方法分別爲insert、delete、update。由於那個項目是對接的一個項目，對接的小夥伴和我協商了下，不將update合併爲insert，如果合併的話，按那個項目本身，其實通過insert執行overwrite相當於間接地Update，本質上，或者說在展現上是沒什麼區別的包括所調用的put。但那僅僅是就着那個項目的程序而言，如果基於HBase shell層面。將同一rowkey的數據插入HBase，其實雖然展現一條，但是相應的timestamp是不一樣的，而且最大的版本數可以通過配置文件進行相應地設置。
38、請簡述大數據的結果展現方式。
1)報表形式
基於數據挖掘得出的數據報表，包括數據表格、矩陣、圖形和自定義格式的報表等，使用方便、設計靈活。
2)圖形化展現
提供曲線、餅圖、堆積圖、儀表盤、魚骨分析圖等圖形形式宏觀展現模型數據的分佈情況，從而便於進行決策。
3)KPI展現
提供表格式績效一覽表並可自定義績效查看方式，如數據表格或走勢圖，企業管理者可根據可度量的目標快速評估進度。
4)查詢展現
按數據查詢條件和查詢內容，以數據表格來彙總查詢結果，提供明細查詢功能，並可在查詢的數據表格基礎上進行上鑽、下鑽、旋轉等操作。
39、例舉身邊的大數據。
QQ，微博等社交軟件產生的數據
天貓，京東等電子商務產生的數據
互聯網上的各種數據
40、簡述大數據的數據管理方式。
對於圖像、視頻、URL、地理位置等類型多樣的數據，難以用傳統的結構化方式描述，因此需要使用由多維表組成的面向列存儲的數據管理系統來組織和管理數據。也就是說，將數據按行排序，按列存儲，將相同字段的數據作爲一個列族來聚合存儲。不同的列族對應數據的不同屬性，這些屬性可以根據需求動態增加，通過這樣的分佈式實時列式數據庫對數據統一進行結構化存儲和管理，避免了傳統數據存儲方式下的關聯查詢。
41、什麼是大數據?
大數據是指無法在容許的時間內用常規軟件工具對其內容進行抓取、管理和處理的數據。
42、海量日誌數據，提取出某日訪問百度次數最多的那個IP。
首先是這一天，並且是訪問百度的日誌中的IP取出來，逐個寫入到一個大文件中。注意到IP是32位的，最多有個2^32個IP。同樣可以採用映射的方法，比如模1000，把整個大文件映射爲1000個小文件，再找出每個小文中出現頻率最大的IP(可以採用hash_map進行頻率統計，然後再找出頻率最大的幾個)及相應的頻率。然後再在這1000個最大的IP中，找出那個頻率最大的IP，即爲所求。
或者如下闡述(雪域之鷹)：
算法思想：分而治之+Hash
1)IP地址最多有2^32=4G種取值情況，所以不能完全加載到內存中處理;
2)可以考慮採用“分而治之”的思想，按照IP地址的Hash(IP)%1024值，把海量IP日誌分別存儲到1024個小文件中。這樣，每個小文件最多包含4MB個IP地址;
3)對於每一個小文件，可以構建一個IP爲key，出現次數爲value的Hashmap，同時記錄當前出現次數最多的那個IP地址;
4)可以得到1024個小文件中的出現次數最多的IP，再依據常規的排序算法得到總體上出現次數最多的IP;
43、搜索引擎會通過日誌文件把用戶每次檢索使用的所有檢索串都記錄下來，每個查詢串的長度爲1-255字節。
假設目前有一千萬個記錄(這些查詢串的重複度比較高，雖然總數是1千萬，但如果除去重複後，不超過3百萬個。一個查詢串的重複度越高，說明查詢它的用戶越多，也就是越熱門。)，請你統計最熱門的10個查詢串，要求使用的內存不能超過1G。
典型的TopK算法，還是在這篇文章裏頭有所闡述，詳情請參見：十一、從頭到尾徹底解析Hash表算法。
文中，給出的最終算法是：
第一步、先對這批海量數據預處理，在O(N)的時間內用Hash表完成統計(之前寫成了排序，特此訂正。July、2011.04.27);
第二步、藉助堆這個數據結構，找出TopK，時間複雜度爲N‘logK。
即，藉助堆結構，我們可以在log量級的時間內查找和調整/移動。因此，維護一個K(該題目中是10)大小的小根堆，然後遍歷300萬的Query，分別和根元素進行對比所以，我們最終的時間複雜度是：O(N)+N’*O(logK)，(N爲1000萬，N’爲300萬)。ok，更多，詳情，請參考原文。
或者：採用trie樹，關鍵字域存該查詢串出現的次數，沒有出現爲0。最後用10個元素的最小推來對出現頻率進行排序。
44、有一個1G大小的一個文件，裏面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M。返回頻數最高的100個詞。
方案：順序讀文件中，對於每個詞x，取hash(x)%5000，然後按照該值存到5000個小文件(記爲x0,x1,…x4999)中。這樣每個文件大概是200k左右。
如果其中的有的文件超過了1M大小，還可以按照類似的方法繼續往下分，直到分解得到的小文件的大小都不超過1M。
對每個小文件，統計每個文件中出現的詞以及相應的頻率(可以採用trie樹/hash_map等)，並取出出現頻率最大的100個詞(可以用含100個結點的最小堆)，並把100個詞及相應的頻率存入文件，這樣又得到了5000個文件。下一步就是把這5000個文件進行歸併(類似與歸併排序)的過程了。
45、有10個文件，每個文件1G，每個文件的每一行存放的都是用戶的query，每個文件的query都可能重複。要求你按照query的頻度排序。
還是典型的TOPK算法，解決方案如下：
方案1：
順序讀取10個文件，按照hash(query)%10的結果將query寫入到另外10個文件(記爲)中。這樣新生成的文件每個的大小大約也1G(假設hash函數是隨機的)。
找一臺內存在2G左右的機器，依次對用hash_map(query,query_count)來統計每個query出現的次數。利用快速/堆/歸併排序按照出現次數進行排序。將排序好的query和對應的query_cout輸出到文件中。這樣得到了10個排好序的文件(記爲)。
對這10個文件進行歸併排序(內排序與外排序相結合)。
方案2：
一般query的總量是有限的，只是重複的次數比較多而已，可能對於所有的query，一次性就可以加入到內存了。這樣，我們就可以採用trie樹/hash_map等直接來統計每個query出現的次數，然後按出現次數做快速/堆/歸併排序就可以了。
方案3：
與方案1類似，但在做完hash，分成多個文件後，可以交給多個文件來處理，採用分佈式的架構來處理(比如MapReduce)，最後再進行合併。
46、JVM&垃圾回收機制
三個代：年輕代（Young Generation）、年老代（Old Generation）和持久代（Permanent Generation）
47、在2.5億個整數中找出不重複的整數，注，內存不足以容納這2.5億個整數。
方案1：採用2-Bitmap(每個數分配2bit，00表示不存在，01表示出現一次，10表示多次，11無意義)進行，共需內存2^32*2bit=1GB內存，還可以接受。然後掃描這2.5億個整數，查看Bitmap中相對應位，如果是00變01，01變10，10保持不變。所描完事後，查看bitmap，把對應位是01的整數輸出即可。
方案2：也可採用與第1題類似的方法，進行劃分小文件的方法。然後在小文件中找出不重複的整數，並排序。然後再進行歸併，注意去除重複的元素。
48、騰訊面試題：給40億個不重複的unsignedint的整數，沒排過序的，然後再給一個數，如何快速判斷這個數是否在那40億個數當中?
第一反應時快速排序+二分查找。以下是其它更好的方法：
方案1：oo，申請512M的內存，一個bit位代表一個unsignedint值。讀入40億個數，設置相應的bit位，讀入要查詢的數，查看相應bit位是否爲1，爲1表示存在，爲0表示不存在。
方案2：這個問題在《編程珠璣》裏有很好的描述，大家可以參考下面的思路
49、怎麼在海量數據中找出重複次數最多的一個?
方案1：先做hash，然後求模映射爲小文件，求出每個小文件中重複次數最多的一個，並記錄重複次數。然後找出上一步求出的數據中重複次數最多的一個就是所求(具體參考前面的題)。
50、上千萬或上億數據(有重複)，統計其中出現次數最多的錢N個數據。
方案1：上千萬或上億的數據，現在的機器的內存應該能存下。所以考慮採用hash_map/搜索二叉樹/紅黑樹等來進行統計次數。然後就是取出前N個出現次數最多的數據了，可以用第2題提到的堆機制完成。
51、一個文本文件，大約有一萬行，每行一個詞，要求統計出其中最頻繁出現的前10個詞，請給出思想，給出時間複雜度分析。
方案1：這題是考慮時間效率。用trie樹統計每個詞出現的次數，時間複雜度是O(n*le)(le表示單詞的平準長度)。然後是找出出現最頻繁的前10個詞，可以用堆來實現，前面的題中已經講到了，時間複雜度是O(n*lg10)。所以總的時間複雜度，是O(n*le)與O(n*lg10)中較大的哪一個。
52、WARN TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster uito ensure that workers are registered and have sufficient memory
當前的集羣的可用資源不能滿足應用程序所請求的資源。
資源分2類： cores 和 ram
Core代表對執行可用的executor slots
Ram代表每個Worker上被需要的空閒內存來運行你的Application。
解決方法：
應用不要請求多餘空閒可用資源的
關閉掉已經執行結束的Application
53、Application isn’t using all of the Cores: How to set the Cores used by a Spark App
設置每個App所能獲得的core
解決方法：
spark-env.sh裏設置spark.deploy.defaultCores 或spark.cores.max
54、Spark Executor OOM: How to set Memory Parameters on Spark
OOM是內存裏堆的東西太多了
1）增加job的並行度，即增加job的partition數量，把大數據集切分成更小的數據，可以減少一次性load到內存中的數據量。InputFomart， getSplit來確定。
2）spark.storage.memoryFraction
管理executor中RDD和運行任務時的內存比例，如果shuffle比較小，只需要一點點shuffle memory，那麼就調大這個比例。默認是0.6。不能比老年代還要大。大了就是浪費。
3）spark.executor.memory如果還是不行，那麼就要加Executor的內存了，改完executor內存後，這個需要重啓。
55、Shark Server/ Long Running Application Metadata Cleanup
Spark程序的元數據是會往內存中無限存儲的。spark.cleaner.ttl來防止OOM，主要出現在Spark Steaming和Shark Server裏。
export SPARK_JAVA_OPTS +="-Dspark.kryoserializer.buffer.mb=10 -Dspark.cleaner.ttl=43200"
56、Class Not Found: Classpath Issues
問題1、缺少jar，不在classpath裏。3
問題2、jar包衝突，同一個jar不同版本。
解決1：
將所有依賴jar都打入到一個fatJar包裏，然後手動設置依賴到指定每臺機器的DIR。
val conf = new SparkConf().setAppName(appName).setJars(Seq(System.getProperty("user.dir") + "/target/scala-2.10/sparktest.jar"))
解決2：
把所需要的依賴jar包都放到default classpath裏，分發到各個worker node上。
57、使用mr，spark,spark sql編寫wordcount程序
58、如何爲一個hadoop任務設置mappers的數量
使用job.setNumMapTask(intn)手動分割，這是不靠譜的
官方文檔：“Note:Thisisonlyahinttotheframework”說明這個方法只是提示作用，不起決定性作用
實際上要用公式計算：
Max(min.split，min(max.split，block))就設置分片的最大最下值computeSplitSize()設置
可以參考這篇文章：http://blog.csdn.net/strongerbit/article/details/7440111
59、有可能使hadoop任務輸出到多個目錄中麼?如果可以，怎麼做?
在1.X版本後使用MultipleOutputs.java類實現
60、如何爲一個hadoop任務設置要創建的reducer的數量
配置job.setNumReduceTask(intn)
或者調整hdfs-site.xml中的mapred.tasktracker.reduce.tasks.maximum默認參數值
61、Spark Streaming和Storm有何區別？
一個實時毫秒一個準實時亞秒，不過storm的吞吐率比較低。
62、如果公司叫你寫hadoop平臺設計方案，你會如何規劃Hadoop生產集羣？
這個題目比較考驗全局觀，站在架構師的層面去思考
63、hadoop集羣監控，你會關注哪些監控點？
偏重集羣的運維