快手大數(shù)據(jù)架構(gòu)演進實錄，真的不一般

關(guān)注我們,設(shè)為星標,每天7:30不見不散,架構(gòu)路上與您共享 
回復"架構(gòu)師"獲取資源

快手大數(shù)據(jù)架構(gòu)團隊是在 2017 年開始組建的，整個大數(shù)據(jù)架構(gòu)服務也是從那時開始演進發(fā)展的。出于目標與成本上的考慮，快手的大數(shù)據(jù)架構(gòu)服務大部分都是基于開源系統(tǒng)構(gòu)建的。截止到目前為止，快手的大數(shù)據(jù)架構(gòu)的發(fā)展大概經(jīng)歷 3 個階段：

2017 年左右，快手大數(shù)據(jù)架構(gòu)服務主要以支持離線分析場景為主，服務建設(shè)首先從離線存儲計算服務起步，行業(yè)內(nèi)已經(jīng)公認 Hadoop 是解決這類場景的最佳方案，考慮到后續(xù)我們會基于這個版本之上進行持續(xù)開發(fā)迭代，所以我們選擇下載 CDH Hadoop 2.6 的源代碼（選擇 CDH 版本是因為比 apache 版本要更加穩(wěn)定，且沒有選擇更高版本，也是基于穩(wěn)定性的考慮，不過現(xiàn)在想起來，其實當時可以換到最新版本），并編譯源碼進行部署。主要以推廣應用、解決業(yè)務問題，以及做一些輕量型的改進為主。此外，快手在一開始就重度依賴 Kafka 服務，除了離線日志收集傳輸場景外，還包括在線服務消息隊列以及 cache 同步場景。選擇 Kafka 主要是因為其性能好且有大廠（LinkedIn）最佳實踐。我們對 Kafka 系統(tǒng)的建設(shè)起步還算比較早的，那時主要在解決 Kafka 集群擴展性與可用性的問題，在 2017 年 11 月，我們就解決了 Kafka 集群的擴容問題，能夠做到集群擴容對業(yè)務基本無影響，且整個擴容流程自動化完成，有興趣的同學可參考 2019 年北京 QCon 上分享的議題：《快手萬億級別 Kafka 集群應用實踐與技術(shù)演進之路》。

https://www.infoq.cn/article/Q0o*QzLQiay31MWiOBJH?utm_source=tuicool&utm_medium=referral

大概在 2018 上半年，大數(shù)據(jù)架構(gòu)服務開始延伸到實時計算以及交互式分析場景。對于實時計算場景，我們采用了 Flink 引擎，主要是因為 Flink 完全是原生的實時計算引擎，相比于 Storm，有著豐富實時語義的實現(xiàn)、窗口抽象、狀態(tài)存儲等能力，為開發(fā)者提供了非常多便利的工具。相比于 Spark，F(xiàn)link 的實時性更好。對于 OLAP 分析需求，我們采用 Druid 引擎，并同時提供了配套的 Superset 交互分析可視化平臺。該系統(tǒng)一經(jīng)落地，受到了廣泛研發(fā)同學的喜愛，并得到了快速的發(fā)展。在 OlAP 引擎上，我們最終沒有選擇 Kylin，主要的原因是 Druid 有著更好的實時性、更多查詢能力以及更大的查詢靈活性。Kylin 雖然有數(shù)據(jù)立方體建模加速查詢能力，但是 Druid 的物化能力也可以做到類似的效果（不過當時物化功能開源版本沒有實現(xiàn)，后來我們自己實現(xiàn)了）。

快手的大數(shù)據(jù)架構(gòu)存儲服務除了支持離線存儲場景之外，還同時在支持快手短視頻在線存儲場景?？焓侄桃曨l存儲平臺（對象存儲平臺），內(nèi)部代號 blobstore，采用 HDFS 服務存儲對象的數(shù)據(jù)本身，同時采用 HBase 存儲對象的索引，整體由 gateway 服務進行對象存儲邏輯層的實現(xiàn)。作為對象存儲服務而言，這套架構(gòu)設(shè)計的簡單且實用。截止到目前，快手的對象存儲服務仍沿用著這套基礎(chǔ)架構(gòu)，并進行了功能與能力上的大范圍增強。前期我們主要做了一些 HDFS、HBase 服務面向在線場景下的可用性改進，如單點宕機快速恢復等。

