[[414445]]

本文轉(zhuǎn)載自微信公眾號「明哥的IT隨筆」，作者IT明哥。轉(zhuǎn)載本文請聯(lián)系明哥的IT隨筆公眾號。

前言

大家好，我是明哥!

正所謂 “抬頭看天，低頭走路”，大數(shù)據(jù)從業(yè)者既要腳踏實(shí)地立足當(dāng)前技術(shù)棧做出高效易用的大數(shù)據(jù)產(chǎn)品，又要仰望星空順應(yīng)大數(shù)據(jù)的發(fā)展趨勢，做出有技術(shù)前瞻性能適應(yīng)未來變化的大數(shù)據(jù)產(chǎn)品。

明哥前期發(fā)布了一篇名為 “從歷年 Gartner hype cycle 看大數(shù)據(jù)行業(yè)的發(fā)展歷史和趨勢” 的博文，在那篇博文中，明哥梳理了下歷年 Gartner hype cycle 中關(guān)于大數(shù)據(jù)的部分，并據(jù)此總結(jié)了大數(shù)據(jù)行業(yè)的發(fā)展歷史和趨勢，該篇博文可以算是從面到點(diǎn)從上到下的視角推論的大數(shù)據(jù)的發(fā)展趨勢。該博文鏈接如下：

從歷年 Gartner hype cycle 看大數(shù)據(jù)行業(yè)的發(fā)展歷史和趨勢

在這篇博文中，明哥將依托自己十四年 IT 從業(yè)經(jīng)驗(yàn)和六年大數(shù)據(jù)行業(yè)從業(yè)經(jīng)驗(yàn)的經(jīng)歷，從自身的感觸和技術(shù)的視角，總結(jié)下大數(shù)據(jù)行業(yè)的發(fā)展趨勢，可以算是以從點(diǎn)到面從下到上的視角，對上文的一個(gè)呼應(yīng)。

需要聲明下，明哥自身能力有限經(jīng)歷有限，所以這里總結(jié)的行業(yè)趨勢僅僅是管中窺豹，遠(yuǎn)遠(yuǎn)達(dá)不到大而全，話說回來，能讓大家看后有所悟有所感，明哥就覺得可以了。

以下是正文。

趨勢一：大數(shù)據(jù)和云計(jì)算進(jìn)一步深度融合，大數(shù)據(jù)擁抱云計(jì)算走向云原生化

關(guān)于該趨勢，明哥在前期發(fā)布過一篇博文，“大數(shù)據(jù)與云計(jì)算深度融合的趨勢體現(xiàn)在哪些方面?” 對該趨勢做了自己的解讀，這里再次簡要描述下。該博文鏈接如下:

大數(shù)據(jù)與云計(jì)算深度融合的趨勢體現(xiàn)在哪些方面?

云原生(Cloud Native)理念，本質(zhì)上是一套“利用云計(jì)算技術(shù)為用戶降本增效”的最佳實(shí)踐與方法論。大數(shù)據(jù)擁抱云計(jì)算走向云原生化，體現(xiàn)在一下四個(gè)方面：

