開篇語

近幾年互聯(lián)網(wǎng)服務(wù)安全事故的頻發(fā)，使得越來越多的企業(yè)及開發(fā)者意識(shí)到數(shù)據(jù)備份、災(zāi)備等重要性，高可用性、高容災(zāi)性及高可擴(kuò)展性的系統(tǒng)和架構(gòu)建設(shè)工作也被更多地置于重心。

在這個(gè)過程中，基于公有云提供的基礎(chǔ)設(shè)施實(shí)現(xiàn)高可用已成為多數(shù)技術(shù)團(tuán)隊(duì)的選擇。

而面對(duì)跨區(qū)域+高可用需求時(shí)，許多開發(fā)者卻犯了難，一方面業(yè)務(wù)場景的不同對(duì)架構(gòu)設(shè)計(jì)提出了不盡相同的需求，基本上沒有可完全復(fù)制的架構(gòu)模版;另一方面是納入考慮的因素在不斷增多，數(shù)據(jù)延遲、成本開銷、物理隔離、快速的恢復(fù)能力……如何能在加法的基礎(chǔ)上做好減法，對(duì)技術(shù)團(tuán)隊(duì)創(chuàng)新能力提出了更高要求。

對(duì)此，我們專訪了FreeWheel架構(gòu)師張磊及FreeWheel 首席工程師姜冰，探討在服務(wù)全球6個(gè)數(shù)據(jù)中心，日均產(chǎn)生近10億廣告投放展示日志的場景下，做好跨區(qū)域高可用的實(shí)踐之道。

跨區(qū)域、高可用性實(shí)踐背景

數(shù)據(jù)處理平臺(tái)提出的多維挑戰(zhàn)

作為美國Comcast旗下領(lǐng)先的視頻廣告管理和投放平臺(tái)，F(xiàn)reeWheel的數(shù)據(jù)來自于全球6大數(shù)據(jù)中心(美國東西海岸各兩個(gè)、歐洲兩個(gè))，每天產(chǎn)生10億左右的廣告投放展示日志，新增超過3TB的數(shù)據(jù)，并且有至少18個(gè)月的數(shù)據(jù)可以隨時(shí)滿足查詢尋求。

在數(shù)據(jù)應(yīng)用對(duì)實(shí)時(shí)性和可靠性要求逐漸增加的情況下， FreeWheel根據(jù)其自身數(shù)據(jù)特點(diǎn)和應(yīng)用需求，采用了一套以Kafka，Hadoop和HBase為核心的Lambda處理架構(gòu)。

其中，各個(gè)數(shù)據(jù)中心的廣告服務(wù)器實(shí)時(shí)地將廣告數(shù)據(jù)傳輸?shù)奖镜豄afka集群。中心化的Kafka MirrorMaker將多數(shù)據(jù)中心的數(shù)據(jù)聚集到一個(gè)全局的Kafka集群。流式處理框架會(huì)從全局Kafka集群消費(fèi)數(shù)據(jù)，處理之后一方面寫回Kafka(為下游的各類實(shí)時(shí)應(yīng)用服務(wù));一方面寫入HBase，并由Hadoop離線作業(yè)將HBase的內(nèi)容聚合轉(zhuǎn)換成Parquet文件寫入HDFS。構(gòu)建于Presto之上的OLAP服務(wù)會(huì)同時(shí)查詢HBase和HDFS，對(duì)外提供數(shù)據(jù)的實(shí)時(shí)或批量查詢(整體架構(gòu)見下圖)。

 

 

FreeWheel數(shù)據(jù)處理系統(tǒng)架構(gòu)圖

FreeWheel部署的這一套數(shù)據(jù)處理系統(tǒng)，很好地實(shí)現(xiàn)了預(yù)期的設(shè)計(jì)目標(biāo)。但過往幾年里，隨著數(shù)據(jù)量的不斷增長和業(yè)務(wù)變化的需求，這種模式面臨了如下挑戰(zhàn)：

可擴(kuò)展性：越來越多的數(shù)據(jù)產(chǎn)品接入到新的數(shù)據(jù)平臺(tái)，對(duì)OLAP服務(wù)的擴(kuò)展性提出了嚴(yán)苛的要求。而在自建的數(shù)據(jù)中心，受限于規(guī)劃和整體容量，很難根據(jù)需求靈活地?cái)U(kuò)展。 同時(shí)，在“超級(jí)碗”這樣大型賽事的直播帶來流量瞬時(shí)波動(dòng)的場景下，傳統(tǒng)的數(shù)據(jù)中心也很難滿足對(duì)容量的彈性需求。

