繼續(xù)?。。?！貓眼大數(shù)據(jù)Java String builder和String buffer區(qū)別？Java中的StringBuilder和StringBuffer都是可變的字符串類，它們之間的主要區(qū)別在于線程安全性和性能。線程安全性：StringBuilder是非線程安全的，也就是說(shuō)它的方法沒(méi)有被同步，不適用于多線程環(huán)境。StringBuffer是線程安全的，它的方法都被同步，適用于多線程環(huán)境。在多線程環(huán)境下，使用StringBuffer可以保證數(shù)據(jù)的一致性和正確性。性能：StringBuilder相對(duì)于StringBuffer具有更好的性能，因?yàn)镾tringBuilder的方法沒(méi)有被同步，不需要...

我是大數(shù)據(jù)歐老師，曾在互聯(lián)網(wǎng)某大廠任大數(shù)據(jù)負(fù)責(zé)人，從業(yè)大數(shù)據(jù)領(lǐng)域近 10 年，全網(wǎng)粉絲 5000+，從很多候選人的面試和咨詢中復(fù)盤了大數(shù)據(jù)工程師的面試全流程，如果你有求職大數(shù)據(jù)工程師的計(jì)劃，歡迎找我聊一聊！數(shù)據(jù)傾斜的解決方案解決方案五：將reduce join轉(zhuǎn)為map join方案適用場(chǎng)景：在對(duì)RDD使用join類操作，或者是在Spark SQL中使用join語(yǔ)句時(shí)，而且join操作中的一個(gè)RDD或表的數(shù)據(jù)量比較?。ū热鐜装費(fèi)或者一兩G），比較適用此方案。方案實(shí)現(xiàn)思路：不使用join算子進(jìn)行連接操作，而使用Broadcast變量與map類算子實(shí)現(xiàn)join操作，進(jìn)而完全規(guī)避掉shuffle類的...

?我是大數(shù)據(jù)歐老師，曾在互聯(lián)網(wǎng)某大廠任大數(shù)據(jù)負(fù)責(zé)人，從業(yè)大數(shù)據(jù)領(lǐng)域近 10 年，全網(wǎng)粉絲 5000+，從很多候選人的面試和咨詢中復(fù)盤了大數(shù)據(jù)工程師的面試全流程，如果你有求職大數(shù)據(jù)工程師的計(jì)劃，歡迎找我聊一聊！某個(gè)task莫名其妙內(nèi)存溢出的情況這種情況下去定位出問(wèn)題的代碼就比較容易了。我們建議直接看yarn-client模式下本地log的異常棧，或者是通過(guò)YARN查看yarn-cluster模式下的log中的異常棧。一般來(lái)說(shuō)，通過(guò)異常棧信息就可以定位到你的代碼中哪一行發(fā)生了內(nèi)存溢出。然后在那行代碼附近找找，一般也會(huì)有shuffle類算子，此時(shí)很可能就是這個(gè)算子導(dǎo)致了數(shù)據(jù)傾斜。但是大家要注意的是，...

1. Flink 的核心組件：JobManager 和 TaskManager在 Apache Flink 中，JobManager 和 TaskManager 是分布式執(zhí)行的核心組件，負(fù)責(zé)協(xié)調(diào)和執(zhí)行應(yīng)用程序。1.1 JobManagerJobManager 是 Flink 集群的大腦，它主要負(fù)責(zé)三個(gè)方面的工作：?作業(yè)調(diào)度： 接收用戶提交的作業(yè)，并將這些作業(yè)拆分成不同的任務(wù)。?資源管理： 與 Flink 的資源管理器（如 YARN 或 Mesos）協(xié)作，為作業(yè)分配必要的資源。?容錯(cuò)與狀態(tài)管理： 控制作業(yè)的執(zhí)行，包括容錯(cuò)機(jī)制。負(fù)責(zé)設(shè)置檢查點(diǎn)（checkpoints）來(lái)保存作業(yè)的狀態(tài)，以便在失敗時(shí)...