• 一是應(yīng)用方的大數(shù)據(jù)平臺主動(dòng)上云：使用大數(shù)據(jù)技術(shù)的業(yè)務(wù)應(yīng)用建設(shè)方，不再自建數(shù)據(jù)中心，而是將大數(shù)據(jù)平臺搬到了云上，有的是在云廠商的 IaaS 層上自建大數(shù)據(jù)平臺(現(xiàn)在以這種方式在云上使用大數(shù)據(jù)的案例已經(jīng)比較少了)，有的直接使用云廠商提供的 PaaS 層大數(shù)據(jù)相關(guān)產(chǎn)品(aws 的 emr，阿里云的 e-MapReduce等)，有的甚至直接使用云廠商推出的 SaaS層大數(shù)據(jù)相關(guān)產(chǎn)品(aws的redshift, 阿里云的maxcompute等)，而且在上云的過程中，大家都很重視混合云和多云部署，避免 vendor-lockin;
• 二是云計(jì)算廠商在不斷推出云上托管的各種基于大數(shù)據(jù)服務(wù)，以吸引更多業(yè)務(wù)方上云：各大云廠商為了提高自己的市場競爭力，從而進(jìn)一步鞏固和拓寬自己的市場地位，都在積極推出各種托管的大數(shù)據(jù)相關(guān)產(chǎn)品，有 s3/oss, emr/e-mapreduce，有 aws redshift, 有阿里云 maxcompute，還有各種云上數(shù)據(jù)庫，云上 serverless 形態(tài)的各種大數(shù)據(jù)服務(wù)等等，該名單還在不斷增長中。
• 三是各傳統(tǒng)大數(shù)據(jù)廠商已經(jīng)轉(zhuǎn)向依托云來提供自己的產(chǎn)品和服務(wù)，如 elastic 很早就開始基于云交付自己的elk 技術(shù)棧了，如 spark 背后的商業(yè)公司 databricks 的大數(shù)據(jù)平臺和產(chǎn)品一直都是基于云來向客戶提供服務(wù)的(可以對接aws, gcp, azure等云平臺)，如 cloudera 不斷探索改變自己的商業(yè)模式(從大數(shù)據(jù)三駕馬車的輝煌期，到業(yè)績下滑下的和 hortorworks的合并，再到主動(dòng)改變商業(yè)模式基于云來交付自己的產(chǎn)品和服務(wù)，甚至數(shù)據(jù)中心版的大數(shù)據(jù)平臺都改名為了 cdp private cloud base)，如 kafka 背后的商業(yè)公司 Confluent 也在基于云推廣自己的 Confluent Platform.

confluent platform and confluent cloud

• 四是各個(gè)具體的大數(shù)據(jù)組件都在主動(dòng)改變自身架構(gòu)，積極向云原生靠攏以“云化”：從理念層面講，大數(shù)據(jù)已經(jīng)從最早的強(qiáng)調(diào)“數(shù)據(jù)本地性”和“移動(dòng)數(shù)據(jù)不如移動(dòng)計(jì)算”的理念，演進(jìn)到了現(xiàn)在的強(qiáng)調(diào)“存儲計(jì)算分離”的理念。各個(gè)新推出的組件和框架主動(dòng)擁抱云原生，如 pulsa，TiDB 等都是依托于存儲計(jì)算分離的云原生架構(gòu); 各個(gè)傳統(tǒng)的組件雖然有歷史包袱，也在不斷求新求變，如 flink/spark 都深度整合支持了 kubernetes 集群模式;如 kafka也在不斷探索如花云化：包括完全去掉zookeeper依賴，包括 Rebalance Protocol 的 Static Membership 等;正如古語所言，“順則昌不順則亡”，一些不適應(yīng)云原生架構(gòu)的技術(shù)組件，其市場正在不斷萎縮，如很多場景下，kubernetes 都替代了yarn, 對象存儲 oss/s3 等也在替代 hdfs (我們也注意到了apache 社區(qū)推出的 Ozone，該組件在對象存儲的基礎(chǔ)上，也融合推出了文件系統(tǒng)api，該組件的背后有很多原 hdfs 社區(qū)的 committer在貢獻(xiàn)代碼，在 cloudera 的 cdp 平臺中也內(nèi)嵌支持了該組件)。下圖展示了 flink/spark跟 kubernetes 的深度整合：(注意不是簡單的使用 k8s operator 將 spark/flink 作業(yè)運(yùn)行在 k8s 集群中，而是 native 的深度的整合)
• 大數(shù)據(jù)云與計(jì)算的深度融合是大勢所趨，其主要體現(xiàn)在以上四個(gè)方面，需要強(qiáng)調(diào)的是，這四個(gè)方面是相輔相成，互相促進(jìn)的。
  • 如應(yīng)用方的大數(shù)據(jù)平臺上云的需求，促使了云計(jì)算廠商推出更好的托管的大數(shù)據(jù)增值服務(wù);
  • 而云計(jì)算廠商推出的更多更好的大數(shù)據(jù)增值服務(wù)，也反過來促使了更多的應(yīng)用方大數(shù)據(jù)平臺上云;
  • 如基礎(chǔ)設(shè)施上云的大趨勢，促使了具體的大數(shù)據(jù)組件調(diào)整自身架構(gòu)從而云化(因?yàn)轫槃t昌不順則亡);
  • 而大數(shù)據(jù)具體組件云原生化的架構(gòu)調(diào)整，也反過來促使了云計(jì)算廠商和大數(shù)據(jù)廠商能夠基于云基礎(chǔ)設(shè)施推出更多更好的大數(shù)據(jù)服務(wù)。

