一、連接！連接！連接！

幾乎所有現(xiàn)代平臺(tái)提供商的一個(gè)核心目標(biāo)在于構(gòu)建一個(gè)“包容性生態(tài)系統(tǒng)”，這一生態(tài)系統(tǒng)能夠讓用戶在同一平臺(tái)上執(zhí)行各類活動(dòng)。

然而，不容忽視的現(xiàn)實(shí)是，并沒(méi)有一個(gè)完美的平臺(tái)能夠應(yīng)付所有需求！一項(xiàng)成功的架構(gòu)設(shè)計(jì)必須始終考慮入站和出站的連接，并且要允許用戶利用其他工具來(lái)實(shí)現(xiàn)其需求。

數(shù)年前，我曾參與過(guò)一個(gè)卓越的大數(shù)據(jù)平臺(tái)項(xiàng)目，該平臺(tái)采用了一種尖端的倉(cāng)庫(kù)工具。然而，令人遺憾的是，該平臺(tái)并未全面支持API調(diào)用（尤其是最新的RESTful和開(kāi)放API），這意味著無(wú)法流暢地將數(shù)據(jù)引入平臺(tái)。同時(shí)，用戶必須安裝ODBC驅(qū)動(dòng)程序并通過(guò)管理員權(quán)限配置DSN才能提取數(shù)據(jù)，這一操作過(guò)程異常繁瑣。

這就好比是一個(gè)思維敏捷的天才，卻無(wú)法閱讀或表達(dá)自己一樣！

需要考慮的事項(xiàng)：

• 這個(gè)平臺(tái)是否能夠支持來(lái)自各種數(shù)據(jù)源的多種連接方式？
• 是否為最終用戶提供了最新的解決方案，以便他們能夠輕松地從生態(tài)系統(tǒng)之外進(jìn)行數(shù)據(jù)查詢？

二、關(guān)于“膚淺”或“有毒”的安全架構(gòu)

雖然人們普遍聲稱“安全高于一切”，但很少有人從項(xiàng)目的一開(kāi)始就充分考慮安全架構(gòu)。安全框架的后期介入有時(shí)會(huì)導(dǎo)致兩種截然不同的情況：

• 要么它幾乎無(wú)法發(fā)揮作用，只是依賴“繁瑣的流程”來(lái)欺騙內(nèi)部或外部的審計(jì)機(jī)構(gòu)。
• 要么它過(guò)度干預(yù)，采用復(fù)雜的流程來(lái)阻止用戶執(zhí)行任何操作。

我曾經(jīng)見(jiàn)過(guò)一些處理生產(chǎn)數(shù)據(jù)的極端案例，其中的安全措施使得環(huán)境受到高度隔離，最終用戶只能通過(guò)一種渠道來(lái)查詢數(shù)據(jù)。

毫無(wú)疑問(wèn)，安全確實(shí)至關(guān)重要，但如果結(jié)果是“在安全之下幾乎沒(méi)有（或沒(méi)有）可用的資源” — 那我認(rèn)為這已經(jīng)違背了初衷。

需要考慮的事項(xiàng)：

• 一開(kāi)始就應(yīng)確保團(tuán)隊(duì)中有經(jīng)驗(yàn)豐富的安全架構(gòu)師，他是否具備實(shí)際交付項(xiàng)目的經(jīng)驗(yàn)？
• 安全框架是否可能妨礙用戶進(jìn)行日常的業(yè)務(wù)操作？

三、與更廣泛基礎(chǔ)架構(gòu)的低兼容性

幾乎所有數(shù)據(jù)平臺(tái)項(xiàng)目最初都懷揣著宏大的愿景，比如“改變世界”，但實(shí)際上，絕大多數(shù)項(xiàng)目都在實(shí)施過(guò)程中做出了一些妥協(xié)。

當(dāng)我們無(wú)法淘汰舊系統(tǒng)、必須依賴現(xiàn)有解決方案時(shí)，兼容性問(wèn)題會(huì)成為一道難以逾越的障礙！

