[[414445]]

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

前言

大家好，我是明哥!

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

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

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

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

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

以下是正文。

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

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

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

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

• 一是應(yīng)用方的大數(shù)據(jù)平臺(tái)主動(dòng)上云：使用大數(shù)據(jù)技術(shù)的業(yè)務(wù)應(yīng)用建設(shè)方，不再自建數(shù)據(jù)中心，而是將大數(shù)據(jù)平臺(tái)搬到了云上，有的是在云廠商的 IaaS 層上自建大數(shù)據(jù)平臺(tái)(現(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等)，而且在上云的過(guò)程中，大家都很重視混合云和多云部署，避免 vendor-lockin;
• 二是云計(jì)算廠商在不斷推出云上托管的各種基于大數(shù)據(jù)服務(wù)，以吸引更多業(yè)務(wù)方上云：各大云廠商為了提高自己的市場(chǎng)競(jìng)爭(zhēng)力，從而進(jìn)一步鞏固和拓寬自己的市場(chǎng)地位，都在積極推出各種托管的大數(shù)據(jù)相關(guān)產(chǎn)品，有 s3/oss, emr/e-mapreduce，有 aws redshift, 有阿里云 maxcompute，還有各種云上數(shù)據(jù)庫(kù)，云上 serverless 形態(tài)的各種大數(shù)據(jù)服務(wù)等等，該名單還在不斷增長(zhǎng)中。
• 三是各傳統(tǒng)大數(shù)據(jù)廠商已經(jīng)轉(zhuǎn)向依托云來(lái)提供自己的產(chǎn)品和服務(wù)，如 elastic 很早就開(kāi)始基于云交付自己的elk 技術(shù)棧了，如 spark 背后的商業(yè)公司 databricks 的大數(shù)據(jù)平臺(tái)和產(chǎn)品一直都是基于云來(lái)向客戶(hù)提供服務(wù)的(可以對(duì)接aws, gcp, azure等云平臺(tái))，如 cloudera 不斷探索改變自己的商業(yè)模式(從大數(shù)據(jù)三駕馬車(chē)的輝煌期，到業(yè)績(jī)下滑下的和 hortorworks的合并，再到主動(dòng)改變商業(yè)模式基于云來(lái)交付自己的產(chǎn)品和服務(wù)，甚至數(shù)據(jù)中心版的大數(shù)據(jù)平臺(tái)都改名為了 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)“存儲(chǔ)計(jì)算分離”的理念。各個(gè)新推出的組件和框架主動(dòng)擁抱云原生，如 pulsa，TiDB 等都是依托于存儲(chǔ)計(jì)算分離的云原生架構(gòu); 各個(gè)傳統(tǒng)的組件雖然有歷史包袱，也在不斷求新求變，如 flink/spark 都深度整合支持了 kubernetes 集群模式;如 kafka也在不斷探索如花云化：包括完全去掉zookeeper依賴(lài)，包括 Rebalance Protocol 的 Static Membership 等;正如古語(yǔ)所言，“順則昌不順則亡”，一些不適應(yīng)云原生架構(gòu)的技術(shù)組件，其市場(chǎng)正在不斷萎縮，如很多場(chǎng)景下，kubernetes 都替代了yarn, 對(duì)象存儲(chǔ) oss/s3 等也在替代 hdfs (我們也注意到了apache 社區(qū)推出的 Ozone，該組件在對(duì)象存儲(chǔ)的基礎(chǔ)上，也融合推出了文件系統(tǒng)api，該組件的背后有很多原 hdfs 社區(qū)的 committer在貢獻(xiàn)代碼，在 cloudera 的 cdp 平臺(tái)中也內(nèi)嵌支持了該組件)。下圖展示了 flink/spark跟 kubernetes 的深度整合：(注意不是簡(jiǎn)單的使用 k8s operator 將 spark/flink 作業(yè)運(yùn)行在 k8s 集群中，而是 native 的深度的整合)
• 大數(shù)據(jù)云與計(jì)算的深度融合是大勢(shì)所趨，其主要體現(xiàn)在以上四個(gè)方面，需要強(qiáng)調(diào)的是，這四個(gè)方面是相輔相成，互相促進(jìn)的。
  • 如應(yīng)用方的大數(shù)據(jù)平臺(tái)上云的需求，促使了云計(jì)算廠商推出更好的托管的大數(shù)據(jù)增值服務(wù);
  • 而云計(jì)算廠商推出的更多更好的大數(shù)據(jù)增值服務(wù)，也反過(guò)來(lái)促使了更多的應(yīng)用方大數(shù)據(jù)平臺(tái)上云;
  • 如基礎(chǔ)設(shè)施上云的大趨勢(shì)，促使了具體的大數(shù)據(jù)組件調(diào)整自身架構(gòu)從而云化(因?yàn)轫槃t昌不順則亡);
  • 而大數(shù)據(jù)具體組件云原生化的架構(gòu)調(diào)整，也反過(guò)來(lái)促使了云計(jì)算廠商和大數(shù)據(jù)廠商能夠基于云基礎(chǔ)設(shè)施推出更多更好的大數(shù)據(jù)服務(wù)。

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

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

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

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

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

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

