多态数据转换技术/数据湖/大数据
Polymorphic data transformation techniques / data lake/ big data
背景：我们正在研究一种解决方案，以从各种客户端获取大量遥测数据。数据为 xml 格式，包含多个独立的信息组，其中有很多嵌套元素。客户端有不同的版本，因此数据在数据湖中以不同但相似的模式摄取。例如，startDate 字段可以是字符串或包含日期的对象。 ) 我们的目标是在 BI 工具中可视化累积的信息。
问题：
处理多态数据的最佳实践是什么？
- 使用编程语言将所需数据（简化版）处理并转换为 uni-schema 文件，然后在 spark 和 databricks 中处理并在 BI 工具中使用。
- 将数据分解为有意义的组，并使用 spark 和 databricks 处理和连接（使用数据关系）它们。
感谢您就此主题发表评论并分享意见和经验，尤其是来自主题专家和数据工程师的意见和经验。如果您还可以分享一些关于这个特定主题的有用资源，那就更好了。
干杯！
您为此线程选择的标签之一指出您希望将 Databricks 用于此 t运行sformation。 Databricks 是我正在使用的工具之一，我认为它足够强大和有效来进行这种数据处理。由于我使用最多的数据处理平台是 Azure 和 Cloudera，我的答案将依赖 Azure stack，因为它与 Databricks 集成。这是我根据我的经验推荐的。
您首先想到的是定义数据层并为它们创建平台。特别是，对于您的情况，它应该具有 Landing Zone、Staging、ODS 和 Data Warehouse 层。
着陆区
将用于从您的客户端摄取多态数据。这只能由 Azure Data Factory (ADF) connecting between the client and Azure Blob Storage 完成。我建议，在这一层中，我们不要将任何 t运行sformation 放入 ADF 管道中，以便我们可以创建一个用于摄取原始文件的通用管道。如果有许多客户端可以将数据发送到 Azure 存储，这很好。您也可以为它们创建一些专用文件夹。
通常，我会根据客户类型创建文件夹。例如，如果我有 3 种类型的客户端，Oracle、SQL 服务器和 SAP，我的 Azure 存储上的根文件夹将是 oracle、sql_server 和 sap，后跟 server/database/client 名称.
此外，如果您要从 IoT 设备获取数据，您似乎必须设置 Azure IoT 中心。如果是这样的话，page 会有所帮助。
暂存区
将成为架构清理区。我将拥有多个 ADF 管道，这些管道 t运行sform 来自 Landing Zone 的多态数据并将其摄取到暂存区。您将必须为每个分解的数据集和数据源创建架构 (delta table)。我建议使用 Delta Lake，因为它很容易管理和检索数据。
您将拥有的运行信息选项是：
仅使用 ADF t运行信息。它将允许您 unnest 一些嵌套的 XML 列以及进行一些数据清理和从着陆区 w运行gling 以便可以将相同的数据集插入相同的 table.
对于您的情况，您可能必须为乘以客户端版本的每个数据集创建特定的 ADF 管道。
使用额外的通用 ADF 管道 运行 Databricks t运行sformation 基于数据集和客户端版本。这将允许 ADF t运行sformation 无法实现的更复杂的 t运行sformations。
对于您的情况，每个数据集乘以客户端版本，也会有一个特定的 Databricks 笔记本。
因此，一个特定数据集的不同版本将从原始文件中提取，根据模式进行清理，并为每个数据源[=67]摄取到一个table中=].跨不同数据源的主数据集会有一些重复数据。
ODS 区域
将成为 so-called 数据单一真实来源的区域。多个数据源将合并为一个。因此，所有重复的数据都被消除，数据集之间的关系得到澄清，导致每个问题的第二项。如果您只有一个数据源，这也将是应用更多数据清理的领域，例如验证和一致性。结果，一个数据集将存储在一个 table.
我建议使用 ADF 运行 Databricks，但是这次，我们可以使用 SQL notebook 而不是 Python 因为数据很好地插入到 table 中已有暂存区。
Power BI 可以使用该阶段的数据。阅读 more 关于 Power BI 与 Databricks 的集成。
此外，如果您仍然想要一个 数据仓库 或星型模式来进行高级分析，您可以做进一步的 t运行sformation（再次通过 ADF 和 Databricks）和利用 Azure Synapse.
源代码管理
幸运的是，由于被微软收购 Github，我上面提到的工具已经集成了源代码版本控制。 Databricks 笔记本和 ADF 管道源代码可以进行版本控制。检查 Azure DevOps.
非常感谢您对 PhuriChal 的全面回答！事实上，数据源始终是相同的软件，但有各种不同的版本，不幸的是数据属性在这些版本中并不总是保持稳定。是否可以选择在摄取后处理原始数据，以便在数据块中进一步处理之前使用高级编程语言统一和解析不匹配的属性？（我们可能有许多这样的处理代码来为特定的建议提炼原始数据)我在原文中加了例子post.
Version1:{
'theProperty': 8
}
Version2:{
'data':{
'myProperty': 10
}
}
Processing =>
Refined version: [{
'property: 8
},
{
'property: 10
}]
以便在数据进入数据块进行进一步处理之前解决不一致问题。这也可以是一个选项吗？
背景：我们正在研究一种解决方案，以从各种客户端获取大量遥测数据。数据为 xml 格式，包含多个独立的信息组，其中有很多嵌套元素。客户端有不同的版本，因此数据在数据湖中以不同但相似的模式摄取。例如，startDate 字段可以是字符串或包含日期的对象。 ) 我们的目标是在 BI 工具中可视化累积的信息。
问题： 处理多态数据的最佳实践是什么？
- 使用编程语言将所需数据（简化版）处理并转换为 uni-schema 文件，然后在 spark 和 databricks 中处理并在 BI 工具中使用。
- 将数据分解为有意义的组，并使用 spark 和 databricks 处理和连接（使用数据关系）它们。
感谢您就此主题发表评论并分享意见和经验，尤其是来自主题专家和数据工程师的意见和经验。如果您还可以分享一些关于这个特定主题的有用资源，那就更好了。
干杯！
您为此线程选择的标签之一指出您希望将 Databricks 用于此 t运行sformation。 Databricks 是我正在使用的工具之一，我认为它足够强大和有效来进行这种数据处理。由于我使用最多的数据处理平台是 Azure 和 Cloudera，我的答案将依赖 Azure stack，因为它与 Databricks 集成。这是我根据我的经验推荐的。
您首先想到的是定义数据层并为它们创建平台。特别是，对于您的情况，它应该具有 Landing Zone、Staging、ODS 和 Data Warehouse 层。
着陆区
将用于从您的客户端摄取多态数据。这只能由 Azure Data Factory (ADF) connecting between the client and Azure Blob Storage 完成。我建议，在这一层中，我们不要将任何 t运行sformation 放入 ADF 管道中，以便我们可以创建一个用于摄取原始文件的通用管道。如果有许多客户端可以将数据发送到 Azure 存储，这很好。您也可以为它们创建一些专用文件夹。
通常，我会根据客户类型创建文件夹。例如，如果我有 3 种类型的客户端，Oracle、SQL 服务器和 SAP，我的 Azure 存储上的根文件夹将是 oracle、sql_server 和 sap，后跟 server/database/client 名称.
此外，如果您要从 IoT 设备获取数据，您似乎必须设置 Azure IoT 中心。如果是这样的话，page 会有所帮助。
暂存区
将成为架构清理区。我将拥有多个 ADF 管道，这些管道 t运行sform 来自 Landing Zone 的多态数据并将其摄取到暂存区。您将必须为每个分解的数据集和数据源创建架构 (delta table)。我建议使用 Delta Lake，因为它很容易管理和检索数据。
您将拥有的运行信息选项是：
仅使用 ADF t运行信息。它将允许您 unnest 一些嵌套的 XML 列以及进行一些数据清理和从着陆区 w运行gling 以便可以将相同的数据集插入相同的 table.
对于您的情况，您可能必须为乘以客户端版本的每个数据集创建特定的 ADF 管道。
使用额外的通用 ADF 管道 运行 Databricks t运行sformation 基于数据集和客户端版本。这将允许 ADF t运行sformation 无法实现的更复杂的 t运行sformations。
对于您的情况，每个数据集乘以客户端版本，也会有一个特定的 Databricks 笔记本。
因此，一个特定数据集的不同版本将从原始文件中提取，根据模式进行清理，并为每个数据源[=67]摄取到一个table中=].跨不同数据源的主数据集会有一些重复数据。
ODS 区域
将成为 so-called 数据单一真实来源的区域。多个数据源将合并为一个。因此，所有重复的数据都被消除，数据集之间的关系得到澄清，导致每个问题的第二项。如果您只有一个数据源，这也将是应用更多数据清理的领域，例如验证和一致性。结果，一个数据集将存储在一个 table.
我建议使用 ADF 运行 Databricks，但是这次，我们可以使用 SQL notebook 而不是 Python 因为数据很好地插入到 table 中已有暂存区。
Power BI 可以使用该阶段的数据。阅读 more 关于 Power BI 与 Databricks 的集成。
此外，如果您仍然想要一个 数据仓库 或星型模式来进行高级分析，您可以做进一步的 t运行sformation（再次通过 ADF 和 Databricks）和利用 Azure Synapse.
源代码管理
幸运的是，由于被微软收购 Github，我上面提到的工具已经集成了源代码版本控制。 Databricks 笔记本和 ADF 管道源代码可以进行版本控制。检查 Azure DevOps.
非常感谢您对 PhuriChal 的全面回答！事实上，数据源始终是相同的软件，但有各种不同的版本，不幸的是数据属性在这些版本中并不总是保持稳定。是否可以选择在摄取后处理原始数据，以便在数据块中进一步处理之前使用高级编程语言统一和解析不匹配的属性？（我们可能有许多这样的处理代码来为特定的建议提炼原始数据)我在原文中加了例子post.
Version1:{
'theProperty': 8
}
Version2:{
'data':{
'myProperty': 10
}
}
Processing =>
Refined version: [{
'property: 8
},
{
'property: 10
}]
以便在数据进入数据块进行进一步处理之前解决不一致问题。这也可以是一个选项吗？