大數(shù)據(jù)技術(shù)面試大綱范文

大數(shù)據(jù)技術(shù)面試大綱范文第一篇大數(shù)據(jù)技術(shù)面試大綱范文第一篇Hive支持索引（版本之前），但是Hive的索引與關(guān)系型數(shù)據(jù)庫(kù)中的索引并不相同，比如，Hive不支持主鍵或者外鍵。并且Hive索引提供的功能很有限，效率也并不高，因此Hive索引很少使用。

適用于不更新的靜態(tài)字段。以免總是重建索引數(shù)據(jù)。每次建立、更新數(shù)據(jù)后，都要重建索引以構(gòu)建索引表。

hive在指定列上建立索引，會(huì)產(chǎn)生一張索引表（Hive的一張物理表），里面的字段包括：索引列的值、該值對(duì)應(yīng)的HDFS文件路徑、該值在文件中的偏移量。

Hive版本后引入bitmap索引處理器，這個(gè)處理器適用于去重后，值較少的列（例如，某字段的取值只可能是幾個(gè)枚舉值）因?yàn)樗饕怯每臻g換時(shí)間，索引列的取值過(guò)多會(huì)導(dǎo)致建立bitmap索引表過(guò)大。

注意：Hive中每次有數(shù)據(jù)時(shí)需要及時(shí)更新索引，相當(dāng)于重建一個(gè)新表，否則會(huì)影響數(shù)據(jù)查詢(xún)的效率和準(zhǔn)確性，Hive官方文檔已經(jīng)明確表示Hive的索引不推薦被使用，在新版本的Hive中已經(jīng)被廢棄了。

擴(kuò)展：Hive是在版本之后支持索引的，在版本后引入bitmap索引處理器，在版本開(kāi)始移除索引的功能，取而代之的是版本開(kāi)始的物化視圖，自動(dòng)重寫(xiě)的物化視圖替代了索引的功能。

大數(shù)據(jù)技術(shù)面試大綱范文第二篇Sparkstreaming是sparkcoreAPI的一種擴(kuò)展，可以用于進(jìn)行大規(guī)模、高吞吐量、容錯(cuò)的實(shí)時(shí)數(shù)據(jù)流的處理。

它支持從多種數(shù)據(jù)源讀取數(shù)據(jù)，比如Kafka、Flume、Twitter和TCPSocket，并且能夠使用算子比如map、reduce、join和window等來(lái)處理數(shù)據(jù)，處理后的數(shù)據(jù)可以保存到文件系統(tǒng)、數(shù)據(jù)庫(kù)等存儲(chǔ)中。

Sparkstreaming內(nèi)部的基本工作原理是：接受實(shí)時(shí)輸入數(shù)據(jù)流，然后將數(shù)據(jù)拆分成batch，比如每收集一秒的數(shù)據(jù)封裝成一個(gè)batch，然后將每個(gè)batch交給spark的計(jì)算引擎進(jìn)行處理，最后會(huì)生產(chǎn)處一個(gè)結(jié)果數(shù)據(jù)流，其中的數(shù)據(jù)也是一個(gè)一個(gè)的batch組成的。

大數(shù)據(jù)技術(shù)面試大綱范文第三篇數(shù)據(jù)商業(yè)分析的目標(biāo)是利用大數(shù)據(jù)為所有職場(chǎng)人員做出迅捷，高質(zhì)，高效的決策提供可規(guī)?；慕鉀Q方案。商業(yè)分析是創(chuàng)造價(jià)值的數(shù)據(jù)科學(xué)。

數(shù)據(jù)商業(yè)分析中會(huì)存在很多判斷：

比如想知道線上渠道A、B各自帶來(lái)了多少流量，新上線的產(chǎn)品有多少用戶(hù)喜歡，新注冊(cè)流中注冊(cè)的人數(shù)有多少。這些都需要通過(guò)數(shù)據(jù)來(lái)展示結(jié)果。

我們需要知道渠道A為什么比渠道B好，這些是要通過(guò)數(shù)據(jù)去發(fā)現(xiàn)的。也許某個(gè)關(guān)鍵字帶來(lái)的流量轉(zhuǎn)化率比其他都要低，這時(shí)可以通過(guò)信息、知識(shí)、數(shù)據(jù)沉淀出發(fā)生的原因是什么。

在對(duì)渠道A、B有了判斷之后，根據(jù)以往的知識(shí)預(yù)測(cè)未來(lái)會(huì)發(fā)生什么。在投放渠道C、D的時(shí)候，猜測(cè)渠道C比渠道D好，當(dāng)上線新的注冊(cè)流、新的優(yōu)化，可以知道哪一個(gè)節(jié)點(diǎn)比較容易出問(wèn)題，這些都是通過(guò)數(shù)據(jù)進(jìn)行預(yù)測(cè)的過(guò)程。

所有工作中最有意義的還是商業(yè)決策，通過(guò)數(shù)據(jù)來(lái)判斷應(yīng)該做什么。這是商業(yè)分析最終的目的。

大數(shù)據(jù)面試中考察的算法相對(duì)容易一些，?？嫉挠信判蛩惴?，查找算法，二叉樹(shù)等，下面講解一些最容易考的算法。

大數(shù)據(jù)技術(shù)面試大綱范文第四篇相同點(diǎn)：都是將mapper（Spark里是ShuffleMapTask）的輸出進(jìn)行partition，不同的partition送到不同的reducer（Spark里reducer可能是下一個(gè)stage里的ShuffleMapTask，也可能是ResultTask）

不同點(diǎn)：

MapReduce默認(rèn)是排序的，spark默認(rèn)不排序，除非使用sortByKey算子。

MapReduce可以劃分成split，map()、spill、merge、shuffle、sort、reduce()等階段，spark沒(méi)有明顯的階段劃分，只有不同的stage和算子操作。

MR落盤(pán)，Spark不落盤(pán)，spark可以解決mr落盤(pán)導(dǎo)致效率低下的問(wèn)題。

大數(shù)據(jù)技術(shù)面試大綱范文第五篇

Spark運(yùn)行流程

具體運(yùn)行流程如下：

SparkContext向資源管理器注冊(cè)并向資源管理器申請(qǐng)運(yùn)行Executor

資源管理器分配Executor，然后資源管理器啟動(dòng)Executor

Executor發(fā)送心跳至資源管理器

SparkContext構(gòu)建DAG有向無(wú)環(huán)圖

將DAG分解成Stage（TaskSet）

把Stage發(fā)送給TaskScheduler

Executor向SparkContext申請(qǐng)Task

TaskScheduler將Task發(fā)送給Executor運(yùn)行

同時(shí)SparkContext將應(yīng)用程序代碼發(fā)放給Executor

Task在Executor上運(yùn)行，運(yùn)行完畢釋放所有資源

大數(shù)據(jù)技術(shù)面試大綱范文第六篇receiver方式的容錯(cuò)性：在默認(rèn)的配置下，這種方式可能會(huì)因?yàn)榈讓拥氖《鴣G失數(shù)據(jù)。如果要啟用高可靠機(jī)制，讓數(shù)據(jù)零丟失，就必須啟用SparkStreaming的預(yù)寫(xiě)日志機(jī)制（WriteAheadLog，WAL）。該機(jī)制會(huì)同步地將接收到的Kafka數(shù)據(jù)寫(xiě)入分布式文件系統(tǒng)（比如HDFS）上的預(yù)寫(xiě)日志中。所以，即使底層節(jié)點(diǎn)出現(xiàn)了失敗，也可以使用預(yù)寫(xiě)日志中的數(shù)據(jù)進(jìn)行恢復(fù)。

Kafka中的topic的partition，與Spark中的RDD的partition是沒(méi)有關(guān)系的。在1、()中，提高partition的數(shù)量，只會(huì)增加Receiver方式中讀取partition的線程的數(shù)量。不會(huì)增加Spark處理數(shù)據(jù)的并行度。可以創(chuàng)建多個(gè)Kafka輸入DStream，使用不同的consumergroup和topic，來(lái)通過(guò)多個(gè)receiver并行接收數(shù)據(jù)。

優(yōu)點(diǎn)：簡(jiǎn)化并行讀取：如果要讀取多個(gè)partition，不需要?jiǎng)?chuàng)建多個(gè)輸入DStream然后對(duì)它們進(jìn)行union操作。Spark會(huì)創(chuàng)建跟Kafkapartition一樣多的RDDpartition，并且會(huì)并行從Kafka中讀取數(shù)據(jù)。所以在Kafkapartition和RDDpartition之間，有一個(gè)一對(duì)一的映射關(guān)系。

高性能：如果要保證零數(shù)據(jù)丟失，在基于receiver的方式中，需要開(kāi)啟WAL機(jī)制。這種方式其實(shí)效率低下，因?yàn)閿?shù)據(jù)實(shí)際上被復(fù)制了兩份，Kafka自己本身就有高可靠的機(jī)制，會(huì)對(duì)數(shù)據(jù)復(fù)制一份，而這里又會(huì)復(fù)制一份到WAL中。而基于direct的方式，不依賴(lài)Receiver，不需要開(kāi)啟WAL機(jī)制，只要Kafka中作了數(shù)據(jù)的復(fù)制，那么就可以通過(guò)Kafka的副本進(jìn)行恢復(fù)。

基于receiver的方式，是使用Kafka的高階API來(lái)在ZooKeeper中保存消費(fèi)過(guò)的offset的。這是消費(fèi)Kafka數(shù)據(jù)的傳統(tǒng)方式。這種方式配合著WAL機(jī)制可以保證數(shù)據(jù)零丟失的高可靠性，但是卻無(wú)法保證數(shù)據(jù)被處理一次且僅一次，可能會(huì)處理兩次。因?yàn)镾park和ZooKeeper之間可能是不同步的。

基于direct的方式，使用Kafka的低階API，SparkStreaming自己就負(fù)責(zé)追蹤消費(fèi)的offset，并保存在checkpoint中。Spark自己一定是同步的，因此可以保證數(shù)據(jù)是消費(fèi)一次且僅消費(fèi)一次。

Receiver方式是通過(guò)zookeeper來(lái)連接kafka隊(duì)列，Direct方式是直接連接到kafka的節(jié)點(diǎn)上獲取數(shù)據(jù)。

大數(shù)據(jù)技術(shù)面試大綱范文第七篇ORC和Parquet都是高性能的存儲(chǔ)方式，這兩種存儲(chǔ)格式總會(huì)帶來(lái)存儲(chǔ)和性能上的提升。

Parquet:

Parquet支持嵌套的數(shù)據(jù)模型，類(lèi)似于ProtocolBuffers，每一個(gè)數(shù)據(jù)模型的schema包含多個(gè)字段，每一個(gè)字段有三個(gè)屬性：重復(fù)次數(shù)、數(shù)據(jù)類(lèi)型和字段名。重復(fù)次數(shù)可以是以下三種：required(只出現(xiàn)1次)，repeated(出現(xiàn)0次或多次)，optional(出現(xiàn)0次或1次)。每一個(gè)字段的數(shù)據(jù)類(lèi)型可以分成兩種：group(復(fù)雜類(lèi)型)和primitive(基本類(lèi)型)。

