2017年的數(shù)據(jù)工程生態(tài)系統(tǒng)

大數(shù)據(jù)

自從我們在2014年推出Insight Data Engineering Fellows計劃以來，我們與數(shù)據(jù)行業(yè)的75多個團(tuán)隊(duì)建立了聯(lián)系,討論了頂級團(tuán)隊(duì)（如Facebook，Airbnb，Slack，紐約時報，LinkedIn，亞馬遜和Tesla）工程師面臨的最新挑戰(zhàn)。此外，我們不斷增長的校友網(wǎng)絡(luò)現(xiàn)在有著150多名工程師和750多名數(shù)據(jù)科學(xué)家 ，經(jīng)常在Insight社區(qū)分享他們的經(jīng)驗(yàn)。感謝這個強(qiáng)大的社區(qū)，我們有一個探索數(shù)據(jù)領(lǐng)域技術(shù)新興模式的獨(dú)一無二的基地。

我們不斷探索將這些知識傳遞給下一代數(shù)據(jù)工程師和擴(kuò)散的更多數(shù)據(jù)社區(qū)的方法，開發(fā)了更為互動的數(shù)據(jù)工程生態(tài)系統(tǒng)圖，該迭代提供了數(shù)據(jù)管道核心組件的簡化視圖，同時更深入地探索了分布式系統(tǒng)技術(shù)的復(fù)雜世界。

大數(shù)據(jù)

數(shù)據(jù)工程趨勢

通過更新此地圖，我們已經(jīng)反映了當(dāng)前數(shù)據(jù)團(tuán)隊(duì)可用的工具和服務(wù)的最新變化。強(qiáng)調(diào)了一些值得注意的趨勢。

科技融合：Kafka 和 Spark

盡管有著數(shù)量巨大的工具被引入數(shù)據(jù)工程領(lǐng)域，似乎有兩個顯著的趨同點(diǎn)。

在眾多可用的排隊(duì)技術(shù)中，Kafka 是最廣泛采用的。

自從LinkedIn于2011年將其基于日志的解決方案發(fā)布給開源社區(qū)以來，Kafka的流行程度一直在穩(wěn)步上升，現(xiàn)在已成為流媒體數(shù)據(jù)的默認(rèn)攝取工具。

除了流媒體數(shù)據(jù)之外，Kafka越來越多地被用作許多公司的微服務(wù)的集中式消息總線 。除了讓人印象深刻的高吞吐量、高可靠性和與許多其他流行技術(shù)的集成之外，其廣為流行的原因就是易于使用。

大數(shù)據(jù)

其他廣為傳播的技術(shù)有Apache Spark，通用的分布式處理框架。

自從Hadoop早期壟斷“大數(shù)據(jù)”以來，出現(xiàn)了許多有能力的框架，Spark已經(jīng)鞏固了其處理大規(guī)模數(shù)據(jù)的“默認(rèn)”工具的地位。

Spark已經(jīng)被證明是一個功能全面的工具，從傳統(tǒng)批處理到在線機(jī)器學(xué)習(xí)模型的一切工作都能勝任。 Spark高水平的開發(fā)，像DataFrames和SQL一樣結(jié)構(gòu)化的APIs，以及流和圖形庫使得它可以使用代碼庫解決許多實(shí)際問題。和Kafka一樣，它有著很棒的社區(qū)支持，而且很多新的和現(xiàn)有的項(xiàng)目正在與Spark集成。

雖然Kafka和Spark是受歡迎的選擇，但肯定不適合每一種用例。調(diào)查每個工具的優(yōu)點(diǎn)，缺點(diǎn)和替代方案很重要。我們經(jīng)常在Insight強(qiáng)調(diào)，請務(wù)必選擇正確的工具！

架構(gòu)趨勢：與Kappa統(tǒng)一

除了特定技術(shù)的趨勢，我們注意到許多團(tuán)隊(duì)朝著理想化的Kappa架構(gòu)前進(jìn)。與Lambda方法相反，許多技術(shù)現(xiàn)在采用的批處理問題只是流處理問題的一個子集。