趨勢二：大數(shù)據(jù)與數(shù)據(jù)庫日益融合的趨勢

• 大數(shù)據(jù)與數(shù)據(jù)庫日益融合的趨勢，首先體現(xiàn)在大數(shù)據(jù)與數(shù)據(jù)庫的邊界本身就比較模糊：
  • 如具有大數(shù)據(jù)基因的各種 NoSql 數(shù)據(jù)庫 MongoDB, es, Hbase 等也是數(shù)據(jù)庫生態(tài)的一部分;
  • 如 greenPlum, Vertica 等 mpp 數(shù)據(jù)庫本身就是大數(shù)據(jù)生態(tài)的一部分;
  • 如新型 NewSql 數(shù)據(jù)庫 TiDB, CockroachDB, OceanBase 更是橫跨數(shù)據(jù)庫生態(tài)與大數(shù)據(jù)生態(tài)。
• 大數(shù)據(jù)與數(shù)據(jù)庫日益融合的趨勢，也體現(xiàn)在大數(shù)據(jù)組件本身在技術(shù)上借用和參考了很多傳統(tǒng)數(shù)據(jù)庫的理念和技術(shù)，使得大數(shù)據(jù)組件越來越像存儲與計(jì)算分離的數(shù)據(jù)庫：
  • 如各種大數(shù)據(jù)處理引擎都提供了對 sql 語法的支持：hive/spark/flink/presto sql;
  • 如各種大數(shù)據(jù)處理引擎本身在對 sql 的解析和優(yōu)化上經(jīng)常使用的框架 calcite/antlr4 在實(shí)現(xiàn)細(xì)節(jié)上就參考了數(shù)據(jù)庫的實(shí)現(xiàn);
  • 如大數(shù)據(jù)參考數(shù)據(jù)庫對元數(shù)據(jù)的管理，抽象出了 catalog 的概念，各大數(shù)據(jù)處理引擎如 spark/flink 都有自己的各種 catalog 的實(shí)現(xiàn);
  • 如大數(shù)據(jù)處理引擎參考數(shù)據(jù)庫實(shí)現(xiàn)了對事務(wù) acid 特性的支持，參考數(shù)據(jù)庫的 mvcc 機(jī)制實(shí)現(xiàn)了對并發(fā)讀寫和多版本控制的支持，具體的有 hive acid事務(wù)表，還有數(shù)據(jù)湖框架 delta lake/hudi/iceberg等。
• 大數(shù)據(jù)與數(shù)據(jù)庫日益融合的趨勢，還體現(xiàn)在數(shù)據(jù)庫也在不斷演變以適應(yīng)大數(shù)據(jù)場景：數(shù)據(jù)庫從技術(shù)架構(gòu)上來講，經(jīng)歷了從早期的關(guān)系型數(shù)據(jù)庫 sql，到大數(shù)據(jù)初生時(shí)代的各種 Nosql，再到現(xiàn)在的各種 NewSql, 也經(jīng)歷了從單機(jī)到讀寫分離再到集群化部署的趨勢;

最后有必要說明下，由于大數(shù)據(jù)和數(shù)據(jù)庫日益融合，依托數(shù)據(jù)庫的傳統(tǒng)數(shù)據(jù)倉庫 Data Warehouse 和依托大數(shù)據(jù)的數(shù)據(jù)湖 Data Lake，二者之間的界限也越來越模糊并日益融合了，有的廠商還特地引進(jìn)了新的術(shù)語來描述這種新型架構(gòu)并得到了業(yè)界更廣泛的認(rèn)可和支持，該術(shù)語就是業(yè)界常說的湖倉一體的概念，即 Lake House。