Parquet中沒(méi)有Map、Array這樣的復(fù)雜數(shù)據(jù)結(jié)構(gòu)，但是可以通過(guò)repeated和group組合來(lái)實(shí)現(xiàn)的。

由于Parquet支持的數(shù)據(jù)模型比較松散，可能一條記錄中存在比較深的嵌套關(guān)系，如果為每一條記錄都維護(hù)一個(gè)類(lèi)似的樹(shù)狀結(jié)可能會(huì)占用較大的存儲(chǔ)空間，因此Dremel論文中提出了一種高效的對(duì)于嵌套數(shù)據(jù)格式的壓縮算法：Striping/Assembly算法。通過(guò)Striping/Assembly算法，parquet可以使用較少的存儲(chǔ)空間表示復(fù)雜的嵌套格式，并且通常Repetitionlevel和Definitionlevel都是較小的整數(shù)值，可以通過(guò)RLE算法對(duì)其進(jìn)行壓縮，進(jìn)一步降低存儲(chǔ)空間。

Parquet文件是以二進(jìn)制方式存儲(chǔ)的，是不可以直接讀取和修改的，Parquet文件是自解析的，文件中包括該文件的數(shù)據(jù)和元數(shù)據(jù)。

ORC:

ORC文件是自描述的，它的元數(shù)據(jù)使用ProtocolBuffers序列化，并且文件中的數(shù)據(jù)盡可能的壓縮以降低存儲(chǔ)空間的消耗。

和Parquet類(lèi)似，ORC文件也是以二進(jìn)制方式存儲(chǔ)的，所以是不可以直接讀取，ORC文件也是自解析的，它包含許多的元數(shù)據(jù)，這些元數(shù)據(jù)都是同構(gòu)ProtoBuffer進(jìn)行序列化的。

ORC會(huì)盡可能合并多個(gè)離散的區(qū)間盡可能的減少I(mǎi)/O次數(shù)。

ORC中使用了更加精確的索引信息，使得在讀取數(shù)據(jù)時(shí)可以指定從任意一行開(kāi)始讀取，更細(xì)粒度的統(tǒng)計(jì)信息使得讀取ORC文件跳過(guò)整個(gè)rowgroup，ORC默認(rèn)會(huì)對(duì)任何一塊數(shù)據(jù)和索引信息使用ZLIB壓縮，因此ORC文件占用的存儲(chǔ)空間也更小。

在新版本的ORC中也加入了對(duì)BloomFilter的支持，它可以進(jìn)一步提升謂詞下推的效率，在Hive版本以后也加入了對(duì)此的支持。

大數(shù)據(jù)技術(shù)面試大綱范文第八篇在Oracle中，什么是OCR、OLR和VF？?答案部分Oracle集群使用兩種類(lèi)型的文件來(lái)管理集群資源和節(jié)點(diǎn)：OCR（OracleClusterRegistry，Oracle集群注冊(cè)表）和VF（VotingFile，表決磁盤(pán)文件）。這兩種文件必須存放在共享存儲(chǔ)上。其中，OCR相當(dāng)于集群的控制文件，用于解決健忘問(wèn)題，VF用于解決腦裂問(wèn)題。在中引入一個(gè)新的文件，稱(chēng)作OLR（OracleLocalRegistry，Oracle本地注冊(cè)表），它只允許存放在本地。Oracle集群軟件（Clusterware）把整個(gè)集群的配置信息放在共享存儲(chǔ)上，這個(gè)存儲(chǔ)就是OCR磁盤(pán)（OCRDisk）。OCR是OracleRAC配置信息倉(cāng)庫(kù)，它管理集群節(jié)點(diǎn)的相關(guān)信息及實(shí)例到節(jié)點(diǎn)的映射信息。因此，OCR的內(nèi)容非常的重要，對(duì)OCR的操作必須確保OCR內(nèi)容完整性。在整個(gè)集群運(yùn)行過(guò)程中，并不是所有節(jié)點(diǎn)都能操作OCR磁盤(pán)，而只有一個(gè)節(jié)點(diǎn)能對(duì)OCR磁盤(pán)進(jìn)行讀寫(xiě)操作，這個(gè)節(jié)點(diǎn)叫作MasterNode。在每個(gè)節(jié)點(diǎn)的內(nèi)存中都有一份OCR內(nèi)容的拷貝，這份拷貝叫作OCRCache。同時(shí)，每個(gè)節(jié)點(diǎn)都有一個(gè)OCRP

大數(shù)據(jù)技術(shù)面試大綱范文第九篇shuffle階段分為四個(gè)步驟：依次為：分區(qū)，排序，規(guī)約，分組，其中前三個(gè)步驟在map階段完成，最后一個(gè)步驟在reduce階段完成。

shuffle是Mapreduce的核心，它分布在Mapreduce的map階段和reduce階段。一般把從Map產(chǎn)生輸出開(kāi)始到Reduce取得數(shù)據(jù)作為輸入之前的過(guò)程稱(chēng)作shuffle。

Collect階段：將MapTask的結(jié)果輸出到默認(rèn)大小為100M的環(huán)形緩沖區(qū)，保存的是key/value，Partition分區(qū)信息等。

Spill階段：當(dāng)內(nèi)存中的數(shù)據(jù)量達(dá)到一定的閥值的時(shí)候，就會(huì)將數(shù)據(jù)寫(xiě)入本地磁盤(pán)，在將數(shù)據(jù)寫(xiě)入磁盤(pán)之前需要對(duì)數(shù)據(jù)進(jìn)行一次排序的操作，如果配置了combiner，還會(huì)將有相同分區(qū)號(hào)和key的數(shù)據(jù)進(jìn)行排序。

MapTask階段的Merge：把所有溢出的臨時(shí)文件進(jìn)行一次合并操作，以確保一個(gè)MapTask最終只產(chǎn)生一個(gè)中間數(shù)據(jù)文件。

Copy階段：ReduceTask啟動(dòng)Fetcher線程到已經(jīng)完成MapTask的節(jié)點(diǎn)上復(fù)制一份屬于自己的數(shù)據(jù)，這些數(shù)據(jù)默認(rèn)會(huì)保存在內(nèi)存的緩沖區(qū)中，當(dāng)內(nèi)存的緩沖區(qū)達(dá)到一定的閥值的時(shí)候，就會(huì)將數(shù)據(jù)寫(xiě)到磁盤(pán)之上。

ReduceTask階段的Merge：在ReduceTask遠(yuǎn)程復(fù)制數(shù)據(jù)的同時(shí)，會(huì)在后臺(tái)開(kāi)啟兩個(gè)線程對(duì)內(nèi)存到本地的數(shù)據(jù)文件進(jìn)行合并操作。

Sort階段：在對(duì)數(shù)據(jù)進(jìn)行合并的同時(shí)，會(huì)進(jìn)行排序操作，由于MapTask階段已經(jīng)對(duì)數(shù)據(jù)進(jìn)行了局部的排序，ReduceTask只需保證Copy的數(shù)據(jù)的最終整體有效性即可。

Shuffle中的緩沖區(qū)大小會(huì)影響到mapreduce程序的執(zhí)行效率，原則上說(shuō)，緩沖區(qū)越大，磁盤(pán)io的次數(shù)越少，執(zhí)行速度就越快。緩沖區(qū)的大小可以通過(guò)參數(shù)調(diào)整,參數(shù)：默認(rèn)100M

大數(shù)據(jù)技術(shù)面試大綱范文第十篇Flink運(yùn)行時(shí)由兩種類(lèi)型的進(jìn)程組成：一個(gè)JobManager和一個(gè)或者多個(gè)TaskManager。

Client不是運(yùn)行時(shí)和程序執(zhí)行的一部分，而是用于準(zhǔn)備數(shù)據(jù)流并將其發(fā)送給JobManager。之后，客戶(hù)端可以斷開(kāi)連接（分離模式），或保持連接來(lái)接收進(jìn)程報(bào)告（附加模式）?？蛻?hù)端可以作為觸發(fā)執(zhí)行Java/Scala程序的一部分運(yùn)行，也可以在命令行進(jìn)程./bin/flinkrun...中運(yùn)行。

可以通過(guò)多種方式啟動(dòng)JobManager和TaskManager：直接在機(jī)器上作為standalone集群?jiǎn)?dòng)、在容器中啟動(dòng)、或者通過(guò)YARN等資源框架管理并啟動(dòng)。TaskManager連接到JobManagers，宣布自己可用，并被分配工作。

JobManager：

JobManager具有許多與協(xié)調(diào)Flink應(yīng)用程序的分布式執(zhí)行有關(guān)的職責(zé)：它決定何時(shí)調(diào)度下一個(gè)task（或一組task）、對(duì)完成的task或執(zhí)行失敗做出反應(yīng)、協(xié)調(diào)checkpoint、并且協(xié)調(diào)從失敗中恢復(fù)等等。這個(gè)進(jìn)程由三個(gè)不同的組件組成：

ResourceManager負(fù)責(zé)Flink集群中的資源提供、回收、分配，管理taskslots。

Dispatcher提供了一個(gè)REST接口，用來(lái)提交Flink應(yīng)用程序執(zhí)行，并為每個(gè)提交的作業(yè)啟動(dòng)一個(gè)新的JobMaster。它還運(yùn)行FlinkWebUI用來(lái)提供作業(yè)執(zhí)行信息。

JobMaster負(fù)責(zé)管理單個(gè)JobGraph的執(zhí)行。Flink集群中可以同時(shí)運(yùn)行多個(gè)作業(yè)，每個(gè)作業(yè)都有自己的JobMaster。

TaskManagers：

TaskManager（也稱(chēng)為worker）執(zhí)行作業(yè)流的task，并且緩存和交換數(shù)據(jù)流。

必須始終至少有一個(gè)TaskManager。在TaskManager中資源調(diào)度的最小單位是taskslot。TaskManager中taskslot的數(shù)量表示并發(fā)處理task的數(shù)量。請(qǐng)注意一個(gè)taskslot中可以執(zhí)行多個(gè)算子。

大數(shù)據(jù)技術(shù)面試大綱范文第十一篇當(dāng)jobclient向YARN提交一個(gè)應(yīng)用程序后，YARN將分兩個(gè)階段運(yùn)行這個(gè)應(yīng)用程序：一是啟動(dòng)ApplicationMaster;第二個(gè)階段是由ApplicationMaster創(chuàng)建應(yīng)用程序，為它申請(qǐng)資源，監(jiān)控運(yùn)行直到結(jié)束。具體步驟如下:

用戶(hù)向YARN提交一個(gè)應(yīng)用程序，并指定ApplicationMaster程序、啟動(dòng)ApplicationMaster的命令、用戶(hù)程序。