還有一個方面是運維，我一直堅持大數(shù)據(jù)架構(gòu)服務運維和研發(fā)要在同一個團隊，主要是因為大數(shù)據(jù)架構(gòu)服務眾多，導致運維流程繁多，且非常復雜。整體運維和研發(fā)的溝通協(xié)作非常頻繁。同一個團隊可以更加密切配合。在運維上，我們一開始就主張盡可能通過平臺化的方式提效整個運維工作，所以在開始階段，我們就強調(diào)運維操作的復用性，運維以自動化，工具化構(gòu)建為主，并引入 ambari 作為大數(shù)據(jù)服務運維的基礎(chǔ)平臺，逐漸開始接管各類大數(shù)據(jù)架構(gòu)服務，并鼓勵運維同學多總結(jié)目前沒有被平臺化的操作流程，提煉流程的通用性，為下一步全面平臺化運維做好準備工作。

截止到 2018 年 6 月左右，整個大數(shù)據(jù)架構(gòu)系統(tǒng)已經(jīng)初步完成存儲、調(diào)度、計算層服務與運維的從 0 到 1 的建設(shè)，并已經(jīng)在快手大范圍應用起來了。

公司業(yè)務進一步擴大與高速增長，給整個大數(shù)據(jù)架構(gòu)服務的穩(wěn)定性、擴展性、性能都帶來了巨大的沖擊。作為應對，在大數(shù)據(jù)架構(gòu)服務從 0 到 1 的構(gòu)建之后，我們開始夯實各層服務的現(xiàn)有能力，對現(xiàn)有的開源服務進行大量的深度開發(fā)與定制。受限于篇幅限制，這里主要會挑一些重點的改進簡單介紹下。

在存儲服務上，HDFS/HBase 服務主要的改進包括：單點故障快速恢復、讀寫性能優(yōu)化、服務分級保障與回退等待、服務柔性可用、fastfail、QPS 限流、擴展性改進等，此外我們還自研了位圖數(shù)據(jù)庫 BitBase，用于 UV 計算，留存計算等場景。簡單介紹下 HDFS 服務分級保障能力，這個功能主要是面對離線場景的。在離線計算的場景下，集群整體業(yè)務負載基本上沒有固定規(guī)律，因為個別大作業(yè)啟動起來后，會直接造成 HDFS 主節(jié)點的滿載，滿載的主要表現(xiàn)是服務延遲升高，QPS 打平，RPC 服務請求堆積。一旦該現(xiàn)象出現(xiàn)在凌晨時段，將會影響核心鏈路數(shù)據(jù)的產(chǎn)出，造成故障。為了保障核心鏈路的生產(chǎn)的穩(wěn)定，我們引入了優(yōu)先級的概念，并連同計算資源調(diào)度服務一起，給核心作業(yè)（高優(yōu)先級）提供計算與存儲資源的整體保障。在實現(xiàn)上，HDFS 主節(jié)點 RPC 服務采用多隊列設(shè)計，將不同優(yōu)先級的作業(yè)請求路由到不同隊列，處理線程池線程按照不同比例從不同隊列取請求進行處理，一旦高優(yōu)先級隊列請求出現(xiàn)高時延情況，則直接降低低優(yōu)先級隊列請求處理比例，將資源向高優(yōu)先級隊列傾斜，從而保障高優(yōu)先級作業(yè)請求的延遲穩(wěn)定。如果低優(yōu)先級隊列滿，則反饋給客戶端特殊信號，客戶端進行 backoff 等待重試。由于核心作業(yè)相對穩(wěn)定，負載也相對穩(wěn)定，基本不會出現(xiàn)由于核心作業(yè)導致服務過載的情況。通過這個能力的控制，可以保障核心作業(yè)的數(shù)據(jù)產(chǎn)出延遲穩(wěn)定，不受低優(yōu)異常作業(yè)流量徒增的影響。