高可用性：雖然像Hadoop這樣的大數(shù)據(jù)基礎(chǔ)設(shè)施本身可以保證一定程度的高可用性，但在遇到數(shù)據(jù)中心整體性故障時(shí)，依然會(huì)對(duì)服務(wù)造成影響。

開發(fā)和測試效率：大數(shù)據(jù)平臺(tái)開發(fā)和測試中，基于真實(shí)環(huán)境的集成測試和性能測試可以覆蓋單元測試和回歸測試的盲區(qū)，這需要經(jīng)常啟停一些基礎(chǔ)組件甚至整套端到端服務(wù)。但在自有數(shù)據(jù)中心里，受到資源限制，很難做到及時(shí)滿足需求，因而也降低了開發(fā)和測試的效率。

理論上，上述挑戰(zhàn)中的一部分可通過在另一個(gè)自建數(shù)據(jù)中心里再部署一套數(shù)據(jù)處理系統(tǒng)解決或緩解，但考慮到規(guī)劃、擴(kuò)容所需時(shí)長以及問題根治性等因素，在2016年底，F(xiàn)reeWheel決定與AWS合作，將數(shù)據(jù)平臺(tái)和數(shù)據(jù)處理系統(tǒng)部署到云端。

選型過程并不復(fù)雜，F(xiàn)reeWheel主要從成熟程度、數(shù)據(jù)監(jiān)管、可用區(qū)(AZ)數(shù)以及原生服務(wù)的數(shù)量與廣度等方面考量，最終選擇了AWS作為云服務(wù)商。

基于AWS原生服務(wù)的使用權(quán)衡

整體上，F(xiàn)reeWheel在AWS上也部署了一套Kafka MirrorMaker，同步所有數(shù)據(jù)中心的數(shù)據(jù)，再將數(shù)據(jù)處理平臺(tái)基本原樣搬到了AWS上。

但如何權(quán)衡是直接使用像Kinesis、DynamoDB這樣的AWS原生服務(wù)，還是自己維護(hù)Kafka、HBase等基礎(chǔ)設(shè)施? FreeWheel也有一些思考。

張磊對(duì)此總結(jié)了兩點(diǎn)。一是從平臺(tái)需求出發(fā)。AWS許多原生服務(wù)在某種程度上的確能帶來開發(fā)和維護(hù)成本的降低，但對(duì)于基礎(chǔ)數(shù)據(jù)平臺(tái)這類數(shù)據(jù)量極其龐大并且對(duì)穩(wěn)定性要求很高的業(yè)務(wù)， AWS的原生服務(wù)能不能滿足需求，能滿足需求的情況下成本是不是可控，這些都會(huì)是最終影響選型的因素。二是需要考慮開發(fā)者自身對(duì)技術(shù)的把控。AWS的原生服務(wù)很多時(shí)候?qū)κ褂谜邅碚f還是黑盒。當(dāng)大家需要花大量時(shí)間去了解這些服務(wù)的內(nèi)部運(yùn)作原理，限制和故障處理時(shí)，不一定能降低時(shí)間和運(yùn)維成本。

涉及到具體權(quán)衡與改造，姜冰也舉例講解了何時(shí)該選擇自身維護(hù)：

以AWS原生服務(wù)Amazon EMR和Amazon Kinesis為例，映射到FreeWheel的數(shù)據(jù)處理系統(tǒng)中相應(yīng)的是Hadoop Cluster和Kafka�；�于FreeWheel以7*24小時(shí)流計(jì)算為主的業(yè)務(wù)類型，如果直接使用EMR及Kinesis，將面臨如下問題：

原生服務(wù)開放程度較弱，因而開發(fā)者缺乏更多的機(jī)會(huì)維護(hù)和管理自身集群。例如從對(duì)外兼容性上看，Kafka下游接了多樣的開源解決方案，與Spark、Flink等有天然集成，但Kinesis是閉源的托管服務(wù)，下游集成由AWS主導(dǎo)，日志記錄的更新和變化將受制于AWS內(nèi)部研發(fā)。