RM為這個(gè)應(yīng)用程序分配第一個(gè)Container，并與之對(duì)應(yīng)的NM通訊，要求它在這個(gè)Container中啟動(dòng)應(yīng)用程序ApplicationMaster。

ApplicationMaster向RM注冊(cè)，然后拆分為內(nèi)部各個(gè)子任務(wù)，為各個(gè)內(nèi)部任務(wù)申請(qǐng)資源，并監(jiān)控這些任務(wù)的運(yùn)行，直到結(jié)束。

AM采用輪詢(xún)的方式向RM申請(qǐng)和領(lǐng)取資源。

RM為AM分配資源，以Container形式返回。

AM申請(qǐng)到資源后，便與之對(duì)應(yīng)的NM通訊，要求NM啟動(dòng)任務(wù)。

NodeManager為任務(wù)設(shè)置好運(yùn)行環(huán)境，將任務(wù)啟動(dòng)命令寫(xiě)到一個(gè)腳本中，并通過(guò)運(yùn)行這個(gè)腳本啟動(dòng)任務(wù)。

各個(gè)任務(wù)向AM匯報(bào)自己的狀態(tài)和進(jìn)度，以便當(dāng)任務(wù)失敗時(shí)可以重啟任務(wù)。

應(yīng)用程序完成后，ApplicationMaster向ResourceManager注銷(xiāo)并關(guān)閉自己。

大數(shù)據(jù)技術(shù)面試大綱范文第十二篇Flink摒棄了Java原生的序列化方法，以獨(dú)特的方式處理數(shù)據(jù)類(lèi)型和序列化，包含自己的類(lèi)型描述符，泛型類(lèi)型提取和類(lèi)型序列化框架。

TypeInformation是所有類(lèi)型描述符的基類(lèi)。它揭示了該類(lèi)型的一些基本屬性，并且可以生成序列化器。

TypeInformation支持以下幾種類(lèi)型：

BasicTypeInfo:任意Java基本類(lèi)型或String類(lèi)型

BasicArrayTypeInfo:任意Java基本類(lèi)型數(shù)組或String數(shù)組

WritableTypeInfo:任意HadoopWritable接口的實(shí)現(xiàn)類(lèi)

TupleTypeInfo:任意的FlinkTuple類(lèi)型(支持Tuple1toTuple25)。Flinktuples是固定長(zhǎng)度固定類(lèi)型的JavaTuple實(shí)現(xiàn)

CaseClassTypeInfo:任意的ScalaCaseClass(包括Scalatuples)

PojoTypeInfo:任意的POJO(JavaorScala)，例如，Java對(duì)象的所有成員變量，要么是public修飾符定義，要么有g(shù)etter/setter方法

GenericTypeInfo:任意無(wú)法匹配之前幾種類(lèi)型的類(lèi)

大數(shù)據(jù)技術(shù)面試大綱范文第十三篇面試的時(shí)候遇到了一個(gè)筆試題，是leetcode的原題，原題的連接：復(fù)制大概的內(nèi)容：刪除鏈表的倒數(shù)第N個(gè)節(jié)點(diǎn)，并返回鏈表的頭節(jié)點(diǎn)。一開(kāi)始遇到這個(gè)題也是一臉懵，通過(guò)查看解題思路才了解到有幾種解決方式：?jiǎn)蜗蝽?xiàng)鏈表實(shí)現(xiàn)類(lèi)：publicclassListNode{intval;ListNodenext;ListNode(intx){val=x;}}復(fù)制0x01：兩次循環(huán)求長(zhǎng)度實(shí)現(xiàn)思路：1、先循環(huán)一遍鏈表，求出鏈表的長(zhǎng)度L，倒數(shù)第N個(gè)節(jié)點(diǎn)就是從開(kāi)頭數(shù)第（L-N+1）個(gè)節(jié)點(diǎn),將此節(jié)點(diǎn)的next指向下下節(jié)點(diǎn)就可以了。在解題的過(guò)程中要添加一個(gè)亞節(jié)點(diǎn)（dummy）進(jìn)行輔助（如:圖1），D就是我們的亞節(jié)點(diǎn)。圖1代碼：ListNodedummy=newListNode(0);//亞節(jié)點(diǎn);intlength=0;ListNodefirst=head;//通過(guò)移動(dòng)頭節(jié)點(diǎn)循環(huán)求出鏈表的長(zhǎng)度while(first!=null){

大數(shù)據(jù)技術(shù)面試大綱范文第十四篇本文檔是根據(jù)

discourse/·discourse/discourse·GitHub

頁(yè)面中的內(nèi)容進(jìn)行翻譯的。云平臺(tái)安裝在基于云平臺(tái)的Discourse安裝通常不會(huì)超過(guò)30分鐘，哪怕你沒(méi)有任何有關(guān)Rails或Linuxshell的知識(shí)都能夠順利完成安裝。下面我們是通過(guò)

DigitalOcean

服務(wù)提供商來(lái)進(jìn)行安裝測(cè)的，但是所有的安裝步驟都能夠在所有兼容

Docker

的云計(jì)算平臺(tái)上進(jìn)行，同時(shí)也可以在本地的服務(wù)器上完成安裝。

如果你連30分鐘都沒(méi)有的話？你可以聯(lián)系Discourse社區(qū)來(lái)幫你完成安裝，Discourse社區(qū)將會(huì)收取一次性$150（美元）的費(fèi)用。

單擊此處鏈接來(lái)對(duì)服務(wù)進(jìn)行購(gòu)買(mǎi)

。創(chuàng)建一個(gè)新的云服務(wù)器創(chuàng)建一個(gè)你的新云服務(wù)器，例如：DigitalOcean

，當(dāng)然你也可以使用其他平臺(tái)提供的服務(wù)器。默認(rèn)配置

當(dāng)前版本的LTSUbuntu操作系統(tǒng)

能夠很好的工作。最少，需要一個(gè)64位的Linux操作系統(tǒng)，并且這個(gè)操作系統(tǒng)的內(nèi)核需要更新到最新的版本。默認(rèn)配置

1GB

的內(nèi)存針對(duì)小型的Discourse社區(qū)通常都能很好的運(yùn)行。但我們推薦

大數(shù)據(jù)技術(shù)面試大綱范文第十五篇Client：客戶(hù)端

切分文件。文件上傳HDFS的時(shí)候，Client將文件切分成一個(gè)一個(gè)的Block，然后進(jìn)行存儲(chǔ)

與NameNode交互，獲取文件的位置信息

與DataNode交互，讀取或者寫(xiě)入數(shù)據(jù)

Client提供一些命令來(lái)管理HDFS，比如啟動(dòng)關(guān)閉HDFS、訪問(wèn)HDFS目錄及內(nèi)容等

NameNode：名稱(chēng)節(jié)點(diǎn)，也稱(chēng)主節(jié)點(diǎn)，存儲(chǔ)數(shù)據(jù)的元數(shù)據(jù)信息，不存儲(chǔ)具體的數(shù)據(jù)

管理HDFS的名稱(chēng)空間

管理數(shù)據(jù)塊（Block）映射信息

配置副本策略

處理客戶(hù)端讀寫(xiě)請(qǐng)求

DataNode：數(shù)據(jù)節(jié)點(diǎn)，也稱(chēng)從節(jié)點(diǎn)。NameNode下達(dá)命令，DataNode執(zhí)行實(shí)際的操作

存儲(chǔ)實(shí)際的數(shù)據(jù)塊

執(zhí)行數(shù)據(jù)塊的讀/寫(xiě)操作

SecondaryNameNode：并非NameNode的熱備。當(dāng)NameNode掛掉的時(shí)候，它并不能馬上替換NameNode并提供服務(wù)

輔助NameNode，分擔(dān)其工作量

定期合并Fsimage和Edits，并推送給NameNode

在緊急情況下，可輔助恢復(fù)NameNode

大數(shù)據(jù)技術(shù)面試大綱范文第十六篇數(shù)據(jù)傾斜以為著某一個(gè)或者某幾個(gè)partition的數(shù)據(jù)特別大，導(dǎo)致這幾個(gè)partition上的計(jì)算需要耗費(fèi)相當(dāng)長(zhǎng)的時(shí)間。

在spark中同一個(gè)應(yīng)用程序劃分成多個(gè)stage，這些stage之間是串行執(zhí)行的，而一個(gè)stage里面的多個(gè)task是可以并行執(zhí)行，task數(shù)目由partition數(shù)目決定，如果一個(gè)partition的數(shù)目特別大，那么導(dǎo)致這個(gè)task執(zhí)行時(shí)間很長(zhǎng)，導(dǎo)致接下來(lái)的stage無(wú)法執(zhí)行，從而導(dǎo)致整個(gè)job執(zhí)行變慢。

避免數(shù)據(jù)傾斜，一般是要選用合適的key，或者自己定義相關(guān)的partitioner，通過(guò)加鹽或者哈希值來(lái)拆分這些key，從而將這些數(shù)據(jù)分散到不同的partition去執(zhí)行。

如下算子會(huì)導(dǎo)致shuffle操作，是導(dǎo)致數(shù)據(jù)傾斜可能發(fā)生的關(guān)鍵點(diǎn)所在：groupByKey；reduceByKey；aggregaByKey；join；cogroup；

大數(shù)據(jù)技術(shù)面試大綱范文第十七篇這道題?？迹@里只是給大家一個(gè)思路，簡(jiǎn)單說(shuō)下！面試之前還需做更多準(zhǔn)備。

join其實(shí)常見(jiàn)的就分為兩類(lèi)：map-sidejoin和reduce-sidejoin。

當(dāng)大表和小表join時(shí)，用map-sidejoin能顯著提高效率。

如果其中有張表較小的話，我們則可以自己實(shí)現(xiàn)在map端實(shí)現(xiàn)數(shù)據(jù)關(guān)聯(lián)，跳過(guò)大量數(shù)據(jù)進(jìn)行shuffle的過(guò)程，運(yùn)行時(shí)間得到大量縮短，根據(jù)不同數(shù)據(jù)可能會(huì)有幾倍到數(shù)十倍的性能提升。

在大數(shù)據(jù)量的情況下，join是一中非常昂貴的操作，需要在join之前應(yīng)盡可能的先縮小數(shù)據(jù)量。

對(duì)于縮小數(shù)據(jù)量，有以下幾條建議：

若兩個(gè)RDD都有重復(fù)的key，join操作會(huì)使得數(shù)據(jù)量會(huì)急劇的擴(kuò)大。所有，最好先使用distinct或者combineByKey操作來(lái)減少key空間或者用cogroup來(lái)處理重復(fù)的key，而不是產(chǎn)生所有的交叉結(jié)果。在combine時(shí)，進(jìn)行機(jī)智的分區(qū)，可以避免第二次shuffle。

如果只在一個(gè)RDD出現(xiàn)，那你將在無(wú)意中丟失你的數(shù)據(jù)。所以使用外連接會(huì)更加安全，這樣你就能確保左邊的RDD或者右邊的RDD的數(shù)據(jù)完整性，在join之后再過(guò)濾數(shù)據(jù)。

