概述可靠数据系统的过去、现在和未来。
当我们在2019年推出数据可观察性类别时，这个术语对我来说几乎是无法发音的。
四年后，该类别已经在现代数据堆栈中坚定地确立为核心层。数据可观察性是G2类别，得到了Gartner、Forrester等机构的认可，并且最重要的是被数百家公司广泛采用，其中包括一些全球最先进的数据组织。
事实上，一家快速发展的公司的首席技术官最近告诉我：“这是一个长期趋势，因为世界正在发生变化。数据可观察性迟早会发生，没有人能够阻止它。”
虽然我仍然无法总是正确发音（英语作为第二语言，有人吗？），但数据可观察性已经成为现代数据团队必备的工具，我为这个运动的发展路径感到骄傲。
那么，数据可靠性的未来会是什么样子？要了解我们前进的方向，首先需要回顾一下我们已经取得的进展。
我们的起点
在2010年代中期，数据团队开始迁移到云端，并采用数据存储和计算技术—Redshift、Snowflake、Databricks、GCP等等—以满足对分析的不断增长的需求。云计算使得数据处理更快速，转换更容易，可访问性更强。
随着数据变得更加普遍，数据管道变得更加复杂，新的角色进入场景来管理这种混乱（你好，数据工程师），可能的用例数量也激增。
好处是什么？更明智的决策，更多的数据用例和更智能的软件。
坏处是什么？基本的东西，比如数据质量，被忽视了，而被这个现代数据堆栈中更抢眼的部分所取代。
在过去的生活中，我亲眼目睹了糟糕数据的影响。凌晨五点，我们的首席财务官发来信息说“数据看起来不对。”持有者在仪表板无法更新时在我的电脑显示器上贴上便笺。由于我们的产品被提供了不准确的数据，困惑的客户摇头不解。
数据可观察性就是从这种痛苦中诞生的，我们将其称为数据停机，它提供了一个切实可行的解决方案。受应用可观察性和站点可靠性工程的启发，数据可观察性在数据影响业务之前监控和警报组织中的数据事故。数据可观察性提供了一种自动化、过程驱动的实现数据可靠性的替代方法，降低成本，推动增长，并大幅减少凌晨五点的火灾演习。
历史上，最强大的数据可观察性方法包括三个主要阶段：检测、解决和预防。
- 检测：数据可观察性检测数据中的异常和其他问题，并在利益相关者发现之前向数据团队的适当所有者发出警报。
- 解决：同时，数据可观察性平台为团队提供解决问题的工具，包括字段级别的血缘关系、自动化的根本原因分析和影响分析、有关影响该资产的过去事件的信息、相关查询日志和dbt模型、受影响的报告等等。
- 预防：最后，数据可观察性还提供了防止数据问题首次发生的机制，比如在管道中设置断路器，并在数据上创建代码更改将对数据产生的影响的可见性等等，以防止不良数据首次进入管道。
在开始阶段，数据可观察性专注于通过利用元数据和数据本身来拼凑数据健康状况的图像，检测、解决和防止数据问题。通过监控和警报从数据摄入到数据消费的过程中的数据问题，团队可以检测到未预料到的上游表格的更改，这导致下游来源破裂或变得不可靠。
超越数据的检测和解决
然而，与任何行业一样，数据空间也在不断演变，影响着团队对事故检测和解决以及数据可观察性的思考方式。这种演变归功于一些令人兴奋的趋势：数据产品的崛起，以及由此导致的数据团队向工程组织更加接近或直接融入其中的持续迁移。
随着数据团队在组织中的范围扩大和数据用例的增加，数据团队对企业的利润影响比以往任何时候都更大。现在，企业中的每个人都每天利用数据来获取见解、为数字服务提供动力并训练机器学习模型。事实上，我们已经超越了将数据作为产品的简单处理方式。在2023年，数据本身就是一个产品。
几百个客户后，包括百事、Gusto、MasterClass和Vimeo的团队，在我们的发现中，我们需要超越仅仅关注数据，以实现数据的可靠性。不可靠的数据不是孤立存在的…它受到数据生态系统的三个要素的影响：数据 + 代码 + 基础设施。
这种更广泛的视野反映了我们软件工程领域的朋友们如何处理检测和解决问题。应用程序的可观察性从基础设施开始，但分析的范围远远超过此，以检测和解决软件停机问题；根本原因分析考虑了代码、基础设施、服务、网络和许多其他因素。对于软件工程师来说，可靠性并非孤立实现，通常受到多个因素的影响，经常同时作用或相互叠加。
在数据领域，情况通常也是如此，我们应该开始以这种方式处理它。
让我们通过一个数据领域的假想例子来说明。
假设你有一个显示陈旧结果的仪表盘。你可能首先查看你的数据，在这种情况下，可能是从Google获取的描述广告活动的上游表。是不是有人更改了广告活动名称，破坏了硬编码的数据流水线？或者你在点击事件表中得到的是空值而不是用户UUID？没有结果，那么接下来呢？
你查看代码。也许你的分析工程师对过滤最新数据的SQL进行了更改？他们的初衷是好的，但也许产生了意外后果？你查看了你的dbt存储库。不，一切正常。
最后，你查看基础设施。你迅速切换到Airflow的用户界面——也许你正在一个小实例上运行Airflow，它耗尽了内存（不应该将那些行加载到内存中！！），导致下游数据不新鲜的问题。欧里卡——你找到了！
经验告诉我们，这三个因素都对数据停机有重要影响。所以无论你首先查找的是哪个因素，你都要经历一个漫长而繁琐的过程，逐个进行有根据的猜测并逐一排除。哦，我们提到了它需要访问和精通组成你的数据堆栈的8种不同工具吗？
现在，想象一下，你可以快速将你看到的症状（陈旧的仪表盘…）与数据、代码和基础设施发生的所有变化相互关联。哦，而且你不需要统计学博士学位或者在公司有10年经验，了解数据仓库中的每一列。这一切都在你的指尖之间——对数据、代码和基础设施如何协同工作以导致仪表盘出错的全面理解。想象一下，你可以节省多少时间和资源，避免利益相关者的沮丧，更不用说清晨被叫醒了。
为了真正实现数据可观察性的潜力并实现可靠的数据，团队需要采取三层方法，将数据、代码和基础设施综合在一起，以全面了解对数据健康产生影响的因素。
我们还意识到，实现数据可靠性不仅仅是打开一个工具。这涉及到团队上创建一个新的纪律——一种操作思维方式。团队需要引入监控数据系统、响应事故和逐步改进的流程。
组织结构、流程和技术必须不断发展以实现这些目标。想象一下：仪表板可以根据支持它们的上游表格定义和监控数据产品的可靠性，并可以在整个组织中轻松共享，以实现透明度、协作和责任。并且可以根据用例和所有者将数据和流水线分段，以实现有针对性的故障排除和事件解决。
可靠数据与人工智能的未来
在这个阶段，认为大型语言模型（LLMs）将成为未来的【插入行业名称】几乎是老生常谈了，但对数据行业的影响是不同的。
当前数据和工程方面的生成式AI用例几乎完全侧重于提高生产效率，例如GitHub Co-Pilot、Snowflake Document AI和Databricks LakehouseIQ。在许多方面，我们不知道生成式AI的未来将会带来什么，但我们知道数据团队将在其中发挥重要作用。
LLMs有着帮助提高数据质量的激动人心机会，但更有力的论点是数据质量和可靠性可以帮助LLMs。事实上，我认为，提供生产用例的LLMs如果没有坚实的基础是无法存在的：即有大量高质量、可靠、可信赖的数据。
总体而言，今天绝大多数生成式AI应用都托管在云端，并通过API提供。为了支持它们，您需要一个稳健的基于云的数据堆栈，可靠地存储、转换、训练和提供支持它们的数据。
与此观点呼应，在Snowflake 2023年第一季度财报电话会议上，Snowflake首席执行官Frank Slootman表示：“生成式AI由数据驱动。这是模型训练并变得越来越有趣和相关的方式…您不能随意放任这些[LLMs]接触到人们无法理解其质量、定义和传承的数据。”
我们已经看到了不可靠模型训练的影响。就在去年，全球信用巨头Equifax表示，一个基于错误数据训练的机器学习模型导致他们向数百万消费者发送错误的信用评分。在此之前不久，Unity Technologies由于错误的广告数据为其定向算法提供燃料，导致1.1亿美元的收入损失。在未来几年中，除非我们优先考虑信任，否则这将不可避免地成为一个更大的问题。
随着企业在未来几年中见证人工智能应用的崛起，数据可观察性将成为支持LLMs和所有其他人工智能用例的关键能力。
正如Databricks的联合创始人Matei Zaharia、Patrick Wendell、Reynold Xin和Ali Ghodsi所建议的：“企业应用对于产生幻觉或错误响应的容忍度很低…在机器学习生命周期的每个阶段，数据和模型必须共同进行维护，以构建最佳应用。对于生成模型来说，这更加重要，因为质量和安全在很大程度上取决于良好的训练数据。”
我完全同意。实现更好、更有影响力的人工智能的第一步是什么？好的、可靠的数据 – 以及大量的数据。
加入我们，好吗？
通过LinkedIn与Barr Moses联系，分享您的想法、感受和情感。您认为这个领域将发展成什么样子？