我是大數(shù)據(jù)歐老師，曾在互聯(lián)網(wǎng)某大廠任大數(shù)據(jù)負(fù)責(zé)人，從業(yè)大數(shù)據(jù)領(lǐng)域近 10 年，全網(wǎng)粉絲 5000+，從很多候選人的面試和咨詢中復(fù)盤了大數(shù)據(jù)工程師的面試全流程，如果你有求職大數(shù)據(jù)工程師的計(jì)劃，歡迎找我聊一聊！數(shù)據(jù)傾斜的解決方案解決方案八：參數(shù)調(diào)優(yōu)shuffle相關(guān)參數(shù)調(diào)優(yōu)以下是Shffule過(guò)程中的一些主要參數(shù)，這里詳細(xì)講解了各個(gè)參數(shù)的功能、默認(rèn)值以及基于實(shí)踐經(jīng)驗(yàn)給出的調(diào)優(yōu)建議。Spark 參數(shù)優(yōu)化詳解以下列舉了Spark參數(shù)調(diào)優(yōu)的一些關(guān)鍵參數(shù)及其優(yōu)化建議：1. spark.shuffle.file.buffer (默認(rèn)值：32k)該參數(shù)用于設(shè)置 shuffle write task 的 Buf...

原則一：避免創(chuàng)建重復(fù)的RDD通常來(lái)說(shuō)，我們?cè)陂_(kāi)發(fā)一個(gè)Spark作業(yè)時(shí)，首先是基于某個(gè)數(shù)據(jù)源（比如Hive表或HDFS文件）創(chuàng)建一個(gè)初始的RDD；接著對(duì)這個(gè)RDD執(zhí)行某個(gè)算子操作，然后得到下一個(gè)RDD；以此類推，循環(huán)往復(fù)，直到計(jì)算出最終我們需要的結(jié)果。在這個(gè)過(guò)程中，多個(gè)RDD會(huì)通過(guò)不同的算子操作（比如map、reduce等）串起來(lái)，這個(gè)“RDD串”，就是RDD lineage，也就是“RDD的血緣關(guān)系鏈”。我們?cè)陂_(kāi)發(fā)過(guò)程中要注意：對(duì)于同一份數(shù)據(jù)，只應(yīng)該創(chuàng)建一個(gè)RDD，不能創(chuàng)建多個(gè)RDD來(lái)代表同一份數(shù)據(jù)。一個(gè)簡(jiǎn)單的例子：錯(cuò)誤的做法： val rdd1 = sc.textFile("hdf...

調(diào)優(yōu)概述在開(kāi)發(fā)完Spark作業(yè)之后，就該為作業(yè)配置合適的資源了。Spark的資源參數(shù)，基本都可以在spark-submit命令中作為參數(shù)設(shè)置。很多Spark初學(xué)者，通常不知道該設(shè)置哪些必要的參數(shù)，以及如何設(shè)置這些參數(shù)，最后就只能胡亂設(shè)置，甚至壓根兒不設(shè)置。資源參數(shù)設(shè)置的不合理，可能會(huì)導(dǎo)致沒(méi)有充分利用集群資源，作業(yè)運(yùn)行會(huì)極其緩慢；或者設(shè)置的資源過(guò)大，隊(duì)列沒(méi)有足夠的資源來(lái)提供，進(jìn)而導(dǎo)致各種異常?？傊?，無(wú)論是哪種情況，都會(huì)導(dǎo)致Spark作業(yè)的運(yùn)行效率低下，甚至根本無(wú)法運(yùn)行。因此我們必須對(duì)Spark作業(yè)的資源使用原理有一個(gè)清晰的認(rèn)識(shí)，并知道在Spark作業(yè)運(yùn)行過(guò)程中，有哪些資源參數(shù)是可以設(shè)置的，以及如...

CMS 垃圾收集器是什么？CMS（Concurrent Mark-Sweep，即并發(fā)標(biāo)記清掃）是一種用于Java的垃圾收集技術(shù)，主要處理堆內(nèi)存中老年代的垃圾回收。CMS垃圾收集器的主要特性1.并發(fā)性：CMS收集器的目標(biāo)是避免凍結(jié)所有的應(yīng)用線程，也就是"Stop-The-World"的操作。為了實(shí)現(xiàn)這一目標(biāo)，CMS在標(biāo)記和清除階段的大部分時(shí)間與應(yīng)用線程并發(fā)運(yùn)行。2.四階段工作過(guò)程：CMS收集器的工作流程包括以下四個(gè)階段：?初始標(biāo)記（Initial Mark)：這個(gè)階段需要暫停所有的應(yīng)用線程，以標(biāo)記所有從GC Roots開(kāi)始即能直接關(guān)聯(lián)到的對(duì)象。?并發(fā)標(biāo)記（Concurrent...