如果我們?nèi)菀椎玫絉DD的可以的有用的子集合，那么我們可以先用filter或者reduce，如何在再用join。

大數(shù)據(jù)技術(shù)面試大綱范文第十八篇簡(jiǎn)單描述：

Reduce大致分為copy、sort、reduce三個(gè)階段，重點(diǎn)在前兩個(gè)階段。

copy階段包含一個(gè)eventFetcher來(lái)獲取已完成的map列表，由Fetcher線程去copy數(shù)據(jù)，在此過(guò)程中會(huì)啟動(dòng)兩個(gè)merge線程，分別為inMemoryMerger和onDiskMerger，分別將內(nèi)存中的數(shù)據(jù)merge到磁盤(pán)和將磁盤(pán)中的數(shù)據(jù)進(jìn)行merge。待數(shù)據(jù)copy完成之后，copy階段就完成了。

開(kāi)始進(jìn)行sort階段，sort階段主要是執(zhí)行finalMerge操作，純粹的sort階段，完成之后就是reduce階段，調(diào)用用戶(hù)定義的reduce函數(shù)進(jìn)行處理。

詳細(xì)步驟：

Copy階段：簡(jiǎn)單地拉取數(shù)據(jù)。Reduce進(jìn)程啟動(dòng)一些數(shù)據(jù)copy線程(Fetcher)，通過(guò)HTTP方式請(qǐng)求maptask獲取屬于自己的文件（maptask的分區(qū)會(huì)標(biāo)識(shí)每個(gè)maptask屬于哪個(gè)reducetask，默認(rèn)reducetask的標(biāo)識(shí)從0開(kāi)始）。

Merge階段：在遠(yuǎn)程拷貝數(shù)據(jù)的同時(shí)，ReduceTask啟動(dòng)了兩個(gè)后臺(tái)線程對(duì)內(nèi)存和磁盤(pán)上的文件進(jìn)行合并，以防止內(nèi)存使用過(guò)多或磁盤(pán)上文件過(guò)多。

merge有三種形式：內(nèi)存到內(nèi)存；內(nèi)存到磁盤(pán)；磁盤(pán)到磁盤(pán)。默認(rèn)情況下第一種形式不啟用。當(dāng)內(nèi)存中的數(shù)據(jù)量到達(dá)一定閾值，就直接啟動(dòng)內(nèi)存到磁盤(pán)的merge。與map端類(lèi)似，這也是溢寫(xiě)的過(guò)程，這個(gè)過(guò)程中如果你設(shè)置有Combiner，也是會(huì)啟用的，然后在磁盤(pán)中生成了眾多的溢寫(xiě)文件。內(nèi)存到磁盤(pán)的merge方式一直在運(yùn)行，直到?jīng)]有map端的數(shù)據(jù)時(shí)才結(jié)束，然后啟動(dòng)第三種磁盤(pán)到磁盤(pán)的merge方式生成最終的文件。

合并排序：把分散的數(shù)據(jù)合并成一個(gè)大的數(shù)據(jù)后，還會(huì)再對(duì)合并后的數(shù)據(jù)排序。

對(duì)排序后的鍵值對(duì)調(diào)用reduce方法：鍵相等的鍵值對(duì)調(diào)用一次reduce方法，每次調(diào)用會(huì)產(chǎn)生零個(gè)或者多個(gè)鍵值對(duì)，最后把這些輸出的鍵值對(duì)寫(xiě)入到HDFS文件中。

大數(shù)據(jù)技術(shù)面試大綱范文第十九篇七、Memcached客戶(hù)端程序Memcached的java客戶(hù)端已經(jīng)存在三種了：?官方提供的基于傳統(tǒng)阻塞io由GregWhalin維護(hù)的客戶(hù)端?DustinSallings實(shí)現(xiàn)的基于javanio的Spymemcached?XMemcached1.三種API比較1)較早推出的memcachedJAVA客戶(hù)端API，應(yīng)用廣泛，運(yùn)行比較穩(wěn)定。2)spymemcachedAsimple,asynchronous,single-.支持異步，單線程的memcached客戶(hù)端，用到了版本的concurrent和nio，存取速度會(huì)高于前者，但是穩(wěn)定性不好，測(cè)試中常報(bào)timeOut等相關(guān)異常。3)xmemcachedXMemcached同樣是基于javanio的客戶(hù)端，javanio相比于傳統(tǒng)阻塞io模型來(lái)說(shuō)，有效率高（特別在高并發(fā)下）和資源耗費(fèi)相對(duì)較少的優(yōu)點(diǎn)。傳統(tǒng)阻塞IO為了提高效率，需要?jiǎng)?chuàng)建一定數(shù)量的連接形成連接池，而nio僅需要一個(gè)連接即可（當(dāng)然,nio也是可以做

大數(shù)據(jù)技術(shù)面試大綱范文第二十篇數(shù)據(jù)傾斜問(wèn)題主要有以下幾種：

空值引發(fā)的數(shù)據(jù)傾斜

不同數(shù)據(jù)類(lèi)型引發(fā)的數(shù)據(jù)傾斜

不可拆分大文件引發(fā)的數(shù)據(jù)傾斜

數(shù)據(jù)膨脹引發(fā)的數(shù)據(jù)傾斜

表連接時(shí)引發(fā)的數(shù)據(jù)傾斜

確實(shí)無(wú)法減少數(shù)據(jù)量引發(fā)的數(shù)據(jù)傾斜

以上傾斜問(wèn)題的具體解決方案可查看：Hive千億級(jí)數(shù)據(jù)傾斜解決方案

注意：對(duì)于leftjoin或者rightjoin來(lái)說(shuō)，不會(huì)對(duì)關(guān)聯(lián)的字段自動(dòng)去除null值，對(duì)于innerjoin來(lái)說(shuō)，會(huì)對(duì)關(guān)聯(lián)的字段自動(dòng)去除null值。

小伙伴們?cè)陂喿x時(shí)注意下，在上面的文章（Hive千億級(jí)數(shù)據(jù)傾斜解決方案）中，有一處sql出現(xiàn)了上述問(wèn)題（舉例的時(shí)候原本是想使用leftjoin的，結(jié)果手誤寫(xiě)成了join）。此問(wèn)題由公眾號(hào)讀者發(fā)現(xiàn)，感謝這位讀者指正。

大數(shù)據(jù)技術(shù)面試大綱范文第二十一篇YARN的基本設(shè)計(jì)思想是將MapReduceV1中的JobTracker拆分為兩個(gè)獨(dú)立的服務(wù)：ResourceManager和ApplicationMaster。

ResourceManager負(fù)責(zé)整個(gè)系統(tǒng)的資源管理和分配，ApplicationMaster負(fù)責(zé)單個(gè)應(yīng)用程序的的管理。

調(diào)度器根據(jù)容量、隊(duì)列等限制條件，將系統(tǒng)中的資源分配給正在運(yùn)行的應(yīng)用程序，在保證容量、公平性和服務(wù)等級(jí)的前提下，優(yōu)化集群資源利用率，讓所有的資源都被充分利用應(yīng)用程序管理器負(fù)責(zé)管理整個(gè)系統(tǒng)中的所有的應(yīng)用程序，包括應(yīng)用程序的提交、與調(diào)度器協(xié)商資源以啟動(dòng)ApplicationMaster、監(jiān)控ApplicationMaster運(yùn)行狀態(tài)并在失敗時(shí)重啟它。

ApplicationMaster：用戶(hù)提交的一個(gè)應(yīng)用程序會(huì)對(duì)應(yīng)于一個(gè)ApplicationMaster，它的主要功能有：

與RM調(diào)度器協(xié)商以獲得資源，資源以Container表示。

將得到的任務(wù)進(jìn)一步分配給內(nèi)部的任務(wù)。

與NM通信以啟動(dòng)/停止任務(wù)。

監(jiān)控所有的內(nèi)部任務(wù)狀態(tài)，并在任務(wù)運(yùn)行失敗的時(shí)候重新為任務(wù)申請(qǐng)資源以重啟任務(wù)。

NodeManager：NodeManager是每個(gè)節(jié)點(diǎn)上的資源和任務(wù)管理器，一方面，它會(huì)定期地向RM匯報(bào)本節(jié)點(diǎn)上的資源使用情況和各個(gè)Container的運(yùn)行狀態(tài)；另一方面，他接收并處理來(lái)自AM的Container啟動(dòng)和停止請(qǐng)求。

Container：Container是YARN中的資源抽象，封裝了各種資源。一個(gè)應(yīng)用程序會(huì)分配一個(gè)Container，這個(gè)應(yīng)用程序只能使用這個(gè)Container中描述的資源。不同于MapReduceV1中槽位slot的資源封裝，Container是一個(gè)動(dòng)態(tài)資源的劃分單位，更能充分利用資源。

大數(shù)據(jù)技術(shù)面試大綱范文第二十二篇在hbase中每當(dāng)有memstore數(shù)據(jù)flush到磁盤(pán)之后，就形成一個(gè)storefile，當(dāng)storeFile的數(shù)量達(dá)到一定程度后，就需要將storefile文件來(lái)進(jìn)行compaction操作。

Compact的作用：

合并文件

清除過(guò)期，多余版本的數(shù)據(jù)

提高讀寫(xiě)數(shù)據(jù)的效率4HBase中實(shí)現(xiàn)了兩種compaction的方式：minorandmajor.這兩種compaction方式的區(qū)別是：

Minor操作只用來(lái)做部分文件的合并操作以及包括minVersion=0并且設(shè)置ttl的過(guò)期版本清理，不做任何刪除數(shù)據(jù)、多版本數(shù)據(jù)的清理工作。

Major操作是對(duì)Region下的HStore下的所有StoreFile執(zhí)行合并操作，最終的結(jié)果是整理合并出一個(gè)文件。

大數(shù)據(jù)技術(shù)面試大綱范文第二十三篇采集層主要可以使用Flume,Kafka等技術(shù)。

Flume：Flume是管道流方式，提供了很多的默認(rèn)實(shí)現(xiàn)，讓用戶(hù)通過(guò)參數(shù)部署，及擴(kuò)展API.

Kafka：Kafka是一個(gè)可持久化的分布式的消息隊(duì)列。Kafka是一個(gè)非常通用的系統(tǒng)。你可以有許多生產(chǎn)者和很多的消費(fèi)者共享多個(gè)主題Topics。

相比之下,Flume是一個(gè)專(zhuān)用工具被設(shè)計(jì)為旨在往HDFS，HBase發(fā)送數(shù)據(jù)。它對(duì)HDFS有特殊的優(yōu)化，并且集成了Hadoop的安全特性。

所以，Cloudera建議如果數(shù)據(jù)被多個(gè)系統(tǒng)消費(fèi)的話，使用kafka；如果數(shù)據(jù)被設(shè)計(jì)給Hadoop使用，使用Flume。