EMR適合批處理的工作模式，在全天候不間斷的運(yùn)行狀態(tài)下，基于AWS基礎(chǔ)計(jì)算和存儲(chǔ)資源自建的Hadoop集群能夠提供更好的可用性，從而更好地應(yīng)對(duì)流處理場景;

在上述場景下，F(xiàn)reeWheel并沒有主動(dòng)選擇EMR或Kinesis原生服務(wù)，而是從成本、性能、開放程度、規(guī)模化和容錯(cuò)管理等維度與自身維護(hù)做了對(duì)比實(shí)踐。但張磊也提到，在一般的使用場景下，對(duì)于AWS的原生服務(wù)，比如RDS，Athena等，F(xiàn)reeWheel會(huì)鼓勵(lì)并盡可能地使用， 這樣才能更有效地滿足高可用需求，并降低總體開發(fā)維護(hù)成本。

截至目前，經(jīng)過測試和調(diào)整，F(xiàn)reeWheel已逐步把面向客戶的的所有產(chǎn)品都遷移到AWS環(huán)境中，目前自有數(shù)據(jù)中心里只有極少數(shù)對(duì)內(nèi)的服務(wù)在運(yùn)行。而最終它們也都會(huì)遷移到AWS環(huán)境中。

高可用實(shí)踐需求及實(shí)現(xiàn)方案解析

高可用性設(shè)計(jì)目標(biāo)

一個(gè)完整的全系統(tǒng)高可用性設(shè)計(jì)通常會(huì)涉及五大層面：基礎(chǔ)設(shè)施、服務(wù)器、應(yīng)用程序、系統(tǒng)服務(wù)、區(qū)域。

在基礎(chǔ)設(shè)施層，F(xiàn)reeWheel更多的是將AWS視為一項(xiàng)服務(wù)。雖然AWS會(huì)充分保證其基礎(chǔ)設(shè)施的穩(wěn)定性，F(xiàn)reeWheel還是會(huì)在所有的服務(wù)都可能出問題這一假設(shè)下指導(dǎo)設(shè)計(jì)。服務(wù)器層也是如此。

數(shù)據(jù)層，如果該數(shù)據(jù)存在于FreeWheel自身系統(tǒng)，其通常會(huì)借助于像Kafka、HBase的天然多副本能力，即設(shè)置多個(gè)副本提供數(shù)據(jù)容災(zāi)。

應(yīng)用程序?qū)樱現(xiàn)reeWheel一般會(huì)將它做到無狀態(tài)，從而更容易實(shí)現(xiàn)快速恢復(fù)和高可用，無論是水平擴(kuò)展還是垂直擴(kuò)展都更方便。

服務(wù)層，F(xiàn)reeWheel采用的是Failover(故障轉(zhuǎn)移)機(jī)制。即應(yīng)用服務(wù)器設(shè)置多臺(tái)，彼此之間通過心跳聯(lián)系。數(shù)據(jù)庫、緩存、應(yīng)用服務(wù)器等任何位置出現(xiàn)瓶頸就只需增加處理能力。目前，對(duì)于服務(wù)器的對(duì)等可替換性，主要有三種類型：Active-Active(雙主)、Active-Standby(主備)以及單Active。

在雙主模式下，F(xiàn)reeWheel通常會(huì)通過先綁定Amazon ELB，再注冊(cè)到Amazon Route 53的方式，從而實(shí)現(xiàn)自動(dòng)對(duì)應(yīng)用無感知訪問。

對(duì)于主備模式，F(xiàn)reeWheel通常會(huì)將相應(yīng)的信息注冊(cè)到ZooKeeper，由ZooKeeper實(shí)現(xiàn)Failover的分布式協(xié)調(diào)服務(wù)，從而實(shí)現(xiàn)Master的選舉和對(duì)外服務(wù)發(fā)現(xiàn)。

對(duì)于單主模式，一般是一些離線任務(wù)，F(xiàn)reeWheel會(huì)將其綁定在ASG(Auto Scaling Group)中，出現(xiàn)問題時(shí)可以自動(dòng)擴(kuò)展重試。

高可用的整體實(shí)現(xiàn)方案