趨勢三：大數(shù)據(jù)更加青睞存儲計(jì)算分離的架構(gòu)

存儲與計(jì)算是對物理資源不同緯度的需求，存儲和計(jì)算分離的架構(gòu)更加靈活，方便對存儲和計(jì)算獨(dú)立進(jìn)行擴(kuò)縮容，成本更優(yōu)更具性價(jià)比。

• 大數(shù)據(jù)更加青睞存儲計(jì)算分離的架構(gòu)，體現(xiàn)在大數(shù)據(jù)生態(tài)更加豐富，由不同的框架解決不同的問題：計(jì)算層面有 spark/flink/presto， 存儲層面有 hdfs/ozone/s3，數(shù)據(jù)管理層面有元數(shù)據(jù)管理的 hive catalog, 文件格式有 orc/parquet, 表格式 table format 有 hudi/iceberg/delta lake, 資源管理有 yarn/mesos/k8s等等;
• 大數(shù)據(jù)更加青睞存儲計(jì)算分離的架構(gòu)，也體現(xiàn)在一些傳統(tǒng)的存儲引擎也在進(jìn)一步細(xì)化架構(gòu)，支持存儲與計(jì)算分離：如 NewSQL 數(shù)據(jù)庫 TidB,在底層分為計(jì)算層 TiDB/TiSpark,存儲層 TiKV/TiFlash,元數(shù)據(jù)層 PD; 如云原生消息系統(tǒng) pulsa，在底層分為計(jì)算層 broker 和存儲層 bookkeeper; 如 hdfs 的進(jìn)化版 Ozone在底層支持對象存儲;如消息系統(tǒng) Kafka 也通過 tiered storage 支持本地存儲和遠(yuǎn)端云端對象存儲;

infinite storage with confluent cloud

大數(shù)據(jù)更加青睞存儲計(jì)算分離的架構(gòu)，還體現(xiàn)在大數(shù)據(jù)集群整體在架構(gòu)上也更靈活更適應(yīng)存儲與計(jì)算分離，比如星環(huán)的大數(shù)據(jù)平臺 tdh 底層的 tos 云操作系統(tǒng)是基于k8s和docker的;再比如 Cloudear 的大數(shù)據(jù)平臺 dcp 的公有云版 cdp public cloud 和私有云版 cdp private cloud，兩者都是集群模式+容器模式，存儲依賴集群模式中的集群，而計(jì)算依賴容器模式中的容器，存儲有計(jì)算解耦可以獨(dú)自進(jìn)行擴(kuò)縮容。(私有云版在底層分為 cdp private cloud base 和 cdp private cloud plus，其中base是集群模式，和原來 cdh/hdp 的架構(gòu)相同;plus是容器模式，底層依托 openShift (底層是k8s)實(shí)現(xiàn)跨云多云環(huán)境中的容器管理;)!

趨勢四：大數(shù)據(jù)更加青睞對象存儲

大數(shù)據(jù)為了進(jìn)一步適應(yīng)云原生化的大方向，在存儲上相比文件系統(tǒng)，更加青睞對象存儲。

對象存儲在性能上比不上文件系統(tǒng)，尤其是對文件和目錄的重命名 rename 操作上，以及對目錄的 list 操作上，(對象存儲沒有目錄樹的概念，所謂的目錄是抽象出來的;很多云廠商會限制對目錄的 list 操作的次數(shù))，但是對象存儲相比文件系統(tǒng)，在成本和擴(kuò)展性上更有優(yōu)勢，所以云廠商更青睞對象存儲。