大數(shù)據(jù)技術(shù)面試大綱范文第二十四篇我們學(xué)習(xí)了面向?qū)ο蟮囊恍├碚撝R(shí)，比如，面向?qū)ο笏拇筇匦浴⒔涌诤统橄箢?lèi)、面向?qū)ο蠛兔嫦蜻^(guò)程編程風(fēng)格、基于接口而非實(shí)現(xiàn)編程和多用組合少用繼承設(shè)計(jì)思想等等。接下來(lái)，我們?cè)儆盟墓?jié)課的時(shí)間，通過(guò)兩個(gè)更加貼近實(shí)戰(zhàn)的項(xiàng)目來(lái)進(jìn)一步學(xué)習(xí)，如何將這些理論應(yīng)用到實(shí)際的軟件開(kāi)發(fā)中。據(jù)我了解，大部分工程師都是做業(yè)務(wù)開(kāi)發(fā)的，所以，今天我們講的這個(gè)實(shí)戰(zhàn)項(xiàng)目也是一個(gè)典型的業(yè)務(wù)系統(tǒng)開(kāi)發(fā)案例。我們都知道，很多業(yè)務(wù)系統(tǒng)都是基于MVC三層架構(gòu)來(lái)開(kāi)發(fā)的。實(shí)際上，更確切點(diǎn)講，這是一種基于貧血模型的MVC三層架構(gòu)開(kāi)發(fā)模式。雖然這種開(kāi)發(fā)模式已經(jīng)成為標(biāo)準(zhǔn)的Web項(xiàng)目的開(kāi)發(fā)模式，但它卻違反了面向?qū)ο缶幊田L(fēng)格，是一種徹徹底底的面向過(guò)程的編程風(fēng)格，因此而被有些人稱(chēng)為反模式（antipattern）。特別是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DomainDrivenDesign，簡(jiǎn)稱(chēng)DDD）盛行之后，這種基于貧血模型的傳統(tǒng)的開(kāi)發(fā)模式就更加被人詬病。而基于充血模型的DDD開(kāi)發(fā)模式越來(lái)越被人提倡。所以，我打算用兩節(jié)課的時(shí)間，結(jié)合一個(gè)虛擬錢(qián)包系統(tǒng)的開(kāi)發(fā)案例，帶你徹底弄清楚這兩種開(kāi)發(fā)模式?？紤]到你有可能不太了解我剛剛提到的這幾個(gè)概念，所以，在正式進(jìn)入實(shí)戰(zhàn)項(xiàng)目的講解之前，

大數(shù)據(jù)技術(shù)面試大綱范文第二十五篇可以這樣說(shuō)：

flume那邊采用的channel是將數(shù)據(jù)落地到磁盤(pán)中，保證數(shù)據(jù)源端安全性（可以在補(bǔ)充一下，flume在這里的channel可以設(shè)置為memory內(nèi)存中，提高數(shù)據(jù)接收處理的效率，但是由于數(shù)據(jù)在內(nèi)存中，安全機(jī)制保證不了，故選擇channel為磁盤(pán)存儲(chǔ)。整個(gè)流程運(yùn)行有一點(diǎn)的延遲性）

sparkStreaming通過(guò)拉模式整合的時(shí)候，使用了FlumeUtils這樣一個(gè)類(lèi)，該類(lèi)是需要依賴(lài)一個(gè)額外的jar包（）

要想保證數(shù)據(jù)不丟失，數(shù)據(jù)的準(zhǔn)確性，可以在構(gòu)建StreamingConext的時(shí)候，利用（checkpoint,creatingFunc:()=>StreamingContext）來(lái)創(chuàng)建一個(gè)StreamingContext,使用來(lái)創(chuàng)建StreamingContext對(duì)象，傳入的第一個(gè)參數(shù)是checkpoint的存放目錄，第二參數(shù)是生成StreamingContext對(duì)象的用戶(hù)自定義函數(shù)。如果checkpoint的存放目錄存在，則從這個(gè)目錄中生成StreamingContext對(duì)象；如果不存在，才會(huì)調(diào)用第二個(gè)函數(shù)來(lái)生成新的StreamingContext對(duì)象。在creatingFunc函數(shù)中，除了生成一個(gè)新的StreamingContext操作，還需要完成各種操作，然后調(diào)用(checkpointDirectory)來(lái)初始化checkpoint功能，最后再返回StreamingContext對(duì)象。

這樣，在之后，就可以直接調(diào)用start()函數(shù)來(lái)啟動(dòng)（或者是從中斷點(diǎn)繼續(xù)運(yùn)行）流式應(yīng)用了。如果有其他在啟動(dòng)或繼續(xù)運(yùn)行都要做的工作，可以在start()調(diào)用前執(zhí)行。

大數(shù)據(jù)技術(shù)面試大綱范文第二十六篇十種常見(jiàn)排序算法可以分為兩大類(lèi)：

比較類(lèi)排序：通過(guò)比較來(lái)決定元素間的相對(duì)次序，由于其時(shí)間復(fù)雜度不能突破O(nlogn)，因此也稱(chēng)為非線性時(shí)間比較類(lèi)排序。

非比較類(lèi)排序：不通過(guò)比較來(lái)決定元素間的相對(duì)次序，它可以突破基于比較排序的時(shí)間下界，以線性時(shí)間運(yùn)行，因此也稱(chēng)為線性時(shí)間非比較類(lèi)排序。

算法復(fù)雜度：

相關(guān)概念：

穩(wěn)定：如果a原本在b前面，而a=b，排序之后a仍然在b的前面。

不穩(wěn)定：如果a原本在b的前面，而a=b，排序之后a可能會(huì)出現(xiàn)在b的后面。

時(shí)間復(fù)雜度：對(duì)排序數(shù)據(jù)的總的操作次數(shù)。反映當(dāng)n變化時(shí)，操作次數(shù)呈現(xiàn)什么規(guī)律。

空間復(fù)雜度：是指算法在計(jì)算機(jī)內(nèi)執(zhí)行時(shí)所需存儲(chǔ)空間的度量，它也是數(shù)據(jù)規(guī)模n的函數(shù)。

下面講解大數(shù)據(jù)中最常考的兩種：快排和歸并

大數(shù)據(jù)技術(shù)面試大綱范文第二十七篇機(jī)器人在家庭和工作中提供幫助的夢(mèng)想已成為當(dāng)今的現(xiàn)實(shí)。環(huán)顧四周，您可能會(huì)發(fā)現(xiàn)一個(gè)機(jī)器人！目前，機(jī)器人在世界各地發(fā)揮著作用-從打掃客廳，送貨上門(mén)到檢查高風(fēng)險(xiǎn)環(huán)境和在機(jī)場(chǎng)停車(chē)庫(kù)巡邏-等等。機(jī)器人技術(shù)已經(jīng)在提高家庭和工作場(chǎng)所的效率和安全性。隨著機(jī)器人變得更加自主并且能夠執(zhí)行越來(lái)越復(fù)雜的任務(wù)，這些好處將成倍增長(zhǎng)?！癗VIDIA致力于解決計(jì)算機(jī)可以解決的非常困難的挑戰(zhàn)。毫無(wú)疑問(wèn)，機(jī)器人技術(shù)是人工智能的最后前沿之一。它需要多種技術(shù)的融合?！盢VIDIA首席執(zhí)行官黃仁勛在2019年該公司位于西雅圖的機(jī)器人研究實(shí)驗(yàn)室開(kāi)幕時(shí)曾表示說(shuō)。VelodyneLidar正在與NVIDIA合作，將先進(jìn)的傳感器技術(shù)和開(kāi)發(fā)平臺(tái)引入自動(dòng)移動(dòng)機(jī)器人。兩者都是構(gòu)建可在受控情況下安全運(yùn)行的移動(dòng)機(jī)器人的關(guān)鍵組件。VelodyneLidar為自動(dòng)駕駛汽車(chē)，駕駛員輔助，交付解決方案，機(jī)器人技術(shù)，導(dǎo)航，地圖繪制等提供了智能，強(qiáng)大的激光雷達(dá)解決方案。Velodyne總部位于加利福尼亞州圣何塞，其突破性的激光雷達(dá)傳感器技術(shù)產(chǎn)品組合享譽(yù)全球。實(shí)際中的機(jī)器人應(yīng)用程序：NVIDIAJetsonEdgeAI平臺(tái)Velodyne和NVIDIA的能力使

大數(shù)據(jù)技術(shù)面試大綱范文第二十八篇Flink中的時(shí)間有三種類(lèi)型，如下圖所示：

EventTime：是事件創(chuàng)建的時(shí)間。它通常由事件中的時(shí)間戳描述，例如采集的日志數(shù)據(jù)中，每一條日志都會(huì)記錄自己的生成時(shí)間，F(xiàn)link通過(guò)時(shí)間戳分配器訪問(wèn)事件時(shí)間戳。

IngestionTime：是數(shù)據(jù)進(jìn)入Flink的時(shí)間。

ProcessingTime：是每一個(gè)執(zhí)行基于時(shí)間操作的算子的本地系統(tǒng)時(shí)間，與機(jī)器相關(guān)，默認(rèn)的時(shí)間屬性就是ProcessingTime。

例如，一條日志進(jìn)入Flink的時(shí)間為2021-01-2210:00:，到達(dá)Window的系統(tǒng)時(shí)間為2021-01-2210:00:，日志的內(nèi)容如下：2021-01-0618:37:INFOFailovertorm2

對(duì)于業(yè)務(wù)來(lái)說(shuō)，要統(tǒng)計(jì)1min內(nèi)的故障日志個(gè)數(shù)，哪個(gè)時(shí)間是最有意義的？——eventTime，因?yàn)槲覀円鶕?jù)日志的生成時(shí)間進(jìn)行統(tǒng)計(jì)。

大數(shù)據(jù)技術(shù)面試大綱范文第二十九篇一.介紹很多模塊當(dāng)前不用，在編譯安裝的時(shí)候沒(méi)有編譯進(jìn)去。php支持將模塊單獨(dú)添加進(jìn)去，不用重新編譯了。php可以將源碼包中的模塊單獨(dú)編譯，然后將編譯完的模塊在中指定，重啟即可加載。當(dāng)前模擬添加curl模塊二.操作1.移動(dòng)到源碼包中的ext文件中cd/root/tar/這個(gè)文件夾下每個(gè)模塊都有一個(gè)文件夾，現(xiàn)在移動(dòng)到curl模塊文件夾中cdcurl2.執(zhí)行phpize，如果有多個(gè)版本，要執(zhí)行對(duì)應(yīng)版本/usr/local/php/bin/phpize結(jié)果類(lèi)似：Configuringfor:PHPApiVersion:20151012ZendModuleApiNo:20151012ZendExtensionApiNo:320151012復(fù)制如果提示有如下報(bào)錯(cuò)，安裝m4和autoconfyum-yinstallm4autoconf3.編譯這個(gè)模塊./configure--with-php-config=/usr/local/php/bin/php-config``make&&makeinstall結(jié)果類(lèi)似：Installings