在 Kafka 消息服務上，主要改進包括單點故障快速恢復、平滑擴容、Mirror 服務集群化、資源隔離、Cache 改造、智能限速、QPS 限流、柔性可用、Kafka On HDFS 存儲計算分離等。簡單介紹下 Kafka On HDFS 這個能力，Kafka 服務的性能主要依賴內(nèi)存 cache 層，一旦讀數(shù)據(jù) miss cache，會產(chǎn)生磁盤讀操作（lag 讀），由于目前磁盤主要還是機械盤，因此一旦 lag 讀，性能會急劇下降。此外，如果 topic 的 consumer group 很多的話，非常容易造成磁盤單盤熱點，使得性能進一步惡化，甚至影響 broker 上的其他 topic 的讀寫操作。另一方面，隨著業(yè)務快速發(fā)展，Kafka 集群規(guī)模也越來越大，原有 Kafka 的架構(gòu)模式在超大規(guī)模下會造成大量的運維成本。為了解決上述兩個問題，我們開發(fā)了 Kafka On HDFS 方案，并控制一旦 group 的讀操作產(chǎn)生了 cache miss，broker 會直接從 HDFS 讀取數(shù)據(jù)返回給消費者，且由于 HDFS 的數(shù)據(jù)是按照塊打散的，所以在消費者 lag 讀的時候，能夠充分利用多盤的能力支持讀，進而提升 lag 讀性能。另一方面，由于 Kafka On HDFS 方案可實現(xiàn)存儲與計算的分離，這樣 broker 變成了無狀態(tài)的服務，在單點宕機的時候，可以直接從 HDFS 上恢復，感興趣的同學可以關(guān)注 2020 年 Qcon 北京的議題：《快手實時處理系統(tǒng)存儲架構(gòu)演進之路》

https://qcon.infoq.cn/2020/beijing/presentation/2344

在調(diào)度引擎上，主要改進點是資源超配功能以及自研了 YARN 的新版本調(diào)度器 KwaiScheduler，改進調(diào)度性能，并定制了大量的調(diào)度策略、例如標簽調(diào)度、作業(yè)分級阻斷、基于用戶的公平調(diào)度、基于優(yōu)先級的調(diào)度等，此外還重構(gòu)了資源搶占模塊。其中 KwaiScheduler 采用了分批與并行混合調(diào)度方案，SLS 工具評測出來的調(diào)度性能相比于 apache hadoop3.0 的版本有 20~30 倍提升，調(diào)度性能可達：2.5w/s~3.5w/s。

 YARN 的新版本調(diào)度器 KwaiScheduler：

https://www.infoq.cn/article/vkH8pdfqAZFh3YXaSSsG

在計算引擎上，自研了智能 SQL 引擎 Beacon，可以自動路由 Presto、Spark、MR 引擎，整個引擎路由完全對用戶透明，提升了性能并降低了使用成本。OLAP 引擎上，深度定制 Druid 系統(tǒng)，開發(fā)了物化視圖功能、精準去重功能、中心節(jié)點優(yōu)化改進單集群擴展性、資源隔離以及可用性改進點等。此外，我們還引入了 Clickhouse 引擎，并同時自研了 Clickhouse On HDFS 服務 KwaiCH，徹底解決了 Clickhouse 服務運維難，擴容難的問題。實時引擎上，增加新的狀態(tài)存儲引擎 SlimBase，Source 同步消費功能，JobManger 高可用、實時 SQL 建模等。

智能 SQL 引擎 Beacon：

https://www.infoq.cn/article/BN9cJjg1t-QSWE6fqkoR?utm_source=related_read

Clickhouse On HDFS 服務 KwaiCH

https://www.infoq.cn/article/vGabIOdeUM87hv6X8qlL?from=singlemessage

狀態(tài)存儲引擎 SlimBase

https://open.mi.com/conference/hbasecon-asia-2019

在運維上，基于 ambari 自研了可以管理 10w+ 機器規(guī)模的服務管理平臺 Kalaxy，基本囊括了大數(shù)據(jù)服務運維、基礎(chǔ)運維的全部場景。極大提升了運維效率。

從 2020 年開始，快手大數(shù)據(jù)架構(gòu)整體上會做進一步整合，并朝向云化服務發(fā)展，為公司各業(yè)務線提供一體式的大數(shù)據(jù)基礎(chǔ)服務。具體詳情，敬請期待。

當聽到快手成為 2020 年春節(jié)聯(lián)歡晚會獨家互動合作伙伴時，我是非常興奮的，同時也是壓力巨大的。和春晚活動相關(guān)的大數(shù)據(jù)服務包括：在線短視頻上傳服務、在線消息中間件服務、實時計算、日志上傳與離線計算。