當(dāng)然了，大數(shù)據(jù)為適應(yīng)對象存儲，自身在架構(gòu)和技術(shù)上也在不斷演進(jìn)，比如大數(shù)據(jù)的數(shù)據(jù)倉庫框架 hive 在擴(kuò)展性上受到不少詬病，而其擴(kuò)展性問題的一個(gè)原因，就是在對元數(shù)據(jù)的管理上只做到了目錄粒度而不是文件粒度，即 hive 在管理表和分區(qū)的元數(shù)據(jù)時(shí)，只記錄了表和分區(qū)對應(yīng)的目錄，至于該目錄底層有哪些文件，是在計(jì)算時(shí)通過 list 掃描得到的，由于在對象存儲系統(tǒng)中 list 是比較昂貴的操作，所以在對接對象存儲時(shí)，hive 這樣處理顯然是不合適的。事實(shí)上，更適應(yīng)云原生和對象存儲的框架如 Iceberg/Delta lake等，在元數(shù)據(jù)中都做到了文件的粒度而不是目錄的粒度。

關(guān)于文件系統(tǒng)和對象存儲的詳細(xì)對比，有興趣的小伙伴可以自行 google,明哥在這里不再贅述。

趨勢五：大數(shù)據(jù)和機(jī)器學(xué)習(xí)/人工智能日益融合

大數(shù)據(jù)和機(jī)器學(xué)習(xí)/人工智能日益融合的趨勢，體現(xiàn)在大數(shù)據(jù)需要AI上，也體現(xiàn)在AI需要大數(shù)據(jù)上。

• 一方面，大數(shù)據(jù)需要AI:
  • 大數(shù)據(jù)的元數(shù)據(jù)管理需要AI: 當(dāng)企業(yè)面對數(shù)據(jù)量大且種類繁多的數(shù)據(jù)資產(chǎn)時(shí)(大數(shù)據(jù)的 5V 包括 volume 和 variety)，如何有效管理和使用這些數(shù)據(jù)以挖掘更大商業(yè)價(jià)值，就尤其需要數(shù)據(jù)治理和元數(shù)據(jù)管理了。元數(shù)據(jù)的范疇和概念在擴(kuò)大化，元數(shù)據(jù)不再僅僅是數(shù)據(jù)管理人員事先提供的靜態(tài)的元數(shù)據(jù)，還包括利用機(jī)器學(xué)習(xí)可推導(dǎo)得出的動(dòng)態(tài)發(fā)現(xiàn)的元數(shù)據(jù)。Gartner 推崇 Data Fabric 數(shù)據(jù)經(jīng)緯的概念, 該概念尤其強(qiáng)調(diào)元數(shù)據(jù)管理和增強(qiáng)型數(shù)據(jù)管理，即主動(dòng)利用機(jī)器學(xué)習(xí)驅(qū)動(dòng)的元數(shù)據(jù)，快速提供來自于不同數(shù)據(jù)源的數(shù)據(jù)并自動(dòng)化數(shù)據(jù)管理。這其中會更多地用到圖計(jì)算和知識圖譜，“Graphs form the foundation of data fabrics and knowledge graphs“，來幫助我們發(fā)現(xiàn)數(shù)據(jù)之間潛在的關(guān)聯(lián)關(guān)系。
  • 大數(shù)據(jù)將我們從從BI時(shí)代帶到了AI時(shí)代, 對數(shù)據(jù)的分析也不再是BI時(shí)代簡單的統(tǒng)計(jì)分析和提供各種報(bào)表，而是AI時(shí)代更強(qiáng)調(diào)的綜合使用各種算法做 Augmented analytics 提供 data story等商業(yè)洞察;
  • 在物聯(lián)網(wǎng)的各種邊緣設(shè)備 edge 上也更加提倡通過邊緣計(jì)算內(nèi)嵌各種 ML 和 AI 模型，將基于AI的計(jì)算推到更靠近數(shù)據(jù)產(chǎn)生的地方，以提供更高的數(shù)據(jù)時(shí)效性，以減少數(shù)據(jù)傳輸，以挖掘更多應(yīng)用場景等等。
