目前最大的誤區(qū)之一仍然是，只有大公司才能負(fù)擔(dān)得起大數(shù)據(jù)驅(qū)動(dòng)的解決方案，它只適用于海量數(shù)據(jù)，而且價(jià)格昂貴。這已不再是事實(shí)，有幾次技術(shù)變革改變了這種心態(tài)。

大數(shù)據(jù)技術(shù)的成熟度

第一次技術(shù)變革與成熟度和質(zhì)量有關(guān)。毫無(wú)疑問(wèn)，十年前，大數(shù)據(jù)技術(shù)需要做出一定的努力才能使其工作或使所有部分協(xié)同工作。

過(guò)去有無(wú)數(shù)來(lái)自開(kāi)發(fā)人員的故事，他們浪費(fèi)了80％的時(shí)間試圖用Spark，Hadoop，Kafka或其他方法克服愚蠢的故障。如今，這些技術(shù)已變得足夠可靠，它們消除了早期的各種故障并學(xué)會(huì)了如何相互配合。

與捕捉內(nèi)部錯(cuò)誤相比，出現(xiàn)基礎(chǔ)設(shè)施故障的機(jī)會(huì)要大得多。在大多數(shù)情況下，即使是基礎(chǔ)設(shè)施問(wèn)題也可以容忍，因?yàn)榇蠖鄶?shù)大數(shù)據(jù)處理框架的設(shè)計(jì)都是容錯(cuò)的。此外，這些技術(shù)為計(jì)算提供了穩(wěn)定、強(qiáng)大和簡(jiǎn)單的抽象，并允許開(kāi)發(fā)人員專注于開(kāi)發(fā)的業(yè)務(wù)方面。

各種大數(shù)據(jù)技術(shù)

第二次技術(shù)變革正在發(fā)生——近年來(lái)，無(wú)數(shù)的開(kāi)源和專有技術(shù)被發(fā)明出來(lái)——Apache Pino、Delta Lake、Hudi、Presto、Clickhouse、Snowflake、Upsolver、Serverless等等。數(shù)千名開(kāi)發(fā)者的創(chuàng)造力和創(chuàng)意已經(jīng)轉(zhuǎn)化為大膽而卓越的解決方案，并具有巨大的激勵(lì)作用。

讓我們討論一個(gè)典型的分析數(shù)據(jù)平臺(tái)（ADP）。它包括四個(gè)主要層次：

· 儀表板和可視化– ADP的外觀，向最終用戶提供分析摘要。

· 數(shù)據(jù)處理–數(shù)據(jù)流水線，用于驗(yàn)證，豐富和轉(zhuǎn)換數(shù)據(jù)從一種形式到另一種形式。

數(shù)據(jù)倉(cāng)庫(kù)–存放組織良好的數(shù)據(jù)的地方–匯總，數(shù)據(jù)集市等

· Data Lake，用于存放純?cè)紨?shù)據(jù)的地方，是Data Warehouse的基礎(chǔ)。

· 每個(gè)等級(jí)都有足夠的替代品，可滿足任何口味和要求。這些技術(shù)中有一半是在過(guò)去5年內(nèi)出現(xiàn)的。

關(guān)于它們的重要一點(diǎn)是，技術(shù)的開(kāi)發(fā)旨在相互兼容。例如，典型的低成本小型ADP可能包含Apache Spark作為處理組件的基礎(chǔ)，AWS S3或類似的Data Lake，Clickhouse作為倉(cāng)庫(kù)，OLAP用于低延遲查詢，而Grafana用于漂亮的儀表板。

具有更強(qiáng)保證的更復(fù)雜的ADP可以以不同的方式組成。例如，將Apache Hudi和S3引入作為數(shù)據(jù)倉(cāng)庫(kù)可以確保更大的規(guī)模，而Clickhouse仍然可以低延遲地訪問(wèn)聚合數(shù)據(jù)。

成本效益

第三次技術(shù)變革是由云端造成的。云服務(wù)成為真正的游戲規(guī)則改變者。他們將大數(shù)據(jù)作為即用型平臺(tái)（大數(shù)據(jù)即服務(wù)）進(jìn)行處理，使開(kāi)發(fā)人員可以專注于功能開(kāi)發(fā)，從而使云計(jì)算能夠關(guān)注基礎(chǔ)架構(gòu)。

開(kāi)發(fā)人員可以選擇特定技術(shù)和一定程度的無(wú)服務(wù)器。無(wú)服務(wù)器越多，它的可組合性就越好，但是更多的供應(yīng)商鎖定將使它成為不利的一面。鎖定在特定的云提供商和無(wú)服務(wù)器堆棧上的解決方案可以縮短上市時(shí)間。在無(wú)服務(wù)器技術(shù)之間明智地選擇可使解決方案具有成本效益。