在線場景下，主要是要能扛住極端并發(fā)下的峰值流量，保障活動期間服務整體穩(wěn)定運行。原有的 HDFS、HBase、Kafka 服務在面對超高并發(fā)請求的壓力下，可能會出現(xiàn)服務雪崩以及大規(guī)模的節(jié)點不可用的情況，將會造成重大事故。于是，為了應對可能的極限峰值壓力，我們在三個月的時間內(nèi)開發(fā)并上線了過載保護、服務限流與快速 failover、分級保障等能力，實現(xiàn)了 HDFS、HBase、Kafka 三類服務的柔性可用，以及靈活的服務請求控制能力，使得 HDFS、HBase、Kafka 服務在極端壓力下，也可以保持峰值吞吐提供服務。當然也不能只依賴服務管控的方式，在服務容量規(guī)劃與評估上，我們也做了大量的工作，最終也是比較精準的預測了春晚的流量。在整個三個月里，我們也進行了非常多次的全鏈路壓測與故障演練，以便確認系統(tǒng)在超高壓力下的能夠提供高穩(wěn)定性的服務。

實時計算場景下，主要是保障活動實時大盤的高穩(wěn)定性運行。為了保障實時服務整體穩(wěn)定，我們除了開發(fā)并上線服務柔性可用的能力以及進行壓測之外，還針對活動以及核心數(shù)據(jù)的實時生產(chǎn)，建設(shè)了多條互備的物理鏈路，一旦單條物理鏈路出現(xiàn)問題，可以隨時切換到另外一條上，保障了活動期間實時數(shù)據(jù)的產(chǎn)出的高穩(wěn)定性。

離線場景下，主要面臨的問題是日志服務可能會被降級，會導致生產(chǎn) ODS 層數(shù)據(jù)延遲，進而導致公司級別的離線核心數(shù)據(jù)的產(chǎn)出出現(xiàn)延遲。此外，活動當天的數(shù)據(jù)規(guī)模以及日志服務恢復時可能帶來的峰值不好預期，所以數(shù)據(jù)真實的恢復時間也不好評估，給離線鏈路的核心數(shù)據(jù)產(chǎn)出的預案設(shè)計帶來了非常大的困難。為了應對這種情況，我們首先把作業(yè)按照重要性進行了分級，并制定了多種情況下的數(shù)據(jù)恢復以及數(shù)據(jù)的分級產(chǎn)出方案。在資源保障上，YARN 提供了按照優(yōu)先級進行作業(yè)阻斷提交與回收的能力，以及按照作業(yè)優(yōu)先級進行資源調(diào)度的能力，保障了離線鏈路上核心數(shù)據(jù)的及時產(chǎn)出。

通過對大數(shù)據(jù)架構(gòu)服務，面向以上幾種場景下能力的改造，我們順利完成了整個春晚活動的穩(wěn)定性保障任務。整體活動期間，各類大數(shù)據(jù)架構(gòu)服務整體穩(wěn)定平穩(wěn)，全部達成了之前穩(wěn)定性預期的目標。

大數(shù)據(jù)架構(gòu)團隊針對資源調(diào)度系統(tǒng) YARN 做了很多非常好的改進以及資源上的規(guī)劃。

在資源管理上，1）采用了”隊列隔離 + 優(yōu)先級調(diào)度能力”的雙層保障。規(guī)劃了生產(chǎn)隊列、adhoc 隊列、回溯隊列、test 隊列，以便做到不同大類別作業(yè)的資源消耗的隔離，不同類型的作業(yè)相互之間不受影響。此外，每個作業(yè)都要設(shè)置優(yōu)先級，并在隊列內(nèi)部提供了按照作業(yè)優(yōu)先級進行資源調(diào)度與隔離的能力，可細粒度控制不同等級作業(yè)資源消耗，最終實現(xiàn)分級保障的目標；2）給每個業(yè)務線設(shè)置 quota（quota 等于 minshare），并保障在任何情況下，每個業(yè)務線都可以使用到 quota 數(shù)量的資源。

在調(diào)度策略上，1）針對同一集群不同性質(zhì)的作業(yè)利用標簽調(diào)度進行物理隔離，例如離線作業(yè)、實時作業(yè)之間的物理隔離；2）針對 adhoc 場景，提供按照個人用戶公平的資源的調(diào)度策略，以便保障每個人都能獲得相同資源，避免一個人由于提交作業(yè)過多而占用大量資源的情況；3）重構(gòu)并開啟了資源搶占功能，解決由于大作業(yè)長時間占用資源不釋放導致 quota 資源量不能被快速滿足的情況。4）開發(fā)上線 App Slot 搶占能力，避免高優(yōu)先級受最大 APP 限制不能快速執(zhí)行的問題。