大數(shù)據(jù)技術(shù)面試大綱范文第三十篇Client寫(xiě)入->存入MemStore，一直到MemStore滿(mǎn)->Flush成一個(gè)StoreFile，直至增長(zhǎng)到一定閾值->觸發(fā)Compact合并操作->多個(gè)StoreFile合并成一個(gè)StoreFile，同時(shí)進(jìn)行版本合并和數(shù)據(jù)刪除->當(dāng)StoreFilesCompact后，逐步形成越來(lái)越大的StoreFile->單個(gè)StoreFile大小超過(guò)一定閾值后（默認(rèn)10G），觸發(fā)Split操作，把當(dāng)前RegionSplit成2個(gè)Region，Region會(huì)下線，新Split出的2個(gè)孩子Region會(huì)被HMaster分配到相應(yīng)的HRegionServer上，使得原先1個(gè)Region的壓力得以分流到2個(gè)Region上

由此過(guò)程可知，HBase只是增加數(shù)據(jù)，沒(méi)有更新和刪除操作，用戶(hù)的更新和刪除都是邏輯層面的，在物理層面，更新只是追加操作，刪除只是標(biāo)記操作。

用戶(hù)寫(xiě)操作只需要進(jìn)入到內(nèi)存即可立即返回，從而保證I/O高性能。

大數(shù)據(jù)技術(shù)面試大綱范文第三十一篇什么叫透明壓縮呢？OkHttp在發(fā)送請(qǐng)求的時(shí)候，會(huì)自動(dòng)加入gzip請(qǐng)求頭Accept-Encoding:gzip。所以，當(dāng)返回的數(shù)據(jù)帶有g(shù)zip響應(yīng)頭時(shí)Content-Encoding=gzip，OkHttp會(huì)自動(dòng)幫我們解壓數(shù)據(jù)。（Accept-Encoding和Content-Encoding是一對(duì)請(qǐng)求頭，分別對(duì)應(yīng)著請(qǐng)求和返回）為什么要進(jìn)行壓縮呢？因?yàn)樗艽蠓鶞p少傳輸?shù)娜萘俊Ｏ褚恍〤PU資源占用不高的服務(wù)，比如Kafka，我們就可以開(kāi)啟gzip壓縮，加快信息的流轉(zhuǎn)。這個(gè)壓縮比有多高呢？可以看下下面實(shí)實(shí)在在的截圖，對(duì)于普通的xml或者json，數(shù)據(jù)可以由9MB壓縮到350KB左右，壓縮比足足達(dá)到了26。它讓系統(tǒng)性能飛起來(lái)SpringCloud微服務(wù)體系，現(xiàn)在有非常多的公司在用。即使是一些傳統(tǒng)企業(yè)，一些大數(shù)據(jù)量的toB企業(yè)，也想嘗一嘗螃蟹。對(duì)于一個(gè)簡(jiǎn)單的SpringBoot服務(wù)，我們只需要在yml文件中配置上相應(yīng)的壓縮就可以了。這樣，我們就打通了瀏覽器到Web服務(wù)的這一環(huán)。這種壓縮方式，對(duì)于大數(shù)據(jù)量的服務(wù)來(lái)說(shuō)，是救命式的！具體配置如下。server:port:8082compress

大數(shù)據(jù)技術(shù)面試大綱范文第三十二篇首先一點(diǎn)需要明白：Hbase是基于HDFS來(lái)存儲(chǔ)的。

HDFS：

一次性寫(xiě)入，多次讀取。

保證數(shù)據(jù)的一致性。

主要是可以部署在許多廉價(jià)機(jī)器中，通過(guò)多副本提高可靠性，提供了容錯(cuò)和恢復(fù)機(jī)制。

HBase：

瞬間寫(xiě)入量很大，數(shù)據(jù)庫(kù)不好支撐或需要很高成本支撐的場(chǎng)景。

數(shù)據(jù)需要長(zhǎng)久保存，且量會(huì)持久增長(zhǎng)到比較大的場(chǎng)景。

HBase不適用與有join，多級(jí)索引，表關(guān)系復(fù)雜的數(shù)據(jù)模型。

大數(shù)據(jù)量（100sTB級(jí)數(shù)據(jù)）且有快速隨機(jī)訪問(wèn)的需求。如：淘寶的交易歷史記錄。數(shù)據(jù)量巨大無(wú)容置疑，面向普通用戶(hù)的請(qǐng)求必然要即時(shí)響應(yīng)。

業(yè)務(wù)場(chǎng)景簡(jiǎn)單，不需要關(guān)系數(shù)據(jù)庫(kù)中很多特性（例如交叉列、交叉表，事務(wù)，連接等等）。

大數(shù)據(jù)技術(shù)面試大綱范文第三十三篇在Kafka中，生產(chǎn)者寫(xiě)入消息、消費(fèi)者讀取消息的操作都是與leader副本進(jìn)行交互的，從而實(shí)現(xiàn)的是一種主寫(xiě)主讀的生產(chǎn)消費(fèi)模型。Kafka并不支持主寫(xiě)從讀，因?yàn)橹鲗?xiě)從讀有2個(gè)很明顯的缺點(diǎn):

數(shù)據(jù)一致性問(wèn)題：數(shù)據(jù)從主節(jié)點(diǎn)轉(zhuǎn)到從節(jié)點(diǎn)必然會(huì)有一個(gè)延時(shí)的時(shí)間窗口，這個(gè)時(shí)間窗口會(huì)導(dǎo)致主從節(jié)點(diǎn)之間的數(shù)據(jù)不一致。某一時(shí)刻，在主節(jié)點(diǎn)和從節(jié)點(diǎn)中A數(shù)據(jù)的值都為X，之后將主節(jié)點(diǎn)中A的值修改為Y，那么在這個(gè)變更通知到從節(jié)點(diǎn)之前，應(yīng)用讀取從節(jié)點(diǎn)中的A數(shù)據(jù)的值并不為最新的Y，由此便產(chǎn)生了數(shù)據(jù)不一致的問(wèn)題。

而kafka的主寫(xiě)主讀的優(yōu)點(diǎn)就很多了：

大數(shù)據(jù)技術(shù)面試大綱范文第三十四篇這個(gè)問(wèn)題雖然見(jiàn)過(guò)無(wú)數(shù)次，面試官問(wèn)過(guò)無(wú)數(shù)次，還是有不少面試者不能完整的說(shuō)出來(lái)，所以請(qǐng)務(wù)必記住。并且很多問(wèn)題都是從HDFS讀寫(xiě)流程中引申出來(lái)的。

HDFS寫(xiě)流程：

Client客戶(hù)端發(fā)送上傳請(qǐng)求，通過(guò)RPC與NameNode建立通信，NameNode檢查該用戶(hù)是否有上傳權(quán)限，以及上傳的文件是否在HDFS對(duì)應(yīng)的目錄下重名，如果這兩者有任意一個(gè)不滿(mǎn)足，則直接報(bào)錯(cuò)，如果兩者都滿(mǎn)足，則返回給客戶(hù)端一個(gè)可以上傳的信息；

Client根據(jù)文件的大小進(jìn)行切分，默認(rèn)128M一塊，切分完成之后給NameNode發(fā)送請(qǐng)求第一個(gè)block塊上傳到哪些服務(wù)器上；

注：Hadoop在設(shè)計(jì)時(shí)考慮到數(shù)據(jù)的安全與高效,數(shù)據(jù)文件默認(rèn)在HDFS上存放三份,存儲(chǔ)策略為本地一份，同機(jī)架內(nèi)其它某一節(jié)點(diǎn)上一份,不同機(jī)架的某一節(jié)點(diǎn)上一份。

客戶(hù)端收到地址之后與服務(wù)器地址列表中的一個(gè)節(jié)點(diǎn)如A進(jìn)行通信，本質(zhì)上就是RPC調(diào)用，建立pipeline，A收到請(qǐng)求后會(huì)繼續(xù)調(diào)用B，B在調(diào)用C，將整個(gè)pipeline建立完成，逐級(jí)返回Client；

Client開(kāi)始向A上發(fā)送第一個(gè)block（先從磁盤(pán)讀取數(shù)據(jù)然后放到本地內(nèi)存緩存），以packet（數(shù)據(jù)包，64kb）為單位，A收到一個(gè)packet就會(huì)發(fā)送給B，然后B發(fā)送給C，A每傳完一個(gè)packet就會(huì)放入一個(gè)應(yīng)答隊(duì)列等待應(yīng)答；

數(shù)據(jù)被分割成一個(gè)個(gè)的packet數(shù)據(jù)包在pipeline上依次傳輸，在pipeline反向傳輸中，逐個(gè)發(fā)送ack（命令正確應(yīng)答），最終由pipeline中第一個(gè)DataNode節(jié)點(diǎn)A將pipelineack發(fā)送給Client；

當(dāng)一個(gè)block傳輸完成之后,Client再次請(qǐng)求NameNode上傳第二個(gè)block，NameNode重新選擇三臺(tái)DataNode給Client。

HDFS讀流程：

Client向NameNode發(fā)送RPC請(qǐng)求。請(qǐng)求文件block的位置；

大數(shù)據(jù)技術(shù)面試大綱范文第三十五篇假設(shè)NameNode1當(dāng)前為Active狀態(tài)，NameNode2當(dāng)前為Standby狀態(tài)。如果某一時(shí)刻N(yùn)ameNode1對(duì)應(yīng)的ZKFailoverController進(jìn)程發(fā)生了“假死”現(xiàn)象，那么Zookeeper服務(wù)端會(huì)認(rèn)為NameNode1掛掉了，根據(jù)前面的主備切換邏輯，NameNode2會(huì)替代NameNode1進(jìn)入Active狀態(tài)。但是此時(shí)NameNode1可能仍然處于Active狀態(tài)正常運(yùn)行，這樣NameNode1和NameNode2都處于Active狀態(tài)，都可以對(duì)外提供服務(wù)。這種情況稱(chēng)為腦裂。

腦裂對(duì)于NameNode這類(lèi)對(duì)數(shù)據(jù)一致性要求非常高的系統(tǒng)來(lái)說(shuō)是災(zāi)難性的，數(shù)據(jù)會(huì)發(fā)生錯(cuò)亂且無(wú)法恢復(fù)。zookeeper社區(qū)對(duì)這種問(wèn)題的解決方法叫做fencing，中文翻譯為隔離，也就是想辦法把舊的ActiveNameNode隔離起來(lái)，使它不能正常對(duì)外提供服務(wù)。

在進(jìn)行fencing的時(shí)候，會(huì)執(zhí)行以下的操作：

首先嘗試調(diào)用這個(gè)舊ActiveNameNode的HAServiceProtocolRPC接口的transitionToStandby方法，看能不能把它轉(zhuǎn)換為Standby狀態(tài)。