#大數(shù)據(jù)知識(shí)體系# 挺好的,繼續(xù)加油https://www.sqlboy.tech/

調(diào)優(yōu)概述有的時(shí)候，我們可能會(huì)遇到大數(shù)據(jù)計(jì)算中一個(gè)最棘手的問(wèn)題——數(shù)據(jù)傾斜，此時(shí)Spark作業(yè)的性能會(huì)比期望差很多。數(shù)據(jù)傾斜調(diào)優(yōu)，就是使用各種技術(shù)方案解決不同類型的數(shù)據(jù)傾斜問(wèn)題，以保證Spark作業(yè)的性能。數(shù)據(jù)傾斜發(fā)生時(shí)的現(xiàn)象絕大多數(shù)task執(zhí)行得都非?？欤珎€(gè)別task執(zhí)行極慢。比如，總共有1000個(gè)task，997個(gè)task都在1分鐘之內(nèi)執(zhí)行完了，但是剩余兩三個(gè)task卻要一兩個(gè)小時(shí)。這種情況很常見(jiàn)。原本能夠正常執(zhí)行的Spark作業(yè)，某天突然報(bào)出OOM（內(nèi)存溢出）異常，觀察異常棧，是我們寫的業(yè)務(wù)代碼造成的。這種情況比較少見(jiàn)。數(shù)據(jù)傾斜發(fā)生的原理數(shù)據(jù)傾斜的原理很簡(jiǎn)單：在進(jìn)行shuffle的時(shí)候，...

原則六：使用高性能的算子除了shuffle相關(guān)的算子有優(yōu)化原則之外，其他的算子也都有著相應(yīng)的優(yōu)化原則。使用reduceByKey/aggregateByKey替代groupByKey:詳情見(jiàn)“原則五：使用map-side預(yù)聚合的shuffle操作”。使用mapPartitions替代普通map:mapPartitions類的算子，一次函數(shù)調(diào)用會(huì)處理一個(gè)partition所有的數(shù)據(jù)，而不是一次函數(shù)調(diào)用處理一條，性能相對(duì)來(lái)說(shuō)會(huì)高一些。但是有的時(shí)候，使用mapPartitions會(huì)出現(xiàn)OOM（內(nèi)存溢出）的問(wèn)題。因?yàn)閱未魏瘮?shù)調(diào)用就要處理掉一個(gè)partition所有的數(shù)據(jù)，如果內(nèi)存不夠，垃圾回收時(shí)是無(wú)法...

原則四：盡量避免使用shuffle類算子如果有可能的話，要盡量避免使用shuffle類算子。因?yàn)镾park作業(yè)運(yùn)行過(guò)程中，最消耗性能的地方就是shuffle過(guò)程。shuffle過(guò)程，簡(jiǎn)單來(lái)說(shuō)，就是將分布在集群中多個(gè)節(jié)點(diǎn)上的同一個(gè)key，拉取到同一個(gè)節(jié)點(diǎn)上，進(jìn)行聚合或join等操作。比如reduceByKey、join等算子，都會(huì)觸發(fā)shuffle操作。shuffle過(guò)程中，各個(gè)節(jié)點(diǎn)上的相同key都會(huì)先寫入本地磁盤文件中，然后其他節(jié)點(diǎn)需要通過(guò)網(wǎng)絡(luò)傳輸拉取各個(gè)節(jié)點(diǎn)上的磁盤文件中的相同key。而且相同key都拉取到同一個(gè)節(jié)點(diǎn)進(jìn)行聚合操作時(shí)，還有可能會(huì)因?yàn)橐粋€(gè)節(jié)點(diǎn)上處理的key過(guò)多，導(dǎo)致內(nèi)存不夠存放，...

原則三：對(duì)多次使用的RDD進(jìn)行持久化當(dāng)你在Spark代碼中多次對(duì)一個(gè)RDD做了算子操作后，恭喜，你已經(jīng)實(shí)現(xiàn)Spark作業(yè)第一步的優(yōu)化了，也就是盡可能復(fù)用RDD。此時(shí)就該在這個(gè)基礎(chǔ)之上，進(jìn)行第二步優(yōu)化了，也就是要保證對(duì)一個(gè)RDD執(zhí)行多次算子操作時(shí)，這個(gè)RDD本身僅僅被計(jì)算一次。Spark中對(duì)于一個(gè)RDD執(zhí)行多次算子的默認(rèn)原理是這樣的：每次你對(duì)一個(gè)RDD執(zhí)行一個(gè)算子操作時(shí)，都會(huì)重新從源頭處計(jì)算一遍，計(jì)算出那個(gè)RDD來(lái)，然后再對(duì)這個(gè)RDD執(zhí)行你的算子操作。這種方式的性能是很差的。因此對(duì)于這種情況，我們的建議是：對(duì)多次使用的RDD進(jìn)行持久化。此時(shí)Spark就會(huì)根據(jù)你的持久化策略，將RDD中的數(shù)據(jù)保存到...

