作者 ｜ Iván Gómez Arnedo
譯者 ｜ 蓋磊
策劃 ｜ Tina
作為 DeNexus 安全服務提供商，需要良好選型的資料平臺實現巨量資料的分析和管理。DeNexus 根據自身需求選型了 Databricks 的湖倉一體解決方案，滿足自身對資料型別、使用者型別、可擴充套件性、版本管理和 MLOps 上的需求。
DeNexus 致力於解決威脅全球關鍵基礎設施的網路安全風險，併為承保這些設施的保險公司提供服務。
挑戰：可靠的資料
關鍵基礎設施並不僅限於機場、電力設施和能源供給等中心，還包括由複雜運營技術 （OT） 構成的生態，以及 IT 網路、工業控制系統（ICS）、企業軟體和人員等。
需要關注的是，關鍵基礎設施正面對著愈發嚴重的網路安全風險。在過去五年中，能源、可再生能源、製造、運輸、供應鏈生態系統等都已成為不斷增長的勒索軟體和惡意軟體攻擊的受害者。僅在近兩年中，針對 ICS 和 OT 的勒索軟體攻擊就增長了五倍以上。解決網路安全風險挑戰的代價高昂，因為其呈現出的巨量資料將會吞噬所投入的大量資金。
針對此，DeNexus 推出了支撐資料的採集、儲存和使用的專有資料湖“DeNexus 知識中心”（DeNexus Knowledge Center），為 DeNexus 自研風險量化演算法的開發和訓練提供資料服務，進而形成了供 DeRISK 使用的產品。DeRISK 是 DeNexus 推出的一款安全、高效、靈活並高度可擴充套件的風險量化 SaaS 平臺
圖 1 DeNexus 知識中心（DeNexus Knowledge Center）結構圖
DeNexus 的需求
支援不同型別使用者的資料訪問需求
：包括執行復雜資料轉換的高階使用者，以及僅是使用 SQL 的基礎使用者。
強大的資料版本控制功能
：確保特定檔案和表的版本不會在高階建模中發生更改，能記錄資料湖中所有的歷史交易，可輕鬆訪問和使用歷史版本資料。
支援異構資料
：為 DeRISK 的輸入輸出和各種格式的商業智慧資料提供支撐，包括結構化的、半結構化的和非結構化資料。
高可擴充套件性
：考慮業務的快速增長，設計上需滿足 PB 級資料儲存。參見線上影片“面向無窮：夠大並非總是夠好”。
委託架構
：為最佳化內部人力資源配置，解決方案應儘可能考慮採用 SaaS 或 PaaS。
機器學習模型運營化（MLOps）
：該資料湖的一個主要用例，是透過模型應用使用資料。資料平臺的使用者主要是企業中的資料科學家。為推進開發並加速上線部署，最佳實踐需參考 MLOps 範例。
強安全性和合規性約束
：資料儲存需具備很好的靈活性和動態性。
DeNexus 在評估了市場上現有的解決方案後，擯棄了基於 資料倉庫理念 的解決方案。因為面對以 Parquet 或 Avro 格式提供的資料，以及 Spark 或 Presto/Trino 等工具，是否依然需要去區分資料湖和資料倉庫，這取決於具體的用例。對於 DeNexus 而言，是完全沒有必要的。因為 DeNexus 的資料平臺事實上是全新構建的，資料主要並非來自 SQL Server、PostgreSQL、MySQL 等 關係資料庫管理系統，從一開始就不存在任何需要做遷移的資料來源。
近資料倉庫之父 Bill Inmon 最也闡述了類似的觀點：
“一開始，我們會把所有的資料都扔到一個大坑中，稱其為“資料湖”。但我們很快就會發現，僅僅將資料扔進坑裡是毫無意義的操作。為使資料有用，即加以分析，資料需要相互關聯，併為終端使用者提供良好設計的資料分析基礎設施。除非這兩個條件得到滿足，否則資料湖就會變成一片沼澤，並在一段時間後開始散發臭味。不符合分析標準的資料湖，就是浪費時間和金錢。”
—— Bill Inmon，“構建湖倉一體”
解決方案：湖倉一體
資料倉庫的主要優點在於 ACID、版本管理和最佳化等，而資料湖的主要優點是儲存代價低、支援異構資料格式等。DeNexus 的資料管理系統考慮結合二者的優點，因此需要的是 倉湖一體平臺。DeNexus 選擇了 Databricks 產品，一方面考慮其提供了倉湖一體的原生實現，其它方面考慮因素將在下面做展開介紹。
圖 2 資料倉庫、資料湖和倉湖一體的對比
機器學習演算法並不能很好地適配資料倉庫，因為 BI 查詢通常僅抽取少量的資料，但 XGBoost， Pytorch， TensorFlow 等實現的機器學習演算法需在不使用 SQL 的情況下處理大量資料集。此外，使用 JCBD/ODBC 聯結器時會做多次資料型別轉換，導致資料讀取效率很低，而且一般不能直接相容資料倉庫所使用的內部專有資料格式。另一種做法是將資料以開放資料格式匯出為檔案，但這增加了額外的 ETL 步驟，增加了複雜性，也不合時宜。
儘管 Snowflake 這類“雲原生”資料倉庫支援以資料湖格式（開放資料格式）讀取外部表，也實現了湖倉一體方法，但是：
Snowflake 資料的主要來源是自身的內部資料，儲存成本更高。因此在一些情況下仍然需要 ETL 流水線，增加了額外的維護流程，並導致更多的可能故障點。
對資料湖中的資料，Snowflake 並未提供與其內部資料相同的管理功能，例如事務、索引等。
Snowflake 的 SQL 引擎的最佳化，主要針對其內部格式查詢資料。
此外，正如前面提及的 Presto/Trino、AWS Athena 等資料湖查詢工具，Snowflake 的單一用途工具並不能解決資料整體上的問題。這些工具缺乏正常資料倉庫所具有的 ACID 交易、索引等基本資料管理特性。
圖 3 DeNexus 資料平臺結構圖
Databricks 如何滿足需求
支援不同型別使用者的資料訪問
：要使用 SQL 訪問資料，必須有人去處理原始資料，並做結構化處理。那麼是否能用基本的 SQL 語句完成資料轉換？答案雖然是肯定的，但只能祝一切好運。
SQL 有其強大之處，但並非適用於一切。SQL 並非一種 通用程式語言，因此非常難以實現遞迴和迴圈，難以使用變數。鑑於我們無法整體把握實現 DeRISK 產品路線圖所需執行的資料轉換，因此多樣性是一個重要的考慮因素。Databricks 產品支援執行 Spark、Python、Scala、Java 和 R 等語言，甚至支援 SQL，適用於不同型別的使用者。完美！
強大的資料版本控制
：Databricks 原生支援 DELTA 格式。Delta Lake 是完全相容 ACID 的，這就解決了 Spark 的 不相容 ACID 這一主要問題。此外，Delta Lake 支援在流水線出現錯誤時恢復系統，並易於對資料提供確保，例如確保開發模型中所使用的資料不變（參見 Delta Lake 文件：“資料版本管理”https：//docs。delta。io/latest/quick-start。html#read-older-versions-of-data-using-time-travel）。此外，Delta Lake 是完全開源的。
Spark 等 Databricks 產品支援處理各種的型別資料
，結構化的、半結構化的，以及非結構化的。
此外，Spark 並不使用特定的資料格式。鑑於 Spark 是完全開源的，我們可以手工開發聯結器，或是使用 Python、Scala、R 和 Java 等語言的原生軟體庫。畢竟，Databricks 不僅託管了 Spark 一款產品。
卓越技術：除非看到類似 Google、Netflix、Uber 和 Facebook 這樣的技術領導者從開源系統轉向了專有系統，否則儘可放心地使用 Databricks 這些從技術角度看十分卓越的開源系統。開源系統更具多樣性。（https：//www。datagrom。com/data-science-machine-learning-ai-blog/snowflake-vs-databricks）
Databricks PaaS 本質上是可擴充套件的
，資料平臺可使用所有的雲資源。例如，使用 S3 可滿足更大的儲存需求，以及一些新環境中的一次性儲存需求；Databricks 可直接滿足對更多處理能力的需求，極大節約了企業最具價值資源即軟體工程人員的時間；一旦新的資料科學家加入團隊，不再需要在本地配置個人計算機；使用者可在任何時候細粒度控制在執行的機器數量，及各臺機器所具備的功能，同時避免出現意外計費的情況！
此外，Spark DBR（即 Databricks 的商業版 Spark）比常規 Spark 的效能更快，但需要為 Databricks Runtimes 額外付費。這是物有所值的。
圖 4 Spark 開源版與 DBR 版的效能對比（來自 YouTube）
基於 Databricks+ 託管 MLflow，實現 MLOps 完整解決方案
。MLflow 提供了模型開發的環境，以及機器學習全生命週期的平臺。MLflow 最初是由 Databricks 建立，之後捐獻給 Linux 基金會。參見 GitHub：mlflow/mlflow：機器學習生命週期的開源平臺
MLflow 支援資料科學家輕鬆追蹤實驗中使用的資料表版本，並在後期重現指定版本的資料。此外，MLflow 為資料科學家提供了協作環境，支援同事間相互共享模型和程式碼。MLflow 可與 Azure-ML 和 AWS SageMaker 等機器學習平臺聯合使用。在 Databricks 託管 MLflow 中註冊的模型，可以輕鬆地用於 Azure ML 和 AWS SageMaker 中。
此外，使用 Databricks 託管的 MLflow，資料科學家可基於 Spark ML 和 Koalas（即 Spark 中實現的 Pandas）輕鬆實現演算法並行化。
資料儲存層和處理層的完全解耦
。Databricks 實現了計算和儲存的分離，可處理在任何位置、以任何格式儲存的資料。不需要任何專用的格式或工具，因此資料遷移具有高度的靈活性。
總 結
圖 5 顯示了資料的三個階段，以及每個階段所使用的工具：
資料處理
：Databricks、Python+AWS Lambda、EC2。
資料發現
：Databricks、AWS Athena。
MLOps
：Databricks、AWS SageMaker。
各階段的共同點是，都使用了 Databricks 產品。
過程中不存在任何的供應商鎖定，除了使用 AWS Glue 資料目錄實現外部元資料儲存。按使用付費的模式，支援使用者根據特定場景選型替代服務。儘管這類場景目前我們尚未遇見，但不排除未來可能遇上。
圖 5 整合所有服務的資料平臺（譯者注：圖片來自 CIDR 2021 論文“Lakehouse： A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics” ）
http：//cidrdb。org/cidr2021/papers/cidr2021_paper17。pdf。
如果希望良好的架構和資料模型能解決資料一致性、治理和架構實施上的大部分問題……並且希望能在這些資料上獲得更多的功能和靈活性……那麼請選型 Databricks 產品……幾乎沒有 Spark 和 Delta Lake 做不到的事情。
作者簡介：
Iván Gómez Arnedo
是一位具有豐富經驗的資料工程師，致力於解決架構和可擴充套件性等具有挑戰性問題，以及構建資料密集型應用，取得了良好的業績。在加入 DeNexus 之前，Iván 曾在 BASF 銀行和 Santander 銀行參與多項關鍵資料專案。
https：//blog。denexus。io/databricks