如果transitionToStandby方法調(diào)用失敗，那么就執(zhí)行Hadoop配置文件之中預(yù)定義的隔離措施，Hadoop目前主要提供兩種隔離措施，通常會(huì)選擇sshfence：

大數(shù)據(jù)技術(shù)面試大綱范文第三十六篇輸入數(shù)據(jù)有很多task，尤其是有很多小文件的時(shí)候，有多少個(gè)輸入block就會(huì)有多少個(gè)task啟動(dòng)；

spark中有partition的概念，每個(gè)partition都會(huì)對(duì)應(yīng)一個(gè)task，task越多，在處理大規(guī)模數(shù)據(jù)的時(shí)候，就會(huì)越有效率。不過(guò)task并不是越多越好，如果平時(shí)測(cè)試，或者數(shù)據(jù)量沒(méi)有那么大，則沒(méi)有必要task數(shù)量太多。

參數(shù)可以通過(guò)spark_home/conf/配置文件設(shè)置:

針對(duì)sparksql的task數(shù)量：

非sparksql程序設(shè)置生效：

大數(shù)據(jù)技術(shù)面試大綱范文第三十七篇這個(gè)問(wèn)題如果深挖還挺復(fù)雜的，這里簡(jiǎn)單介紹下總體流程：

parser：基于antlr框架對(duì)sql解析，生成抽象語(yǔ)法樹(shù)。

變量替換：通過(guò)正則表達(dá)式找出符合規(guī)則的字符串，替換成系統(tǒng)緩存環(huán)境的變量

SQLConf中的，默認(rèn)是可用的；參考SparkSqlParser

parser：將antlr的tree轉(zhuǎn)成sparkcatalyst的LogicPlan，也就是未解析的邏輯計(jì)劃；詳細(xì)參考AstBuild,ParseDriver

analyzer：通過(guò)分析器，結(jié)合catalog，把logicalplan和實(shí)際的數(shù)據(jù)綁定起來(lái)，將未解析的邏輯計(jì)劃生成邏輯計(jì)劃；詳細(xì)參考QureyExecution

緩存替換：通過(guò)CacheManager，替換有相同結(jié)果的logicalplan（邏輯計(jì)劃）

logicalplan優(yōu)化，基于規(guī)則的優(yōu)化；優(yōu)化規(guī)則參考Optimizer，優(yōu)化執(zhí)行器RuleExecutor

生成sparkplan，也就是物理計(jì)劃；參考QueryPlanner和SparkStrategies

sparkplan準(zhǔn)備階段

構(gòu)造RDD執(zhí)行，涉及spark的wholeStageCodegenExec機(jī)制，基于janino框架生成java代碼并編譯

大數(shù)據(jù)技術(shù)面試大綱范文第三十八篇MR：抽象層次低，需要使用手工代碼來(lái)完成程序編寫(xiě)，使用上難以上手；

Spark：Spark采用RDD計(jì)算模型，簡(jiǎn)單容易上手。

MR：只提供map和reduce兩個(gè)操作，表達(dá)能力欠缺；

Spark：Spark采用更加豐富的算子模型，包括map、flatmap、groupbykey、reducebykey等；

MR：一個(gè)job只能包含map和reduce兩個(gè)階段，復(fù)雜的任務(wù)需要包含很多個(gè)job，這些job之間的管理以來(lái)需要開(kāi)發(fā)者自己進(jìn)行管理；

Spark：Spark中一個(gè)job可以包含多個(gè)轉(zhuǎn)換操作，在調(diào)度時(shí)可以生成多個(gè)stage，而且如果多個(gè)map操作的分區(qū)不變，是可以放在同一個(gè)task里面去執(zhí)行；

MR：中間結(jié)果存放在hdfs中；

Spark：Spark的中間結(jié)果一般存在內(nèi)存中，只有當(dāng)內(nèi)存不夠了，才會(huì)存入本地磁盤(pán)，而不是hdfs；

MR：只有等到所有的maptask執(zhí)行完畢后才能執(zhí)行reducetask；

Spark：Spark中分區(qū)相同的轉(zhuǎn)換構(gòu)成流水線在一個(gè)task中執(zhí)行，分區(qū)不同的需要進(jìn)行shuffle操作，被劃分成不同的stage需要等待前面的stage執(zhí)行完才能執(zhí)行。

MR：只適合batch批處理，時(shí)延高，對(duì)于交互式處理和實(shí)時(shí)處理支持不夠；

Spark：Sparkstreaming可以將流拆成時(shí)間間隔的batch進(jìn)行處理，實(shí)時(shí)計(jì)算。

大數(shù)據(jù)技術(shù)面試大綱范文第三十九篇1.架構(gòu)模型

SparkStreaming在運(yùn)行時(shí)的主要角色包括：Master、Worker、Driver、Executor，F(xiàn)link在運(yùn)行時(shí)主要包含：Jobmanager、Taskmanager和Slot。

2.任務(wù)調(diào)度

SparkStreaming連續(xù)不斷的生成微小的數(shù)據(jù)批次，構(gòu)建有向無(wú)環(huán)圖DAG，SparkStreaming會(huì)依次創(chuàng)建DStreamGraph、JobGenerator、JobScheduler。

Flink根據(jù)用戶(hù)提交的代碼生成StreamGraph，經(jīng)過(guò)優(yōu)化生成JobGraph，然后提交給JobManager進(jìn)行處理，JobManager會(huì)根據(jù)JobGraph生成ExecutionGraph，ExecutionGraph是Flink調(diào)度最核心的數(shù)據(jù)結(jié)構(gòu)，JobManager根據(jù)ExecutionGraph對(duì)Job進(jìn)行調(diào)度。

3.時(shí)間機(jī)制

SparkStreaming支持的時(shí)間機(jī)制有限，只支持處理時(shí)間。Flink支持了流處理程序在時(shí)間上的三個(gè)定義：處理時(shí)間、事件時(shí)間、注入時(shí)間。同時(shí)也支持watermark機(jī)制來(lái)處理滯后數(shù)據(jù)。

4.容錯(cuò)機(jī)制

對(duì)于SparkStreaming任務(wù)，我們可以設(shè)置checkpoint，然后假如發(fā)生故障并重啟，我們可以從上次checkpoint之處恢復(fù)，但是這個(gè)行為只能使得數(shù)據(jù)不丟失，可能會(huì)重復(fù)處理，不能做到恰一次處理語(yǔ)義。

Flink則使用兩階段提交協(xié)議來(lái)解決這個(gè)問(wèn)題。

大數(shù)據(jù)技術(shù)面試大綱范文第四十篇Hadoop底層使用MapReduce計(jì)算架構(gòu)，只有map和reduce兩種操作，表達(dá)能力比較欠缺，而且在MR過(guò)程中會(huì)重復(fù)的讀寫(xiě)hdfs，造成大量的磁盤(pán)io讀寫(xiě)操作，所以適合高時(shí)延環(huán)境下批處理計(jì)算的應(yīng)用；

Spark是基于內(nèi)存的分布式計(jì)算架構(gòu)，提供更加豐富的數(shù)據(jù)集操作類(lèi)型，主要分成轉(zhuǎn)化操作和行動(dòng)操作，包括map、reduce、filter、flatmap、groupbykey、reducebykey、union和join等，數(shù)據(jù)分析更加快速，所以適合低時(shí)延環(huán)境下計(jì)算的應(yīng)用；

spark與hadoop最大的區(qū)別在于迭代式計(jì)算模型?；趍apreduce框架的Hadoop主要分為map和reduce兩個(gè)階段，兩個(gè)階段完了就結(jié)束了，所以在一個(gè)job里面能做的處理很有限；spark計(jì)算模型是基于內(nèi)存的迭代式計(jì)算模型，可以分為n個(gè)階段，根據(jù)用戶(hù)編寫(xiě)的RDD算子和程序，在處理完一個(gè)階段后可以繼續(xù)往下處理很多個(gè)階段，而不只是兩個(gè)階段。所以spark相較于mapreduce，計(jì)算模型更加靈活，可以提供更強(qiáng)大的功能。

但是spark也有劣勢(shì)，由于spark基于內(nèi)存進(jìn)行計(jì)算，雖然開(kāi)發(fā)容易，但是真正面對(duì)大數(shù)據(jù)的時(shí)候，在沒(méi)有進(jìn)行調(diào)優(yōu)的情況下，可能會(huì)出現(xiàn)各種各樣的問(wèn)題，比如OOM內(nèi)存溢出等情況，導(dǎo)致spark程序可能無(wú)法運(yùn)行起來(lái)，而mapreduce雖然運(yùn)行緩慢，但是至少可以慢慢運(yùn)行完。

大數(shù)據(jù)技術(shù)面試大綱范文第四十一篇

構(gòu)建抽象語(yǔ)法樹(shù)的事情交給了Calcite去做。SQLquery會(huì)經(jīng)過(guò)Calcite解析器轉(zhuǎn)變成SQL節(jié)點(diǎn)樹(shù)，通過(guò)驗(yàn)證后構(gòu)建成Calcite的抽象語(yǔ)法樹(shù)（也就是圖中的LogicalPlan）。另一邊，TableAPI上的調(diào)用會(huì)構(gòu)建成TableAPI的抽象語(yǔ)法樹(shù)，并通過(guò)Calcite提供的RelBuilder轉(zhuǎn)變成Calcite的抽象語(yǔ)法樹(shù)。然后依次被轉(zhuǎn)換成邏輯執(zhí)行計(jì)劃和物理執(zhí)行計(jì)劃。

在提交任務(wù)后會(huì)分發(fā)到各個(gè)TaskManager中運(yùn)行，在運(yùn)行時(shí)會(huì)使用Janino編譯器編譯代碼后運(yùn)行。

大數(shù)據(jù)技術(shù)面試大綱范文第四十二篇導(dǎo)讀：XGBoost是一個(gè)高效、可擴(kuò)展的機(jī)器學(xué)習(xí)算法，用于回歸和分類(lèi)（），使得XGBoostGradientBoosting開(kāi)源包可用。Oracle20c數(shù)據(jù)庫(kù)中引入的一個(gè)新的機(jī)器學(xué)習(xí)算法叫做XGBoost。XGBoost是一個(gè)開(kāi)源軟件庫(kù)，它在大多數(shù)常用的數(shù)據(jù)科學(xué)、機(jī)器學(xué)習(xí)和軟件開(kāi)發(fā)語(yǔ)言中提供了一個(gè)梯度提升框架。該算法是在之前的決策樹(shù)、Bagging、隨機(jī)森林、Boosting和梯度提升等工作的基礎(chǔ)上發(fā)展而來(lái)。XGBoost是一個(gè)高效、可擴(kuò)展的機(jī)器學(xué)習(xí)算法，經(jīng)過(guò)多年的研究、開(kāi)發(fā)和驗(yàn)證，XGBoost可以用于分類(lèi)的典型用例，包括分類(lèi)、回歸和排名問(wèn)題（）。OML4SQLXGBoost（OracleMachineLearningforSQLXGBoost）是一個(gè)可擴(kuò)展的梯度樹(shù)提升系統(tǒng)，支持分類(lèi)和回歸。它提供了開(kāi)源的梯度提升框架。通過(guò)準(zhǔn)備訓(xùn)練數(shù)據(jù)，調(diào)用XGBoost，構(gòu)建和持久化模型，并應(yīng)用該模型進(jìn)行預(yù)測(cè)，使得XGBoostGradientBoosting開(kāi)源包在數(shù)據(jù)庫(kù)中可用。你可以