Hadoop 是快手大數(shù)據(jù)架構(gòu)體系的一部分，通常說的 Hadoop 指的是 HDFS、YARN、MR 這三個服務。目前 Hadoop 主要應用在離線數(shù)據(jù)分析場景。

HDFS 是海量離線數(shù)據(jù)存儲底層基礎(chǔ)服務，快手所有離線的數(shù)據(jù)都存儲在 HDFS 上，其規(guī)模達 EB 級別，為了降低成本，我們還采用 EC 技術(shù)進一步降低副本空間，目前快手 EC 的數(shù)據(jù)規(guī)模達數(shù)百 PB。

YARN 系統(tǒng)為各種計算類型作業(yè)（MR、Spark、FLink 等）進行資源的分配與調(diào)度。我們自研了 YARN 的新型調(diào)度器 KwaiScheduler，評測的調(diào)度性能可達：2.5w/s~3.5w/s，相比于 Apache Hadoop 3.0 的版本有 20~30 倍提升。此外，kwaiScheduler 提供了可插拔的調(diào)度策略，增加調(diào)度策略變得極其容易，目前借助該功能提供了混合式的調(diào)度策略：針對 adhoc 場景，提供面向個人公平的資源調(diào)度策略；針對數(shù)據(jù)例行生產(chǎn)，提供面向作業(yè)優(yōu)先級的調(diào)度策略；面向?qū)崟r場景，提供資源均衡的調(diào)度策略等等。

此外，為了進一步改進性能，我們在進行 Spark 引擎替換 MR 引擎的工作，快手的 MR 引擎的作業(yè)占比在逐漸減低中，但是由于 MR 引擎出色的穩(wěn)定性表現(xiàn)，在部分核心 ETL 場景下，MR 引擎可能會被保留。

綜上所述，Hadoop 是非常核心的底層基礎(chǔ)服務，在快手大數(shù)據(jù)架構(gòu)體系中占據(jù)著核心地位。

Hadoop（狹義 Hadoop）主要指的是 HDFS、YARN、MR 這三個服務，主要解決了企業(yè)離線數(shù)據(jù)分析的場景需求。近幾年新型開源分析系統(tǒng) Spark、Flink、Druid、Clickhouse 等在實時性，性能上比 Hadoop 有很大程度的提升與補充。但是這些系統(tǒng)也僅僅是對 MR 這個計算引擎的替換，目前在大數(shù)據(jù)場景下，主流的存儲與資源管理系統(tǒng)仍然是 HDFS 和 YARN，且短期內(nèi)不會出現(xiàn)什么變化。

之所以存儲會選擇 HDFS，一方面是因為 HDFS 系統(tǒng)的穩(wěn)定性、可靠性以及擴展性非常出色，另一方面，企業(yè)現(xiàn)有的數(shù)據(jù)已經(jīng)存儲到 HDFS 系統(tǒng)上，遷移本身成本也是比較大的。整體上沒有什么強烈理由需要替換。

