@Rays
2021-11-18T13:19:14.000000Z
字数 4264
阅读 692
构建DeNexus数据平台：为什么在Databricks和Snowflake间选型前者
摘要： 作为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文档：“数据版本管理”）。此外，Delta Lake是完全开源的。
Spark等Databricks产品支持处理各种的类型数据，结构化的、半结构化的，以及非结构化的。
此外，Spark并不使用特定的数据格式。鉴于Spark是完全开源的，我们可以手工开发连接器，或是使用Python、Scala、R和Java等语言的原生软件库。毕竟，Databricks不仅托管了Spark一款产品。
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 整合所有服务的数据平台。
Iván Gómez Arnedo是一位具有丰富经验的数据工程师，致力于解决架构和可扩展性等具有挑战性问题，以及构建数据密集型应用，取得了良好的业绩。在加入DeNexus之前，Iván曾在BASF银行和Santander银行参与多项关键数据项目。
原文链接： Building our Data Platform: Why we have chosen Databricks over Snowflake