• 另一方面，AI 也需要大數(shù)據(jù)：從事人工智能相關(guān)工作的小伙伴們，都知道 AI 有個(gè)三要素的概念，即：數(shù)據(jù)，算法，算力，其中數(shù)據(jù)的質(zhì)量和數(shù)量，決定了模型好壞的上限;而好的算法和足夠的算力，可以推動(dòng)模型的效果更逼近這個(gè)上限。
  • 三要素中的數(shù)據(jù)作為 AI 的原材料，跟大數(shù)據(jù)有著密不可分的關(guān)系，正是大數(shù)系統(tǒng)提供了AI的數(shù)據(jù)原材料。在現(xiàn)階段，算法同學(xué)一般是從大數(shù)據(jù)系統(tǒng)中提取出來數(shù)據(jù)，存放在本地文件系統(tǒng)中，再進(jìn)行模型的訓(xùn)練;不過已經(jīng)有一些大數(shù)據(jù)框架，著手于利用大數(shù)據(jù)系統(tǒng)中的數(shù)據(jù)直接進(jìn)行模型訓(xùn)練和模型部署與應(yīng)用了，比如 spark mllib, koalas, flink ml;我們也看到，alluxio client 通過 fuse api 接口以本地文件的形式，直接提供大數(shù)據(jù)平臺中的數(shù)據(jù)給算法模型進(jìn)行訓(xùn)練，起到了數(shù)據(jù)橋梁的作用，減少了中間數(shù)據(jù)導(dǎo)出的繁瑣過程。
  • 三要素中的算力，也可以依賴大數(shù)據(jù)的集群資源管理框架來提供，比如 yarn 在對 cpu 和 mem 資源管理的基礎(chǔ)上，已經(jīng)擴(kuò)展支持了對 gpu 資源的管理;
  • 三要素中的算法，在很多大數(shù)據(jù)框架也直接提供了對常見算法的實(shí)現(xiàn)，比如 spark mllib, flink ml等。

趨勢六：大數(shù)據(jù)日益重視數(shù)據(jù)安全與數(shù)據(jù)治理

明哥覺得，現(xiàn)階段數(shù)據(jù)安全問題日益凸顯，有以下幾方面的原因：

• 一方面企業(yè)本身仍然面臨著傳統(tǒng)的各種內(nèi)外部數(shù)據(jù)威脅，這點(diǎn)沒啥新意，我們就不再贅述;
• 另一方面，國家出臺了各種政策和法規(guī)需要遵守沒有重視數(shù)據(jù)合規(guī)性的企業(yè)會面臨政府的天價(jià)罰單，(我們看到前段時(shí)間滴滴上市前臨門一腳被叫停，就是處于數(shù)據(jù)安全)。
• 還有一點(diǎn)，就是在云環(huán)境下，安全問題更加凸顯。以往大數(shù)據(jù)都是在數(shù)據(jù)中心的內(nèi)網(wǎng)運(yùn)行，面臨的威脅少暴露出來的也不多;而當(dāng)前隨著大數(shù)據(jù)上云的趨勢，大量云計(jì)算廠商推出了自己云上托管的大數(shù)據(jù)服務(wù)，云上應(yīng)用案列越來越多，遭受的攻擊嘗試也越來越多，相應(yīng)的被發(fā)現(xiàn)和暴露出來的安全漏洞問題也就越來越多。

在應(yīng)對數(shù)據(jù)安全問題上，傳統(tǒng)的3A 即 authentication, authorization 和 audit 的概念仍然適用，encryption 加密算法也仍然使用，具體使的支撐框架常見的有 Kerberos, ldap, knox, ranger 和 sentry 等。

在數(shù)據(jù)治理上，前文提到，當(dāng)企業(yè)面對數(shù)據(jù)量大且種類繁多的數(shù)據(jù)資產(chǎn)時(shí)(大數(shù)據(jù)的 5V 包括 volume 和 variety)，如何有效管理和使用這些數(shù)據(jù)以挖掘更大商業(yè)價(jià)值，就尤其需要數(shù)據(jù)治理和元數(shù)據(jù)管理了。此時(shí)元數(shù)據(jù)的范疇和概念有擴(kuò)大化的趨勢，元數(shù)據(jù)不再僅僅是數(shù)據(jù)管理人員事先提供的靜態(tài)的元數(shù)據(jù)，還包括利用機(jī)器學(xué)習(xí)可推導(dǎo)得出的動(dòng)態(tài)發(fā)現(xiàn)的元數(shù)據(jù)。