對于 YARN 系統(tǒng)而言，雖然 K8s 目前發(fā)展勢頭強勁，但是大部分企業(yè)仍然應用 K8s 在在線服務領(lǐng)域，離線數(shù)據(jù)分析領(lǐng)域?qū)嵺`少之又少。主要是因為 K8s 系統(tǒng)在調(diào)度能力上，以及對現(xiàn)有分析引擎的支持上還不是特別完善。而 YARN 本身也在快速迭代，且各大互聯(lián)網(wǎng)公司對 YARN 的調(diào)度能力以及擴展性、甚至資源超配都做到很大的改進。整體上替換 YARN 的動力也不強。未來一個可能的方向是要考慮如何將 YARN 和 K8S 服務整體一起，提供統(tǒng)一的調(diào)度服務。

所以，我覺得對于自己組建大數(shù)據(jù)架構(gòu)服務的企業(yè)來說，要對整個大數(shù)據(jù)生態(tài)的基礎(chǔ)服務有比較深入的了解。從應用上看，Hadoop 仍然是一個很好的大數(shù)據(jù)基礎(chǔ)服務，只不過要因地制宜，且把更多能力更強的新型系統(tǒng)引入到企業(yè)中，幫助解決不同場景下的需求。最后再做到服務整合，在提升性能的前提下，減少業(yè)務的使用成本。

首先再明確下這兩個概念：

大數(shù)據(jù)架構(gòu)：是為解決大數(shù)據(jù)業(yè)務場景需求的分布式基礎(chǔ)服務，其定位可以認為是大數(shù)據(jù)方向的基礎(chǔ)架構(gòu)。整體上可劃分為三個層次

• 分布式存儲層：主要包括各類大數(shù)據(jù)場景的存儲服務，如分布式文件系統(tǒng)（HDFS）、分布式 KV 系統(tǒng)（HBase）以及分布式消息緩存（Kafka）等。主要解決的是海量數(shù)據(jù)的存儲問題（也有相當多的互聯(lián)網(wǎng)公司利 Kafka 系統(tǒng)進行數(shù)據(jù)傳輸接入）

• 分布式調(diào)度層：資源調(diào)度層目前主要使用的 YARN，提供了一個資源池抽象層，把各類計算引擎作業(yè)統(tǒng)一管理與調(diào)度。

• 計算引擎層：是面向各類場景的計算引擎，包括解決實時計算場景需求的 Flink 系統(tǒng)，解決離線計算場景的 SQL 類引擎，以及解決交互式分析場景下的 adhoc 以及 olap 引擎。

云架構(gòu)：是實現(xiàn)云計算能力的底層基礎(chǔ)服務與設(shè)施，行業(yè)內(nèi)公認的云架構(gòu)分為三大層次：

• 基礎(chǔ)設(shè)施層（IaaS，基礎(chǔ)設(shè)施即服務）：將基礎(chǔ)設(shè)施，例如網(wǎng)絡，機器等硬件資源抽象成服務，提供給客戶使用，解決了客戶在如何采購機器，建設(shè)機房，以及構(gòu)建網(wǎng)絡等基礎(chǔ)類工作的問題。

• 平臺層（PaaS，平臺即服務）：將平臺，例如開發(fā)、存儲、調(diào)度與計算平臺等，做整合抽象成服務，為用戶提供了開發(fā)環(huán)境，解決用戶快速構(gòu)建業(yè)務服務的能力。

• 軟件服務層（SaaS，軟件即服務）：將軟件，例如推送、反作弊等應用，作為服務提供?？蛻艨梢愿鶕?jù)需求通過互聯(lián)網(wǎng)向廠商訂購，并使用應用軟件服務。

從這兩個概念上看，大數(shù)據(jù)架構(gòu)可以認為是云架構(gòu)中 PaaS 層的一部分。專注于為客戶提供在大數(shù)據(jù)場景下的業(yè)務快速構(gòu)建能力。大數(shù)據(jù)架構(gòu)服務，連同數(shù)據(jù)生產(chǎn)開發(fā)套件一起為面向數(shù)據(jù)分析的客戶提供一體式的 PaaS 層解決方案。從這個方面上看，即使在云架構(gòu)中，依然會保留大數(shù)據(jù)架構(gòu)技術(shù)。

從各自發(fā)展上來看，創(chuàng)業(yè)企業(yè)、小型企業(yè)以及一部分中型企業(yè)，需求相對來說可能會比較簡單，出于成本、人力的考慮，會投向云架構(gòu)提供的服務上，以便快速實現(xiàn)業(yè)務邏輯提供產(chǎn)品獲取利潤。對于大型企業(yè)以及一部分中型企業(yè)而言，業(yè)務體量很大，面臨的需求也會變得豐富、個性化且復雜，云架構(gòu)所提供的服務，不一定能夠完全滿足具體的場景與需求，此外，如果放到云上，數(shù)據(jù)本身也存在安全層面的隱患，所以除了成本因素外，還會考慮快速支持、安全等因素，通常會自建大數(shù)據(jù)架構(gòu)服務，以便有效支撐企業(yè)發(fā)展。當然在這些企業(yè)中的大數(shù)據(jù)架構(gòu)技術(shù)并不是簡單的拿來應用，與此同時，還會對其進行大量深度定制開發(fā)，以便滿足企業(yè)發(fā)展需求。整個大數(shù)據(jù)架構(gòu)技術(shù)會也會向著服務能力整合統(tǒng)一，以及企業(yè)內(nèi)部云化的方向發(fā)展。

所以從上述兩個方面看，大數(shù)據(jù)架構(gòu)技術(shù)并不會沒落，且會和云架構(gòu)一樣繼續(xù)蓬勃發(fā)展。