無論是跨Region(區(qū)域)還是跨AZ(可用區(qū))，數(shù)據(jù)交換都將產(chǎn)生一定的成本開銷。面對(duì)著龐大數(shù)據(jù)量和跨區(qū)域/可用區(qū)間的數(shù)據(jù)延遲，在AWS多可用區(qū)實(shí)踐過程中，F(xiàn)reeWheel針對(duì)數(shù)據(jù)平臺(tái)對(duì)于高可用的需求及AWS自身高可用實(shí)踐經(jīng)驗(yàn)，采用了多種定制方式——主要對(duì)Hadoop-HBase、Kafka、Zookeeper及數(shù)據(jù)處理部分實(shí)現(xiàn)了不同的高可用解決方案。

1. Hadoop-HBase多可用區(qū)

在設(shè)計(jì)之初，F(xiàn)reeWheel就試圖平衡了成本、性能和可用性之間的關(guān)系。但是類似數(shù)據(jù)庫系統(tǒng)中的CAP理論，這三者很難同時(shí)得到滿足。例如，AWS上很多及其類型和存儲(chǔ)類型都不盡相同。為了提升HBase性能需要采用instance store這類本地SDD存儲(chǔ)方式，而相應(yīng)的弊端也隨之產(chǎn)生：一旦掛載這個(gè)instance store這個(gè)實(shí)例出現(xiàn)異常，相應(yīng)的存儲(chǔ)就會(huì)丟失。尤其是當(dāng)其真實(shí)宿主機(jī)發(fā)生大面積故障時(shí)，可能導(dǎo)致數(shù)據(jù)的徹底丟失。

因此，F(xiàn)reeWheel也需要對(duì)HBase在多個(gè)可用區(qū)上實(shí)現(xiàn)高可用。

對(duì)于存儲(chǔ)模塊，F(xiàn)reeWheel選擇兩個(gè)可用區(qū)來部署，通過HDFS Storage Policy接口，實(shí)現(xiàn)數(shù)據(jù)塊副本數(shù)在主可用區(qū)和次可用區(qū)的分布。 對(duì)于無狀態(tài)的數(shù)據(jù)應(yīng)用優(yōu)先部署在與Hadoop/HBase主可用區(qū)同側(cè)，并支持在次可用區(qū)快速部署。應(yīng)用和數(shù)據(jù)優(yōu)先同側(cè)的策略，可以有效降低數(shù)據(jù)應(yīng)用的因?yàn)榭缈捎脜^(qū)帶來的數(shù)據(jù)延遲，并降低可用區(qū)之間網(wǎng)絡(luò)傳輸?shù)某杀鹃_銷。借助AWS提供不同存儲(chǔ)介質(zhì)的IOPS和持久化特點(diǎn)，實(shí)現(xiàn)針對(duì)不同業(yè)務(wù)的工作負(fù)載靈活選擇存儲(chǔ)節(jié)點(diǎn)配置，并實(shí)現(xiàn)業(yè)務(wù)之間的物理隔離(原理如下圖)。

 

 

其中，隔離思路主要是基于不同的工作負(fù)載選用不用的EC2實(shí)例或EBS實(shí)例。這樣也可根據(jù)自身的業(yè)務(wù)特點(diǎn)，在AWS中選擇不同的硬件、實(shí)例類型或EBS類型來滿足需求。此外，F(xiàn)reeWheel也可以在AWS Hadoop上實(shí)現(xiàn)一組機(jī)器的上線及下線，而且只把具有某一類標(biāo)簽的機(jī)器上、下線，而不影響到其他數(shù)據(jù)。

2. Kafka多可用區(qū)

Kafka Topic內(nèi)每個(gè)Partition有多個(gè)副本，多可用區(qū)部署，需保證在不同可用區(qū)的副本個(gè)數(shù)的劃分。姜冰提到，在正常情況下每個(gè)Partition里可設(shè)置多個(gè)副本，如果要保證高可用，意味著需要將多個(gè)副本同時(shí)被部署到同一可用區(qū)上，但同時(shí)，這樣做的弊端是無法保證可用區(qū)級(jí)別高可用，如果一個(gè)可用區(qū)宕機(jī)將導(dǎo)致整個(gè)Partition不可用。

于是，考慮到跨可用區(qū)帶來的數(shù)據(jù)延遲以及成本開銷，F(xiàn)reeWheel針對(duì)數(shù)據(jù)應(yīng)用和規(guī)模實(shí)現(xiàn)了不同的策略。