盡管此選項(xiàng)對(duì)初創(chuàng)公司而言不是很有用，因?yàn)樗鼈儍A向于利用典型的10萬(wàn)美元云信用額度，并且在AWS，GCP和Azure之間進(jìn)行跳轉(zhuǎn)是一種很普通的生活方式。必須事先弄清這個(gè)事實(shí)，而必須提出更多與云無(wú)關(guān)的技術(shù)。

通常，工程師會(huì)區(qū)分以下成本：開(kāi)發(fā)費(fèi)用、維修費(fèi)用、變更成本。

開(kāi)發(fā)費(fèi)用

云技術(shù)無(wú)疑簡(jiǎn)化了工程工作。有好幾個(gè)區(qū)域?qū)λ蟹e極的影響。

第一個(gè)是架構(gòu)和設(shè)計(jì)決策。無(wú)服務(wù)器堆棧提供了豐富的模式和可重用組件集，為解決方案的體系結(jié)構(gòu)提供了堅(jiān)實(shí)而一致的基礎(chǔ)。

只有一個(gè)問(wèn)題可能會(huì)減慢設(shè)計(jì)階段：大數(shù)據(jù)技術(shù)是自然分布的，因此在設(shè)計(jì)相關(guān)解決方案時(shí)必須考慮可能的故障和中斷，以確保數(shù)據(jù)的可用性和一致性。另外，解決方案所需的精力更少，可以擴(kuò)展。

第二個(gè)是集成和端到端測(cè)試。無(wú)服務(wù)器堆棧允許創(chuàng)建隔離的沙箱，播放，測(cè)試，修復(fù)問(wèn)題，從而減少開(kāi)發(fā)回送和時(shí)間。

另一個(gè)優(yōu)勢(shì)是，云強(qiáng)加了解決方案部署過(guò)程的自動(dòng)化。不用說(shuō)，此功能是任何成功團(tuán)隊(duì)的必備屬性。

維修費(fèi)用

云提供商聲稱要解決的主要目標(biāo)之一是減少監(jiān)視和保持生產(chǎn)環(huán)境活動(dòng)的精力。他們?cè)噲D建立幾乎沒(méi)有零投入的理想抽象。

但是，實(shí)際情況有所不同。關(guān)于這個(gè)想法，通常維護(hù)仍然需要一些努力。下表突出顯示了最突出的種類。

但除此之外，該方案在很大程度上取決于基礎(chǔ)架構(gòu)和許可成本。設(shè)計(jì)階段非常重要，因?yàn)樗梢蕴魬?zhàn)特定技術(shù)并提前估算其運(yùn)行時(shí)間成本。

變更成本

大數(shù)據(jù)技術(shù)關(guān)注客戶的另一個(gè)重要方面-變更成本。我們的經(jīng)驗(yàn)表明，大數(shù)據(jù)與任何其他技術(shù)之間沒(méi)有區(qū)別。如果解決方案不是過(guò)度設(shè)計(jì)的，那么變更的成本就可以與非大數(shù)據(jù)堆棧完全媲美。大數(shù)據(jù)帶來(lái)了一個(gè)好處。大數(shù)據(jù)解決方案被設(shè)計(jì)為分離是很自然的。設(shè)計(jì)正確的解決方案看起來(lái)不像是整體解決方案，可以在需要的地方短期內(nèi)應(yīng)用局部更改，而影響生產(chǎn)的風(fēng)險(xiǎn)較小。

總而言之，我們確實(shí)認(rèn)為大數(shù)據(jù)可以負(fù)擔(dān)得起。它為開(kāi)發(fā)人員提出了新的設(shè)計(jì)模式和方法，開(kāi)發(fā)人員可以利用它來(lái)組裝符合最嚴(yán)格的業(yè)務(wù)要求并同時(shí)具有成本效益的任何分析數(shù)據(jù)平臺(tái)。

大數(shù)據(jù)驅(qū)動(dòng)的解決方案可能是快速成長(zhǎng)的初創(chuàng)公司的良好基礎(chǔ)，這些初創(chuàng)公司希望變得靈活，應(yīng)用快速更改且TTM跑道短。一旦企業(yè)需要更大的數(shù)據(jù)量，大數(shù)據(jù)驅(qū)動(dòng)的解決方案就可以與企業(yè)一起擴(kuò)展。

大數(shù)據(jù)技術(shù)允許以小規(guī)?；虼笠?guī)模實(shí)施近實(shí)時(shí)分析，而經(jīng)典解決方案卻難以與性能相提并論。

云提供商已將大數(shù)據(jù)提升到了新的水平，從而提供了可靠，可擴(kuò)展和即用的功能。快速交付來(lái)開(kāi)發(fā)具有成本效益的ADP從未如此簡(jiǎn)單。利用大數(shù)據(jù)提升您的業(yè)務(wù)。
責(zé)任編輯：YYX