在數(shù)據(jù)治理上，Gartner 推崇 Data Fabric 數(shù)據(jù)經(jīng)緯的概念, 該概念尤其強(qiáng)調(diào)元數(shù)據(jù)管理和增強(qiáng)型數(shù)據(jù)管理，即主動(dòng)利用機(jī)器學(xué)習(xí)驅(qū)動(dòng)的元數(shù)據(jù)，快速提供來自于不同數(shù)據(jù)源的數(shù)據(jù)并自動(dòng)化數(shù)據(jù)管理。這其中會更多地用到圖計(jì)算和知識圖譜，“Graphs form the foundation of data fabrics and knowledge graphs“，來幫助我們發(fā)現(xiàn)數(shù)據(jù)之間潛在的關(guān)聯(lián)關(guān)系。

數(shù)據(jù)治理的一些相關(guān)概念，包括元數(shù)據(jù)，主數(shù)據(jù)，數(shù)據(jù)血緣等，支撐框架包括 atlas,ranger 等。

趨勢七：大數(shù)據(jù)日益重視數(shù)據(jù)的時(shí)效性

大數(shù)據(jù)強(qiáng)調(diào)數(shù)據(jù)有熱度，數(shù)據(jù)價(jià)值具有時(shí)效性且隨著時(shí)間的推移價(jià)值會遞減，這是大家的共識，也是實(shí)時(shí)計(jì)算和準(zhǔn)實(shí)時(shí)計(jì)算日益受到業(yè)界重視的原因，筆者沒有太多補(bǔ)充，不過我想指出一點(diǎn)，即實(shí)時(shí)計(jì)算究竟需要做到什么級別的實(shí)時(shí)，是在業(yè)務(wù)需求，現(xiàn)有技術(shù)能力，和運(yùn)維復(fù)雜性之間的妥協(xié)，并不是一定總是要追求毫秒微妙級別的實(shí)時(shí)，很多時(shí)候秒級別分鐘級別甚至小時(shí)級別的延時(shí)，也是可以接受的。

業(yè)界這塊相關(guān)的概念有流批一體，仔細(xì)分析又包括存儲引擎層面的流批一體，計(jì)算框架層面的流批一體，以及業(yè)務(wù)代碼層面的流批一體。

在存儲引擎層面，離線批量處理場景一般使用文件系統(tǒng)結(jié)合數(shù)據(jù)庫;實(shí)時(shí)準(zhǔn)實(shí)時(shí)流處理場景一般使用消息隊(duì)列結(jié)合數(shù)據(jù)庫。不過隨著數(shù)據(jù)湖倉概念的崛起，尤其是伴隨著 delta lake/hudi/iceberg 的崛起和 hive 實(shí)時(shí)化的進(jìn)展，使用這些框架做流批一體的存儲的案列將會越來越多(當(dāng)然對應(yīng)的場景是分鐘級別的準(zhǔn)實(shí)時(shí)的場景);隨著 kafka 支持tiered storage , 使用 kafka結(jié)合對象存儲并配置合適的 retention period 做流批一體的存儲的案例也會越來越多。

在計(jì)算框架層面，flink 和 spark 都支持流批一體，即同一個(gè)計(jì)算框架即支持用戶的流處理應(yīng)用程序，也支持用戶的批處理應(yīng)用程序。

在業(yè)務(wù)代碼層面的流批一體上，即同一套業(yè)務(wù)代碼，不做任何代碼層面的改動(dòng)，僅僅通過配置不同的參數(shù)，就能提交做為流處理或批處理應(yīng)用程序運(yùn)行，目前看來似乎 FLINK SQL 走得最遠(yuǎn)做得最好。