一、連接！連接！連接！

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

然而，不容忽視的現(xiàn)實是，并沒有一個完美的平臺能夠應付所有需求！一項成功的架構設計必須始終考慮入站和出站的連接，并且要允許用戶利用其他工具來實現(xiàn)其需求。

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

這就好比是一個思維敏捷的天才，卻無法閱讀或表達自己一樣！

需要考慮的事項：

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

二、關于“膚淺”或“有毒”的安全架構

雖然人們普遍聲稱“安全高于一切”，但很少有人從項目的一開始就充分考慮安全架構。安全框架的后期介入有時會導致兩種截然不同的情況：

• 要么它幾乎無法發(fā)揮作用，只是依賴“繁瑣的流程”來欺騙內部或外部的審計機構。
• 要么它過度干預，采用復雜的流程來阻止用戶執(zhí)行任何操作。

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

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

需要考慮的事項：

• 一開始就應確保團隊中有經(jīng)驗豐富的安全架構師，他是否具備實際交付項目的經(jīng)驗？
• 安全框架是否可能妨礙用戶進行日常的業(yè)務操作？

三、與更廣泛基礎架構的低兼容性

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

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

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

需要考慮的事項：

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

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

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

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

• 展示層復制基礎數(shù)據(jù)層，以適應報告和可視化需求。
• 公有云復制本地數(shù)據(jù)，以利用計算能力和尖端工具。

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

想象一下，本可以通過維護一個單一的日記來管理日常活動；然而，你的妻子創(chuàng)建了一個“家庭”日歷，你的秘書從你的單一日記中又創(chuàng)建了一個“工作”日歷。或許在多花一些時間進行額外的管理后，這種方式仍然可以運行；但如果你的妻子決定在你的家庭日歷中在上班時間購物，而這與你的工作日歷發(fā)生了沖突呢？

需要考慮的事項：

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

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

現(xiàn)代架構通常采用嚴格的環(huán)境分段，典型地包括開發(fā)（DEV）、用戶驗收測試（UAT）和生產（PROD）環(huán)境。盡管很多公司正在積極采用最新的技術，如公有云（AWS、Azure、GCP）和基礎架構即代碼（IaC，例如Terraform），但它們仍然將生產環(huán)境托管在公司的防火墻之后，即本地環(huán)境。

我不會在這里詳細討論持續(xù)集成/持續(xù)交付（CI/CD）方面的挑戰(zhàn)，因為已經(jīng)有許多專家深入探討了部署流程的問題。我要強調的是，確保在所有平臺之間實現(xiàn)“工具、配置和庫”的同步是至關重要的。

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

需要考慮的事項：

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

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

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

需要考慮的事項：

• 我們是否在IaC自動化代碼中設置了適當?shù)目刂拼胧坷纾欠褚髲娭茍?zhí)行生態(tài)系統(tǒng)配置？是否在所有節(jié)點之間實施了嚴格的隔離？
• 我們是否定期掃描整個由IaC創(chuàng)建的基礎設施，并清理掉空閑的節(jié)點？

七、弱或沒有遙測功能

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

一個強大/預配置的遙測組件可以支持架構師在設計過程中，并且最重要的是，它可以提高終端用戶對平臺的可見性，最終成為平臺治理的重要組成部分。

需要考慮的事項：

• 我們的架構中是否包括獨立的遙測組件？
• 如果沒有，我們是否可以借助更廣泛的基礎架構中的遙測組件？例如，安全、審計或合規(guī)性方面的遙測組件。

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

多年來，數(shù)據(jù)混淆一直是一個備受關注的話題，我確信幾乎所有的數(shù)據(jù)平臺都將面臨這一挑戰(zhàn)，尤其是在從公有云查詢本地數(shù)據(jù)或實施用戶權限隔離時。

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

一些解決方案甚至會對物理數(shù)據(jù)造成永久性的損害，但隨后它們必須構建更復雜的機制來與受損數(shù)據(jù)匹配，這將引入不必要的流程和成本。

需要考慮的事項：

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

我相信上述常見錯誤并不能構成一個排他性的列表，希望大家在未來的架構設計項目中避免重復掉入這些陷阱。