infinite storage with confluent cloud

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

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

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

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

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

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

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

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

• 一方面，大數(shù)據(jù)需要AI:
  • 大數(shù)據(jù)的元數(shù)據(jù)管理需要AI: 當(dāng)企業(yè)面對(duì)數(shù)據(jù)量大且種類(lèi)繁多的數(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ù)，快速提供來(lái)自于不同數(shù)據(jù)源的數(shù)據(jù)并自動(dòng)化數(shù)據(jù)管理。這其中會(huì)更多地用到圖計(jì)算和知識(shí)圖譜，“Graphs form the foundation of data fabrics and knowledge graphs“，來(lái)幫助我們發(fā)現(xiàn)數(shù)據(jù)之間潛在的關(guān)聯(lián)關(guān)系。
  • 大數(shù)據(jù)將我們從從BI時(shí)代帶到了AI時(shí)代, 對(duì)數(shù)據(jù)的分析也不再是BI時(shí)代簡(jiǎn)單的統(tǒng)計(jì)分析和提供各種報(bào)表，而是AI時(shí)代更強(qiáng)調(diào)的綜合使用各種算法做 Augmented analytics 提供 data story等商業(yè)洞察;
  • 在物聯(lián)網(wǎng)的各種邊緣設(shè)備 edge 上也更加提倡通過(guò)邊緣計(jì)算內(nèi)嵌各種 ML 和 AI 模型，將基于AI的計(jì)算推到更靠近數(shù)據(jù)產(chǎn)生的地方，以提供更高的數(shù)據(jù)時(shí)效性，以減少數(shù)據(jù)傳輸，以挖掘更多應(yīng)用場(chǎ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)中提取出來(lái)數(shù)據(jù)，存放在本地文件系統(tǒng)中，再進(jìn)行模型的訓(xùn)練;不過(guò)已經(jīng)有一些大數(shù)據(jù)框架，著手于利用大數(shù)據(jù)系統(tǒng)中的數(shù)據(jù)直接進(jìn)行模型訓(xùn)練和模型部署與應(yīng)用了，比如 spark mllib, koalas, flink ml;我們也看到，alluxio client 通過(guò) fuse api 接口以本地文件的形式，直接提供大數(shù)據(jù)平臺(tái)中的數(shù)據(jù)給算法模型進(jìn)行訓(xùn)練，起到了數(shù)據(jù)橋梁的作用，減少了中間數(shù)據(jù)導(dǎo)出的繁瑣過(guò)程。
  • 三要素中的算力，也可以依賴(lài)大數(shù)據(jù)的集群資源管理框架來(lái)提供，比如 yarn 在對(duì) cpu 和 mem 資源管理的基礎(chǔ)上，已經(jīng)擴(kuò)展支持了對(duì) gpu 資源的管理;
  • 三要素中的算法，在很多大數(shù)據(jù)框架也直接提供了對(duì)常見(jiàn)算法的實(shí)現(xiàn)，比如 spark mllib, flink ml等。

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

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

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

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

在數(shù)據(jù)治理上，前文提到，當(dāng)企業(yè)面對(duì)數(shù)據(jù)量大且種類(lèi)繁多的數(shù)據(jù)資產(chǎn)時(shí)(大數(shù)據(jù)的 5V 包括 volume 和 variety)，如何有效管理和使用這些數(shù)據(jù)以挖掘更大商業(yè)價(jià)值，就尤其需要數(shù)據(jù)治理和元數(shù)據(jù)管理了。此時(shí)元數(shù)據(jù)的范疇和概念有擴(kuò)大化的趨勢(shì)，元數(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ù)，快速提供來(lái)自于不同數(shù)據(jù)源的數(shù)據(jù)并自動(dòng)化數(shù)據(jù)管理。這其中會(huì)更多地用到圖計(jì)算和知識(shí)圖譜，“Graphs form the foundation of data fabrics and knowledge graphs“，來(lái)幫助我們發(fā)現(xiàn)數(shù)據(jù)之間潛在的關(guān)聯(lián)關(guān)系。

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

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

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

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

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

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

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