云的数据质量和可靠性 – Azure、AWS 和 GCP

已发表: 2022-07-01

从数据到企业洞察之旅的“数据信任”的圣杯并不是全新的。由于 BI 和分析工作负载与数据仓库分离，鸿沟已经扩大。

业务需求、IT 应用环境支持的业务运营以及业务团队在数据仓库中积累的数据的可靠性之间存在更大的差距。

出现了一些概念和工具来解决以下形式的差距：

在这场混乱中，数据质量解决方案和工具深埋在 MDM 和数据治理计划中。尽管如此，仍然存在两个挑战——第一个是回顾过去，同时询问数据是否可信。

其次，“质量”是根据黄金记录和主数据来衡量的——标准化本身也在不断发展。

虽然大数据炒作始于 Hadoop，但解决了对容量、速度和准确性的担忧，但这仍然是企业游戏。

真正的创新始于 MPP 系统，如 AWS 上的 Redshift 以原生方式构建云，它保证了处理海量数据集的更高性能，具有良好的经济性和 SQL 友好的界面。

这反过来又催生了一组数据摄取工具，例如 Fivetran，这使得将数据带到云上变得更加容易。

今天，数据被存储在云文件系统和云数据仓库的数据湖中，我们看到这反映在 Databricks 和 Snowflake 等供应商的增长中。

数据驱动的梦想看起来比以前更近了。

业务团队渴望分析数据并将其转换为他们的需求，并且 BI 工具生态系统不断发展以创建数据的业务视图。

随着各种团队在云仓库上转换和操作数据，数据从严格控制和治理的环境转移到狂野的西部。

这不仅仅是数据的数量和增长。渴望数据的团队（数据消费者）也以 BI 团队、分析团队和数据科学团队的形式激增。

事实上，在数字原生组织（完全建立在云上）中，即使是业务团队也是数据团队。例如，营销人员需要有关产品流量的实时信息来优化活动。

为这些专业和分散的团队提供他们的要求和期望并不是一件容易的事。

数据生态系统做出了明智的反应，标志着数据工程和管道的开始作为一个基本单元来打包专门的转换、连接、聚合等。

现实情况是，数据团队一直在与损坏的管道、不断变化的模式和格式进行战斗，这些问题会影响所有数据消费者，例如损坏的 BI 仪表板和来自 ML 模型的垃圾预测。

这需要围绕建立对数据的信任进行新的思考，以前的数据质量指标和方法是不够的。

我们需要数据可靠性指标来监控和观察各种形状（例如分布）和形式（架构更改、格式更改）的数据变化以及满足 BI 工程师/分析师和数据科学家需求的数据变化。

随着企业转向自助服务工具，商业智能 (BI)、数据分析、损坏的仪表板和漂移的机器学习模型对于各种规模的企业来说都是痛苦的。

事实上，对于拥有较小数据团队的企业来说，这个问题更加突出，因为他们花费了大量时间来解决数据可靠性问题，否则这些问题可以用来释放数据的价值。

这也需要一种更经济的方式，以基于云原生架构提供工程效率，优化和扩展按需计算和存储，以提供数据可靠性监控。

尽管在使数据更接近业务团队方面取得了重大进展，但现代数据生态系统中仍然存在未解决的差距。

当前的工具带来了能力，它们还将数据基础设施的底层复杂性直接暴露给业务团队。

大多数企业发现开始使用云计算具有挑战性，因为没有多少低代码工具可以轻松处理数据。

这些工具通常对数据的复杂性有很好的抽象，但它们并不总是具有与用户的特定目标和目的相一致的用户界面。

这个领域正在加速发展，我们看到新的团队在数据可靠性领域带来了无代码/低代码。

广泛的工具正在重新构想在云上监控现代数据生态系统的问题。

Data Dog & New Relic 类工具监控云上的数据基础设施。 Unravel 等其他工具可监控云上的数据堆栈。

还出现了一些工具来监控云上的数据管道。最后，Qualdo-DRX 是监控数据质量和可靠性的领先工具，专为所有公共云提供和重新构想。

对此有什么想法吗？ 在下面的评论中让我们知道，或者将讨论带到我们的 Twitter 或 Facebook。