1. Flink時(shí)間語(yǔ)義的理解Flink提供了三種時(shí)間語(yǔ)義，以滿足不同計(jì)算場(chǎng)景的需求：處理時(shí)間，事件時(shí)間和注入時(shí)間。?處理時(shí)間(Processing Time)：一種直觀的時(shí)間語(yǔ)義，表示數(shù)據(jù)進(jìn)入算子并開(kāi)始處理的實(shí)際時(shí)間點(diǎn)。?事件時(shí)間(Event Time)：表示事件實(shí)際發(fā)生的時(shí)間，通常在消息的時(shí)間戳字段中找到。由于可能會(huì)有數(shù)據(jù)亂序的問(wèn)題，但它能保證精確度高的計(jì)算場(chǎng)景。?注入時(shí)間(Ingestion Time)：介于處理時(shí)間和事件時(shí)間之間的折中選擇，代表數(shù)據(jù)進(jìn)入Flink處理系統(tǒng)的時(shí)間。這方面的細(xì)節(jié)問(wèn)題較少被詢問(wèn)。2. 理解時(shí)間語(yǔ)義的應(yīng)用場(chǎng)景和優(yōu)勢(shì)每種時(shí)間語(yǔ)義都有其獨(dú)特的使用場(chǎng)景和優(yōu)勢(shì)。?處理時(shí)...

1. 數(shù)據(jù)處理模型：流處理、批處理和微批處理我們首先來(lái)認(rèn)識(shí)一些基本的數(shù)據(jù)處理模型。在大數(shù)據(jù)世界中，你會(huì)遇到流處理、批處理和微批處理這三種模型。流處理是一種實(shí)時(shí)的數(shù)據(jù)處理方式，數(shù)據(jù)一生成就立即被處理，無(wú)需等待。其連續(xù)且高效的特性使得它適用于需要實(shí)時(shí)分析結(jié)果的場(chǎng)景，例如實(shí)時(shí)股票市場(chǎng)分析或網(wǎng)絡(luò)監(jiān)控。流處理的代表有 Apache Flink 和 Apache Storm。相比之下，批處理增加了一個(gè)數(shù)據(jù)積累階段，僅在數(shù)據(jù)達(dá)到一定量時(shí)才進(jìn)行處理。這種模式適用于不需要實(shí)時(shí)響應(yīng)的場(chǎng)景，比如零售業(yè)的日銷售數(shù)據(jù)分析。Hadoop MapReduce 則在批處理領(lǐng)域卓有成效。最后，微批處理作為一種折衷策略，介于流處...

在處理流數(shù)據(jù)時(shí)，窗口運(yùn)算是一項(xiàng)關(guān)鍵技能。特別是在Flink這種實(shí)時(shí)計(jì)算平臺(tái)上，理解和合理使用窗口運(yùn)算對(duì)于數(shù)據(jù)處理的效率和精準(zhǔn)度至關(guān)重要。1. Flink窗口運(yùn)算的理解Flink提供了豐富的窗口運(yùn)算支持，包括滾動(dòng)窗口、滑動(dòng)窗口、會(huì)話窗口等多種窗口類型，適應(yīng)各種各樣的需求場(chǎng)景。?滾動(dòng)窗口(Tumbling Windows)：窗口之間沒(méi)有重疊和間隙，通常用于固定時(shí)間間隔的數(shù)據(jù)統(tǒng)計(jì)和分析。?滑動(dòng)窗口(Sliding Windows)：窗口之間有重疊，某個(gè)數(shù)據(jù)可能屬于多個(gè)窗口，適用于需要連續(xù)觀測(cè)變化的場(chǎng)景。?會(huì)話窗口(Session Windows)：窗口之間有間隙，針對(duì)的是數(shù)據(jù)的活動(dòng)會(huì)話或者事件，適用...