在 DeNexus，我们正在解决困扰全球关键基础设施和承保这些基础设施的保险公司的网络风险挑战。
挑战：可靠的数据
关键基础设施远不止机场、电力线和能源配送中心。它涉及复杂运营技术 (OT) 和 IT 网络、ICS、企业软件和人员的生态系统。
此外，关键基础设施面临越来越大的网络安全风险。在过去五年中，能源、可再生能源、制造、运输、供应链生态系统等都成为勒索软件和恶意软件攻击增加的受害者。仅在过去两年中，针对 ICS 和 OT 的勒索软件攻击就增长了 500% 以上。网络风险挑战是一项代价高昂的挑战，在这种挑战中，所面临的风险可能只会被这一挑战所呈现的巨大数据量所掩盖。
DeNexus 创建了其专有的数据湖DeNexus K知识中心，以收集、存储和使用必要的数据来开发和训练我们专有的风险量化算法，并从安全、高效、灵活和高度可扩展的角度将其使用产品化给我们的客户风险量化SaaS平台——DeRISK。
图 1：DeNexus 知识中心
DeNexus 需要
- 允许不同类型的用户访问数据：高级用户（可以利用复杂的转换）和基本用户（只熟悉 SQL）。
- 强大的数据版本控制：能够确保某个文件/表版本不会因高级建模而改变。应记录数据湖中所有过去的交易，以便轻松访问和使用以前版本的数据。
- 异构数据支持：结构化、非结构化或半结构化数据以及不同的数据格式，来自 DeRISK 的内向外、外向内和商业情报数据源。
- 高可扩展性：随着我们的快速增长，我们希望为 PB 级的数据量做好准备。“英菲尼迪的设计：足够大并不总是足够好。”
- 基础设施委托：解决方案应该（尽可能）SaaS或PaaS来优化内部人力资本的使用。
- ML-OPS：我们数据湖的主要用途之一是通过模型应用来利用数据（数据平台的主要客户是我们的数据科学家）。在ML-OPS模式应遵循的最佳实践措施，以促进发展，加快生产部署。
- 强大的安全性和合规性约束：数据存储必须是灵活和动态的。
在评估了市场上现有的解决方案后，基于众所周知的数据仓库概念的解决方案 被抛弃了。随着对Parquet或Avro等格式以及Spark或Presto/Trino等工具提供的数据的快速访问，区分数据湖和数据仓库是否仍然有意义？这取决于用例，在我们的情况下，它不是。为什么？我们的主要数据源并非来自SQL Server、PostgreSQL、MySQL等RDMBS系统。实际上，我们的数据并非来自任何地方，因为我们没有迁移，我们从头开始创建我们的数据平台。
比尔·英蒙（Bill Inmon）最近也做出了类似的观察：
“一开始，我们把所有这些数据都扔进了一个叫做‘数据湖’的坑里。但我们很快发现，仅仅把数据扔进坑里是一种毫无意义的练习。为了有用 - 被分析 - 数据需要相互关联，并仔细安排其分析基础设施并提供给最终用户。除非我们满足这两个条件，否则数据湖就会变成沼泽，过一段时间沼泽就开始散发臭味。不符合分析标准的数据湖是浪费时间和金钱。“ - 比尔·英蒙 (Bill Inmon) 建造数据湖库
解决方案：Data Lakehouse
我们需要一个数据管理系统，它结合了数据仓库（ACID 兼容性、数据版本控制和优化功能）和数据湖（低成本存储和多种数据格式）的主要优势，因此我们需要一个Data Lakehouse 平台， Databricks之所以被选中，是因为它对 Data Lakehouse 是什么的本地实现以及下一节中描述的原因。
图 2 数据仓库：数据湖 - 数据湖库比较
机器学习 (ML) 算法不适用于数据仓库 (DWH)。与通常提取少量数据的 BI 查询不同，这些 ML 算法在不使用 SQL（XGBoost、Pytorch、TensorFlow ……）的情况下处理大型数据集。由于数据类型的不断转换（在使用 JCBD/ODBC 连接器时执行），读取这些数据的效率很低，而且通常与数据仓库中使用的内部专有数据格式没有直接兼容性。对于这些用例，数据可以以开放数据格式导出到文件中，但这增加了另一个 ETL 步骤，从而增加了复杂性和陈旧性。
可以说，像Snowflake这样的“云原生”数据仓库支持以数据湖格式（开放数据格式）读取外部表，也实现了 Data Lakehouse 方法，但是：
- 他们的主要数据源是他们的内部数据（存储成本要高得多），因此在某些情况下仍然需要 ETL 管道（添加维护流程和更多可能的故障点）
- 他们无法为数据湖中的数据提供与其内部数据相同的管理功能（例如：事务、索引……）。
- 他们的 SQL 引擎主要针对以内部格式查询数据进行了优化。
此外，直接查询数据湖存储中数据的一次性工具（如前面提到的Presto/Trino或AWS Athena）并不能解决整个数据问题，因为它们缺乏普通数据仓库具有的基本管理功能（ACID 事务） ，索引...）。
图 3：DeNexus 数据平台
为什么它能满足我们的需求？
允许不同类型的用户访问数据：为了使用 SQL 访问数据，必须有人处理原始数据并赋予其结构。可以使用简单的 SQL 完成这些转换吗？答案是肯定的，但祝你好运......
SQL 对很多事情都很有用，但对其他事情却不是（它很难实现递归或循环，很难使用变量……）因为它不是一种通用的编程语言。由于我们不知道在实施我们的 DeRISK 产品路线图期间所需的全部转换范围，我们决定追求多功能性：Databricks允许执行 Spark 和 Python、Scala、Java、R 和……SQL！因此，它可以被多种类型的用户使用。瞧！
强大的数据版本控制 -> Delta。Databricks本机实现DELTA 格式。这解决了 Spark 的主要问题之一：它与 ACID 不兼容（Delta 完全兼容 ACID）。此外，这允许在管道出现错误的情况下使用恢复系统，并提供一种简单的方法来保证，例如，开发模型中使用的数据将始终相同（数据版本控制）。此外，Delta 是完全开源的。
Databricks（如 Spark）允许我们处理所有类型的数据（结构化、半结构化和非结构化）和数据格式：
此外，如果 Spark 不支持特定格式，则可以手动开发连接器（Spark 是完全开源的）或使用本机 Python、Scala、R 或 Java 库（Databricks不仅仅是托管的 Spark）。
可扩展性与 Databricks 的 PaaS 性质以及我们数据平台中所有云资源的使用相关：S3 满足更多的存储需求，以及新环境的一次性需求（如果新的数据科学家加入团队，不再需要在本地配置他/她的计算机）或更多的处理能力由Databricks直接满足，这释放了非常宝贵的资源的大部分时间：软件工程师。在任何时候，您都可以详细控制正在运行的机器数量以及它们具有哪些功能（也可以避免在计费时出现意外！）。
此外，使用 Spark DBR（Databricks的Spark实现）比常规 Spark 快得多，这使得为Databricks运行时支付的额外费用是值得的。
图 4：Spark 开源与 Spark DBR（通过 YouTube）
Databricks + 托管 MLflow 作为完整的 ML-Ops 解决方案。为模型开发提供环境和整个机器学习生命周期的平台。
Databricks最初创建了 Mlflow，然后将其捐赠给了 Linux 基金会
GitHub - mlflow/mlflow: 机器学习生命周期的开源平台
它允许我们的数据科学家轻松跟踪实验中使用的表版本，并在以后重现该版本的数据。此外，它为他们提供了一个协作环境，在其中他们可以轻松地与其他同事共享他们的模型/代码。
它甚至可以与 Azure-ML 或 AWS SageMaker 等其他 ML 平台结合使用：在Databricks Managed MLflow 中注册的模型可以在 Azure-ML 或 AWS SageMaker 中轻松使用。
此外，Databricks Managed Mlflow的使用使我们的数据科学家能够使用 Spark ML 和 Koalas（在 Spark 中实现 Pandas）轻松地并行化他们的算法。
数据存储和处理层完全解耦。数据可以位于任何位置或格式，并且可以使用Databricks来处理它（单独的计算和存储）。没有使用专有格式或工具，因此我们可以高度灵活地迁移我们的数据。
最后的想法
本文开头的图表（图 4）显示了数据的三个阶段以及每个阶段使用的工具：
- 数据处理：Databricks、Python+ AWS Lambda、EC2。
- 数据可发现性：Databricks、AWS Athena。
- ML-Ops：Databricks、AWS SageMaker。
有一个共同点：Databricks的使用。
此外，没有任何类型的供应商锁定（AWS Glue 数据目录被用于外部化 Metastore），并且按使用付费模型允许我们为某些我们现在没有的场景使用替代方案，但我们将来可能会有。
图 5：统治所有这些的数据平台
作者简介：
Iván Gómez Arnedo 是一位经验丰富的数据工程师，在解决具有挑战性的架构和可扩展性问题以及构建数据密集型应用程序方面充满热情并取得了良好的记录。在加入 DeNexus 之前，Iván 曾在巴斯夫和桑坦德银行的众多关键数据项目中工作。