大數(shù)據(jù)技術(shù)面試大綱范文第四十三篇spark通過(guò)這個(gè)參數(shù)指定master元數(shù)據(jù)在zookeeper中保存的位置，包括Worker，Driver和Application以及Executors。standby節(jié)點(diǎn)要從zk中，獲得元數(shù)據(jù)信息，恢復(fù)集群運(yùn)行狀態(tài)，才能對(duì)外繼續(xù)提供服務(wù)，作業(yè)提交資源申請(qǐng)等，在恢復(fù)前是不能接受請(qǐng)求的。

注：Master切換需要注意2點(diǎn)：1、在Master切換的過(guò)程中，所有的已經(jīng)在運(yùn)行的程序皆正常運(yùn)行！因?yàn)镾parkApplication在運(yùn)行前就已經(jīng)通過(guò)ClusterManager獲得了計(jì)算資源，所以在運(yùn)行時(shí)Job本身的調(diào)度和處理和Master是沒(méi)有任何關(guān)系。2、在Master的切換過(guò)程中唯一的影響是不能提交新的Job：一方面不能夠提交新的應(yīng)用程序給集群，因?yàn)橹挥蠥ctiveMaster才能接受新的程序的提交請(qǐng)求；另外一方面，已經(jīng)運(yùn)行的程序中也不能夠因Action操作觸發(fā)新的Job的提交請(qǐng)求。

大數(shù)據(jù)技術(shù)面試大綱范文第四十四篇快速排序的基本思想：通過(guò)一趟排序?qū)⒋庞涗浄指舫瑟?dú)立的兩部分，其中一部分記錄的關(guān)鍵字均比另一部分的關(guān)鍵字小，則可分別對(duì)這兩部分記錄繼續(xù)進(jìn)行排序，以達(dá)到整個(gè)序列有序。

算法描述

快速排序使用分治法來(lái)把一個(gè)串（list）分為兩個(gè)子串（sub-lists）。具體算法描述如下：

從數(shù)列中挑出一個(gè)元素，稱(chēng)為“基準(zhǔn)”（pivot）；

重新排序數(shù)列，所有元素比基準(zhǔn)值小的擺放在基準(zhǔn)前面，所有元素比基準(zhǔn)值大的擺在基準(zhǔn)的后面（相同的數(shù)可以到任一邊）。在這個(gè)分區(qū)退出之后，該基準(zhǔn)就處于數(shù)列的中間位置。這個(gè)稱(chēng)為分區(qū)（partition）操作；

遞歸地（recursive）把小于基準(zhǔn)值元素的子數(shù)列和大于基準(zhǔn)值元素的子數(shù)列排序。

大數(shù)據(jù)技術(shù)面試大綱范文第四十五篇完整版教程下載地址：;tid=94547第3章

Matlab簡(jiǎn)易使用之基礎(chǔ)操作本期教程開(kāi)始講解Matlab的簡(jiǎn)易使用之基礎(chǔ)操作，作為學(xué)習(xí)DSP的必備軟件，掌握簡(jiǎn)單的Matlab操作是必須的。初學(xué)者重要提示界面說(shuō)明矩陣和陣列檢索矩陣中的數(shù)據(jù)工作區(qū)中的數(shù)據(jù)保存和加載字符串函數(shù)繪圖功能總結(jié)

初學(xué)者重要提示

本章主要介紹了matlab的基礎(chǔ)操作，如果之前沒(méi)有接觸過(guò)這方面的知識(shí)，務(wù)必要實(shí)際動(dòng)手操作。

Matlab界面說(shuō)明

當(dāng)前文件夾（Current

Folder）用于訪問(wèn)電腦中的文件。

命令窗口（CommandWindow）用于輸入命令，公式計(jì)算等也可以在這里進(jìn)行。

工作區(qū)（Workspace）瀏覽用戶(hù)創(chuàng)建的數(shù)據(jù)或者從文件中導(dǎo)入的數(shù)據(jù)。

命令歷史記錄（CommandHistory）記錄用戶(hù)在command窗口輸入的命令，雙擊這些歷史命令可以返回到

大數(shù)據(jù)技術(shù)面試大綱范文第四十六篇未被external修飾的是內(nèi)部表，被external修飾的為外部表。

區(qū)別：

內(nèi)部表數(shù)據(jù)由Hive自身管理，外部表數(shù)據(jù)由HDFS管理；

內(nèi)部表數(shù)據(jù)存儲(chǔ)的位置是（默認(rèn)：/user/hive/warehouse），外部表數(shù)據(jù)的存儲(chǔ)位置由自己制定（如果沒(méi)有LOCATION，Hive將在HDFS上的/user/hive/warehouse文件夾下以外部表的表名創(chuàng)建一個(gè)文件夾，并將屬于這個(gè)表的數(shù)據(jù)存放在這里）；

刪除內(nèi)部表會(huì)直接刪除元數(shù)據(jù)（metadata）及存儲(chǔ)數(shù)據(jù)；刪除外部表僅僅會(huì)刪除元數(shù)據(jù)，HDFS上的文件并不會(huì)被刪除。

大數(shù)據(jù)技術(shù)面試大綱范文第四十七篇SecondaryNameNode是合并NameNode的editlogs到fsimage文件中；

它的具體工作機(jī)制：

SecondaryNameNode詢(xún)問(wèn)NameNode是否需要checkpoint。直接帶回NameNode是否檢查結(jié)果；

SecondaryNameNode請(qǐng)求執(zhí)行checkpoint；

NameNode滾動(dòng)正在寫(xiě)的edits日志；

生成新的鏡像文件；

拷貝到NameNode；

NameNode將重新命名成fsimage；

所以如果NameNode中的元數(shù)據(jù)丟失，是可以從SecondaryNameNode恢復(fù)一部分元數(shù)據(jù)信息的，但不是全部，因?yàn)镹ameNode正在寫(xiě)的edits日志還沒(méi)有拷貝到SecondaryNameNode，這部分恢復(fù)不了。

大數(shù)據(jù)技術(shù)面試大綱范文第四十八篇Hbase中的每張表都通過(guò)行鍵(rowkey)按照一定的范圍被分割成多個(gè)子表（HRegion），默認(rèn)一個(gè)HRegion超過(guò)256M就要被分割成兩個(gè)，由HRegionServer管理，管理哪些HRegion由Hmaster分配。HRegion存取一個(gè)子表時(shí)，會(huì)創(chuàng)建一個(gè)HRegion對(duì)象，然后對(duì)表的每個(gè)列族（ColumnFamily）創(chuàng)建一個(gè)store實(shí)例，每個(gè)store都會(huì)有0個(gè)或多個(gè)StoreFile與之對(duì)應(yīng)，每個(gè)StoreFile都會(huì)對(duì)應(yīng)一個(gè)HFile，HFile就是實(shí)際的存儲(chǔ)文件，一個(gè)HRegion還擁有一個(gè)MemStore實(shí)例。

大數(shù)據(jù)技術(shù)面試大綱范文第四十九篇簡(jiǎn)單概述：

inputFile通過(guò)split被切割為多個(gè)split文件，通過(guò)Record按行讀取內(nèi)容給map（自己寫(xiě)的處理邏輯的方法），數(shù)據(jù)被map處理完之后交給OutputCollect收集器，對(duì)其結(jié)果key進(jìn)行分區(qū)（默認(rèn)使用的hashPartitioner），然后寫(xiě)入buffer，每個(gè)maptask都有一個(gè)內(nèi)存緩沖區(qū)（環(huán)形緩沖區(qū)），存放著map的輸出結(jié)果，當(dāng)緩沖區(qū)快滿(mǎn)的時(shí)候需要將緩沖區(qū)的數(shù)據(jù)以一個(gè)臨時(shí)文件的方式溢寫(xiě)到磁盤(pán)，當(dāng)整個(gè)maptask結(jié)束后再對(duì)磁盤(pán)中這個(gè)maptask產(chǎn)生的所有臨時(shí)文件做合并，生成最終的正式輸出文件，然后等待reducetask的拉取。

詳細(xì)步驟：

讀取數(shù)據(jù)組件InputFormat(默認(rèn)TextInputFormat)會(huì)通過(guò)getSplits方法對(duì)輸入目錄中的文件進(jìn)行邏輯切片規(guī)劃得到block，有多少個(gè)block就對(duì)應(yīng)啟動(dòng)多少個(gè)MapTask。

將輸入文件切分為block之后，由RecordReader對(duì)象(默認(rèn)是LineRecordReader)進(jìn)行讀取，以\n作為分隔符,讀取一行數(shù)據(jù),返回，Key表示每行首字符偏移值，Value表示這一行文本內(nèi)容。

讀取block返回,進(jìn)入用戶(hù)自己繼承的Mapper類(lèi)中，執(zhí)行用戶(hù)重寫(xiě)的map函數(shù)，RecordReader讀取一行這里調(diào)用一次。

Mapper邏輯結(jié)束之后，將Mapper的每條結(jié)果通過(guò)進(jìn)行collect數(shù)據(jù)收集。在collect中，會(huì)先對(duì)其進(jìn)行分區(qū)處理，默認(rèn)使用HashPartitioner。

接下來(lái)，會(huì)將數(shù)據(jù)寫(xiě)入內(nèi)存，內(nèi)存中這片區(qū)域叫做環(huán)形緩沖區(qū)(默認(rèn)100M)，緩沖區(qū)的作用是批量收集Mapper結(jié)果，減少磁盤(pán)IO的影響。我們的Key/Value對(duì)以及Partition的結(jié)果都會(huì)被寫(xiě)入緩沖區(qū)。當(dāng)然，寫(xiě)入之前，Key與Value值都會(huì)被序列化成字節(jié)數(shù)組。

當(dāng)環(huán)形緩沖區(qū)的數(shù)據(jù)達(dá)到溢寫(xiě)比列(默認(rèn))，也就是80M時(shí)，溢寫(xiě)線程啟動(dòng)，需要對(duì)這80MB空間內(nèi)的Key做排序(Sort)。排序是MapReduce模型默認(rèn)的行為，這里的排序也是對(duì)序列化的字節(jié)做的排序。

合并溢寫(xiě)文件，每次溢寫(xiě)會(huì)在磁盤(pán)上生成一個(gè)臨時(shí)文件(寫(xiě)之前判斷是否有Combiner)，如果Map