不要告訴別人（fast工程的意義）fast工程有戰(zhàn)略意義嗎，F(xiàn)AST 2022 有哪些值得關(guān)注的論文？，零點(diǎn)書屋，
0這篇論文是databricks公司首次將內(nèi)部的基于c++的native執(zhí)行引擎細(xì)節(jié)發(fā)表在SIGMOD 2022，作者公共23人，論文地址：https://www-cs.stanford.edu/~matei/papers/2022/sigmod_photon.pdf
?www-cs.stanford.edu/~matei/papers/2022/sigmod_photon.pdf本文不是對(duì)論文的翻譯，而是將論文中詳細(xì)的設(shè)計(jì)和細(xì)節(jié)拿出來(lái)記錄簡(jiǎn)介：論文首先闡述了lakehouse的作用。
首先，企業(yè)會(huì)將大量數(shù)據(jù)存儲(chǔ)在彈性、可擴(kuò)展的data lake上比如amazon s3、azure data lamapinfo破解版ke storage，google cloud storage等，這些數(shù)據(jù)可能是以apache parquet
、orc、delta lake等open file format存儲(chǔ)的raw、uncurated datasets，客戶/用戶可以通過(guò)presto，spark等計(jì)算引擎訪問(wèn)，工作負(fù)載包括BI，ml等其次，為了獲取更高的性能、
數(shù)據(jù)治理，企業(yè)會(huì)通過(guò)ETL把部分?jǐn)?shù)據(jù)從data lake上傳輸?shù)絛ata warehouse（比如apache hive)中，實(shí)際這是一個(gè)兩層的存儲(chǔ)架構(gòu)，這樣帶來(lái)的成本顯而易見(jiàn)所以，出現(xiàn)了所以lakehouse（databrick的產(chǎn)品就是Delta Lake）基于mapinfo破解版。
對(duì)象存儲(chǔ)構(gòu)建了data warehouse的能力，比如統(tǒng)一的數(shù)據(jù)訪問(wèn)、數(shù)據(jù)治理、SQL支持等，這樣的單層架構(gòu)對(duì)于用戶訪問(wèn)數(shù)據(jù)非常友好為了更好的查詢performance，delta lake做了不少的優(yōu)化，比如transactions和time travel，data clustering和data skipping indeices等。
但是僅僅在存儲(chǔ)層努力是不夠的，還需要在query engine 這層努力，這就是本論文要闡述的photonPhoton主要的挑戰(zhàn)：1）與傳統(tǒng)的data warehouse上的執(zhí)行引擎不同，photon需要解決新問(wèn)題，就是raw、uncurated data，mapinfo破解版其特性是：可能存在是highly irregular datasets，poor physical layout，large fields，no useful clustering or data statistics，string來(lái)代表date或者int，
數(shù)據(jù)缺失值不一定用NULL填充而是默認(rèn)值等等這個(gè)其實(shí)就是在機(jī)器學(xué)習(xí)、深度學(xué)習(xí)的場(chǎng)景，樣本數(shù)據(jù)就是上面提到的raw uncurated data，比如展現(xiàn)字段通常比較大，點(diǎn)擊數(shù)據(jù)也比較稀疏，feature log dump。
的數(shù)據(jù)也比較大等等對(duì)比之前的非常規(guī)整的交易數(shù)據(jù)，DL場(chǎng)景的數(shù)據(jù)會(huì)更加不規(guī)則和缺少統(tǒng)計(jì)信息，因此對(duì)于計(jì)算引擎并不友好為了解mapinfo破解版決這個(gè)問(wèn)題，photon是使用vectorized-interpreted model。
，而不是code generation（spark基于code generation） 所謂vectorized-interpreted，就是x100（論文放在文末，這也是clickhouse的框架執(zhí)行模型，在表達(dá)式這塊ck可以使用llvm來(lái)進(jìn)行code generation加速執(zhí)行）的執(zhí)行模型，內(nèi)存列存格式和。
批處理，這樣可以很方便利用CPU SIMD等指令，減少單次處理數(shù)據(jù)帶來(lái)的IO overhead，減少虛函數(shù)調(diào)用次數(shù)等額外開銷等等有諸多好處2）希望支持已有的spark，并且語(yǔ)義兼容，表現(xiàn)在SQL兼容mapinfo破解版和dataframe API兼容，也就是說(shuō)對(duì)于上層用戶來(lái)講是透明的。
這點(diǎn)是為了留住客戶，如果說(shuō)這套引擎不兼容spark api和sql，那么可想而知，客戶反饋肯定是非常差的所以為了解決這個(gè)問(wèn)題，photon是整合到了spark框架中的，與已有的spark api和sql完全兼容。
大體來(lái)說(shuō)，Databricks有一個(gè)從apache spark fork的一個(gè)databricks runtime（DBR)，加入了更多的優(yōu)化和改進(jìn)photon從算子層面重寫然后fit into DBR，作為query plan的執(zhí)行者，這樣即使有部分算子photon不支持可以fall back to DBR。
從這點(diǎn)來(lái)mapinfo破解版說(shuō)，photon只是在算子級(jí)別實(shí)現(xiàn)了vectorized query engine，外層的DBR依然是已有的架構(gòu)，DBR實(shí)現(xiàn)了query optimization，memory manager，IO，monitoring，photon需要與這些組件交互。
這點(diǎn)當(dāng)然也限制了photon的發(fā)揮，因?yàn)閟park是row-based處理數(shù)據(jù)，那么中間必然有row到column的相互轉(zhuǎn)換，而且內(nèi)存管理部分也需要與JVM交互， 增加了實(shí)現(xiàn)復(fù)雜度3）性能更好，spark基于JVM，集群負(fù)載是cpu bounding，因此轉(zhuǎn)向c++實(shí)現(xiàn)。
這毫無(wú)疑問(wèn)，隨著硬件發(fā)展目前計(jì)算引擎已經(jīng)從早期的io bounding轉(zhuǎn)向mapinfo破解版了cpu bounding，我們的集群也是如此，因此如果重構(gòu)必然要基于c++重寫，另外一個(gè)例證是presto也在基于c++做native query engine。
現(xiàn)在的趨勢(shì)就是基于c++或者rust構(gòu)建native的執(zhí)行引擎，未來(lái)jvm的執(zhí)行引擎可能會(huì)逐漸淡出歷史舞臺(tái)完成其歷史使命，在大數(shù)據(jù)早期因?yàn)槭芟抻诖疟P或者網(wǎng)絡(luò)，整個(gè)系統(tǒng)的瓶頸往往在IO，因此jvm構(gòu)建是合適的，可以更快的構(gòu)建出產(chǎn)品比如
hadoop spark presto等目前網(wǎng)絡(luò)普遍在20Gbps甚至50G/100G，RDMA技術(shù)，磁盤也從早期的HDD發(fā)展到SSD，傲騰等帶寬更大、延遲更低，加上軟件上的異步預(yù)取、cache、并行計(jì)算mapinfo破解版。
等技術(shù)，IO瓶頸已經(jīng)基本消除CPU重新成為瓶頸另外一方面，c++、rust、llvm等語(yǔ)言和工具鏈更加成熟，所以，在大數(shù)據(jù)領(lǐng)域出現(xiàn)類似impala、clickhouse、datafusion等native的執(zhí)行引擎，未來(lái)會(huì)逐步擴(kuò)大其。
scope，成為更加高效的解決方案總體來(lái)說(shuō)，photon是基于c++實(shí)現(xiàn)的vectorized query engine，語(yǔ)義和內(nèi)存管理兼容spark，并且在raw, uncurated data上做了大量?jī)?yōu)化。
背景databricks的lakehouse整體架構(gòu)總體上存算分離，分為4個(gè)部分，1· raw data storage，允許用戶選擇獨(dú)立的low comapinfo破解版st storage，比如S3，ADLS，GCS，主要是防止客戶data lock-in和昂貴的遷移成本，databricks提供各種connector來(lái)訪問(wèn)不同的底層存儲(chǔ)，數(shù)據(jù)本身的格式也可能有多種，比如parquet，
orc等等2.automatic data management,這層就是Delta Lake，基于云對(duì)象存儲(chǔ)實(shí)現(xiàn)了數(shù)倉(cāng)的特性，ACID，time travel，audit logging，fast metadata over tabular datasets，DetaLake的data 和。
metadata 都是基于parquet格式存儲(chǔ)，實(shí)現(xiàn)了auto data clusmapinfo破解版tering，cacheing等3.彈性執(zhí)行層，下圖展示了執(zhí)行層架構(gòu)，這層邏輯上實(shí)現(xiàn)了“數(shù)據(jù)面”，所有的數(shù)據(jù)處理都在這層完成，包括internal query，比如auto data-clustering metadata access，還有客戶的queries，比如ETL，SQL，ML等。
每天大概有EB的數(shù)據(jù)被處理，可以看出databricks的客戶挺多的，這層需要彈性、可靠性高、性能好Photon就是通過(guò)處理單線層的query執(zhí)行on each partition of data遷入到執(zhí)行層中。
執(zhí)行層是跑在云廠商提供的VM上，這個(gè)就是spark的典型架構(gòu)了，包括driver，負(fù)責(zé)協(xié)調(diào)，若干mapinfo破解版executor負(fù)責(zé)read and process data，driver和executor組成了DBR。
Lakehouse整體架構(gòu)4.UI層，不解釋The Databricks Runtime（DBR）DBR是在開源的apache spark上進(jìn)行了改進(jìn)和優(yōu)化，photon是DBR的lowest level，處理single thread task with in the context of DBRs 。
multi-threaded shared-nothing execution model.下面是簡(jiǎn)單的DBR任務(wù)提交過(guò)程，跟spark一樣，簡(jiǎn)單重復(fù)下提交到DBR的應(yīng)用被稱為jobs，mapinfo破解版每個(gè)job按照寬依賴被分層stages，stage被換分層tasks，每個(gè)task對(duì)應(yīng)數(shù)據(jù)的一個(gè)分區(qū)partition。
stages之間blocking，串行執(zhí)行，下游stage讀取上有的數(shù)據(jù)輸出，按照stage進(jìn)行容錯(cuò)或者自適應(yīng)執(zhí)行（spark3里的AQE）DBR用單節(jié)點(diǎn)的driver進(jìn)行調(diào)度，query planning，以及其他中央化的工作，driver管理1到多個(gè)executor node，每個(gè)node運(yùn)行多個(gè)task，每個(gè)。
task進(jìn)行數(shù)據(jù)讀取、變化、輸出SQL query也是使用DBR這套架構(gòu)，driver負(fù)責(zé)對(duì)SQL文本或者使用dataframe API生成的dataframe mapinfo破解版object轉(zhuǎn)換成query planQuery plan就是tree of SQL operators(比如filter, project, shuffle) that maps to a lists of stages.在query planning之后，driver就提交task執(zhí)行各個(gè)stages，每個(gè)task運(yùn)行in-memory execution engine來(lái)處理數(shù)據(jù)集。
Photon就是類似的執(zhí)行引擎Phonton的設(shè)計(jì)要點(diǎn)總體上，photon是用c++實(shí)現(xiàn)的一個(gè)列式、批處理也就是vectorized query engine，以shared lib遷入到DBR，run as mapinfo破解版part of single-threaded task in DBR within an executors JVM process. 類似DBR，photon也是把SQL用tree of operator來(lái)表示，每個(gè)op實(shí)現(xiàn)HasNext()/GetNext()接口，從每個(gè)child
pull data，這個(gè)api也用來(lái)跟JVM上的operator通信每個(gè)op內(nèi)部使用列式、向量化（也就是批）來(lái)處理數(shù)據(jù)，這個(gè)與JVM的op以code generation的模式、row based是有差別的，因此在photon與。
JVM算子的邊界上需要做數(shù)據(jù)格式的轉(zhuǎn)換下面詳細(xì)展開JVM vs Native exmapinfo破解版ecution這個(gè)就簡(jiǎn)單說(shuō)下上面已經(jīng)說(shuō)了不少，論文里也提到了目前集群都是cpu bounding，原因1是ssd cache，2是。
delta lake有很多IO優(yōu)化，比如data clustering，3是新的工作負(fù)載數(shù)據(jù)本身是un-normalized，large strings，unstructured nested data，因此更看中性能。
所有這些帶來(lái)的后果是JVM base execution engine成為瓶頸JVM大內(nèi)存GC->off heap op->code難維護(hù)，java code generation受限于generated method size, or code mapinfo破解版cache size，有可能fall back到far slower的volcano-style interpreted code path。
因此選擇native實(shí)現(xiàn)，這點(diǎn)也可以理解，clickhouse已經(jīng)在這塊做的非常成功了，apache doris也發(fā)布了vectorized execution engine2. interpreted vectorization vs code-gen。
這里的主要問(wèn)題是計(jì)算框架采用向量化還是code gen？前者代表論文是monetdb/x100，后者代表論文是hyper前者的實(shí)現(xiàn)代表是clickhouse，monetdb，后者是spark sql，hmapinfo破解版yper，impala等。
前者優(yōu)點(diǎn)是，可以利用批處理以弱化虛函數(shù)調(diào)用開銷、SIMD指令、CPU pipeline和內(nèi)存友好后者是在volcano style基礎(chǔ)上完全消除了虛擬函數(shù)開銷最終photon選擇前者，他們基于weld作code-generation，做了POC驗(yàn)證，得出的結(jié)論是：。
易于開發(fā)和scale，可觀測(cè)性更強(qiáng)，易于適應(yīng)changing data，specialization is still possible具體就不展開了，可以去看論文這兩種方法其實(shí)是可以結(jié)合的，在clickhouse的blog中就有過(guò)闡述，也有一篇論文說(shuō)這個(gè)事情，框架采用vectorization，具體到表達(dá)mapinfo破解版式計(jì)算可以采用code-gen，這樣性能是最高的。
3. row vs column-oriented executionphonton中采用了列存內(nèi)存模型，而不是spark的行存模型，主要理由是列存方便使用SIMD指令處理、更高效的pipelining、
序列化（傳輸or spill），數(shù)據(jù)源本身也是列存模型，比如parquet等，維護(hù)內(nèi)存字典優(yōu)化內(nèi)存等4.partial roll out這個(gè)要解決的點(diǎn)是如何在不影響已有workload的情況下透明上線，因?yàn)閐atabricks上面跑了很多客戶的sql或者是dataframe api的代碼。
photon需要做到的是如果部分算子還沒(méi)有實(shí)現(xiàn)，那么需要mapinfo破解版能fallback到老的代碼，不影響query的執(zhí)行，接下來(lái)的重點(diǎn)是如何與jvm base的DBR整合以實(shí)現(xiàn)這個(gè)目標(biāo)，具體設(shè)計(jì)在下面Vectorized Execution in Photon
首先看下batched columnar data layout，典型的布局，如下圖，
注意這里除了按照列去存儲(chǔ)連續(xù)數(shù)據(jù)外，還增加了position list列，用來(lái)指示active rows（not filtered，也就是有效數(shù)據(jù)）另外一種設(shè)計(jì)是設(shè)計(jì)一個(gè)bitmap來(lái)指示，但是論文說(shuō)這種情況在某些場(chǎng)景下會(huì)導(dǎo)致整體性能下降。
Vectorized Execution Kernels這就是計(jì)算圖的實(shí)現(xiàn)，圖的節(jié)mapinfo破解版點(diǎn)是operator，數(shù)據(jù)在圖中流動(dòng)，TensorFlow也是類似的設(shè)計(jì)，x100首先提出該思想，op的處理粒度是vector of data，也就是向量化的數(shù)據(jù)，下面有個(gè)
kernel的實(shí)現(xiàn)感受下，
注意參數(shù)里的RESTRICT關(guān)鍵字，這意思是參數(shù)指針地址都不同，因此編譯器可以做更多優(yōu)化，在clickhouse里大概提升了平均20%的性能Filters和conditonals的實(shí)現(xiàn)是通過(guò)修改position list of a column batch。
Vectorized hash table，這里實(shí)現(xiàn)了vectorized access，查詢氛圍3步，1是基于batch數(shù)據(jù)算hash，2是一mapinfo破解版個(gè)probe kernel跟進(jìn)hash value load pointer（指向value，注意這里的value是行存），3是跟左表的比，這里也是向量化操作的。
所以3步都是可以做向量化操作引入SIMD，性能很高自適應(yīng)執(zhí)行 Adaptive execution在lakehouse中的一大挑戰(zhàn)就是缺少統(tǒng)計(jì)信息，元信息，以及normalization，因此在此類數(shù)據(jù)集上的高效執(zhí)行是個(gè)挑戰(zhàn)。
Phonton的解決方法是支持batch level adaptivity，也就是說(shuō)在batch size data的小數(shù)據(jù)上實(shí)現(xiàn)數(shù)據(jù)統(tǒng)計(jì)，元信息構(gòu)建以此來(lái)優(yōu)化kernel執(zhí)行內(nèi)存管理，photon實(shí)現(xiàn)
內(nèi)存池，這mapinfo破解版里是基操了，對(duì)于定長(zhǎng)數(shù)據(jù)做了most-recentaly-used cache，變長(zhǎng)數(shù)據(jù)獨(dú)立處理，這里主要思想是跟進(jìn)數(shù)據(jù)大小、模式分級(jí)精細(xì)化管理而且要與spark框架集成下面重點(diǎn)討論如何與DBR集成。
Integration with DBR Photon必須要與DBR進(jìn)行集成，這里主要討論的是query planner and memory management首先討論對(duì)spark sql的支持，這里做的事就是convert spark plans to photon plans，具體做法是在catalyst里面加入轉(zhuǎn)換規(guī)則，規(guī)則處理如下：1是walk the input plan bottomapinfo破解版m up，然后map spark的node到Photon node。
如果一個(gè)node在photon中不支持的話就插入一個(gè)transition node負(fù)責(zé)將列批數(shù)據(jù)轉(zhuǎn)換成row-wise format這個(gè)legacy系統(tǒng)是在DBR里執(zhí)行的，需要注意的是要避免過(guò)多的此類轉(zhuǎn)換，否則代價(jià)太高了。
2是在file scan和first photon node間插入一個(gè)adaptor node用來(lái)將文件讀取的數(shù)據(jù)轉(zhuǎn)成列存數(shù)據(jù)，這里用了zero copy技術(shù)，因?yàn)閜arquet本身也是列存的下圖是個(gè)例子：。
Executing Phonton Plans在做完query planning后，DBR會(huì)啟動(dòng)tasmapinfo破解版ks按照stages執(zhí)行plan，photon執(zhí)行結(jié)點(diǎn)首先將photon part 到一個(gè)PB消息中，通過(guò)JNI傳輸?shù)絧hoton c++ lib，后者反序列化PB消息并執(zhí)行，執(zhí)行的過(guò)程跟JVM的過(guò)程類似，每個(gè)算子實(shí)現(xiàn)HasNext()/GetNext()接口，父節(jié)點(diǎn)以列批pull data from 子節(jié)點(diǎn)。
對(duì)于plan中有data exchange的點(diǎn)，photon會(huì)按照spark shuffle格式寫一份數(shù)據(jù)，并把metadata傳遞給sparkspark框架執(zhí)行shuffle，然后啟動(dòng)新的photon task來(lái)讀數(shù)據(jù)，這里注意的是數(shù)據(jù)序列化和。
反序列化一致性Adapter node mapinfo破解版to read scan dataphoton的leaf node總是adapter node，這個(gè)node拿到spark的scan node獲取的列存數(shù)據(jù)（因?yàn)閿?shù)據(jù)源是列存的格式比如parquet），adapter node的GetNext()函數(shù)就是調(diào)用JNI從spark的OffheapColumnVecto中拿數(shù)據(jù)，這里傳遞了2個(gè)pointer，1是列存數(shù)據(jù)，2是NULL數(shù)組，每次JNI的調(diào)用代價(jià)大概是c++。
虛擬函數(shù)調(diào)用代價(jià)23ns per call這樣也就實(shí)現(xiàn)了上文提到的數(shù)據(jù)讀取做到zero copyTransition node to pass photon data to spamapinfo破解版rkphoton的last node是transition node，必須將列批數(shù)據(jù)轉(zhuǎn)成row-wise格式供spark算子后續(xù)處理。
注意的是這里的轉(zhuǎn)換是成本很大的，所以不能做太多，photon后續(xù)還會(huì)持續(xù)改進(jìn)這里Unified Memory Management因?yàn)閜hoton是以share lib方式遷入到JVM進(jìn)程中，因此必須要hooks into
apache spark的內(nèi)存管理為了解決這個(gè)問(wèn)題，photon團(tuán)隊(duì)將memory reservation和memory allocation分開處理memory reservation是向spark unified memory managemapinfo破解版ment要求內(nèi)存，這個(gè)操作可能引發(fā)spill，也就是spark會(huì)向memory consumer釋放內(nèi)存以滿足新的要求，這個(gè)動(dòng)作會(huì)導(dǎo)致。
data spillphoton也是在這套體系中的，也就是說(shuō)可能引發(fā)self spill在photon內(nèi)部也是依據(jù)已有的策略來(lái)確定哪個(gè)memory consumer spill，思路是比如要reserve N bytes，按照consumer的memory size從小到大排序，最后選擇第一個(gè)大于N bytes的consumer來(lái)。
spill，原因是盡量減少consumer的spill次數(shù)，從而提升整體性能一旦photon reserve內(nèi)存成功，就可以成功進(jìn)mapinfo破解版行內(nèi)存的開辟無(wú)需spill所以在photon spilling operator比如hash join，group by等，對(duì)于輸入數(shù)據(jù)的處理分為2個(gè)階段，第一階段是內(nèi)存的reservation，第二階段是allocation階段，這樣再第二階段不會(huì)發(fā)生spill，這樣就保證了當(dāng)前op的高效處理，photon團(tuán)隊(duì)也強(qiáng)調(diào)這樣的策略很關(guān)鍵，因?yàn)樵赾ontext中數(shù)據(jù)量經(jīng)常很大如果說(shuō)在處理當(dāng)前op經(jīng)常會(huì)發(fā)生spill的話，整個(gè)流程就又卡磁盤IO了，并不能發(fā)揮出向量化執(zhí)行引擎優(yōu)勢(shì)。
Managing On-heap vs Off-heap memoryspark有個(gè)靜態(tài)的max offheap sizemapinfo破解版的配置用來(lái)限制每個(gè)節(jié)點(diǎn)可以分配的堆外內(nèi)存，photon主要使用堆外內(nèi)存，因此不會(huì)被GC影響，但是有個(gè)場(chǎng)景是broadcast（比如broadcast hash join），photon還是需要依賴框架的broadcast機(jī)制，這樣需要photon堆外內(nèi)存copy到堆內(nèi)存，這里可能引發(fā)OOM，photon做法是增加1個(gè)listener在query執(zhí)行結(jié)束后清理部分自身的state來(lái)釋放內(nèi)存。
與其他部分的融合與兼容性最后討論下photon與DBR和開源的spark結(jié)合問(wèn)題因?yàn)閜hoton只是對(duì)plan部分進(jìn)行了改變，所以spark框架上做的很多事情依然可以復(fù)用，比如AQE，還有就是photon的mmapinfo破解版etrics也與已有的兼容，可觀測(cè)性比較好 。
在語(yǔ)義兼容方面，為了做到與spark和DBR完全兼容，photon使用unit tests，end to end tests，fuzz tests來(lái)綜合保證效果評(píng)估得益于：列存格式、向量化、SIMD指令。
、runtime adaptivity，photon的主要加速場(chǎng)景是cpu heavy的，比如，join，aggregation，expression evaluation，另外還可以加速其他場(chǎng)景比如寫parquet文件，對(duì)于network io 或者disk io bounding場(chǎng)景加速其實(shí)不明顯。
下圖是各種測(cè)試，
注意photon目前只支持shmapinfo破解版uffle hash join，不支持sort merge joinspark的shuffle hash join也是不支持spill的，因?yàn)閟pill會(huì)帶來(lái)大量隨機(jī)IO，所以spark會(huì)用sort merge join來(lái)應(yīng)對(duì)大量數(shù)據(jù)join。
關(guān)于JVM的轉(zhuǎn)換代價(jià)，photon團(tuán)隊(duì)也做了測(cè)試，從內(nèi)存的列存int類型數(shù)據(jù)讀，整體執(zhí)行時(shí)間0.06%損耗在JNI-internal methods，0.2%損耗在adapter node總體看JNI或者轉(zhuǎn)換沒(méi)有太大代價(jià)。
相比DBR，photon另外一塊比較優(yōu)勢(shì)的點(diǎn)就是runtime adaptivity：1）adapting to sparse batmapinfo破解版ches有些場(chǎng)景下有很多數(shù)據(jù)是比較稀疏的，比如ML，photon會(huì)在每個(gè)batch上track列數(shù)據(jù)的稀疏性，在做join probe的時(shí)候在稀疏列上會(huì)進(jìn)行compact增加內(nèi)存吞吐，還有如果不做compact會(huì)比DBR差，因?yàn)橄∈钄?shù)據(jù)導(dǎo)致了high overhead，然而DBR因?yàn)橥ㄟ^(guò)code-gen方式消除了虛函數(shù)調(diào)用開銷盡管是tuple at time。
這也是需要針對(duì)稀疏數(shù)據(jù)進(jìn)行compact的原因效果如下圖：
2）adaptive string encoding,shuffle是性能殺手，所以photon進(jìn)行了優(yōu)化來(lái)減少shuffle數(shù)據(jù)大小，手段主要是1）縮小uuid數(shù)據(jù)寬度，默認(rèn)uumapinfo破解版id是36B，優(yōu)化到128bit表示，類似ML里的量化，
2）在shuffle寫前加lz4壓縮，另外壓縮也會(huì)導(dǎo)致內(nèi)存占用較小從而避免spill，當(dāng)然代價(jià)是多耗費(fèi)一點(diǎn)cpu。下圖是效果：
總結(jié)photon團(tuán)隊(duì)從現(xiàn)實(shí)出發(fā)，實(shí)現(xiàn)了spark的向量化處理、微批adaptivity，與已有DBR和spark兼容，在cpu heavy的場(chǎng)景提升非常明顯，國(guó)內(nèi)也有一些公司做了類似的嘗試比如阿里云、第四范式
等，從效果看非常不錯(cuò)工作量可以看到不小，論文是Matei領(lǐng)銜23人完成，需要一個(gè)工程能力很強(qiáng)的團(tuán)隊(duì)從計(jì)算引擎的角度看，photon未必是state-of-art，受限于現(xiàn)實(shí)原因，photon必須要嵌入到DBR中mapinfo破解版，大量與JVM交互，數(shù)據(jù)格式也需要列與行互轉(zhuǎn)，帶來(lái)一定的。
overhead另外一條路，個(gè)人認(rèn)為是基于clickhouse來(lái)演進(jìn)，首先實(shí)現(xiàn)clickhouse與hive數(shù)倉(cāng)或者數(shù)據(jù)湖的整合，其次，支持shuffle hash join和shuffle merge join，再次通過(guò)寫checkpoint增強(qiáng)執(zhí)行ETL等大query的容錯(cuò)能力。
這樣的clickhouse可以說(shuō)是state-of-art的執(zhí)行引擎，在性能和功能方面都非常完善。
熱門文章
-
干貨滿滿（成都華大醫(yī)藥衛(wèi)生學(xué)校2020年招生簡(jiǎn)章視頻）成都華大醫(yī)藥衛(wèi)生學(xué)校2021年招生簡(jiǎn)章，成都華大醫(yī)藥衛(wèi)生學(xué)校2020年招生簡(jiǎn)章，巨型豬籠草，
-
不看后悔（抖音開放平臺(tái)官方微信小程序上線怎么關(guān)閉）抖音官方小程序開發(fā)者工具，抖音開放平臺(tái)官方微信小程序上線！，合作學(xué)習(xí)理論，
-
這都可以？（三菱plc軟元件存儲(chǔ)器是干嘛的）三菱plc編程軟件查看軟元件，三菱FX3-PLC軟元件介紹，芭芭農(nóng)場(chǎng)每日答案，
-
一看就會(huì)（拔網(wǎng)線是什么意思?）拔網(wǎng)線是拔哪一根，自己拔網(wǎng)線？啟用本國(guó)互聯(lián)網(wǎng)，DNS被美國(guó)防部控制怎么破？，自行車分類，
-
越早知道越好（vue輪播圖組件）vue中輪播圖，這是我見(jiàn)過(guò)最優(yōu)雅的Vue圖片輪播插件——Vue-Awesome-Swiper，指數(shù)分布公式，
最近發(fā)表
-
墻裂推薦（微信小程序開發(fā)圖解案例教程 pdf）微信小程序開發(fā)示例，小白開發(fā)日記——學(xué)習(xí)開發(fā)微信小程序第四天——設(shè)計(jì)界面(二)，我國(guó)人均水資源是世界多少分之一，
-
萬(wàn)萬(wàn)沒(méi)想到（js實(shí)現(xiàn)滑塊拖動(dòng)）auto.js滑動(dòng)，前端開發(fā)：純JavaScript滑動(dòng)特效插件，主要面向移動(dòng)端（swiper），北京科技大學(xué)官網(wǎng)，
-
原創(chuàng)（swiper-no-swiping）swiper3，Swiper 4特色功能及使用教程，歐洲服務(wù)器，
-
居然可以這樣（swiper組件的( )屬性用于設(shè)置輪播圖是否自動(dòng)播放）swiper自動(dòng)輪播代碼，小程序?qū)W習(xí)日志8：swiper滑動(dòng)輪播組件（輪播圖）（上），山東省綜合素質(zhì)評(píng)價(jià)登錄，
-
滿滿干貨（vue3輪播圖）vue.js輪播圖，Vue輪播圖插件中的精品——Vue-Awesome-Swiper，委托貸款管理辦法2020，