雖然還不是最前沿的，但像Flink ， Apex和Gearpump這樣的技術(shù)正在推動向統(tǒng)一批處理和流處理框架的愿景前進(jìn)。即使是Spark，隨著結(jié)構(gòu)化流的發(fā)布，現(xiàn)在提供了一個單一的界面來操作批量和流數(shù)據(jù)。

大數(shù)據(jù)

從某種意義上說， Apache Beam項(xiàng)目是這些努力的結(jié)果?；贕oogle的數(shù)據(jù)流模型，Beam旨在創(chuàng)建一個統(tǒng)一的API，允許開發(fā)人員編寫與其下的處理引擎無關(guān)的應(yīng)用。

隨著Apache Beam等統(tǒng)一處理框架和項(xiàng)目的出現(xiàn)，Kappa架構(gòu)可能會快速被采用。不管架構(gòu)如何，隨著處理框架的不斷改進(jìn)和發(fā)展，我們期待看到批處理和流處理之間的界線仍然模糊。

托管服務(wù)增加

雖然稍有爭議，“無服務(wù)器”的產(chǎn)品也是一個發(fā)展趨勢?！凹~約時報”等數(shù)據(jù)團(tuán)隊(duì)越來越希望直接架構(gòu)數(shù)據(jù)管道，而不用去管理云基礎(chǔ)設(shè)施。雖然這些服務(wù)的生產(chǎn)用例相對有限，但它們提供的功能正在不斷改進(jìn)。通過像AWS S3，Redshift，Athena，EMR，Kinesis和Lambda以及GCP的BigQuery，Pub / Sub和DataProc這樣的服務(wù)，主要的云提供商正在為這些全方位服務(wù)的解決方案提供投資。

類似于從“內(nèi)部”服務(wù)器到云基礎(chǔ)設(shè)施的過渡，數(shù)據(jù)團(tuán)隊(duì)可能會越來越多地利用數(shù)據(jù)服務(wù)。同時，部分自助服務(wù)和部分托管的混合架構(gòu)將變得越來越普遍。

云提供商的趨勢：AWS與GCP

過去幾年的另一個顯著變化是亞馬遜網(wǎng)絡(luò)服務(wù)（AWS）面臨的競爭增多。雖然像Microsoft Azure，IBM，DigitalOcean和Rackspace這樣的平臺已經(jīng)存在了一段時間，但似乎沒有人可以挑戰(zhàn)AWS在2006年發(fā)布的先行優(yōu)勢。

然而，Google一直為內(nèi)部用戶開發(fā)自己的復(fù)雜基礎(chǔ)架構(gòu)。事實(shí)上，Google一直以內(nèi)部開拓分布式系統(tǒng)而聞名，但選擇發(fā)布白皮書而不是開源。隨著對谷歌云平臺（GCP）的大量投入，他們已推出Google Infrastructure For Everyone Else (GIFEE) 的托管服務(wù)。

在過去幾年中，GCP取得了長足的進(jìn)步，迅速成為一個有利的競爭者。雖然GCP與AWS相比并不能提供全面的服務(wù)，但越來越多的頂級團(tuán)隊(duì)（如Spotify）正在進(jìn)行轉(zhuǎn)換 。也許云提供商的領(lǐng)域最終會減少，但是在不久的將來我們會看到健康的競爭。

前景

雖然沒有人知道數(shù)據(jù)領(lǐng)域的未來如何，但有一點(diǎn)很清楚——新技術(shù)將使我們能夠進(jìn)一步利用我們的數(shù)據(jù)。無論是新技術(shù)和服務(wù)的出現(xiàn)，還是現(xiàn)有的功能的增加，開發(fā)人員都將擁有更豐富的工具來構(gòu)建數(shù)據(jù)管道和平臺。

極客網(wǎng)企業(yè)會員

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。

2017-10-30
2017年的數(shù)據(jù)工程生態(tài)系統(tǒng)
自從我們在2014年推出Insight Data Engineering Fellows計劃以來，我們與數(shù)據(jù)行業(yè)的75多個團(tuán)隊(duì)建立了聯(lián)系,討論了頂級團(tuán)隊(duì)（如Fa

長按掃碼 閱讀全文