一種策略是，對(duì)于用于數(shù)據(jù)處理流程的Kafka Topic，在次可用區(qū)僅部署Partition副本中的Follower。應(yīng)用程序和Kafka主可用區(qū)同側(cè)，讀寫數(shù)據(jù)的流量全部在同一可用區(qū)完成，這樣在主從可用之間，僅有Leader和Follower之間的網(wǎng)絡(luò)傳輸開銷。在主可用區(qū)發(fā)生故障時(shí)，從可用區(qū)的Follower切換成Leader對(duì)外提供服務(wù)(原理如下圖)。

 

 

在這種情況下，Kafka 消費(fèi)者只會(huì)在同一可用區(qū)消費(fèi)，從而避免跨可用區(qū)間因網(wǎng)絡(luò)傳輸帶來的成本消耗，同一可用區(qū)間的延遲性也大大降低。

而對(duì)于以在線服務(wù)為主的數(shù)據(jù)，為了提供更強(qiáng)的高可用和更快速的恢復(fù)能力，Kafka采用3可用區(qū)對(duì)等部署的方案，無差別的對(duì)外提供服務(wù)：每一個(gè)Partition的Leader和Follower以公平的策略隨機(jī)分配到不同的可用區(qū)，在AWS出現(xiàn)可用區(qū)級(jí)別的故障時(shí)，Kafka借助Leader和Follower之間的切換，保證服務(wù)的高可用(原理如下圖)。

 

 

放在FreeWheel的具體業(yè)務(wù)場景中，為保證廣告主預(yù)算與廣告競價(jià)間反饋回路的可用性高且延時(shí)性低，避免出現(xiàn)廣告超量投放或投放價(jià)格與預(yù)算偏差等問題，F(xiàn)reeWheel即需采用上述第二類這種解決方案。

3. Zookeeper多可用區(qū)部署方案

Zookeeper 集群是由1個(gè)leader和若干個(gè)follower組成，這些節(jié)點(diǎn)被部署到3個(gè)AWS可用區(qū)。應(yīng)用通過名字注冊(cè)服務(wù)將主工作服務(wù)(Active)注冊(cè)到Zookeeper。在可用區(qū)發(fā)生故障時(shí)，應(yīng)用Active/Standby角色根據(jù)Zookeeper名字服務(wù)狀態(tài)變化進(jìn)行切換，并注冊(cè)最新的Active服務(wù)到Route53(原理如下圖)。

 

 

4. Pipeline高可用部署方案

目前FreeWheel DIP(Data Ingestion Pipeline)架構(gòu)由兩部分組成，一是流處理工作類型，二是上下游以小時(shí)為級(jí)別的批處理工作類型。

流處理消費(fèi)一次來源于Kafka，同時(shí)會(huì)和HBase交互，所以就流處理來說，如果能解決數(shù)據(jù)和狀態(tài)高可用，其本身是屬于一條無狀態(tài)的數(shù)據(jù)處理流水線。反觀，這也是為什么FreeWheel會(huì)花更多功夫在Kafka、Hadoop-Hbase和Zookeeper高可用部署上的原因，從而進(jìn)一步確保流式數(shù)據(jù)處理狀態(tài)和高可用。

流式處理主要通過Hadoop YARN部署，采用ASG做擴(kuò)展/收縮，以及采用ASG綁定同一YARN隊(duì)列的方式來保證高可用性。

對(duì)于批處理工作類型的解決方案，F(xiàn)reeWheel也有比較好的Failover方案應(yīng)對(duì)異常狀況下的自我修復(fù)�？偟膩碚f，利用分布式的天然架構(gòu)，F(xiàn)reeWheel可以通過監(jiān)控措施很快地對(duì)其進(jìn)行恢復(fù)。

高可用實(shí)踐之切換部署

因?yàn)橥ㄟ^對(duì)有狀態(tài)數(shù)據(jù)(諸如Kafka、HBase、Zookeeper)實(shí)現(xiàn)多可用區(qū)，從底層向上的各個(gè)業(yè)務(wù)可形成自我恢復(fù)的能力，即使在發(fā)生故障時(shí)，也已能在極端的情況下為用戶無縫提供完整服務(wù)。

當(dāng)跨可用區(qū)級(jí)別切換時(shí)，F(xiàn)reeWheel更多貫徹的是DevOps理念，即不用專職的運(yùn)維人員，通過監(jiān)控和腳本自動(dòng)化的工具和方式保證服務(wù)高可用。目前在FreeWheel內(nèi)部受重視的一種模式是監(jiān)控和報(bào)警的代碼化，即通過相應(yīng)的框架實(shí)現(xiàn)監(jiān)控和報(bào)警，用代碼做管理，而非以往那種在站點(diǎn)上做簡單配置的方式。

