一.Hadoop
1.hdfs寫流程
2.hdfs讀流程
3.hdfs的體系結構
4.一個datanode 宕機,怎麼一個流程恢復
5.hadoop 的 namenode 宕機,怎麼解決
6.namenode對元數據的管理
7.元數據的checkpoint
8.yarn資源調度流程
9.hadoop中combiner和partition的作用
10.用mapreduce怎麼處理數據傾斜問題?
11.shuffle 階段,你怎麼理解的
12.Mapreduce 的 map 數量 和 reduce 數量是由什麼決定的 ,怎麼配置
13.MapReduce優化經驗
14.分別舉例什麼情況要使用 combiner,什麼情況不使用?
15.MR運行流程解析
16.簡單描述一下HDFS的系統架構,怎麼保證數據安全?
17.在通過客戶端向hdfs中寫數據的時候,如果某一臺機器宕機了,會怎麼處理
18.Hadoop優化有哪些方面
19.大量數據求topN(寫出mapreduce的實現思路)
20.列出正常工作的hadoop集群中hadoop都分別啟動哪些進程以及他們的作用
21.Hadoop總job和Tasks之間的區別是什麼?
22.Hadoop高可用HA模式
23.簡要描述安裝配置一個hadoop集群的步驟
24.fsimage和edit的區別
25.yarn的三大調度策略
26.hadoop的shell命令用的多嗎?,說出一些常用的
27.用mr實現用戶pv的top10?
28.一個文件只有一行,但是這行有100G大小,mr會不會切分,我們應該怎麼解決
29.hdfs HA機制,一臺namenode宕機了,joualnode,namenode,edit.log fsimage的變化
二.Hive
1.大表join小表產生的問題,怎麼解決?
2.udf udaf udtf區別
3.hive有哪些保存元數據的方式,個有什麼特點。
4.hive內部表和外部表的區別
5.生產環境中為什麼建議使用外部表?
6.insert into 和 override write區別?
7.hive的判斷函數有哪些
8.簡單描述一下HIVE的功能?用hive創建表幾種方式?hive表有幾種?
9.線上業務每天產生的業務日誌(壓縮後>=3G),每天需要加載到hive的log表中,將每天產生的業務日誌在壓縮之後load到hive的log表時,最好使用的壓縮算法是哪個,並說明其原因
10.若在hive中建立分區仍不能優化查詢效率,建表時如何優化
11.union all和union的區別
12.如何解決hive數據傾斜的問題
13.hive性能優化常用的方法
14.簡述delete,drop,truncate的區別
15.order by , sort by , distribute by , cluster by的區別
16.Hive 裡邊欄位的分隔符用的什麼?為什麼用\t?有遇到過欄位裡 邊有\t 的情況嗎,怎麼處理的?為什麼不用 Hive 默認的分隔符,默認的分隔符是什麼?
17.分區分桶的區別,為什麼要分區
18.mapjoin的原理
19.在hive的row_number中distribute by 和 partition by的區別
20.hive開發中遇到什麼問題?
21.什麼時候使用內部表,什麼時候使用外部表
22.hive都有哪些函數,你平常工作中用到哪些
23.手寫sql,連續活躍用戶
24.left semi join和left join區別
25.group by為什麼要排序
26.說說印象最深的一次優化場景,hive常見的優化思路
27.聊聊hive的執行引擎,spark和mr的區別?
28.hive的join底層mr是如何實現的?
29.sql問題,連續幾天活躍的用戶?
30.建好了外部表,用什麼語句把數據文件加載到表裡
31.Hive的執行流程?
32.hive的元數據信息存儲在哪?
33.sql語句的執行順序from-where-group by-having -select-order by -limit
34.on和where的區別
35.hive和傳統資料庫之間的區別
36.hive中導入數據的4種方式
37 下述sql在hive,sparksql兩種執行引擎中,執行流程分別是什麼,區別是什麼?
38.hive的執行計劃有看過嗎,你一般會關注哪幾個點
39.hive底層運行mr或者spark程序的時候語法樹說一下
三.Spark
1.rdd的屬性
2.算子分為哪幾類(RDD支持哪幾種類型的操作)
3.創建rdd的幾種方式
4.spark運行流程
5.Spark中coalesce與repartition的區別
6.sortBy 和 sortByKey的區別
7.map和mapPartitions的區別
8.數據存入Redis 優先使用map mapPartitions foreach foreachPartions哪個
9.reduceByKey和groupBykey的區別
10.cache和checkPoint的比較
11.spark streaming流式統計單詞數量代碼
12.簡述map和flatMap的區別和應用場景
13.計算曝光數和點擊數
14.分別列出幾個常用的transformation和action算子
15.按照需求使用spark編寫以下程序,要求使用scala語言
16.spark應用程式的執行命令是什麼?
17.Spark應用執行有哪些模式,其中哪幾種是集群模式
18.請說明spark中廣播變量的用途
19.以下代碼會報錯嗎?如果會怎麼解決 val arr = new ArrayList[String]; arr.foreach(println)
20.寫出你用過的spark中的算子,其中哪些會產生shuffle過程
21.Spark中rdd與partition的區別
22.請寫出創建Dateset的幾種方式
23.描述一下RDD,DataFrame,DataSet的區別?
24.描述一下Spark中stage是如何劃分的?描述一下shuffle的概念
25.Spark 在yarn上運行需要做哪些關鍵的配置工作?如何kill -個Spark在yarn運行中Application
26.通常來說,Spark與MapReduce相比,Spark運行效率更高。請說明效率更高來源於Spark內置的哪些機制?請列舉常見spark的運行模式?
27.RDD中的數據在哪?
28.如果對RDD進行cache操作後,數據在哪裡?
29.Spark中Partition的數量由什麼決定
30.Scala裡面的函數和方法有什麼區別
31.SparkStreaming怎麼進行監控?
32.Spark判斷Shuffle的依據?
33.Scala有沒有多繼承?可以實現多繼承麼?
34.Sparkstreaming和flink做實時處理的區別
35.Sparkcontext的作用
36.Sparkstreaming讀取kafka數據為什麼選擇直連方式
37.離線分析什麼時候用sparkcore和sparksql
38.Sparkstreaming實時的數據不丟失的問題
39.簡述寬依賴和窄依賴概念,groupByKey,reduceByKey,map,filter,union五種操作哪些會導致寬依賴,哪些會導致窄依賴
40.數據傾斜可能會導致哪些問題,如何監控和排查,在設計之初,要考慮哪些來避免
41.有一千萬條簡訊,有重複,以文本文件的形式保存,一行一條數據,請用五分鐘時間,找出重複出現最多的前10條
42.現有一文件,格式如下,請用spark統計每個單詞出現的次數
43.共享變量和累加器
44.當 Spark 涉及到資料庫的操作時,如何減少 Spark 運行中的資料庫連接數?
45.特別大的數據,怎麼發送到excutor中?
46.spark調優都做過哪些方面?
47.spark任務為什麼會被yarn kill掉?
48.Spark on Yarn作業執行流程?yarn-client和yarn-cluster有什麼區別?
49.Flatmap底層編碼實現?
50.spark_1.X與spark_2.X區別
51.說說spark與flink
52.spark streaming如何保證7*24小時運行機制?
53.spark streaming是Exactly-Once嗎?
四.Kafka
1.Kafka名詞解釋和工作方式
2.Consumer與topic關係
3.kafka中生產數據的時候,如何保證寫入的容錯性?
4.如何保證kafka消費者消費數據是全局有序的
5.有兩個數據源,一個記錄的是廣告投放給用戶的日誌,一個記錄用戶訪問日誌,另外還有一個固定的用戶基礎表記錄用戶基本信息(比如學歷,年齡等等)。現在要分析廣告投放對與哪類用戶更有效,請採用熟悉的技術描述解決思路。另外如果兩個數據源都是實時數據源(比如來自kafka),他們數據在時間上相差5分鐘,需要哪些調整來解決實時分析問題?
6.Kafka和SparkStreaing如何集成?
7.列舉Kafka的優點,簡述Kafka為什麼可以做到每秒數十萬甚至上百萬消息的高效分發?
8.為什麼離線分析要用kafka?
9.Kafka怎麼進行監控?
10.Kafka與傳統的消息隊列服務有很麼不同
11.Kafka api low-level與high-level有什麼區別,使用low-level需要處理哪些細節
12.Kafka的ISR副本同步隊列
13.Kafka消息數據積壓,Kafka消費能力不足怎麼處理?
14.Kafka中的ISR、AR又代表什麼?
15.Kafka中的HW、LEO等分別代表什麼?
16.哪些情景會造成消息漏消費?
17.當你使用kafka-topics.sh創建了一個topic之後,Kafka背後會執行什麼邏輯?
18.topic的分區數可不可以增加?如果可以怎麼增加?如果不可以,那又是為什麼?
19.topic的分區數可不可以減少?如果可以怎麼減少?如果不可以,那又是為什麼?
20.Kafka有內部的topic嗎?如果有是什麼?有什麼所用?
21.聊一聊Kafka Controller的作用?
22.失效副本是指什麼?有那些應對措施?
23.Kafka 都有哪些特點?
24.請簡述下你在哪些場景下會選擇 Kafka?
25.Kafka 的設計架構你知道嗎?
26.Kafka 分區的目的?
27.你知道 Kafka 是如何做到消息的有序性?
28.Kafka 的高可靠性是怎麼實現的?
29.請談一談 Kafka 數據一致性原理
30.ISR、OSR、AR 是什麼?
31.LEO、HW、LSO、LW等分別代表什麼
32.Kafka 在什麼情況下會出現消息丟失?
33.怎麼儘可能保證 Kafka 的可靠性
34.消費者和消費者組有什麼關係?
35.Kafka 的每個分區只能被一個消費者線程,如何做到多個線程同時消費一 個分區?
36.數據傳輸的事務有幾種?
37.Kafka 消費者是否可以消費指定分區消息?
38.Kafka消息是採用Pull模式,還是Push模式?
39.Kafka 消息格式的演變清楚嗎?
40.Kafka 偏移量的演變清楚嗎?
41.Kafka 高效文件存儲設計特點
42.Kafka創建Topic時如何將分區放置到不同的Broker中
43.Kafka新建的分區會在哪個目錄下創建
44.談一談 Kafka 的再均衡
45.談談 Kafka 分區分配策略
46.Kafka Producer 是如何動態感知主題分區數變化的?
47.Kafka 是如何實現高吞吐率的?
48.Kafka 監控都有哪些?
49.如何為Kafka集群選擇合適的Topics/Partitions數量
50.談談你對 Kafka 事務的了解?
51.談談你對 Kafka 冪等的了解?
52.Kafka 缺點?
53.Kafka 新舊消費者的區別
54.Kafka 分區數可以增加或減少嗎?為什麼?
55.kafka消息的存儲機制
56.相比較於傳統消息隊列,kafka的區別
57.消息丟失和消息重複
五.Hbase
1.Hbase調優
2.hbase的rowkey怎麼創建好?列族怎麼創建比較好?
3.hbase過濾器實現用途
4.HBase宕機如何處理
5.hive跟hbase的區別是?
6.hbase寫流程
7.hbase讀流程
8.hbase數據flush過程
9.數據合併過程
10.Hmaster和Hgionserver職責
11.HBase列族和region的關係?
12.請簡述Hbase的物理模型是什麼
13.請問如果使用Hbase做即席查詢,如何設計二級索引
14.如何避免讀、寫HBaes時訪問熱點問題?
15.布隆過濾器在HBASE中的應用
16.Hbase是用來幹嘛的?什麼樣的數據會放到hbase
17.Hbase在建表時的設計原則(注意事項)
18.Hbase中的region server發生故障後的處理方法(zk-->WAL)
19.用phenix和es作為hbase二級索引的區別,最新的hbase已經支持二級索引了,你清楚嗎?
六.數倉
1.維表和寬表的考查(主要考察維表的使用及維度退化手法)
2.數倉表命名規範
3.拉鍊表的使用場景
4.資料庫和數據倉庫有什麼區別
5.有什麼維表
6.數據源都有哪些
7.你們最大的表是什麼表,數據量多少
8.數倉架構體系
9.數據平臺是怎樣的,用到了阿里的那一套嗎?
10.你了解的調度系統有那些?,你們公司用的是哪種調度系統
11.你們公司數倉底層是怎麼抽數據的?
12.為什麼datax抽數據要比sqoop 快?
13.埋點數據你們是怎樣接入的
14.如果你們業務庫的表有更新,你們數倉怎麼處理的?
15.能獨立搭建數倉嗎
16.搭建過CDH 集群嗎
17.說一下你們公司的大數據平臺架構?你有參與嗎?
18.介紹一下你自己的項目和所用的技術
19.對目前的流和批處理的認識?就是談談自己的感受
20.你了解那些OLAP 引擎,MPP 知道一些嗎?clickHouse 了解一些嗎?你自己做過測試性能嗎?
21.Kylin 有了解嗎?介紹一下原理
22.datax 源碼有改造過嗎
23.你們數倉的APP 層是怎麼對外提供服務的?
24.數據接入進來,你們是怎樣規劃的,有考慮數據的膨脹問題嗎
25.簡述拉鍊表,流水錶以及快照表的含義和特點
26.全量表(df),增量表(di),追加表(da),拉鍊表(dz)的區別及使用場景
27.你們公司的數倉分層,每一層是怎麼處理數據的
28.什麼是事實表,什麼是維表
29.星型模型和雪花模型
30.緩慢變化維如何處理,幾種方式
31.datax與sqoop的優缺點
32.datax抽數碰到emoji表情怎麼解決
33.工作中碰到什麼困難,怎麼解決的
34.如何用數據給公司帶來收益
35.需求驅動和業務驅動,數據開發和ETL開發,實戰型和博客型
36.如何用數據實現業務增長?
37.什麼是大數據?千萬級別的數據完全可以用傳統的關係型資料庫集群解決,為什麼要用到大數據平臺。
38.數據質量,元數據管理,指標體系建設,數據驅動
39.什麼是數倉,建設數倉時碰到過什麼問題
40.實時數倉技術選型及保證exactly-once
41.維度建模和範式建模的區別;
42.埋點的碼錶如何設計;
43.集市層和公共層的區別;
44.緩慢變化維的處理方式
45.聊聊數據質量
46.說說你從0-1搭建數倉都做了什麼?你覺得最有挑戰的是什麼?
47.數據模型如何構建,星型、雪花、星座的區別和工作中如何使用;
48.如何優化整個數倉的執行時長,比如7點所有任務跑完,如何優化到5點;
49.數據傾斜,遇到哪些傾斜,怎麼發現的?怎麼處理的?;
50.如何保證數據質量;
51.如何保證指標一致性;
52.了解onedata嗎,說說你的理解;
53.數據漂移如何解決;
54.實時場景如何解決的;
55.拉鍊表如何設計,拉鍊表出現數據回滾的需求怎麼解決。
56.平臺選型依據;
57.數倉分層、模型、每層都是做什麼的?為什麼這麼做?
58.交叉維度的解決方案?
59.數據質量如何保證(DQC)?
60.任務延遲如何優化(SLA)?
61.聊一下數據資產。
62.如果讓你設計實時數倉你會如何設計,為什麼?
63.指標如何定義?
64.sql問題:連續活躍n天用戶的獲取;
65.數據傾斜的sql如何優化;數據量大的sql如何優化?
66.數據倉庫主題的劃分,參考Teradata的LDM模型;
67.Kimball和Inmon的相同和不同;
68.數據質量管理、數據治理有什麼好的方案?知識庫管理有什麼好的思路?血緣關係圖。
69.元數據管理相關問題,集群存儲不夠了,需要清理不需要的任務和數據該怎麼做?
70.業務庫2億數據入倉的策略,一次全量,之後每次增量;
71.什麼場景會出現數據傾斜,怎麼解決?比如select user_id,count(1) from table group by user_id,其中某些user_id的訪問量很大,查詢不出結果該怎麼辦?
72.sql裡面on和where有區別嗎?
73.聊一下技術架構,整個項目每個環節用的什麼技術這個樣子;
74.hive、hbase、spark。。。。這些大數據組件,熟悉哪個或者哪些?我說hive和hbase,對方就問hive和hbase的原理,差異等問題;
75.有沒有實時數倉的經驗,數據實時入倉思路,canal;
76.你對當前的項目組有沒有什麼自己的看法、意見或者需要改進的地方,這個改進對你有沒有什麼影響
77.ods的增量能否做成通用的?
78.公共層和數據集市層的區別和特點?
79.從原理上說一下mpp和mr的區別
80.對了中間還有問數倉數據的輸出主要是哪些還有數倉的分層;
81.報表如何展示
82.數據源,怎麼同步,同步時對業務庫的性能影響,同步後怎麼處理,使用方式誰,怎麼使用
83.你們數倉怎麼分層的以及各層主要做了什麼
84.你們主題是怎麼劃分的,舉個例子
85.如何判斷一個模型的好壞
86.你們需求的開發流程是什麼樣的
七.Flink
1.Flink實時計算時落磁碟嗎
2.日活DAU的統計需要注意什麼
3.Flink調優
4.Flink的容錯是怎麼做的
5.Parquet格式的好處?什麼時候讀的快什麼時候讀的慢
6.flink中checkPoint為什麼狀態有保存在內存中這樣的機制?為什麼要開啟checkPoint?
7.flink保證Exactly_Once的原理?
8.flink的時間形式和窗口形式有幾種?有什麼區別,你們用在什麼場景下的?
9.flink的背壓說下?
10.flink的watermark機制說下,以及怎麼解決數據亂序的問題?
11.flink on yarn執行流程
12.說一說spark 和flink 的區別
13.flink雙流join
14.flink任務提交方式
15.slot資源分配規劃
16.flink消費kafka發生partition數變更,flink底層是不是reblance
17.checkpoint原理
18.checkpoint barrier對齊原理,非對齊checkpoint原理
19.checkpoint失敗的場景
20.flink兩段提交原理
21.flink背壓的底層原理
22.onTimer同state並發操作的安全問題
23.flink kafkaConsumer源碼
24.看過哪些flink源碼
八.Java
1.hashMap底層源碼,數據結構
2.寫出你用過的設計模式,並舉例說明解決的實際問題
3.Java創建線程的幾種方式
4.請簡述作業系統的線程和進程的區別
5.Java程序出現OutOfMemoryError:unable to create new native thread 的原因可能有哪些?如何分析和解決?
6.採用java或自己熟悉的任何語言分別實現簡單版本的線性表和鍊表,只需實現add,remove方法即可
7.ArrayList和LinkedList的區別
8.JVM 內存分哪幾個區,每個區的作用是什麼?
9.Java中迭代器和集合的區別?
10.HashMap 和 HashTable 區別
11.線程池使用注意哪些方面?
12.HashMap和TreeMap的區別?TreeMap排序規則?
13.用java實現單例模式
14.使用遞歸算法求n的階乘:n! ,語言不限
15.HashMap和Hashtable的區別是什麼
16.TreeSet 和 HashSet 區別
17.Stringbuffer 和 Stringbuild 區別
18.Final、Finally、Finalize
19..==和 Equals 區別
20.比較ArrayList,LinkedList的存儲特性和讀寫性能
21.Java 類加載過程
22.java中垃圾收集的方法有哪些?
23.如何判斷一個對象是否存活?(或者GC對象的判定方法)
24.jvm、堆棧
25.java基本數據類型
26.spring AOP應用場景
27.分布式鎖的幾種實現方式
28.兩個數 a=3,b=5,如何不使用中間變量不使用函數情況下調換他們
九.Elasticsearch
1.為什麼要用es?存進es的數據是什麼格式的,怎麼查詢
十.Flume
1.什麼是flume
2.flume運行機制
3.Flume採集數據到Kafka中丟數據怎麼辦
4.Flume怎麼進行監控?
5.Flume的三層架構,collector、agent、storage
十一.Sqoop
1.Sqoop底層運行的任務是什麼
2.sqoop的遷移數據的原理
3.Sqoop參數
4.Sqoop導入導出Null存儲一致性問題
5.Sqoop數據導出一致性問題
6.通過sqoop把數據加載到mysql中,如何設置主鍵?
十二.Redis
1.緩存穿透、緩存雪崩、緩存擊穿
2.數據類型
3.持久化
4.悲觀鎖和樂觀鎖
5.redis 是單線程的,為什麼那麼快
6.redis的熱鍵問題?怎麼解決?
十三.Mysql
1.請寫出mysql登錄命令,用戶名user,密碼123456,地址192.168.1.130
2.為什麼MySQL的索引要使用B+樹而不是其它樹形結構?比如B樹?
十四.數據結構與算法
1.二分查找
2.快排
3.歸併排序
4.冒泡排序
5.字符串反轉
6.Btree簡單講一下
7.動態規劃 最大連續子序列和
8.二叉樹概念,特點及代碼實現
9.鍊表
10.算法題:兩數之和
十五.Linux
1.怎麼查看用戶組
2.怎麼修改文件權限
3.常用的命令有哪些
4.怎麼修改文本文件第一行字符
5.查看內存
6.查看磁碟存儲情況
7.查看磁碟IO讀寫(yum install iotop安裝)
8.直接查看比較高的磁碟讀寫程序
9.查看埠佔用情況
10.查看報告系統運行時長及平均負載
11.查看進程
HDFS讀寫流程
HDFS讀寫流程
hdfs有namenode、secondraynamenode、datanode組成。為n+1模式
NameNode負責管理和記錄整個文件系統的元數據
DataNode 負責管理用戶的文件數據塊,文件會按照固定的大小(blocksize)切成若干塊後分布式存儲在若干臺datanode上,每一個文件塊可以有多個副本,並存放在不同的datanode上,Datanode會定期向Namenode匯報自身所保存的文件block信息,而namenode則會負責保持文件的副本數量
HDFS的內部工作機制對客戶端保持透明,客戶端請求訪問HDFS都是通過向namenode申請來進行
secondraynamenode負責合併日誌
4.一個datanode 宕機,怎麼一個流程恢復Datanode宕機了後,如果是短暫的宕機,可以實現寫好腳本監控,將它啟動起來。如果是長時間宕機了,那麼datanode上的數據應該已經被備份到其他機器了,那這臺datanode就是一臺新的datanode了,刪除他的所有數據文件和狀態文件,重新啟動。
5.hadoop 的 namenode 宕機,怎麼解決先分析宕機後的損失,宕機後直接導致client無法訪問,內存中的元數據丟失,但是硬碟中的元數據應該還存在,如果只是節點掛了,重啟即可,如果是機器掛了,重啟機器後看節點是否能重啟,不能重啟就要找到原因修復了。但是最終的解決方案應該是在設計集群的初期就考慮到這個問題,做namenode的HA。
6.namenode對元數據的管理namenode對數據的管理採用了三種存儲形式:
7.元數據的checkpoint每隔一段時間,會由secondary namenode將namenode上積累的所有edits和一個最新的fsimage下載到本地,並加載到內存進行merge(這個過程稱為checkpoint)
namenode和secondary namenode的工作目錄存儲結構完全相同,所以,當namenode故障退出需要重新恢復時,可以從secondary namenode的工作目錄中將fsimage拷貝到namenode的工作目錄,以恢復namenode的元數據
8.yarn資源調度流程Yarn的資源調度流程
數據傾斜:map /reduce程序執行時,reduce節點大部分執行完畢,但是有一個或者幾個reduce節點運行很慢,導致整個程序的處理時間很長,這是因為某一個key的條數比其他key多很多(有時是百倍或者千倍之多),這條key所在的reduce節點所處理的數據量比其他節點就大很多,從而導致某幾個節點遲遲運行不完,此稱之為數據傾斜。
(1)局部聚合加全局聚合。
第一次在 map 階段對那些導致了數據傾斜的 key 加上 1 到 n 的隨機前綴,這樣本來相
同的 key 也會被分到多個 Reducer 中進行局部聚合,數量就會大大降低。
第二次 mapreduce,去掉 key 的隨機前綴,進行全局聚合。
思想:二次 mr,第一次將 key 隨機散列到不同 reducer 進行處理達到負載均衡目的。第
二次再根據去掉 key 的隨機前綴,按原 key 進行 reduce 處理。
這個方法進行兩次 mapreduce,性能稍差。
(2)增加 Reducer,提升並行度
JobConf.setNumReduceTasks(int)
(3)實現自定義分區
根據數據分布情況,自定義散列函數,將 key 均勻分配到不同 Reducer
11.shuffle 階段,你怎麼理解的12.Mapreduce 的 map 數量 和 reduce 數量是由什麼決定的 ,怎麼配置map的數量由輸入切片的數量決定,128M切分一個切片,只要是文件也分為一個切片,有多少個切片就有多少個map Task。
reduce數量自己配置。
13.MapReduce優化經驗設置合理的map和reduce的個數。合理設置blocksize
避免出現數據傾斜
combine函數
對數據進行壓縮
小文件處理優化:事先合併成大文件,combineTextInputformat,在hdfs上用mapreduce將小文件合併成SequenceFile大文件(key:文件名,value:文件內容)
參數優化
14.分別舉例什麼情況要使用 combiner,什麼情況不使用?求平均數的時候就不需要用combiner,因為不會減少reduce執行數量。在其他的時候,可以依據情況,使用combiner,來減少map的輸出數量,減少拷貝到reduce的文件,從而減輕reduce的壓力,節省網絡開銷,提升執行效率
15.MR運行流程解析詳解MapReduce執行流程
HDFS數據安全性如何保證?
存儲在HDFS系統上的文件,會分割成128M大小的block存儲在不同的節點上,block的副本數默認3份,也可配置成更多份;
第一個副本一般放置在與client(客戶端)所在的同一節點上(若客戶端無datanode,則隨機放),第二個副本放置到與第一個副本同一機架的不同節點,第三個副本放到不同機架的datanode節點,當取用時遵循就近原則;
datanode已block為單位,每3s報告心跳狀態,做10min內不報告心跳狀態則namenode認為block已死掉,namonode會把其上面的數據備份到其他一個datanode節點上,保證數據的副本數量;
datanode會默認每小時把自己節點上的所有塊狀態信息報告給namenode;
採用safemode模式:datanode會周期性的報告block信息。Namenode會計算block的損壞率,當閥值<0.999f時系統會進入安全模式,HDFS只讀不寫。HDFS元數據採用secondaryname備份或者HA備份
17.在通過客戶端向hdfs中寫數據的時候,如果某一臺機器宕機了,會怎麼處理在寫入的時候不會重新重新分配datanode。如果寫入時,一個datanode掛掉,會將已經寫入的數據放置到queue的頂部,並將掛掉的datanode移出pipline,將數據寫入到剩餘的datanode,在寫入結束後, namenode會收集datanode的信息,發現此文件的replication沒有達到配置的要求(default=3),然後尋找一個datanode保存副本。
18.Hadoop優化有哪些方面0)HDFS 小文件影響
(1)影響 NameNode 的壽命,因為文件元數據存儲在 NameNode 的內存中
(2)影響計算引擎的任務數量,比如每個小的文件都會生成一個 Map 任務
1)數據輸入小文件處理:
(1)合併小文件:對小文件進行歸檔(Har)、自定義 Inputformat 將小文件存儲成SequenceFile 文件。
(2)採用 ConbinFileInputFormat 來作為輸入,解決輸入端大量小文件場景。
(3)對於大量小文件 Job,可以開啟 JVM 重用。
2)Map 階段
(1)增大環形緩衝區大小。由 100m 擴大到 200m
(2)增大環形緩衝區溢寫的比例。由 80%擴大到 90%
(3)減少對溢寫文件的 merge 次數。(10 個文件,一次 20 個 merge)
(4)不影響實際業務的前提下,採用 Combiner 提前合併,減少 I/O。
3)Reduce 階段
(1)合理設置 Map 和 Reduce 數:兩個都不能設置太少,也不能設置太多。太少,會導致 Task 等待,延長處理時間;太多,會導致 Map、Reduce 任務間競爭資源,造成處理超時等錯誤。
(2)設置 Map、Reduce 共存:調整 slowstart.completedmaps 參數,使 Map 運行到一定程度後,Reduce 也開始運行,減少 Reduce 的等待時間。
(3)規避使用 Reduce,因為 Reduce 在用於連接數據集的時候將會產生大量的網絡消耗。
(4)增加每個 Reduce 去 Map 中拿數據的並行數
(5)集群性能可以的前提下,增大 Reduce 端存儲數據內存的大小。
4)IO 傳輸
(1)採用數據壓縮的方式,減少網絡 IO 的的時間。安裝 Snappy 和 LZOP 壓縮編碼器。
(2)使用 SequenceFile 二進位文件
5)整體
(1)MapTask 默認內存大小為 1G,可以增加 MapTask 內存大小為 4-5g
(2)ReduceTask 默認內存大小為 1G,可以增加 ReduceTask 內存大小為 4-5g
(3)可以增加 MapTask 的 cpu 核數,增加 ReduceTask 的 CPU 核數
(4)增加每個 Container 的 CPU 核數和內存大小
(5)調整每個 Map Task 和 Reduce Task 最大重試次數
19.大量數據求topN(寫出mapreduce的實現思路)20.列出正常工作的hadoop集群中hadoop都分別啟動哪些進程以及他們的作用1.NameNode它是hadoop中的主伺服器,管理文件系統名稱空間和對集群中存儲的文件的訪問,保存有metadate。
2.SecondaryNameNode它不是namenode的冗餘守護進程,而是提供周期檢查點和清理任務。幫助NN合併editslog,減少NN啟動時間。
3.DataNode它負責管理連接到節點的存儲(一個集群中可以有多個節點)。每個存儲數據的節點運行一個datanode守護進程。
4.ResourceManager(JobTracker)JobTracker負責調度DataNode上的工作。每個DataNode有一個TaskTracker,它們執行實際工作。
5.NodeManager(TaskTracker)執行任務
6.DFSZKFailoverController高可用時它負責監控NN的狀態,並及時的把狀態信息寫入ZK。它通過一個獨立線程周期性的調用NN上的一個特定接口來獲取NN的健康狀態。FC也有選擇誰作為Active NN的權利,因為最多只有兩個節點,目前選擇策略還比較簡單(先到先得,輪換)。
7.JournalNode 高可用情況下存放namenode的editlog文件.
21.Hadoop總job和Tasks之間的區別是什麼?Job是我們對一個完整的mapreduce程序的抽象封裝
Task是job運行時,每一個處理階段的具體實例,如map task,reduce task,maptask和reduce task都會有多個並發運行的實例
22.Hadoop高可用HA模式HDFS高可用原理:
Hadoop HA(High Available)通過同時配置兩個處於Active/Passive模式的Namenode來解決上述問題,狀態分別是Active和Standby. Standby Namenode作為熱備份,從而允許在機器發生故障時能夠快速進行故障轉移,同時在日常維護的時候使用優雅的方式進行Namenode切換。Namenode只能配置一主一備,不能多於兩個Namenode。
主Namenode處理所有的操作請求(讀寫),而Standby只是作為slave,維護儘可能同步的狀態,使得故障時能夠快速切換到Standby。為了使Standby Namenode與Active Namenode數據保持同步,兩個Namenode都與一組Journal Node進行通信。當主Namenode進行任務的namespace操作時,都會確保持久會修改日誌到Journal Node節點中。Standby Namenode持續監控這些edit,當監測到變化時,將這些修改同步到自己的namespace。
當進行故障轉移時,Standby在成為Active Namenode之前,會確保自己已經讀取了Journal Node中的所有edit日誌,從而保持數據狀態與故障發生前一致。
為了確保故障轉移能夠快速完成,Standby Namenode需要維護最新的Block位置信息,即每個Block副本存放在集群中的哪些節點上。為了達到這一點,Datanode同時配置主備兩個Namenode,並同時發送Block報告和心跳到兩臺Namenode。
確保任何時刻只有一個Namenode處於Active狀態非常重要,否則可能出現數據丟失或者數據損壞。當兩臺Namenode都認為自己的Active Namenode時,會同時嘗試寫入數據(不會再去檢測和同步數據)。為了防止這種腦裂現象,Journal Nodes只允許一個Namenode寫入數據,內部通過維護epoch數來控制,從而安全地進行故障轉移。
23.簡要描述安裝配置一個hadoop集群的步驟使用root帳戶登錄。
修改IP。
修改Host主機名。
配置SSH免密碼登錄。
關閉防火牆。
安裝JDK。
上傳解壓Hadoop安裝包。
配置Hadoop的核心配置文件hadoop-evn.sh,core-site.xml,mapred-site.xml,hdfs-site.xml,yarn-site.xml
配置hadoop環境變量
格式化hdfs # bin/hadoop namenode -format
啟動節點start-all.sh
24.fsimage和edit的區別fsimage:filesystem image 的簡寫,文件鏡像。
客戶端修改文件時候,先更新內存中的metadata信息,只有當對文件操作成功的時候,才會寫到editlog。
fsimage是文件meta信息的持久化的檢查點。secondary namenode會定期的將fsimage和editlog合併dump成新的fsimage
25.yarn的三大調度策略FIFO Scheduler把應用按提交的順序排成一個隊列,這是一個先進先出隊列,在進行資源分配的時候,先給隊列中最頭上的應用進行分配資源,待最頭上的應用需求滿足後再給下一個分配,以此類推。
Capacity(容量)調度器,有一個專門的隊列用來運行小任務,但是為小任務專門設置一個隊列會預先佔用一定的集群資源,這就導致大任務的執行時間會落後於使用FIFO調度器時的時間。
在Fair(公平)調度器中,我們不需要預先佔用一定的系統資源,Fair調度器會為所有運行的job動態的調整系統資源。當第一個大job提交時,只有這一個job在運行,此時它獲得了所有集群資源;當第二個小任務提交後,Fair調度器會分配一半資源給這個小任務,讓這兩個任務公平的共享集群資源。
需要注意的是,在下圖Fair調度器中,從第二個任務提交到獲得資源會有一定的延遲,因為它需要等待第一個任務釋放佔用的Container。小任務執行完成之後也會釋放自己佔用的資源,大任務又獲得了全部的系統資源。最終的效果就是Fair調度器即得到了高的資源利用率又能保證小任務及時完成。
26.hadoop的shell命令用的多嗎?,說出一些常用的-ls
-put
-get
-getmerge
-mkdir
-rm
27.用mr實現用戶pv的top10?
map輸入數據,將數據轉換成(用戶,訪問次數)的鍵值對,然後reduce端實現聚合,並且將結果寫入用戶、訪問次數的實體類,並且實現排序,最後的結果做一個top10的篩選
28.一個文件只有一行,但是這行有100G大小,mr會不會切分,我們應該怎麼解決
29.hdfs HA機制,一臺namenode宕機了,joualnode,namenode,edit.log fsimage的變化
二.Hive1.大表join小表產生的問題,怎麼解決?大表join小表,獨鍾愛mapjoin
join因為空值導致長尾(key為空值是用隨機值代替)
join因為熱點值導致長尾,也可以將熱點數據和非熱點數據分開處理,最後合併
2.udf udaf udtf區別HIVE之UDF函數開發
Hive內部表外部表區別及各自使用場景
Hive內部表外部表區別及各自使用場景
insert into:將數據寫到表中
override write:覆蓋之前的內容。
7.hive的判斷函數有哪些Hive常用函數
hive主要是做離線分析的
hive建表有三種方式
hive表有2種:內部表和外部表
9.線上業務每天產生的業務日誌(壓縮後>=3G),每天需要加載到hive的log表中,將每天產生的業務日誌在壓縮之後load到hive的log表時,最好使用的壓縮算法是哪個,並說明其原因選擇lzo,因為該壓縮算法可切分,壓縮率比較高,解壓縮速度很快,非常適合日誌
可以重新建表為分區分桶表
11.union all和union的區別union 去重
union all 不去重
12.如何解決hive數據傾斜的問題Hive調優,數據工程師成神之路
Hive調優,數據工程師成神之路
delet 刪除數據
drop 刪除表
truncate 摧毀表結構並重建
15.order by , sort by , distribute by , cluster by的區別深入探究order by,sort by,distribute by,cluster by的區別,並用數據徵服你
hive 默認的欄位分隔符為 ascii 碼的控制符\001(^A),建表的時候用 fields terminated by '\001'
遇到過欄位裡邊有\t 的情況,自定義 InputFormat,替換為其他分隔符再做後續處理
17.分區分桶的區別,為什麼要分區分區表:原來的一個大表存儲的時候分成不同的數據目錄進行存儲。如果說是單分區表,那麼在表的目錄下就只有一級子目錄,如果說是多分區表,那麼在表的目錄下有多少分區就有多少級子目錄。不管是單分區表,還是多分區表,在表的目錄下,和非最終分區目錄下是不能直接存儲數據文件的
分桶表:原理和hashpartitioner 一樣,將hive中的一張表的數據進行歸納分類的時候,歸納分類規則就是hashpartitioner。(需要指定分桶欄位,指定分成多少桶)
分區表和分桶的區別除了存儲的格式不同外,最主要的是作用:
有了分區為什麼還要分桶?
(1)獲得更高的查詢處理效率。桶為表加上了額外的結構,Hive在處理有些查詢時能利用這個結構。
(2)使取樣( sampling)更高效。在處理大規模數據集時,在開發和修改査詢的階段,如果能在數據集的一小部分數據上試運行查詢,會帶來很多方便。
分桶是相對分區進行更細粒度的劃分。分桶將表或者分區的某列值進行hash值進行區分,如要安裝name屬性分為3個桶,就是對name屬性值的hash值對3取摸,按照取模結果對數據分桶。
與分區不同的是,分區依據的不是真實數據表文件中的列,而是我們指定的偽列,但是分桶是依據數據表中真實的列而不是偽列
18.mapjoin的原理大表join小表,獨鍾愛mapjoin
row_number() over( partition by 分組的欄位 order by 排序的欄位) as rank(rank 可隨意定義表示排序的標識);
row_number() over( distribute by 分組的欄位 sort by 排序的欄位) as rank(rank 可隨意定義表示排序的標識)
注意:
partition by 只能和order by 組合使用
distribute by 只能和 sort by 使用
Hive調優,數據工程師成神之路
Hive內部表外部表區別及各自使用場景
Hive常用函數
23.手寫sql,連續活躍用戶
大廠高頻面試題-連續登錄問題
24.left semi join和left join區別
left semi join和left join區別
25.group by為什麼要排序
26.說說印象最深的一次優化場景,hive常見的優化思路
Hive調優,數據工程師成神之路
27.聊聊hive的執行引擎,spark和mr的區別?
引擎是mr,基於磁碟進行計算,比較慢
引擎是spark,基於內存進行計算,速度比較快
對於超大數據量的話,hiveOnSpark可能會有內存溢出情況
28.hive的join底層mr是如何實現的?
Hive的join底層mapreduce是如何實現的?
29.sql問題,連續幾天活躍的用戶?
大廠高頻面試題-連續登錄問題
30.建好了外部表,用什麼語句把數據文件加載到表裡
31.Hive的執行流程?
用戶提交查詢等任務給Driver。
編譯器獲得該用戶的任務Plan。
編譯器Compiler根據用戶任務去MetaStore中獲取需要的Hive的元數據信息。
編譯器Compiler得到元數據信息,對任務進行編譯,先將HiveQL轉換為抽象語法樹,然後將抽象語法樹轉換成查詢塊,將查詢塊轉化為邏輯的查詢計劃,重寫邏輯查詢計劃,將邏輯計劃轉化為物理的計劃(MapReduce), 最後選擇最佳的策略。
將最終的計劃提交給Driver。
Driver將計劃Plan轉交給ExecutionEngine去執行,獲取元數據信息,提交給JobTracker或者SourceManager執行該任務,任務會直接讀取HDFS中文件進行相應的操作。
獲取執行的結果。
取得並返回執行結果。
Hive的join底層mapreduce是如何實現的?
32.hive的元數據信息存儲在哪?
33.sql語句的執行順序
from-where-group by-having -select-order by -limit
34.on和where的區別
left join(on&where)
35.hive和傳統資料庫之間的區別
1、寫時模式和讀時模式
傳統資料庫是寫時模式,在load過程中,提升了査詢性能,因為預先解析之後可以對列建立索引,並壓縮,但這樣也會花費更多的加載時間。
Hive是讀時模式,1 oad data非常迅速,因為它不需要讀取數據進行解析,僅僅進行文件的複製或者移動。
2、數據格式。Hive中沒有定義專門的數據格式,由用戶指定,需要指定三個屬性:列分隔符,行分隔符,以及讀取文件數據的方法。資料庫中,存儲引擎定義了自己的數據格式。所有數據都會按照一定的組織存儲
3、數據更新。Hive的內容是讀多寫少的,因此,不支持對數據的改寫和刪除,數據都在加載的時候中確定好的。資料庫中的數據通常是需要經常進行修改
4、執行延遲。Hive在查詢數據的時候,需要掃描整個表(或分區),因此延遲較高,只有在處理大數據是才有優勢。資料庫在處理小數據是執行延遲較低。
5、索引。Hive比較弱,不適合實時查詢。資料庫有。
6、執行。Hive是 Mapreduce,資料庫是 Executor
7、可擴展性。Hive高,資料庫低
8、數據規模。Hive大,資料庫小
36.hive中導入數據的4種方式
從本地導入:load data local inpath /home/liuzc into table ods.test
從hdfs導入:load data inpath /user/hive/warehouse/a.txt into ods.test
查詢導入:create table tmp_test as select * from ods.test
查詢結果導入:insert into table tmp.test select * from ods.test
37 下述sql在hive,sparksql兩種執行引擎中,執行流程分別是什麼,區別是什麼?
select
t1.c,t2.b
from
t1 join t2
on t1.id = t2.id
38.hive的執行計劃有看過嗎,你一般會關注哪幾個點
39.hive底層運行mr或者spark程序的時候語法樹說一下
一組分片(Partition),即數據集的基本組成單位。對於RDD來說,每個分片都會被一個計算任務處理,並決定並行計算的粒度。用戶可以在創建RDD時指定RDD的分片個數,如果沒有指定,那麼就會採用默認值。默認值就是程序所分配到的CPU Core的數目。
一個計算每個分區的函數。Spark中RDD的計算是以分片為單位的,每個RDD都會實現compute函數以達到這個目的。compute函數會對迭代器進行複合,不需要保存每次計算的結果。
RDD之間的依賴關係。RDD的每次轉換都會生成一個新的RDD,所以RDD之間就會形成類似於流水線一樣的前後依賴關係。在部分分區數據丟失時,Spark可以通過這個依賴關係重新計算丟失的分區數據,而不是對RDD的所有分區進行重新計算。
一個Partitioner,即RDD的分片函數。當前Spark中實現了兩種類型的分片函數,一個是基於哈希的HashPartitioner,另外一個是基於範圍的RangePartitioner。只有對于于key-value的RDD,才會有Partitioner,非key-value的RDD的Parititioner的值是None。Partitioner函數不但決定了RDD本身的分片數量,也決定了parent RDD Shuffle輸出時的分片數量。
一個列表,存儲存取每個Partition的優先位置(preferred location)。對於一個HDFS文件來說,這個列表保存的就是每個Partition所在的塊的位置。按照「移動數據不如移動計算」的理念,Spark在進行任務調度的時候,會儘可能地將計算任務分配到其所要處理數據塊的存儲位置。
2.算子分為哪幾類(RDD支持哪幾種類型的操作)轉換(Transformation) 現有的RDD通過轉換生成一個新的RDD。lazy模式,延遲執行。
轉換函數包括:map,filter,flatMap,groupByKey,reduceByKey,aggregateByKey,union,join, coalesce 等等。
動作(Action) 在RDD上運行計算,並返回結果給驅動程序(Driver)或寫入文件系統。
動作操作包括:reduce,collect,count,first,take,countByKey以及foreach等等。
collect 該方法把數據收集到driver端 Array數組類型
所有的transformation只有遇到action才能被執行。
當觸發執行action之後,數據類型不再是rdd了,數據就會存儲到指定文件系統中,或者直接列印結 果或者收集起來。
3.創建rdd的幾種方式1.集合併行化創建(有數據)
val arr = Array(1,2,3,4,5)
val rdd = sc.parallelize(arr)
val rdd =sc.makeRDD(arr)
2.讀取外部文件系統,如hdfs,或者讀取本地文件(最常用的方式)(沒數據)
val rdd2 = sc.textFile("hdfs://hdp-01:9000/words.txt")
// 讀取本地文件
val rdd2 = sc.textFile(「file:///root/words.txt」)
3.從父RDD轉換成新的子RDD
調用Transformation類的方法,生成新的RDD
4.spark運行流程Worker的功能:定時和master通信;調度並管理自身的executor
executor:由Worker啟動的,程序最終在executor中運行,(程序運行的一個容器)
spark-submit命令執行時,會根據master地址去向 Master發送請求,
Master接收到Dirver端的任務請求之後,根據任務的請求資源進行調度,(打散的策略),儘可能的 把任務資源平均分配,然後向WOrker發送指令
Worker收到Master的指令之後,就根據相應的資源,啟動executor(cores,memory)
executor會向dirver端建立請求,通知driver,任務已經可以運行了
driver運行任務的時候,會把任務發送到executor中去運行。
5.Spark中coalesce與repartition的區別1)關係:
兩者都是用來改變 RDD 的 partition 數量的,repartition 底層調用的就是 coalesce 方法:coalesce(numPartitions, shuffle = true)
2)區別:
repartition 一定會發生 shuffle,coalesce 根據傳入的參數來判斷是否發生 shuffle
一般情況下增大 rdd 的 partition 數量使用 repartition,減少 partition 數量時使用coalesce
6.sortBy 和 sortByKey的區別sortBy既可以作用於RDD[K] ,還可以作用於RDD[(k,v)]
sortByKey 只能作用於 RDD[K,V] 類型上。
7.map和mapPartitions的區別使用 foreachPartition
* 1,map mapPartition 是轉換類的算子, 有返回值
* 2, 寫mysql,redis 的連接
foreach * 100萬 100萬次的連接
foreachPartions * 200 個分區 200次連接 一個分區中的數據,共用一個連接
foreachParititon 每次迭代一個分區,foreach每次迭代一個元素。
該方法沒有返回值,或者Unit
主要作用於,沒有返回值類型的操作(列印結果,寫入到mysql資料庫中)
在寫入到redis,mysql的時候,優先使用foreachPartititon
9.reduceByKey和groupBykey的區別reduceByKey會傳一個聚合函數, 相當於 groupByKey + mapValues
reduceByKey 會有一個分區內聚合,而groupByKey沒有 最核心的區別
結論:reduceByKey有分區內聚合,更高效,優先選擇使用reduceByKey。
10.cache和checkPoint的比較都是做 RDD 持久化的
1.緩存,是在觸發action之後,把數據寫入到內存或者磁碟中。不會截斷血緣關係
(設置緩存級別為memory_only:內存不足,只會部分緩存或者沒有緩存,緩存會丟失,memory_and_disk :內存不足,會使用磁碟)
2.checkpoint 也是在觸發action之後,執行任務。單獨再啟動一個job,負責寫入數據到hdfs中。(把rdd中的數據,以二進位文本的方式寫入到hdfs中,有幾個分區,就有幾個二進位文件)
3.某一個RDD被checkpoint之後,他的父依賴關係會被刪除,血緣關係被截斷,該RDD轉換成了CheckPointRDD,以後再對該rdd的所有操作,都是從hdfs中的checkpoint的具體目錄來讀取數據。緩存之後,rdd的依賴關係還是存在的。
11.spark streaming流式統計單詞數量代碼object WordCountAll { // newValues當前批次的出現的單詞次數, runningCount表示之前運行的單詞出現的結果 /* def updateFunction(newValues: Seq[Int], runningCount: Option[Int]): Option[Int] = { val newCount = newValues.sum + runningCount.getOrElse(0)// 將歷史前幾個批次的值和當前批次的值進行累加返回當前批次最終的結果 Some(newCount) }*/ /** * String : 單詞 hello * Seq[Int] :單詞在當前批次出現的次數 * Option[Int] :歷史結果 */ val updateFunc = (iter: Iterator[(String, Seq[Int], Option[Int])]) => { //iter.flatMap(it=>Some(it._2.sum + it._3.getOrElse(0)).map(x=>(it._1,x))) iter.flatMap{case(x,y,z)=>Some(y.sum + z.getOrElse(0)).map(m=>(x, m))} } // 屏蔽日誌 Logger.getLogger("org.apache").setLevel(Level.ERROR) def main(args: Array[String]) { // 必須要開啟2個以上的線程,一個線程用來接收數據,另外一個線程用來計算 val conf = new SparkConf().setMaster("local[2]").setAppName("NetworkWordCount") // 設置sparkjob計算時所採用的序列化方式 .set("spark.serializer", "org.apache.spark.serializer.KryoSerializer") .set("spark.rdd.compress", "true") // 節約大量的內存內容 // 如果你的程序出現垃圾回收時間過程,可以設置一下java的垃圾回收參數 // 同時也會創建sparkContext對象 // 批次時間 >= 批次處理的總時間 (批次數據量,集群的計算節點數量和配置) val ssc = new StreamingContext(conf, Seconds(5))
//做checkpoint 寫入共享存儲中 ssc.checkpoint("c://aaa")
// 創建一個將要連接到 hostname:port 的 DStream,如 localhost:9999 val lines: ReceiverInputDStream[String] = ssc.socketTextStream("192.168.175.101", 44444) //updateStateByKey結果可以累加但是需要傳入一個自定義的累加函數:updateFunc val results = lines.flatMap(_.split(" ")).map((_,1)).updateStateByKey(updateFunc, new HashPartitioner(ssc.sparkContext.defaultParallelism), true) //列印結果到控制臺 results.print() //開始計算 ssc.start() //等待停止 ssc.awaitTermination() }}
12.簡述map和flatMap的區別和應用場景map是對每一個元素進行操作,flatmap是對每一個元素操作後並壓平
13.計算曝光數和點擊數
14.分別列出幾個常用的transformation和action算子轉換算子:map,map,filter,reduceByKey,groupByKey,groupBy
行動算子:foreach,foreachpartition,collect,collectAsMap,take,top,first,count,countByKey
15.按照需求使用spark編寫以下程序,要求使用scala語言當前文件a.txt的格式,請統計每個單詞出現的次數
A,b,c
B,b,f,e
object WordCount {
def main(args: Array[String]): Unit = {
val conf = new SparkConf() .setAppName(this.getClass.getSimpleName) .setMaster("local[*]") val sc = new SparkContext(conf)
var sData: RDD[String] = sc.textFile("a.txt") val sortData: RDD[(String, Int)] = sData.flatMap(_.split(",")).map((_,1)).reduceByKey(_+_) sortData.foreach(print) }}
16.spark應用程式的執行命令是什麼?/usr/local/spark-current2.3/bin/spark-submit \
--class com.wedoctor.Application \
--master yarn \
--deploy-mode client \
--driver-memory 1g \
--executor-memory 2g \
--queue root.wedw \
--num-executors 200 \
--jars /home/pgxl/liuzc/config-1.3.0.jar,/home/pgxl/liuzc/hadoop-lzo-0.4.20.jar,/home/pgxl/liuzc/elasticsearch-hadoop-hive-2.3.4.jar \
/home/pgxl/liuzc/sen.jar
17.Spark應用執行有哪些模式,其中哪幾種是集群模式本地local模式
standalone模式
spark on yarn模式
spark on mesos模式
其中,standalone模式,spark on yarn模式,spark on mesos模式是集群模式
18.請說明spark中廣播變量的用途使用廣播變量,每個 Executor 的內存中,只駐留一份變量副本,而不是對 每個 task 都傳輸一次大變量,省了很多的網絡傳輸, 對性能提升具有很大幫助, 而且會通過高效的廣播算法來減少傳輸代價。
19.以下代碼會報錯嗎?如果會怎麼解決 val arr = new ArrayList[String]; arr.foreach(println)val arr = new ArrayList[String]; 這裡會報錯,需要改成 val arr: Array[String] = new Array[String](10)
arr.foreach(println)列印不會報空指針
20.寫出你用過的spark中的算子,其中哪些會產生shuffle過程reduceBykey:
groupByKey:
…ByKey:
21.Spark中rdd與partition的區別22.請寫出創建Dateset的幾種方式23.描述一下RDD,DataFrame,DataSet的區別?1)RDD
優點:
編譯時類型安全
編譯時就能檢查出類型錯誤
面向對象的編程風格
直接通過類名點的方式來操作數據
缺點:
序列化和反序列化的性能開銷
無論是集群間的通信, 還是 IO 操作都需要對對象的結構和數據進行序列化和反序列化。
GC 的性能開銷,頻繁的創建和銷毀對象, 勢必會增加 GC
2)DataFrame
DataFrame 引入了 schema 和 off-heap
schema : RDD 每一行的數據, 結構都是一樣的,這個結構就存儲在 schema 中。Spark 通過 schema 就能夠讀懂數據, 因此在通信和 IO 時就只需要序列化和反序列化數據, 而結構的部分就可以省略了。
3)DataSet
DataSet 結合了 RDD 和 DataFrame 的優點,並帶來的一個新的概念 Encoder。
當序列化數據時,Encoder 產生字節碼與 off-heap 進行交互,能夠達到按需訪問數據的效果,而不用反序列化整個對象。Spark 還沒有提供自定義 Encoder 的 API,但是未來會加入。
三者之間的轉換:
24.描述一下Spark中stage是如何劃分的?描述一下shuffle的概念25.Spark 在yarn上運行需要做哪些關鍵的配置工作?如何kill -個Spark在yarn運行中Application26.通常來說,Spark與MapReduce相比,Spark運行效率更高。請說明效率更高來源於Spark內置的哪些機制?並請列舉常見spark的運行模式?27.RDD中的數據在哪?RDD中的數據在數據源,RDD只是一個抽象的數據集,我們通過對RDD的操作就相當於對數據進行操作。
28.如果對RDD進行cache操作後,數據在哪裡?數據在第一執行cache算子時會被加載到各個Executor進程的內存中,第二次就會直接從內存中讀取而不會區磁碟。
29.Spark中Partition的數量由什麼決定和Mr一樣,但是Spark默認最少有兩個分區。
30.Scala裡面的函數和方法有什麼區別31.SparkStreaming怎麼進行監控?32.Spark判斷Shuffle的依據?父RDD的一個分區中的數據有可能被分配到子RDD的多個分區中
33.Scala有沒有多繼承?可以實現多繼承麼?34.Sparkstreaming和flink做實時處理的區別35.Sparkcontext的作用36.Sparkstreaming讀取kafka數據為什麼選擇直連方式37.離線分析什麼時候用sparkcore和sparksq38.Sparkstreaming實時的數據不丟失的問題39.簡述寬依賴和窄依賴概念,groupByKey,reduceByKey,map,filter,union五種操作哪些會導致寬依賴,哪些會導致窄依賴40.數據傾斜可能會導致哪些問題,如何監控和排查,在設計之初,要考慮哪些來避免41.有一千萬條簡訊,有重複,以文本文件的形式保存,一行一條數據,請用五分鐘時間,找出重複出現最多的前10條42.現有一文件,格式如下,請用spark統計每個單詞出現的次數18619304961,18619304064,186193008,186193009
18619304962,18619304065,186193007,186193008
18619304963,18619304066,186193006,186193010
43.共享變量和累加器累加器(accumulator)是 Spark 中提供的一種分布式的變量機制,其原理類似於mapreduce,即分布式的改變,然後聚合這些改變。累加器的一個常見用途是在調試時對作業執行過程中的事件進行計數。而廣播變量用來高效分發較大的對象。
共享變量出現的原因:
通常在向 Spark 傳遞函數時,比如使用 map() 函數或者用 filter() 傳條件時,可以使用驅動器程序中定義的變量,但是集群中運行的每個任務都會得到這些變量的一份新的副本,更新這些副本的值也不會影響驅動器中的對應變量。
Spark 的兩個共享變量,累加器與廣播變量,分別為結果聚合與廣播這兩種常見的通信模式突破了這一限制。
44.當 Spark 涉及到資料庫的操作時,如何減少 Spark 運行中的資料庫連接數?使用 foreachPartition 代替 foreach,在 foreachPartition 內獲取資料庫的連接。
45.特別大的數據,怎麼發送到excutor中?
46.spark調優都做過哪些方面?
47.spark任務為什麼會被yarn kill掉?
48.Spark on Yarn作業執行流程?yarn-client和yarn-cluster有什麼區別?你們公司還在用SparkOnYan嗎?
49.Flatmap底層編碼實現?Spark flatMap 源碼:
/** * Return a new RDD by first applying a function to all elements of this * RDD, and then flattening the results. */ def flatMap[U: ClassTag](f: T => TraversableOnce[U]): RDD[U] = withScope { val cleanF = sc.clean(f) new MapPartitionsRDD[U, T](this, (context, pid, iter) => iter.flatMap(cleanF)) }Scala flatMap 源碼:
/** Creates a new iterator by applying a function to all values produced by this iterator * and concatenating the results. * * @param f the function to apply on each element. * @return the iterator resulting from applying the given iterator-valued function * `f` to each value produced by this iterator and concatenating the results. * @note Reuse: $consumesAndProducesIterator */ def flatMap[B](f: A => GenTraversableOnce[B]): Iterator[B] = new AbstractIterator[B] { private var cur: Iterator[B] = empty private def nextCur() { cur = f(self.next()).toIterator } def hasNext: Boolean = { // Equivalent to cur.hasNext || self.hasNext && { nextCur(); hasNext } // but slightly shorter bytecode (better JVM inlining!) while (!cur.hasNext) { if (!self.hasNext) return false nextCur() } true } def next(): B =<span style="color:#ffffff"> <span style="background-color:rgb(255,0,0)">(if (hasNext) cur else empty).next()</span></span> }flatMap其實就是將RDD裡的每一個元素執行自定義函數f,這時這個元素的結果轉換成iterator,最後將這些再拼接成一個
新的RDD,也可以理解成原本的每個元素由橫向執行函數f後再變為縱向。畫紅部分一直在回調,當RDD內沒有元素為止。
50.spark_1.X與spark_2.X區別
51.說說spark與flink
52.spark streaming如何保證7*24小時運行機制?
53.spark streaming是Exactly-Once嗎?
四.Kafka1.Kafka名詞解釋和工作方式Producer :消息生產者,就是向kafka broker發消息的客戶端。
Consumer :消息消費者,向kafka broker取消息的客戶端
Topic :咋們可以理解為一個隊列。
Consumer Group (CG):這是kafka用來實現一個topic消息的廣播(發給所有的consumer)和單播(發給任意一個consumer)的手段。一個topic可以有多個CG。topic的消息會複製(不是真的複製,是概念上的)到所有的CG,但每個partion只會把消息發給該CG中的一個consumer。如果需要實現廣播,只要每個consumer有一個獨立的CG就可以了。要實現單播只要所有的consumer在同一個CG。用CG還可以將consumer進行自由的分組而不需要多次發送消息到不同的topic。
Broker :一臺kafka伺服器就是一個broker。一個集群由多個broker組成。一個broker可以容納多個topic。
Partition:為了實現擴展性,一個非常大的topic可以分布到多個broker(即伺服器)上,一個topic可以分為多個partition,每個partition是一個有序的隊列。partition中的每條消息都會被分配一個有序的id(offset)。kafka只保證按一個partition中的順序將消息發給consumer,不保證一個topic的整體(多個partition間)的順序。
Offset:kafka的存儲文件都是按照offset.kafka來命名,用offset做名字的好處是方便查找。例如你想找位於2049的位置,只要找到2048.kafka的文件即可。當然the first offset就是00000000000.kafka
2.Consumer與topic關係本質上kafka只支持Topic;
每個group中可以有多個consumer,每個consumer屬於一個consumer group;
通常情況下,一個group中會包含多個consumer,這樣不僅可以提高topic中消息的並發消費能力,而且還能提高"故障容錯"性,如果group中的某個consumer失效那麼其消費的partitions將會有其他consumer自動接管。
對於Topic中的一條特定的消息,只會被訂閱此Topic的每個group中的其中一個consumer消費,此消息不會發送給一個group的多個consumer;
那麼一個group中所有的consumer將會交錯的消費整個Topic,每個group中consumer消息消費互相獨立,我們可以認為一個group是一個"訂閱"者。
在kafka中,一個partition中的消息只會被group中的一個consumer消費(同一時刻);
一個Topic中的每個partions,只會被一個"訂閱者"中的一個consumer消費,不過一個consumer可以同時消費多個partitions中的消息。
kafka的設計原理決定,對於一個topic,同一個group中不能有多於partitions個數的consumer同時消費,否則將意味著某些consumer將無法得到消息。
kafka只能保證一個partition中的消息被某個consumer消費時是順序的;事實上,從Topic角度來說,當有多個partitions時,消息仍不是全局有序的。
3.kafka中生產數據的時候,如何保證寫入的容錯性?設置發送數據是否需要服務端的反饋,有三個值0,1,-1
0: producer不會等待broker發送ack
1: 當leader接收到消息之後發送ack
-1: 當所有的follower都同步消息成功後發送ack
request.required.acks=0
4.如何保證kafka消費者消費數據是全局有序的偽命題
每個分區內,每條消息都有一個offset,故只能保證分區內有序。
如果要全局有序的,必須保證生產有序,存儲有序,消費有序。
由於生產可以做集群,存儲可以分片,消費可以設置為一個consumerGroup,要保證全局有序,就需要保證每個環節都有序。
只有一個可能,就是一個生產者,一個partition,一個消費者。這種場景和大數據應用場景相悖。
5.有兩個數據源,一個記錄的是廣告投放給用戶的日誌,一個記錄用戶訪問日誌,另外還有一個固定的用戶基礎表記錄用戶基本信息(比如學歷,年齡等等)。現在要分析廣告投放對與哪類用戶更有效,請採用熟悉的技術描述解決思路。另外如果兩個數據源都是實時數據源(比如來自kafka),他們數據在時間上相差5分鐘,需要哪些調整來解決實時分析問題?6.Kafka和SparkStreaing如何集成?7.列舉Kafka的優點,簡述Kafka為什麼可以做到每秒數十萬甚至上百萬消息的高效分發?8.為什麼離線分析要用kafka?Kafka的作用是解耦,如果直接從日誌伺服器上採集的話,實時離線都要採集,等於要採集兩份數據,而使用了kafka的話,只需要從日誌伺服器上採集一份數據,然後在kafka中使用不同的兩個組讀取就行了
9.Kafka怎麼進行監控?Kafka Manager
10.Kafka與傳統的消息隊列服務有很麼不同11.Kafka api low-level與high-level有什麼區別,使用low-level需要處理哪些細節12.Kafka的ISR副本同步隊列ISR(In-Sync Replicas),副本同步隊列。ISR中包括Leader和Follower。如果Leader進程掛掉,會在ISR隊列中選擇一個服務作為新的Leader。有replica.lag.max.messages(延遲條數)和replica.lag.time.max.ms(延遲時間)兩個參數決定一臺服務是否可以加入ISR副本隊列,在0.10版本移除了replica.lag.max.messages參數,防止服務頻繁的進去隊列。
任意一個維度超過閾值都會把Follower剔除出ISR,存入OSR(Outof-Sync Replicas)列表,新加入的Follower也會先存放在OSR中。
13.Kafka消息數據積壓,Kafka消費能力不足怎麼處理?1)如果是Kafka消費能力不足,則可以考慮增加Topic的分區數,並且同時提升消費組的消費者數量,消費者數=分區數。(兩者缺一不可)
2)如果是下遊的數據處理不及時:提高每批次拉取的數量。批次拉取數據過少(拉取數據/處理時間<生產速度),使處理的數據小於生產的數據,也會造成數據積壓。
14.Kafka中的ISR、AR又代表什麼?ISR:in-sync replicas set (ISR),與leader保持同步的follower集合
AR:分區的所有副本
15.Kafka中的HW、LEO等分別代表什麼?LEO:每個副本的最後條消息的offset
HW:一個分區中所有副本最小的offset
16.哪些情景會造成消息漏消費?先提交offset,後消費,有可能造成數據的重複
17.當你使用kafka-topics.sh創建了一個topic之後,Kafka背後會執行什麼邏輯?1)會在zookeeper中的/brokers/topics節點下創建一個新的topic節點,如:/brokers/topics/first
2)觸發Controller的監聽程序
3)kafka Controller 負責topic的創建工作,並更新metadata cache
18.topic的分區數可不可以增加?如果可以怎麼增加?如果不可以,那又是為什麼?可以增加
bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-config --partitions 3
19.topic的分區數可不可以減少?如果可以怎麼減少?如果不可以,那又是為什麼?不可以減少,被刪除的分區數據難以處理。
20.Kafka有內部的topic嗎?如果有是什麼?有什麼所用?__consumer_offsets,保存消費者offset
21.聊一聊Kafka Controller的作用?負責管理集群broker的上下線,所有topic的分區副本分配和leader選舉等工作。
22.失效副本是指什麼?有那些應對措施?不能及時與leader同步,暫時踢出ISR,等其追上leader之後再重新加入
23.Kafka 都有哪些特點?高吞吐量、低延遲:kafka每秒可以處理幾十萬條消息,它的延遲最低只有幾毫秒,每個topic可以分多個partition, consumer group 對partition進行consume操作。
可擴展性:kafka集群支持熱擴展
持久性、可靠性:消息被持久化到本地磁碟,並且支持數據備份防止數據丟失
容錯性:允許集群中節點失敗(若副本數量為n,則允許n-1個節點失敗)
高並發:支持數千個客戶端同時讀寫
24.請簡述下你在哪些場景下會選擇 Kafka?日誌收集:一個公司可以用Kafka可以收集各種服務的log,通過kafka以統一接口服務的方式開放給各種consumer,例如hadoop、HBase、Solr等。
消息系統:解耦和生產者和消費者、緩存消息等。
用戶活動跟蹤:Kafka經常被用來記錄web用戶或者app用戶的各種活動,如瀏覽網頁、搜索、點擊等活動,這些活動信息被各個伺服器發布到kafka的topic中,然後訂閱者通過訂閱這些topic來做實時的監控分析,或者裝載到hadoop、數據倉庫中做離線分析和挖掘。
運營指標:Kafka也經常用來記錄運營監控數據。包括收集各種分布式應用的數據,生產各種操作的集中反饋,比如報警和報告。
流式處理:比如spark streaming和 Flink
25.Kafka 的設計架構你知道嗎?簡單架構如下
詳細如下
Kafka 架構分為以下幾個部分
Producer :消息生產者,就是向 kafka broker 發消息的客戶端。
Consumer :消息消費者,向 kafka broker 取消息的客戶端。
Topic :可以理解為一個隊列,一個 Topic 又分為一個或多個分區。
Consumer Group:這是 kafka 用來實現一個 topic 消息的廣播(發給所有的 consumer)和單播(發給任意一個 consumer)的手段。一個 topic 可以有多個 Consumer Group。
Broker :一臺 kafka 伺服器就是一個 broker。一個集群由多個 broker 組成。一個 broker 可以容納多個 topic。
Partition:為了實現擴展性,一個非常大的 topic 可以分布到多個 broker上,每個 partition 是一個有序的隊列。partition 中的每條消息都會被分配一個有序的id(offset)。將消息發給 consumer,kafka 只保證按一個 partition 中的消息的順序,不保證一個 topic 的整體(多個 partition 間)的順序。
Offset:kafka 的存儲文件都是按照 offset.kafka 來命名,用 offset 做名字的好處是方便查找。例如你想找位於 2049 的位置,只要找到 2048.kafka 的文件即可。當然 the first offset 就是 00000000000.kafka。
26.Kafka 分區的目的?分區對於 Kafka 集群的好處是:實現負載均衡。分區對於消費者來說,可以提高並發度,提高效率。
27.你知道 Kafka 是如何做到消息的有序性?kafka 中的每個 partition 中的消息在寫入時都是有序的,而且消息帶有offset偏移量,消費者按偏移量的順序從前往後消費,從而保證了消息的順序性。但是分區之間的消息是不保證有序的。
28.Kafka 的高可靠性是怎麼實現的?kafka通過分區的多副本機制來保證消息的可靠性。1. 每個分區可以設置多個副本,這些副本分布在不同的broker上;2. 相同partition的多個副本能動態選舉leader來對外服務和管理內部數據同步。這樣,即使有broker出現故障,受影響的partition也會在其他broker上重新選舉出新的leader來繼續服務
更具體來說,可參看下文:
Kafka 的分區多副本架構是 Kafka 可靠性保證的核心,把消息寫入多個副本可以使 Kafka 在發生崩潰時仍能保證消息的持久性。
Producer 往 Broker 發送消息如果我們要往 Kafka 對應的主題發送消息,我們需要通過 Producer 完成。前面我們講過 Kafka 主題對應了多個分區,每個分區下面又對應了多個副本;為了讓用戶設置數據可靠性, Kafka 在 Producer 裡面提供了消息確認機制。也就是說我們可以通過配置來決定消息發送到對應分區的幾個副本才算消息發送成功。可以在定義 Producer 時通過 acks 參數指定(在 0.8.2.X 版本之前是通過 request.required.acks 參數設置的,詳見 KAFKA-3043)。這個參數支持以下三種值:
acks = 0:意味著如果生產者能夠通過網絡把消息發送出去,那麼就認為消息已成功寫入 Kafka 。在這種情況下還是有可能發生錯誤,比如發送的對象無能被序列化或者網卡發生故障,但如果是分區離線或整個集群長時間不可用,那就不會收到任何錯誤。在 acks=0 模式下的運行速度是非常快的(這就是為什麼很多基準測試都是基於這個模式),你可以得到驚人的吞吐量和帶寬利用率,不過如果選擇了這種模式, 一定會丟失一些消息。
acks = 1:意味若 Leader 在收到消息並把它寫入到分區數據文件(不一定同步到磁碟上)時會返回確認或錯誤響應。在這個模式下,如果發生正常的 Leader 選舉,生產者會在選舉時收到一個 LeaderNotAvailableException 異常,如果生產者能恰當地處理這個錯誤,它會重試發送悄息,最終消息會安全到達新的 Leader 那裡。不過在這個模式下仍然有可能丟失數據,比如消息已經成功寫入 Leader,但在消息被複製到 follower 副本之前 Leader發生崩潰。
acks = all(這個和 request.required.acks = -1 含義一樣):意味著 Leader 在返回確認或錯誤響應之前,會等待所有同步副本都收到悄息。如果和 min.insync.replicas 參數結合起來,就可以決定在返回確認前至少有多少個副本能夠收到悄息,生產者會一直重試直到消息被成功提交。不過這也是最慢的做法,因為生產者在繼續發送其他消息之前需要等待所有副本都收到當前的消息。
根據實際的應用場景,我們設置不同的 acks,以此保證數據的可靠性。
另外,Producer 發送消息還可以選擇同步(默認,通過 producer.type=sync 配置) 或者異步(producer.type=async)模式。如果設置成異步,雖然會極大的提高消息發送的性能,但是這樣會增加丟失數據的風險。如果需要確保消息的可靠性,必須將 producer.type 設置為 sync。
Leader 選舉在介紹 Leader 選舉之前,讓我們先來了解一下 ISR(in-sync replicas)列表。每個分區的 leader 會維護一個 ISR 列表,ISR 列表裡面就是 follower 副本的 Borker 編號,只有跟得上 Leader 的 follower 副本才能加入到 ISR 裡面,這個是通過 replica.lag.time.max.ms 參數配置的,具體可以參見 《一文了解 Kafka 的副本複製機制》。只有 ISR 裡的成員才有被選為 leader 的可能。
所以當 Leader 掛掉了,而且 unclean.leader.election.enable=false 的情況下,Kafka 會從 ISR 列表中選擇第一個 follower 作為新的 Leader,因為這個分區擁有最新的已經 committed 的消息。通過這個可以保證已經 committed 的消息的數據可靠性。
綜上所述,為了保證數據的可靠性,我們最少需要配置一下幾個參數:
producer 級別:acks=all(或者 request.required.acks=-1),同時發生模式為同步 producer.type=sync
topic 級別:設置 replication.factor>=3,並且 min.insync.replicas>=2;
broker 級別:關閉不完全的 Leader 選舉,即 unclean.leader.election.enable=false;
29.請談一談 Kafka 數據一致性原理一致性就是說不論是老的 Leader 還是新選舉的 Leader,Consumer 都能讀到一樣的數據。
假設分區的副本為3,其中副本0是 Leader,副本1和副本2是 follower,並且在 ISR 列表裡面。雖然副本0已經寫入了 Message4,但是 Consumer 只能讀取到 Message2。因為所有的 ISR 都同步了 Message2,只有 High Water Mark 以上的消息才支持 Consumer 讀取,而 High Water Mark 取決於 ISR 列表裡面偏移量最小的分區,對應於上圖的副本2,這個很類似於木桶原理。
這樣做的原因是還沒有被足夠多副本複製的消息被認為是「不安全」的,如果 Leader 發生崩潰,另一個副本成為新 Leader,那麼這些消息很可能丟失了。如果我們允許消費者讀取這些消息,可能就會破壞一致性。試想,一個消費者從當前 Leader(副本0) 讀取並處理了 Message4,這個時候 Leader 掛掉了,選舉了副本1為新的 Leader,這時候另一個消費者再去從新的 Leader 讀取消息,發現這個消息其實並不存在,這就導致了數據不一致性問題。
當然,引入了 High Water Mark 機制,會導致 Broker 間的消息複製因為某些原因變慢,那麼消息到達消費者的時間也會隨之變長(因為我們會先等待消息複製完畢)。延遲時間可以通過參數 replica.lag.time.max.ms 參數配置,它指定了副本在複製消息時可被允許的最大延遲時間。
30.ISR、OSR、AR 是什麼?ISR:In-Sync Replicas 副本同步隊列
OSR:Out-of-Sync Replicas
AR:Assigned Replicas 所有副本
ISR是由leader維護,follower從leader同步數據有一些延遲(具體可以參見 圖文了解 Kafka 的副本複製機制),超過相應的閾值會把 follower 剔除出 ISR, 存入OSR(Out-of-Sync Replicas )列表,新加入的follower也會先存放在OSR中。AR=ISR+OSR。
31.LEO、HW、LSO、LW等分別代表什麼LEO:是 LogEndOffset 的簡稱,代表當前日誌文件中下一條
HW:水位或水印(watermark)一詞,也可稱為高水位(high watermark),通常被用在流式處理領域(比如Apache Flink、Apache Spark等),以表徵元素或事件在基於時間層面上的進度。在Kafka中,水位的概念反而與時間無關,而是與位置信息相關。嚴格來說,它表示的就是位置信息,即位移(offset)。取 partition 對應的 ISR中 最小的 LEO 作為 HW,consumer 最多只能消費到 HW 所在的位置上一條信息。
LSO:是 LastStableOffset 的簡稱,對未完成的事務而言,LSO 的值等於事務中第一條消息的位置(firstUnstableOffset),對已完成的事務而言,它的值同 HW 相同
LW:Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值。
32.Kafka 在什麼情況下會出現消息丟失?參考數據可靠性和數據一致性
33.怎麼儘可能保證 Kafka 的可靠性參考數據可靠性和數據一致性
34.消費者和消費者組有什麼關係?每個消費者從屬於消費組。具體關係如下:
35.Kafka 的每個分區只能被一個消費者線程,如何做到多個線程同時消費一個分區?36.數據傳輸的事務有幾種?
數據傳輸的事務定義通常有以下三種級別:
最多一次: 消息不會被重複發送,最多被傳輸一次,但也有可能一次不傳輸
最少一次: 消息不會被漏發送,最少被傳輸一次,但也有可能被重複傳輸.
精確的一次(Exactly once): 不會漏傳輸也不會重複傳輸,每個消息都傳輸被
37.Kafka 消費者是否可以消費指定分區消息?Kafa consumer消費消息時,向broker發出fetch請求去消費特定分區的消息,consumer指定消息在日誌中的偏移量(offset),就可以消費從這個位置開始的消息,customer擁有了offset的控制權,可以向後回滾去重新消費之前的消息,這是很有意義的
38.Kafka消息是採用Pull模式,還是Push模式?Kafka最初考慮的問題是,customer應該從brokes拉取消息還是brokers將消息推送到consumer,也就是pull還push。在這方面,Kafka遵循了一種大部分消息系統共同的傳統的設計:producer將消息推送到broker,consumer從broker拉取消息。
一些消息系統比如Scribe和Apache Flume採用了push模式,將消息推送到下遊的consumer。這樣做有好處也有壞處:由broker決定消息推送的速率,對於不同消費速率的consumer就不太好處理了。消息系統都致力於讓consumer以最大的速率最快速的消費消息,但不幸的是,push模式下,當broker推送的速率遠大於consumer消費的速率時,consumer恐怕就要崩潰了。最終Kafka還是選取了傳統的pull模式。Pull模式的另外一個好處是consumer可以自主決定是否批量的從broker拉取數據。Push模式必須在不知道下遊consumer消費能力和消費策略的情況下決定是立即推送每條消息還是緩存之後批量推送。如果為了避免consumer崩潰而採用較低的推送速率,將可能導致一次只推送較少的消息而造成浪費。Pull模式下,consumer就可以根據自己的消費能力去決定這些策略。Pull有個缺點是,如果broker沒有可供消費的消息,將導致consumer不斷在循環中輪詢,直到新消息到t達。為了避免這點,Kafka有個參數可以讓consumer阻塞知道新消息到達(當然也可以阻塞知道消息的數量達到某個特定的量這樣就可以批量發
39.Kafka 消息格式的演變清楚嗎?Kafka 的消息格式經過了四次大變化,
0.8.x版本的消息格式如下:
這個版本的 Message 格式加入了 Key 相關的信息,以及 內容的長度等,各個欄位的含義介紹如下:
crc:佔用4個字節,主要用於校驗消息的內容;
magic:這個佔用1個字節,主要用於標識 Kafka 版本。
attributes:佔用1個字節,這裡面存儲了消息壓縮使用的編碼。這個版本的 Kafka 僅支持 gzip、snappy 以及 lz4(0.8.2引入) 三種壓縮格式;後四位如果是0001則標識gzip壓縮,如果是0010則是snappy壓縮,如果是0011則是snappy壓縮,如果是0000則表示沒有使用壓縮。
key length:佔用4個字節。主要標識 Key 的內容的長度 K;
key:佔用 K 個字節。存儲的是 key 的具體內容
value length:佔用4個字節。主要標識 value 的內容的長度 V;
value:這個佔用的字節為 V。value即是消息的真實內容,在 Kafka 中這個也叫做payload。
這個版本的MessageSet 格式和之前一樣,就不介紹了。但是需要注意的是,這個版本 MessageSet 中的 offset 欄位存儲的已經不是消息物理偏移量了,而是邏輯地址,比如0,、1、2....。有了邏輯地址,我們就可以解決之前Kafka 0.7.0遇到的一些問題,比如可以在壓縮消息內通過偏移量進行尋址,壓縮消息可以checkpoint內部的消息等。
0.10.x版本的消息格式如下:
可以看出,這個版本相對於 Kafka 0.8.x版本的消息格式變化不大,各個欄位的含義:這個版本的 Message 格式加入了 Key 相關的信息,以及 內容的長度等,各個欄位的含義介紹如下:
crc:佔用4個字節,主要用於校驗消息的內容;
magic:這個佔用1個字節,主要用於標識 Kafka 版本。Kafka 0.10.x magic默認值為1
attributes:佔用1個字節,這裡面存儲了消息壓縮使用的編碼以及Timestamp類型。這個版本的 Kafka 僅支持 gzip、snappy 以及 lz4(0.8.2引入) 三種壓縮格式;後四位如果是 0001 則表示 gzip 壓縮,如果是 0010 則是 snappy 壓縮,如果是 0011 則是 lz4 壓縮,如果是0000則表示沒有使用壓縮。第4個bit位如果為0,代表使用create time;如果為1代表append time;其餘位(第5~8位)保留;
key length:佔用4個字節。主要標識 Key 的內容的長度 K;
key:佔用 K 個字節。存儲的是 key 的具體內容
value length:佔用4個字節。主要標識 value 的內容的長度 V;
value:這個佔用的字節為 V。value即是消息的真實內容,在 Kafka 中這個也叫做payload。
40.Kafka 偏移量的演變清楚嗎?參見官方文檔,此問題很少問
41.Kafka 高效文件存儲設計特點Kafka把topic中一個parition大文件分成多個小文件段,通過多個小文件段,就容易定期清除或刪除已經消費完文件,減少磁碟佔用。
通過索引信息可以快速定位message和確定response的最大大小。
通過index元數據全部映射到memory,可以避免segment file的IO磁碟操作。
通過索引文件稀疏存儲,可以大幅降低index文件元數據佔用空間大小
42.Kafka創建Topic時如何將分區放置到不同的Broker中副本因子不能大於 Broker 的個數;
第一個分區(編號為0)的第一個副本放置位置是隨機從 brokerList 選擇的;
其他分區的第一個副本放置位置相對於第0個分區依次往後移。也就是如果我們有5個 Broker,5個分區,假設第一個分區放在第四個 Broker 上,那麼第二個分區將會放在第五個 Broker 上;第三個分區將會放在第一個 Broker 上;第四個分區將會放在第二個 Broker 上,依次類推;
剩餘的副本相對於第一個副本放置位置其實是由 nextReplicaShift 決定的,而這個數也是隨機產生的;
具體可以參見Kafka創建Topic時如何將分區放置到不同的Broker中。
43.Kafka新建的分區會在哪個目錄下創建我們知道,在啟動 Kafka 集群之前,我們需要配置好 log.dirs 參數,其值是 Kafka 數據的存放目錄,這個參數可以配置多個目錄,目錄之間使用逗號分隔,通常這些目錄是分布在不同的磁碟上用於提高讀寫性能。當然我們也可以配置 log.dir 參數,含義一樣。只需要設置其中一個即可。
如果 log.dirs 參數只配置了一個目錄,那麼分配到各個 Broker 上的分區肯定只能在這個目錄下創建文件夾用於存放數據。
但是如果 log.dirs 參數配置了多個目錄,那麼 Kafka 會在哪個文件夾中創建分區目錄呢?答案是:Kafka 會在含有分區目錄最少的文件夾中創建新的分區目錄,分區目錄名為 Topic名+分區ID。注意,是分區文件夾總數最少的目錄,而不是磁碟使用量最少的目錄!也就是說,如果你給 log.dirs 參數新增了一個新的磁碟,新的分區目錄肯定是先在這個新的磁碟上創建直到這個新的磁碟目錄擁有的分區目錄不是最少為止。
44.談一談 Kafka 的再均衡在Kafka中,當有新消費者加入或者訂閱的topic數發生變化時,會觸發Rebalance(再均衡:在同一個消費者組當中,分區的所有權從一個消費者轉移到另外一個消費者)機制,Rebalance顧名思義就是重新均衡消費者消費。Rebalance的過程如下:
第一步:所有成員都向coordinator發送請求,請求入組。一旦所有成員都發送了請求,coordinator會從中選擇一個consumer擔任leader的角色,並把組成員信息以及訂閱信息發給leader。第二步:leader開始分配消費方案,指明具體哪個consumer負責消費哪些topic的哪些partition。一旦完成分配,leader會將這個方案發給coordinator。coordinator接收到分配方案之後會把方案發給各個consumer,這樣組內的所有成員就都知道自己應該消費哪些分區了。所以對於Rebalance來說,Coordinator起著至關重要的作用
45.談談 Kafka 分區分配策略每個 Topic 一般會有很多個 partitions。為了使得我們能夠及時消費消息,我們也可能會啟動多個 Consumer 去消費,而每個 Consumer 又會啟動一個或多個streams去分別消費 Topic 對應分區中的數據。我們又知道,Kafka 存在 Consumer Group 的概念,也就是 group.id 一樣的 Consumer,這些 Consumer 屬於同一個Consumer Group,組內的所有消費者協調在一起來消費訂閱主題(subscribed topics)的所有分區(partition)。當然,每個分區只能由同一個消費組內的一個consumer來消費。那麼問題來了,同一個 Consumer Group 裡面的 Consumer 是如何知道該消費哪些分區裡面的數據呢?
如上圖,Consumer1 為啥消費的是 Partition0 和 Partition2,而不是 Partition0 和 Partition3?這就涉及到 Kafka內部分區分配策略(Partition Assignment Strategy)了。
在 Kafka 內部存在兩種默認的分區分配策略:Range 和 RoundRobin。當以下事件發生時,Kafka 將會進行一次分區分配:
將分區的所有權從一個消費者移到另一個消費者稱為重新平衡(rebalance),如何rebalance就涉及到本文提到的分區分配策略。下面我們將詳細介紹 Kafka 內置的兩種分區分配策略。本文假設我們有個名為 T1 的主題,其包含了10個分區,然後我們有兩個消費者(C1,C2)來消費這10個分區裡面的數據,而且 C1 的 num.streams = 1,C2 的 num.streams = 2。
Range strategyRange策略是對每個主題而言的,首先對同一個主題裡面的分區按照序號進行排序,並對消費者按照字母順序進行排序。在我們的例子裡面,排完序的分區將會是0, 1, 2, 3, 4, 5, 6, 7, 8, 9;消費者線程排完序將會是C1-0, C2-0, C2-1。然後將partitions的個數除於消費者線程的總數來決定每個消費者線程消費幾個分區。如果除不盡,那麼前面幾個消費者線程將會多消費一個分區。在我們的例子裡面,我們有10個分區,3個消費者線程, 10 / 3 = 3,而且除不盡,那麼消費者線程 C1-0 將會多消費一個分區,所以最後分區分配的結果看起來是這樣的:
C1-0 將消費 0, 1, 2, 3 分區C2-0 將消費 4, 5, 6 分區C2-1 將消費 7, 8, 9 分區
假如我們有11個分區,那麼最後分區分配的結果看起來是這樣的:
C1-0 將消費 0, 1, 2, 3 分區C2-0 將消費 4, 5, 6, 7 分區C2-1 將消費 8, 9, 10 分區
假如我們有2個主題(T1和T2),分別有10個分區,那麼最後分區分配的結果看起來是這樣的:
C1-0 將消費 T1主題的 0, 1, 2, 3 分區以及 T2主題的 0, 1, 2, 3分區C2-0 將消費 T1主題的 4, 5, 6 分區以及 T2主題的 4, 5, 6分區C2-1 將消費 T1主題的 7, 8, 9 分區以及 T2主題的 7, 8, 9分區
可以看出,C1-0 消費者線程比其他消費者線程多消費了2個分區,這就是Range strategy的一個很明顯的弊端。
RoundRobin strategy使用RoundRobin策略有兩個前提條件必須滿足:
所以這裡假設前面提到的2個消費者的num.streams = 2。RoundRobin策略的工作原理:將所有主題的分區組成 TopicAndPartition 列表,然後對 TopicAndPartition 列表按照 hashCode 進行排序,這裡文字可能說不清,看下面的代碼應該會明白:
val allTopicPartitions = ctx.partitionsForTopic.flatMap { case(topic, partitions) =>
info("Consumer %s rebalancing the following partitions for topic %s: %s"
.format(ctx.consumerId, topic, partitions))
partitions.map(partition => {
TopicAndPartition(topic, partition)
})
}.toSeq.sortWith((topicPartition1, topicPartition2) => {
/*
* Randomize the order by taking the hashcode to reduce the likelihood of all partitions of a given topic ending
* up on one consumer (if it has a high enough stream count).
*/
topicPartition1.toString.hashCode < topicPartition2.toString.hashCode
})最後按照round-robin風格將分區分別分配給不同的消費者線程。
在我們的例子裡面,假如按照 hashCode 排序完的topic-partitions組依次為T1-5, T1-3, T1-0, T1-8, T1-2, T1-1, T1-4, T1-7, T1-6, T1-9,我們的消費者線程排序為C1-0, C1-1, C2-0, C2-1,最後分區分配的結果為:
C1-0 將消費 T1-5, T1-2, T1-6 分區;C1-1 將消費 T1-3, T1-1, T1-9 分區;C2-0 將消費 T1-0, T1-4 分區;C2-1 將消費 T1-8, T1-7 分區;
多個主題的分區分配和單個主題類似,這裡就不在介紹了。
根據上面的詳細介紹相信大家已經對Kafka的分區分配策略原理很清楚了。不過遺憾的是,目前我們還不能自定義分區分配策略,只能通過partition.assignment.strategy參數選擇 range 或 roundrobin。partition.assignment.strategy參數默認的值是range。
46.Kafka Producer 是如何動態感知主題分區數變化的?47.Kafka 是如何實現高吞吐率的?Kafka是分布式消息系統,需要處理海量的消息,Kafka的設計是把所有的消息都寫入速度低容量大的硬碟,以此來換取更強的存儲能力,但實際上,使用硬碟並沒有帶來過多的性能損失。kafka主要使用了以下幾個方式實現了超高的吞吐率:
48.Kafka 監控都有哪些?比較流行的監控工具有:
KafkaOffsetMonitor
KafkaManager
Kafka Web Console
Kafka Eagle
JMX協議(可以用諸如jdk自帶的jconsole來進行連接獲取狀態信息)
49.如何為Kafka集群選擇合適的Topics/Partitions數量
參見《如何為Kafka集群選擇合適的Topics/Partitions數量》
50.談談你對 Kafka 事務的了解?參見這篇文章:http://www.jasongj.com/kafka/transaction/
51.談談你對 Kafka 冪等的了解?參見這篇文章:https://www.jianshu.com/p/b1599f46229b
52.Kafka 缺點?由於是批量發送,數據並非真正的實時;
對於mqtt協議不支持;
不支持物聯網傳感數據直接接入;
僅支持統一分區內消息有序,無法實現全局消息有序;
監控不完善,需要安裝插件;
依賴zookeeper進行元數據管理;
53.Kafka 新舊消費者的區別舊的 Kafka 消費者 API 主要包括:SimpleConsumer(簡單消費者) 和 ZookeeperConsumerConnectir(高級消費者)。SimpleConsumer 名字看起來是簡單消費者,但是其實用起來很不簡單,可以使用它從特定的分區和偏移量開始讀取消息。高級消費者和現在新的消費者有點像,有消費者群組,有分區再均衡,不過它使用 ZK 來管理消費者群組,並不具備偏移量和再均衡的可操控性。
現在的消費者同時支持以上兩種行為,所以為啥還用舊消費者 API 呢?
54.Kafka 分區數可以增加或減少嗎?為什麼?我們可以使用 bin/kafka-topics.sh 命令對 Kafka 增加 Kafka 的分區數據,但是 Kafka 不支持減少分區數。Kafka 分區數據不支持減少是由很多原因的,比如減少的分區其數據放到哪裡去?是刪除,還是保留?刪除的話,那麼這些沒消費的消息不就丟了。如果保留這些消息如何放到其他分區裡面?追加到其他分區後面的話那麼就破壞了 Kafka 單個分區的有序性。如果要保證刪除分區數據插入到其他分區保證有序性,那麼實現起來邏輯就會非常複雜。
55.kafka消息的存儲機制
kafka通過 topic來分主題存放數據,主題內有分區,分區可以有多個副本,分區的內部還細分為若干個 segment。都是持久化到磁碟,採用零拷貝技術。
1、高效檢索
分區下面,會進行分段操作,每個分段都會有對應的素引,這樣就可以根據 offset二分查找定位到消息在哪一段,根據段的索引文件,定位具體的 mle ssage
2、分區副本可用性(1 eader選舉,zk來協調
如果1eader宕機,選出了新的1eader,而新的 leader並不能保證已經完全同步了之前1eader的所有數據,只能保證HW(高水位設置)之前的數據是同步過的,此時所有的 follower都要將數據截斷到W的位置,再和新的 leader同步數據,來保證數據一致。
當宕機的 leader恢復,發現新的1eader中的數據和自己持有的數據不一致,此時宕機的1 eader會將自己的數據截斷到宕機之前的hw位置,然後同步新1 eader的數據。宕機的1eader活過來也像 follower一樣同步數據,來保證數據的一致性。
56.相比較於傳統消息隊列,kafka的區別
1、分區性:存儲不會受單一伺服器存儲空間的限制
2、高可用性:副本1 eader選舉
3、消息有序性:一個分區內是有序的。
4、負載均衡性:分區內的一條消息,只會被消費組中的一個消費者消費,主題中的消息,會均衡的發送給消費者組中的所有消費者進行消費。
57.消息丟失和消息重複同步:這個生產者寫一條消息的時候,它就立馬發送到某個分區去。
異步:這個生產者寫一條消息的時候,先是寫到某個緩衝區,這個緩衝區裡的數據還沒寫到 broker集群裡的某個分區的時候,它就返回到 client去了
針對消息丟失:同步模式下,確認機制設置為-1,即讓消息寫入 Leader和 Fol lower之後再確認消息發送成功:
異步模式下,為防止緩衝區滿,可以在配置文件設置不限制阻塞超時時間,當緩衝區滿時讓生產者一直處於阻塞狀態
針對消息重複,將消息的唯一標識保存到外部介質中,每次消費時判斷是否處理過即可
五.Hbase1.Hbase調優HBase應該如何優化?
2.hbase的rowkey怎麼創建好?列族怎麼創建比較好?HBase-Rowkey設計
一個列族在數據底層是一個文件,所以將經常一起查詢的列放到一個列族中,列族儘量少,減少文件的尋址時間。
3.hbase過濾器實現用途簡單講講布隆過濾器及其在HBase中的應用
4.HBase宕機如何處理答:宕機分為HMaster宕機和HRegisoner宕機,如果是HRegisoner宕機,HMaster會將其所管理的region重新分布到其他活動的RegionServer上,由於數據和日誌都持久在HDFS中,該操作不會導致數據丟失。所以數據的一致性和安全性是有保障的。
如果是HMaster宕機,HMaster沒有單點問題,HBase中可以啟動多個HMaster,通過Zookeeper的Master Election機制保證總有一個Master運行。即ZooKeeper會保證總會有一個HMaster在對外提供服務。
5.hive跟hbase的區別是?Hive與HBase的區別及應用場景
6.hbase寫流程
1/ 客戶端要連接zookeeper, 從zk的/hbase節點找到hbase:meta表所在的regionserver(host:port);
2/ regionserver掃描hbase:meta中的每個region的起始行健,對比r000001這條數據在那個region的範圍內;
3/ 從對應的 info:server key中存儲了region是有哪個regionserver(host:port)在負責的;
4/ 客戶端直接請求對應的regionserver;
5/ regionserver接收到客戶端發來的請求之後,就會將數據寫入到region中
7.hbase讀流程
1/ 首先Client連接zookeeper, 找到hbase:meta表所在的regionserver;
2/ 請求對應的regionserver,掃描hbase:meta表,根據namespace、表名和rowkey在meta表中找到r00001所在的region是由那個regionserver負責的;
3/找到這個region對應的regionserver
4/ regionserver收到了請求之後,掃描對應的region返回數據到Client
(先從MemStore找數據,如果沒有,再到BlockCache裡面讀;BlockCache還沒有,再到StoreFile上讀(為了讀取的效率);
如果是從StoreFile裡面讀取的數據,不是直接返回給客戶端,而是先寫入BlockCache,再返回給客戶端。)
8.hbase數據flush過程1)當MemStore數據達到閾值(默認是128M,老版本是64M),將數據刷到硬碟,將內存中的數據刪除,同時刪除HLog中的歷史數據;
2)並將數據存儲到HDFS中;
3)在HLog中做標記點。
9.數據合併過程當數據塊達到4塊,hmaster將數據塊加載到本地,進行合併
當合併的數據超過256M,進行拆分,將拆分後的region分配給不同的hregionserver管理
當hregionser宕機後,將hregionserver上的hlog拆分,然後分配給不同的hregionserver加載,修改.META.
注意:hlog會同步到hdfs
10.Hmaster和Hgionserver職責Hmaster
1、管理用戶對Table的增、刪、改、查操作;
2、記錄region在哪臺Hregion server上
3、在Region Split後,負責新Region的分配;
4、新機器加入時,管理HRegion Server的負載均衡,調整Region分布
5、在HRegion Server宕機後,負責失效HRegion Server 上的Regions遷移。
Hgionserver
HRegion Server主要負責響應用戶I/O請求,向HDFS文件系統中讀寫數據,是HBASE中最核心的模塊。
HRegion Server管理了很多table的分區,也就是region。
11.HBase列族和region的關係?HBase有多個RegionServer,每個RegionServer裡有多個Region,一個Region中存放著若干行的行鍵以及所對應的數據,一個列族是一個文件夾,如果經常要搜索整個一條數據,列族越少越好,如果只有一部分的數據需要經常被搜索,那麼將經常搜索的建立一個列族,其他不常搜索的建立列族檢索較快。
12.請簡述Hbase的物理模型是什麼13.請問如果使用Hbase做即席查詢,如何設計二級索引HBase二級索引設計思想
14.如何避免讀、寫HBaes時訪問熱點問題?HBase-Rowkey設計
15.布隆過濾器在HBASE中的應用簡單講講布隆過濾器及其在HBase中的應用
16.Hbase是用來幹嘛的?什麼樣的數據會放到hbaseHive與HBase的區別及應用場景
17.Hbase在建表時的設計原則(注意事項)
HBase應該如何優化?
18.Hbase中的region server發生故障後的處理方法(zk-->WAL)Hbase檢測宕機是通過 Zookeeper實現的,正常情況下 Regionserver會周期性向 Zookeeper發送心跳,一旦發生宕機,心跳就會停止,超過一定時間( Sessi ontimeout) Zookeeper就會認為 Regionserver宕機離線,並將該消息通知給 Master0一臺 Regionserver只有一個Hog文件,然後,將og按照
Region進行分組,切分到每個 regionserver中,因此在回放之前首先需要將og按照 Region進行分組,每個 Region的日誌數據放在一起,方便後面按照 Region進行回放。這個分組的過程就稱為HLog切分。然後再對 region重新分配,並對其中的Hog進行回放將數據寫入 memstore刷寫到磁碟,完成最終數據恢復。
19.用phenix和es作為hbase二級索引的區別,最新的hbase已經支持二級索引了,你清楚嗎?
六.數倉1.維表和寬表的考查(主要考察維表的使用及維度退化手法)維表數據一般根據ods層數據加工生成,在設計寬表的時候,可以適當的用一些維度退化手法,將維度退化到事實表中,減少事實表和維表的關聯
2.數倉表命名規範OneData方法論在XX的實踐
3.拉鍊表的使用場景你真的了解全量表,增量表及拉鍊表嗎?
4.資料庫和數據倉庫有什麼區別
資料庫和數據倉庫
5.有什麼維表時間維表,用戶維表,醫院維表等
6.數據源都有哪些業務庫數據源:mysql,oracle,mongo
日誌數據:ng日誌,埋點日誌
爬蟲數據
7.你們最大的表是什麼表,數據量多少ng日誌表,三端(app,web,h5)中app端日誌量最大,清洗入庫後的數據一天大概xxxxW
8.數倉架構體系
9.數據平臺是怎樣的,用到了阿里的那一套嗎?沒用到阿里那一套,數據平臺為自研產品
10.你了解的調度系統有那些?,你們公司用的是哪種調度系統airflow,azkaban,ooize,我們公司使用的是airflow
11.你們公司數倉底層是怎麼抽數據的?業務數據用的是datax
日誌數據用的是logstash
12.為什麼datax抽數據要比sqoop 快?Sqoop or Datax
13.埋點數據你們是怎樣接入的logstash-->kafka-->logstash-->hdfs
14.如果你們業務庫的表有更新,你們數倉怎麼處理的?你真的了解全量表,增量表及拉鍊表嗎?
15.能獨立搭建數倉嗎可以
16.搭建過CDH 集群嗎搭建過
17.說一下你們公司的大數據平臺架構?你有參與嗎?
18.介紹一下你自己的項目和所用的技術
19.對目前的流和批處理的認識?就是談談自己的感受目前流處理和批處理共存,主要是看業務需求,批處理相對於流處理來說更穩定一點,但是未來肯定是流批一體的狀態
20.你了解那些OLAP 引擎,MPP 知道一些嗎?clickHouse 了解一些嗎?你自己做過測試性能嗎?OLAP引擎—Kylin介紹
clickhouse概念篇
clickhouse實踐篇-數據類型
clickhouse實踐篇-表引擎
clickhouse實踐篇-SQL語法
21.Kylin 有了解嗎?介紹一下原理OLAP引擎—Kylin介紹
22.datax 源碼有改造過嗎Datax-數據抽取同步利器
23.你們數倉的APP 層是怎麼對外提供服務的?1.直接存入mysql業務庫,業務方直接讀取
2.數據存入mysql,以接口的形式提供數據
3.數據存入kylin,需求方通過jdbc讀取數據
24.數據接入進來,你們是怎樣規劃的,有考慮數據的膨脹問題嗎會根據表數據量及後續業務的發展來選擇數據抽取方案,會考慮數據膨脹問題,所以一般選用增量抽取的方式
25.簡述拉鍊表,流水錶以及快照表的含義和特點你真的了解全量表,增量表及拉鍊表嗎?
26.全量表(df),增量表(di),追加表(da),拉鍊表(dz)的區別及使用場景你真的了解全量表,增量表及拉鍊表嗎?
27.你們公司的數倉分層,每一層是怎麼處理數據的數據倉庫分層架構
28.什麼是事實表,什麼是維表數據倉庫中的維表和事實表
29.星型模型和雪花模型全方位解讀星型模型,雪花模型及星座模型
30.緩慢變化維如何處理,幾種方式緩慢變化維(SCD)常見解決方案
31.datax與sqoop的優缺點Sqoop or Datax
32.datax抽數碰到emoji表情怎麼解決我記得datax抽取碰到表情是能正常抽過來並展示的,在同步到Mysql的時候需要修改編碼
33.工作中碰到什麼困難,怎麼解決的從0-1建設數倉遇到什麼問題?怎麼解決的?
34.如何用數據給公司帶來收益
35.需求驅動和業務驅動,數據開發和ETL開發,實戰型和博客型需求驅動還是業務驅動
36.如何用數據實現業務增長?
37.什麼是大數據?千萬級別的數據完全可以用傳統的關係型資料庫集群解決,為什麼要用到大數據平臺。大數據(big data),IT行業術語,是指無法在一定時間範圍內用常規軟體工具進行捕捉、管理和處理的數據集合,是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。
傳統關係型資料庫很難做數據治理,而且需要考慮到業務發展帶來數據的海量增長,所以需要搭建大數據平臺來支撐。
38.數據質量,元數據管理,指標體系建設,數據驅動數據質量那點事
簡述元數據管理
39.什麼是數倉,建設數倉時碰到過什麼問題從0-1建設數倉遇到什麼問題?怎麼解決的?
40.實時數倉技術選型及保證exactly-once41.維度建模和範式建模的區別;
42.埋點的碼錶如何設計;
43.集市層和公共層的區別;
公共層與數據集市層的區別
44.緩慢變化維的處理方式
緩慢變化維(SCD)常見解決方案
45.聊聊數據質量
數據質量那點事
46.說說你從0-1搭建數倉都做了什麼?你覺得最有挑戰的是什麼?
從0-1建設數倉遇到什麼問題?怎麼解決的?
47.數據模型如何構建,星型、雪花、星座的區別和工作中如何使用;
全方位解讀星型模型,雪花模型及星座模型
48.如何優化整個數倉的執行時長,比如7點所有任務跑完,如何優化到5點;
如何優化整個數倉的執行時長(比如7點所有任務跑完,如何優化到5點)
49.數據傾斜,遇到哪些傾斜,怎麼發現的?怎麼處理的?;
Hive調優,數據工程師成神之路
50.如何保證數據質量;
數據質量那點事
51.如何保證指標一致性;
52.了解onedata嗎,說說你的理解;
OneData方法論在XX的實踐
53.數據漂移如何解決;
54.實時場景如何解決的;
55.拉鍊表如何設計,拉鍊表出現數據回滾的需求怎麼解決。
你真的了解全量表,增量表及拉鍊表嗎?
56.平臺選型依據
根據業務及需求
57.數倉分層、模型、每層都是做什麼的?為什麼這麼做?
數據倉庫分層架構
58.交叉維度的解決方案?
多值維度及交叉維度最佳解決方案
59.數據質量如何保證(DQC)?
數據質量那點事
60.任務延遲如何優化(SLA)?
如何優化整個數倉的執行時長(比如7點所有任務跑完,如何優化到5點)
Hive調優,數據工程師成神之路
61.聊一下數據資產。
OneData方法論在XX的實踐
62.如果讓你設計實時數倉你會如何設計,為什麼?
63.指標如何定義?
64.sql問題:連續活躍n天用戶的獲取;
大廠高頻面試題-連續登錄問題
65.數據傾斜的sql如何優化;數據量大的sql如何優化?
Hive調優,數據工程師成神之路
66.數據倉庫主題的劃分,參考Teradata的LDM模型;
67.Kimball和Inmon的相同和不同;
Kimball架構和Inmon架構
68.數據質量管理、數據治理有什麼好的方案?知識庫管理有什麼好的思路?血緣關係圖。
簡述元數據管理
數據質量那點事
江湖傳言:數據玩的溜,牢飯吃的久?
69.元數據管理相關問題,集群存儲不夠了,需要清理不需要的任務和數據該怎麼做?
簡述元數據管理
70.業務庫2億數據入倉的策略
全量初始化,之後每次增量;
71.什麼場景會出現數據傾斜,怎麼解決?比如select user_id,count(1) from table group by user_id,其中某些user_id的訪問量很大,查詢不出結果該怎麼辦?
Hive調優,數據工程師成神之路
72.sql裡面on和where有區別嗎?
left join(on&where)
73.聊一下技術架構,整個項目每個環節用的什麼技術這個樣子;
74.hive、hbase、spark。。。。這些大數據組件,熟悉哪個或者哪些?我說hive和hbase,對方就問hive和hbase的原理,差異等問題;
75.有沒有實時數倉的經驗,數據實時入倉思路,canal;
76.你對當前的項目組有沒有什麼自己的看法、意見或者需要改進的地方,這個改進對你有沒有什麼影響
根據個人實際情況回答即可
77.ods的增量能否做成通用的?
78.公共層和數據集市層的區別和特點?
公共層與數據集市層的區別
79.從原理上說一下mpp和mr的區別
80.對了中間還有問數倉數據的輸出主要是哪些還有數倉的分層;
數據倉庫分層架構
81.報表如何展示
自研報表系統
powerBI
tableau
82.數據源,怎麼同步,同步時對業務庫的性能影響,同步後怎麼處理,使用方式誰,怎麼使用
83.你們數倉怎麼分層的以及各層主要做了什麼
84.你們主題是怎麼劃分的,舉個例子
85.如何判斷一個模型的好壞
86.你們需求的開發流程是什麼樣的
七.Flink
1.Flink實時計算時落磁碟嗎不落,是內存計算
2.日活DAU的統計需要注意什麼
3.Flink調優
4.Flink的容錯是怎麼做的定期checkpoint存儲oprator state及keyedstate到stateBackend
5.Parquet格式的好處?什麼時候讀的快什麼時候讀的慢
6.flink中checkPoint為什麼狀態有保存在內存中這樣的機制?為什麼要開啟checkPoint?開啟checkpoint可以容錯,程序自動重啟的時候可以從checkpoint中恢復數據
7.flink保證Exactly_Once的原理?1.開啟checkpoint
2.source支持數據重發
3.sink支持事務,可以分2次提交,如kafka;或者sink支持冪等,可以覆蓋之前寫入的數據,如redis
滿足以上三點,可以保證Exactly_Once
8.flink的時間形式和窗口形式有幾種?有什麼區別,你們用在什麼場景下的?
9.flink的背壓說下?
10.flink的watermark機制說下,以及怎麼解決數據亂序的問題?
11.flink on yarn執行流程
Flink任務提交後,Client向HDFS上傳Flink的Jar包和配置,之後向Yarn ResourceManager提交任務,ResourceManager分配Container資源並通知對應的NodeManager啟動ApplicationMaster,ApplicationMaster啟動後加載Flink的Jar包和配置構建環境,然後啟動JobManager,之後ApplicationMaster向ResourceManager申請資源啟動TaskManager,ResourceManager分配Container資源後,由ApplicationMaster通知資源所在節點的NodeManager啟動TaskManager,NodeManager加載Flink的Jar包和配置構建環境並啟動TaskManager,TaskManager啟動後向JobManager發送心跳包,並等待JobManager向其分配任務。
12.說一說spark 和flink 的區別13.flink雙流join
14.flink任務提交方式
15.slot資源分配規劃
16.flink消費kafka發生partition數變更,flink底層是不是reblance
17.checkpoint原理
18.checkpoint barrier對齊原理,非對齊checkpoint原理
19.checkpoint失敗的場景
20.flink兩段提交原理
21.flink背壓的底層原理
22.onTimer同state並發操作的安全問題
23.flink kafkaConsumer源碼
24.看過哪些flink源碼
八.Java1.hashMap底層源碼,數據結構2.寫出你用過的設計模式,並舉例說明解決的實際問題3.Java創建線程的幾種方式繼承Thread類,重寫run方法
實現Runnable接口,實現run方法
通過線程池獲取線程
實現Callable接口並實現call方法,創建該類的實例,使用FutureTask類包裝Callable對象,使用FutureTask對象作為Thread對象的target創建並啟用新線程
4.請簡述作業系統的線程和進程的區別5.Java程序出現OutOfMemoryError:unable to create new native thread 的原因可能有哪些?如何分析和解決?6.採用java或自己熟悉的任何語言分別實現簡單版本的線性表和鍊表,只需實現add,remove方法即可7.ArrayList和LinkedList的區別8.JVM 內存分哪幾個區,每個區的作用是什麼?9.Java中迭代器和集合的區別?
集合是將所有數據加載到內存,然後通過集合的方法去內存中獲取,而迭代器是一個對象,實現了Iterator接口,實現了接口的hasNext和Next方法。
10.HashMap 和 HashTable 區別1) 線程安全性不同
HashMap 是線程不安全的,HashTable 是線程安全的,其中的方法是 Synchronize 的,
在多線程並發的情況下,可以直接使用 HashTabl,但是使用 HashMap 時必須自己增加同步
處理。
2) 是否提供 contains 方法
HashMap 只有 containsValue 和 containsKey 方法;HashTable 有 contains、containsKey
和 containsValue 三個方法,其中 contains 和 containsValue 方法功能相同。
3) key 和 value 是否允許 null 值
Hashtable 中,key 和 value 都不允許出現 null 值。HashMap 中,null 可以作為鍵,這
樣的鍵只有一個;可以有一個或多個鍵所對應的值為 null。
4) 數組初始化和擴容機制
HashTable 在不指定容量的情況下的默認容量為 11,而 HashMap 為 16,Hashtable 不
要求底層數組的容量一定要為 2 的整數次冪,而 HashMap 則要求一定為 2 的整數次冪。
Hashtable 擴容時,將容量變為原來的 2 倍加 1,而 HashMap 擴容時,將容量變為原
來的 2 倍。
11.線程池使用注意哪些方面?線程池分為單線程線程池,固定大小線程池,可緩衝的線程池
12.HashMap和TreeMap的區別?TreeMap排序規則?TreeMap會自動進行排序,根據key的Compare方法進行排序
13.用java實現單例模式
14.使用遞歸算法求n的階乘:n! ,語言不限
15.HashMap和Hashtable的區別是什麼
16.TreeSet 和 HashSet 區別HashSet 是採用 hash 表來實現的。其中的元素沒有按順序排列,add()、remove()以及
contains()等方法都是複雜度為 O(1)的方法。
TreeSet 是採用樹結構實現(紅黑樹算法)。元素是按順序進行排列,但是 add()、
remove()以及 contains()等方法都是複雜度為 O(log (n))的方法。它還提供了一些方法來處理
排序的 set,如 first(),last(),headSet(),tailSet()等等。
17.Stringbuffer 和 Stringbuild 區別1、StringBuffer 與 StringBuilder 中的方法和功能完全是等價的。
2、只是 StringBuffer 中的方法大都採用了 synchronized 關鍵字進行修飾,因此是線程
安全的,而 StringBuilder 沒有這個修飾,可以被認為是線程不安全的。
3、在單線程程序下,StringBuilder 效率更快,因為它不需要加鎖,不具備多線程安全
而 StringBuffer 則每次都需要判斷鎖,效率相對更低
18.Final、Finally、Finalizefinal:修飾符(關鍵字)有三種用法:修飾類、變量和方法。修飾類時,意味著它不
能再派生出新的子類,即不能被繼承,因此它和 abstract 是反義詞。修飾變量時,該變量
使用中不被改變,必須在聲明時給定初值,在引用中只能讀取不可修改,即為常量。修飾
方法時,也同樣只能使用,不能在子類中被重寫。
finally:通常放在 try…catch 的後面構造最終執行代碼塊,這就意味著程序無論正常執
行還是發生異常,這裡的代碼只要 JVM 不關閉都能執行,可以將釋放外部資源的代碼寫在
finally 塊中。
finalize:Object 類中定義的方法,Java 中允許使用 finalize() 方法在垃圾收集器將對象
從內存中清除出去之前做必要的清理工作。這個方法是由垃圾收集器在銷毀對象時調用
的,通過重寫 finalize() 方法可以整理系統資源或者執行其他清理工作。
19..==和 Equals 區別== : 如果比較的是基本數據類型,那麼比較的是變量的值
如果比較的是引用數據類型,那麼比較的是地址值(兩個對象是否指向同一塊內
存)
equals:如果沒重寫 equals 方法比較的是兩個對象的地址值。
如果重寫了 equals 方法後我們往往比較的是對象中的屬性的內容
equals 方法是從 Object 類中繼承的,默認的實現就是使用==
20.比較ArrayList,LinkedList的存儲特性和讀寫性能
21.Java 類加載過程Java類加載需要經歷一下幾個過程:
加載時類加載的第一個過程,在這個階段,將完成一下三件事情:
通過一個類的全限定名獲取該類的二進位流。
將該二進位流中的靜態存儲結構轉化為方法去運行時數據結構。
在內存中生成該類的Class對象,作為該類的數據訪問入口。
驗證的目的是為了確保Class文件的字節流中的信息不回危害到虛擬機.在該階段主要完成以下四鍾驗證:
文件格式驗證:驗證字節流是否符合Class文件的規範,如主次版本號是否在當前虛擬機範圍內,常量池中的常量是否有不被支持的類型.
元數據驗證:對字節碼描述的信息進行語義分析,如這個類是否有父類,是否集成了不被繼承的類等。
字節碼驗證:是整個驗證過程中最複雜的一個階段,通過驗證數據流和控制流的分析,確定程序語義是否正確,主要針對方法體的驗證。如:方法中的類型轉換是否正確,跳轉指令是否正確等。
符號引用驗證:這個動作在後面的解析過程中發生,主要是為了確保解析動作能正確執行。
準備
準備階段是為類的靜態變量分配內存並將其初始化為默認值,這些內存都將在方法區中進行分配。準備階段不分配類中的實例變量的內存,實例變量將會在對象實例化時隨著對象一起分配在Java堆中。
該階段主要完成符號引用到直接引用的轉換動作。解析動作並不一定在初始化動作完成之前,也有可能在初始化之後。
初始化時類加載的最後一步,前面的類加載過程,除了在加載階段用戶應用程式可以通過自定義類加載器參與之外,其餘動作完全由虛擬機主導和控制。到了初始化階段,才真正開始執行類中定義的Java程序代碼。
22.java中垃圾收集的方法有哪些?23.如何判斷一個對象是否存活?(或者GC對象的判定方法)
判斷一個對象是否存活有兩種方法:
引用計數法
可達性算法(引用鏈法)
24.jvm、堆棧
25.java基本數據類型
26.spring AOP應用場景
27.分布式鎖的幾種實現方式
28.兩個數 a=3,b=5,如何不使用中間變量不使用函數情況下調換他們
九.Elasticsearch1.為什麼要用es?存進es的數據是什麼格式的,怎麼查詢
十.Flume1.什麼是flumea.Flume是一個分布式、可靠、和高可用的海量日誌採集、聚合和傳輸的系統。
b.Flume可以採集文件,socket數據包等各種形式源數據,又可以將採集到的數據輸出到HDFS、hbase、hive、kafka等眾多外部存儲系統中
c.一般的採集需求,通過對flume的簡單配置即可實現
d.ume針對特殊場景也具備良好的自定義擴展能力,因此,flume可以適用於大部分的日常數據採集場景
2.flume運行機制Flume分布式系統中最核心的角色是agent,flume採集系統就是由一個個agent所連接起來形成
每一個agent相當於一個數據傳遞員,內部有三個組件:
Source:採集源,用於跟數據源對接,以獲取數據
Sink:下沉地,採集數據的傳送目的,用於往下一級agent傳遞數據或者往最終存儲系統傳遞數據
Channel:angent內部的數據傳輸通道,用於從source將數據傳遞到sink
3.Flume採集數據到Kafka中丟數據怎麼辦
4.Flume怎麼進行監控?
5.Flume的三層架構,collector、agent、storage十一.Sqoop1.Sqoop底層運行的任務是什麼只有Map階段,沒有Reduce階段的任務。
2.sqoop的遷移數據的原理
3.Sqoop參數/opt/module/sqoop/bin/sqoop import \
--connect \
--username \
--password \
--target-dir \
--delete-target-dir \
--num-mappers \
--fields-terminated-by \
--query "$2" ' and $CONDITIONS;'
4.Sqoop導入導出Null存儲一致性問題Hive中的Null在底層是以「\N」來存儲,而MySQL中的Null在底層就是Null,為了保證數據兩端的一致性。在導出數據時採用--input-null-string和--input-null-non-string兩個參數。導入數據時採用--null-string和--null-non-string。
5.Sqoop數據導出一致性問題1)場景1:如Sqoop在導出到Mysql時,使用4個Map任務,過程中有2個任務失敗,那此時MySQL中存儲了另外兩個Map任務導入的數據,此時老闆正好看到了這個報表數據。而開發工程師發現任務失敗後,會調試問題並最終將全部數據正確的導入MySQL,那後面老闆再次看報表數據,發現本次看到的數據與之前的不一致,這在生產環境是不允許的。
2)場景2:設置map數量為1個(不推薦,面試官想要的答案不只這個)
多個Map任務時,採用–staging-table方式,仍然可以解決數據一致性問題。
6.通過sqoop把數據加載到mysql中,如何設置主鍵?
十二.Redis1.緩存穿透、緩存雪崩、緩存擊穿1)緩存穿透是指查詢一個一定不存在的數據。由於緩存命不中時會去查詢資料庫,查不到
數據則不寫入緩存,這將導致這個不存在的數據每次請求都要到資料庫去查詢,造成緩存穿
透。
解決方案:
① 是將空對象也緩存起來,並給它設置一個很短的過期時間,最長不超過 5 分鐘
② 採用布隆過濾器,將所有可能存在的數據哈希到一個足夠大的 bitmap 中,一個一定
不存在的數據會被這個 bitmap 攔截掉,從而避免了對底層存儲系統的查詢壓力
2)如果緩存集中在一段時間內失效,發生大量的緩存穿透,所有的查詢都落在資料庫上,
就會造成緩存雪崩。
解決方案:
儘量讓失效的時間點不分布在同一個時間點
3)緩存擊穿,是指一個 key 非常熱點,在不停的扛著大並發,當這個 key 在失效的瞬間,
持續的大並發就穿破緩存,直接請求資料庫,就像在一個屏障上鑿開了一個洞。
可以設置 key 永不過期
2.數據類型
3.持久化1)RDB 持久化:
① 在指定的時間間隔內持久化
② 服務 shutdown 會自動持久化
③ 輸入 bgsave 也會持久化
2)AOF : 以日誌形式記錄每個更新操作
Redis 重新啟動時讀取這個文件,重新執行新建、修改數據的命令恢復數據。
保存策略:
推薦(並且也是默認)的措施為每秒持久化一次,這種策略可以兼顧速度和安全性。
缺點:
1 比起 RDB 佔用更多的磁碟空間
2 恢復備份速度要慢
3 每次讀寫都同步的話,有一定的性能壓力
4 存在個別 Bug,造成恢復不能
選擇策略:
官方推薦:
string
字符串
list
可以重複的集合
set
不可以重複的集合
hash
類似於 Map<String,String>
zset(sorted set)
帶分數的 set
如果對數據不敏感,可以選單獨用 RDB;不建議單獨用 AOF,因為可能出現 Bug;如果只是做純內存緩存,可以都不用
4.悲觀鎖和樂觀鎖悲觀鎖:執行操作前假設當前的操作肯定(或有很大機率)會被打斷(悲觀)。基於這個假設,我們在做操作前就會把相關資源鎖定,不允許自己執行期間有其他操作幹擾。
樂觀鎖:執行操作前假設當前操作不會被打斷(樂觀)。基於這個假設,我們在做操作前不會鎖定資源,萬一發生了其他操作的幹擾,那麼本次操作將被放棄。Redis 使用的就是樂觀鎖。
5.redis 是單線程的,為什麼那麼快1)完全基於內存,絕大部分請求是純粹的內存操作,非常快速。
2)數據結構簡單,對數據操作也簡單,Redis 中的數據結構是專門進行設計的
3)採用單線程,避免了不必要的上下文切換和競爭條件,也不存在多進程或者多線程導致的切換而消耗 CPU,不用去考慮各種鎖的問題,不存在加鎖釋放鎖操作,沒有因為可能出現死鎖而導致的性能消耗
4)使用多路 I/O 復用模型,非阻塞 IO
5)使用底層模型不同,它們之間底層實現方式以及與客戶端之間通信的應用協議不一樣,
Redis 直接自己構建了 VM 機制 ,因為一般的系統調用系統函數的話,會浪費一定的時間去移動和請求
6.redis的熱鍵問題?怎麼解決?十三.Mysql
1.請寫出mysql登錄命令,用戶名user,密碼123456,地址192.168.1.130mysql -h 192.168.1.130 -uuser -p123456 -P3306 -Dwemeta_test
2.為什麼MySQL的索引要使用B+樹而不是其它樹形結構?比如B樹?B樹
B樹不管葉子節點還是非葉子節點,都會保存數據,這樣導致在非葉子節點中能保存的指針數量變少(有些資料也稱為扇出)
指針少的情況下要保存大量數據,只能增加樹的高度,導致IO操作變多,查詢性能變低;
B+樹
1.單一節點存儲更多的元素,使得查詢的IO次數更少。
2.所有查詢都要查找到葉子節點,查詢性能穩定。
3.所有葉子節點形成有序鍊表,便於範圍查詢,遠遠高於B-樹
十四.數據結構與算法
1.二分查找package com.wedoctor.search;
public class Binarysearch { public static int bsearchWithoutRecursion(int arr[], int key) { int low = 0; int high = arr.length - 1; while (low <= high) { int mid = low + (high - low) / 2; if (arr[mid] > key) high = mid - 1; else if (arr[mid] < key) low = mid + 1; else return mid; } return -1; }
public static void main(String[] args) { int arr[] = {1,3,5,6,8,9,11,14,23}; int num = bsearchWithoutRecursion(arr, 9); System.out.println(num); }}
2.快排3.歸併排序4.冒泡排序package com.wedoctor.sort;
import java.util.Arrays;
public class BubbleSort { public static void main(String[] args) { int[] arr = new int[] { 2, 8, 7, 9, 4, 1, 5, 0 }; bubbleSort(arr); }
public static void bubbleSort(int[] arr) { //控制多少輪 for (int i = 1; i < arr.length; i++) { //控制每一輪的次數 for (int j = 0; j <= arr.length -1 - i; j++) { if (arr[j] > arr[j + 1]) { int temp; temp = arr[j]; arr[j] = arr[j + 1]; arr[j + 1] = temp; } } } System.out.println(Arrays.toString(arr));
}}
5.字符串反轉package com.wedoctor.str;
public class StrReverse { public static String getNewStr(String str){ StringBuffer sb = new StringBuffer(str); String newStr = sb.reverse().toString(); return newStr; }
public static void main(String[] args) { System.out.println(getNewStr("thjymhr")); }}
6.Btree簡單講一下B樹(B-樹)是一種適合外查找的搜索樹,是一種平衡的多叉樹
B樹的每個結點包含著結點的值和結點所處的位置
7.動態規劃 最大連續子序列和package com.wedoctor;
import java.util.Arrays;
public class MaxSum { public static int findMax(int arr[]){ if (arr.length == 1){ return arr[0]; } int mid = (arr.length) / 2; int[] leftArr = Arrays.copyOfRange(arr, 0, mid); int[] rightArr = Arrays.copyOfRange(arr, mid, arr.length);
int lenLeft = findMax(leftArr); int lenRight = findMax(rightArr); int lenMid = maxInMid(leftArr, rightArr);
int max = Math.max(Math.max(lenLeft,lenRight),lenMid); return max; }
public static int maxInMid(int left[],int right[]){ int maxLeft = 0; int maxRight = 0; int tmpLeft = 0; int tmpRight = 0; for (int i = 0;i< left.length;i++){ tmpLeft = tmpLeft + left[left.length - 1 - i]; maxLeft = Math.max(tmpLeft,maxLeft); }
for (int i = 0;i< right.length;i++){ tmpRight = tmpRight + right[i]; maxRight = Math.max(tmpRight,maxRight); } return maxRight + maxLeft; }
public static void main(String[] args) { int arr[] = {3,-1,10}; System.out.println(findMax(arr)); }}
8.二叉樹概念,特點及代碼實現二叉樹是n(n>=0)個結點的有限集合,該集合或者為空集(稱為空二叉樹),或者由一個根結點和兩棵互不相交的、分別稱為根結點的左子樹和右子樹組成。
特點:
實現:
package com.wedoctor;
public class BinaryTreeNode { int data; BinaryTreeNode left; BinaryTreeNode right;
BinaryTreeNode (int x) { data= x; }
public BinaryTreeNode(int data, BinaryTreeNode left, BinaryTreeNode right) { this.data = data; this.left = left; this.right = right; }
public int getData() { return data; }
public void setData(int data) { this.data = data; }
public BinaryTreeNode getLeft() { return left; }
public void setLeft(BinaryTreeNode left) { this.left = left; }
public BinaryTreeNode getRight() { return right; }
public void setRight(BinaryTreeNode right) { this.right = right; }}9.鍊表
10.算法題:兩數之和
十五.Linux1.怎麼查看用戶組
2.怎麼修改文件權限
3.常用的命令有哪些
4.怎麼修改文本文件第一行字符
5.查看內存
top
6.查看磁碟存儲情況
df -h
7.查看磁碟IO讀寫(yum install iotop安裝)
iotop
8.直接查看比較高的磁碟讀寫程序
iotop -o
9.查看埠佔用情況
netstat -tunlp | grep 埠號
10.查看報告系統運行時長及平均負載
uptime
11.查看進程
ps aux
7年老碼農,10W+關注者。【Java與大數據架構】全面分享Java編程、Spark、Flink、Kafka、Elasticsearch、數據湖等乾貨。歡迎掃碼關注!