多年前有一個(gè)項(xiàng)目，旨在引入最新的SSIS/SSAS報(bào)告和分析工具。最初的計(jì)劃是將后端的Oracle數(shù)據(jù)庫(kù)替換為MS SQL，但由于各種因素，這一計(jì)劃在半途中被擱置。結(jié)果，解決方案最終變得“處于待定狀態(tài)”，因?yàn)镾SIS/SSAS并不原生支持Oracle數(shù)據(jù)庫(kù)，必須安裝Oracle“驅(qū)動(dòng)程序”。前后端之間的兼容性問(wèn)題帶來(lái)了大量功能的縮減和性能問(wèn)題。

需要考慮的事項(xiàng)：

• 我的主要解決方案是否能夠自然支持上下游的組件（無(wú)需額外的驅(qū)動(dòng)程序）？
• 假如解決方案最終被擱置并“處于待定狀態(tài)”，我的解決方案中的每個(gè)組件是否足夠兼容舊系統(tǒng)？

四、無(wú)處不在的數(shù)據(jù)復(fù)制

許多最終用戶抱怨他們擁有多個(gè)數(shù)據(jù)源，卻不知道哪一個(gè)是最佳選擇。雖然很多架構(gòu)提案最初的目標(biāo)是實(shí)現(xiàn)“一個(gè)真實(shí)的版本”，但無(wú)可避免的是，數(shù)據(jù)復(fù)制問(wèn)題仍然屢見(jiàn)不鮮。

典型的數(shù)據(jù)復(fù)制情況包括：

• 展示層復(fù)制基礎(chǔ)數(shù)據(jù)層，以適應(yīng)報(bào)告和可視化需求。
• 公有云復(fù)制本地?cái)?shù)據(jù)，以利用計(jì)算能力和尖端工具。

也許你會(huì)反問(wèn)：“那又有何不妥？”雖然多次數(shù)據(jù)復(fù)制存在著一長(zhǎng)串潛在風(fēng)險(xiǎn)，包括數(shù)據(jù)溯源、變更管理、性能和存儲(chǔ)成本效益等問(wèn)題；我在這里舉一個(gè)簡(jiǎn)單的例子：

想象一下，本可以通過(guò)維護(hù)一個(gè)單一的日記來(lái)管理日?；顒?dòng)；然而，你的妻子創(chuàng)建了一個(gè)“家庭”日歷，你的秘書(shū)從你的單一日記中又創(chuàng)建了一個(gè)“工作”日歷。或許在多花一些時(shí)間進(jìn)行額外的管理后，這種方式仍然可以運(yùn)行；但如果你的妻子決定在你的家庭日歷中在上班時(shí)間購(gòu)物，而這與你的工作日歷發(fā)生了沖突呢？

需要考慮的事項(xiàng)：

• 是否需要在不同層面創(chuàng)建額外的數(shù)據(jù)副本？
• 我們是否可以利用API？是否可以使用實(shí)時(shí)連接？是否可以采用虛擬化數(shù)據(jù)倉(cāng)庫(kù)？甚至考慮采用微服務(wù)架構(gòu)嗎？

五、環(huán)境同步的挑戰(zhàn)

現(xiàn)代架構(gòu)通常采用嚴(yán)格的環(huán)境分段，典型地包括開(kāi)發(fā)（DEV）、用戶驗(yàn)收測(cè)試（UAT）和生產(chǎn)（PROD）環(huán)境。盡管很多公司正在積極采用最新的技術(shù)，如公有云（AWS、Azure、GCP）和基礎(chǔ)架構(gòu)即代碼（IaC，例如Terraform），但它們?nèi)匀粚⑸a(chǎn)環(huán)境托管在公司的防火墻之后，即本地環(huán)境。

我不會(huì)在這里詳細(xì)討論持續(xù)集成/持續(xù)交付（CI/CD）方面的挑戰(zhàn)，因?yàn)橐呀?jīng)有許多專家深入探討了部署流程的問(wèn)題。我要強(qiáng)調(diào)的是，確保在所有平臺(tái)之間實(shí)現(xiàn)“工具、配置和庫(kù)”的同步是至關(guān)重要的。