對(duì)于監(jiān)控和報(bào)警，F(xiàn)reeWheel用到的主要工具包括Datadog及開源工具如TerraForm(類似于AWS CloudFormation)和SaltStack等。

Datadog的工作方式是在每一臺(tái)需要監(jiān)控的服務(wù)器上運(yùn)行它的Agent。FreeWheel主要用Datadog實(shí)現(xiàn)EC2級(jí)別監(jiān)控，這樣可以基于機(jī)器類型、用途等，分門別類對(duì)其服務(wù)進(jìn)行監(jiān)控，一是實(shí)現(xiàn)系統(tǒng)級(jí)別(如CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)I/O)的相關(guān)監(jiān)控，二是實(shí)現(xiàn)基于 應(yīng)用級(jí)別的監(jiān)控。

另外，TerraForm會(huì)應(yīng)對(duì)啟動(dòng)資源、擴(kuò)展/回收和權(quán)限配置之類的場景，從而實(shí)現(xiàn)AWS資源配置。SaltStack實(shí)現(xiàn)配置的冪等性管理，并針對(duì)機(jī)器tag進(jìn)行分布式調(diào)用和部署檢查。

當(dāng)可用區(qū)級(jí)別需切換時(shí)，目標(biāo)是希望能做到讓用戶無感知。但目前如果需從主區(qū)域切換至備用區(qū)域情況下，F(xiàn)reeWheel當(dāng)前的設(shè)計(jì)方案是讓用戶有感知，也就是針對(duì)這種場景允許有一定的宕機(jī)時(shí)間。因?yàn)樵谝话闱闆r下，一個(gè)區(qū)域3個(gè)或3個(gè)以上的可用區(qū)(FreeWheel只會(huì)使用有至少3個(gè)可用區(qū)的區(qū)域)已經(jīng)足夠保證高可用性。當(dāng)整個(gè)區(qū)域出現(xiàn)整體性故障時(shí)，允許有一定的宕機(jī)時(shí)間是綜合成本和需求的整體考慮。

高可用實(shí)踐收效及未來規(guī)劃

張磊在采訪中提到，伴隨著高可用實(shí)踐，F(xiàn)reeWheel也獲得了業(yè)務(wù)的高彈性。對(duì)于“超級(jí)碗”及世界杯這類大型體育賽事開始時(shí)，整個(gè)架構(gòu)會(huì)有更好的擴(kuò)展能力應(yīng)對(duì)突發(fā)流量，幫助其在AWS上實(shí)現(xiàn)高度的動(dòng)態(tài)擴(kuò)展性。

未來，F(xiàn)reeWheel一方面會(huì)嘗試將一部分系統(tǒng)走向容器化，比如Data Ingestion Pipeline。當(dāng)然，對(duì)于HBase、Hadoop如何更好地結(jié)合K8S或利用Amazon EKS等工具，F(xiàn)reeWheel還需要下一階段的調(diào)研及實(shí)驗(yàn)。

另一方面，針對(duì)更大范圍的高可用、數(shù)據(jù)安全等問題，F(xiàn)reeWheel還將持續(xù)探索怎樣在平衡性能和成本的條件下多個(gè)區(qū)域提供服務(wù)和快速的災(zāi)難修復(fù)的能力。

采訪嘉賓

張磊 FreeWheel架構(gòu)師，現(xiàn)負(fù)責(zé)公司數(shù)據(jù)平臺(tái)和數(shù)據(jù)產(chǎn)品的整體技術(shù)把控。

姜冰，F(xiàn)reeWheel 首席工程師，現(xiàn)全面負(fù)責(zé)大數(shù)據(jù)平臺(tái)的架構(gòu)和研發(fā)工作。

標(biāo)簽： 安全 大數(shù)據(jù) 大數(shù)據(jù)基礎(chǔ) 大數(shù)據(jù)平臺(tái) 大數(shù)據(jù)平臺(tái)開發(fā) 大數(shù)據(jù)中心 代碼 服務(wù)器 服務(wù)器設(shè)置 服務(wù)商 公有云 互聯(lián)網(wǎng) 互聯(lián)網(wǎng)服務(wù) 腳本 開發(fā)者 權(quán)限 數(shù)據(jù)庫 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。