一、連接！連接！連接！

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

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

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

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

需要考慮的事項：

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

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

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

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

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

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

需要考慮的事項：

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

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

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

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

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

需要考慮的事項：

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

四、無處不在的數據復制

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

典型的數據復制情況包括：

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

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

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

需要考慮的事項：

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

五、環境同步的挑戰

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

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

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

需要考慮的事項：

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

六、未受控的IaC環境

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

需要考慮的事項：

• 我們是否在IaC自動化代碼中設置了適當的控制措施？例如，是否要求強制執行生態系統配置？是否在所有節點之間實施了嚴格的隔離？
• 我們是否定期掃描整個由IaC創建的基礎設施，并清理掉空閑的節點？

七、弱或沒有遙測功能

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

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

需要考慮的事項：

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

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

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

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

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

需要考慮的事項：

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

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