想象一下，你在Azure上開(kāi)發(fā)了一款出色的模型，利用GPU進(jìn)行計(jì)算，使用TensorFlow框架和Databricks；然而，當(dāng)你嘗試將相同的模型部署到生產(chǎn)環(huán)境時(shí)，你發(fā)現(xiàn)只有CPU虛擬機(jī)，沒(méi)有TensorFlow，也沒(méi)有Databricks... 這不是笑話，而是來(lái)自真實(shí)項(xiàng)目的經(jīng)驗(yàn)。

需要考慮的事項(xiàng)：

• 我們是否擁有一個(gè)綜合的架構(gòu)，覆蓋了公有云、本地和云內(nèi)的環(huán)境？它們是否擁有同步的工具、庫(kù)和配置？
• 如果上述情況是否是否定的，我們將如何管理跨不同平臺(tái)的部署？

六、未受控的IaC環(huán)境

基礎(chǔ)架構(gòu)即代碼（IaC）軟件，如Terraform，為自動(dòng)設(shè)置和配置虛擬化基礎(chǔ)設(shè)施帶來(lái)了極大的靈活性。然而，它也帶來(lái)了一個(gè)未受控的虛擬化基礎(chǔ)設(shè)施的風(fēng)險(xiǎn)，可能導(dǎo)致出現(xiàn)“隱藏”的或“空閑”的節(jié)點(diǎn)。

需要考慮的事項(xiàng)：

• 我們是否在IaC自動(dòng)化代碼中設(shè)置了適當(dāng)?shù)目刂拼胧?？例如，是否要求?qiáng)制執(zhí)行生態(tài)系統(tǒng)配置？是否在所有節(jié)點(diǎn)之間實(shí)施了嚴(yán)格的隔離？
• 我們是否定期掃描整個(gè)由IaC創(chuàng)建的基礎(chǔ)設(shè)施，并清理掉空閑的節(jié)點(diǎn)？

七、弱或沒(méi)有遙測(cè)功能

上述問(wèn)題可能自然引發(fā)有關(guān)遙測(cè)的討論。與安全框架中的問(wèn)題一樣，遙測(cè)方面通常在整個(gè)架構(gòu)設(shè)計(jì)的較晚階段才被引入。

一個(gè)強(qiáng)大/預(yù)配置的遙測(cè)組件可以支持架構(gòu)師在設(shè)計(jì)過(guò)程中，并且最重要的是，它可以提高終端用戶對(duì)平臺(tái)的可見(jiàn)性，最終成為平臺(tái)治理的重要組成部分。

需要考慮的事項(xiàng)：

• 我們的架構(gòu)中是否包括獨(dú)立的遙測(cè)組件？
• 如果沒(méi)有，我們是否可以借助更廣泛的基礎(chǔ)架構(gòu)中的遙測(cè)組件？例如，安全、審計(jì)或合規(guī)性方面的遙測(cè)組件。

八、混淆：只通向一方的單程票？

多年來(lái)，數(shù)據(jù)混淆一直是一個(gè)備受關(guān)注的話題，我確信幾乎所有的數(shù)據(jù)平臺(tái)都將面臨這一挑戰(zhàn)，尤其是在從公有云查詢本地?cái)?shù)據(jù)或?qū)嵤┯脩魴?quán)限隔離時(shí)。

雖然有許多聰明的機(jī)制可以用于數(shù)據(jù)混淆，但并非所有這些機(jī)制都能夠?qū)崿F(xiàn)雙通道——也就是以安全的方式啟用/逆轉(zhuǎn)掩碼算法。

一些解決方案甚至?xí)?duì)物理數(shù)據(jù)造成永久性的損害，但隨后它們必須構(gòu)建更復(fù)雜的機(jī)制來(lái)與受損數(shù)據(jù)匹配，這將引入不必要的流程和成本。

需要考慮的事項(xiàng)：

• 我們是否可以在虛擬環(huán)境中使用由安全密鑰管理的可逆算法進(jìn)行數(shù)據(jù)混淆？
• 如果不可避免地需要進(jìn)行物理/永久性數(shù)據(jù)混淆，那么在罕見(jiàn)的情況下恢復(fù)它將產(chǎn)生什么成本？

我相信上述常見(jiàn)錯(cuò)誤并不能構(gòu)成一個(gè)排他性的列表，希望大家在未來(lái)的架構(gòu)設(shè)計(jì)項(xiàng)目中避免重復(fù)掉入這些陷阱。