如何在您的数据堆栈中建立可靠性
数据已经成为现代企业日常运营中不可或缺的一部分，并为数字产品提供动力；对可靠数据的需求只会增加。
通过
-
22年6月8日 - 大数据区 -观点
喜欢 (1)
评论
保存
鸣叫
111次浏览
加入DZone社区，获得完整的会员体验。
2004年7月26日，一家名为Google的5岁创业公司面临着一个严重的问题：他们的应用程序被关闭了。
在几个小时内，美国、法国和英国的用户都无法访问这个流行的搜索引擎。这个当时只有800人的公司和它的数百万用户被蒙在鼓里，因为工程师们正在努力解决这个问题并发现问题的根源。到了中午，由几个惊慌失措的工程师进行的繁琐而密集的程序确定，MyDoom病毒是罪魁祸首。
在2021年，这种长度和规模的故障被认为是相当反常的，但在15年前，这种类型的软件故障并不稀奇。多年来，在带领团队经历了几次这样的经历之后，当时的谷歌工程经理本杰明-特雷诺-斯洛斯（Benjamin Treynor Sloss）认为，必须有一种更好的方式来管理和预防这些令人眼花缭乱的火灾演习，不仅是在谷歌，而且在整个行业。
受他早期建立数据和IT基础设施的启发，Sloss将他的经验编成了一门全新的学科--网站可靠性工程（SRE）--致力于优化软件系统（如谷歌的搜索引擎）的维护和运营，并将可靠性考虑在内。
根据Sloss和其他为该学科铺平道路的人的说法，SRE是关于自动消除对边缘情况和未知因素（如错误的代码、服务器故障和病毒）的担忧。最终，Sloss和他的团队希望有一种方法，让工程师们能够将维护公司快速增长的代码库的手工劳作自动化，同时确保当系统发生故障时，他们的基础得到保障。
"SRE是一种思考和处理生产的方式。大多数开发一个系统的工程师也可以成为该系统的SRE，"他说。"问题是：他们能不能把一个复杂的、也许不是很明确的问题，想出一个可扩展的、技术上合理的解决方案？"
如果谷歌有正确的流程和系统来预测和预防下游问题，不仅可以很容易地修复故障，对用户的影响最小，而且可以完全避免。
数据就是软件，软件就是数据
近20年后，数据团队也面临着类似的命运。像软件一样，数据系统变得越来越复杂，有多个上游和下游的依赖关系。十年甚至五年前，在孤岛上管理你的数据是正常的，也是被接受的，但现在，团队甚至整个公司都在与数据打交道，促进了数据管理的协作性和抗错性的提高。
在过去的几年里，我们见证了数据工程 和分析团队广泛采用软件工程的最佳实践来解决这一差距，从采用像dbt和Apache Airflow这样的开源工具来简化数据转换和协调到基于云的数据湖和数据仓库。
从根本上说，这种向敏捷原则 的转变与我们如何构思、设计、构建和维护数据系统有关。孤岛式的仪表盘和报告只生成一次，很少使用，而且从不更新的日子已经一去不复返了；现在，为了在规模上发挥作用，数据也必须被产品化、维护和管理，以便被整个公司的终端用户使用。
数据可靠性的崛起
简而言之，数据可靠性是一个组织在整个数据生命周期中提供高数据可用性和健康性的能力，从摄入到最终产品：仪表盘、ML模型和生产数据集。在过去，人们一直注意孤立地解决这个难题的不同部分，从测试框架到数据可观察性，但这种方法已经不够了。然而，正如任何数据工程师会告诉你的那样，数据的可靠性（以及真正把数据当作产品的能力）是无法在一个孤岛上实现的。
一个数据资产中的模式变化会影响到多个表，甚至是Tableau仪表盘中的下游字段。当你的财务团队在Looker中查询新的洞察力时，一个缺失的值会让他们陷入歇斯底里。而当500行突然变成5000行时，这通常是一个迹象，说明有些东西不对--你只是不知道这个表在哪里或怎么坏的。
即使有大量优秀的数据工程工具和资源存在，数据也会因为数百万种不同的原因而中断，从操作问题和代码更改到数据本身的问题。
在与数百个数据团队交谈后，并通过我自己的经验，我发现大约80%的数据问题并不是单靠测试就能解决的。 图片来源：Lior Gavish。
根据我自己的经验和与数百个团队交谈后，目前大多数数据工程师有两种方式发现数据质量问题：测试（理想的结果）和来自你下游利益相关者的愤怒信息（可能的结果）。
就像SRE管理应用程序的停机时间一样，今天的数据工程师必须专注于减少数据停机时间--数据不准确、缺失或其他错误的时间段--通过自动化、持续集成和持续部署数据模型以及其他敏捷原则。
在过去，我们已经讨论了如何建立一个快速和肮脏的数据平台；现在，我们在这个设计的基础上，反映了这个实现良好数据的旅程的下一步：数据可靠性栈。
下面是建立一个的方法和原因。
介绍：数据可靠性堆栈
现在，数据团队的任务是建立可扩展的、高性能的数据平台，通过存储、处理和输送数据来满足跨职能分析团队的需求，以产生准确和及时的洞察力。但要达到这个目标，我们还需要适当的方法来确保原始数据首先是可用的和可信赖的。为此，一些最好的团队正在建立数据可靠性堆栈，作为其现代数据平台的一部分。
在我看来，现代数据可靠性堆栈是由四个不同的层次组成的：测试、CI/CD、数据可观察性和数据发现，每个层次都代表了公司数据质量旅程中的一个不同步骤。
数据可靠性堆栈由五层组成，包括测试、CI/CD、数据可观察性和数据发现。图片来源：Lior Gavish。
数据测试
测试你的数据在进入生产数据管道之前发现数据质量问题方面起着关键作用。通过测试，工程师们预测到某些东西可能会被破坏，并编写逻辑来预先检测问题。
数据测试是在生产之前或期间验证你的组织对数据的假设的过程。编写检查诸如唯一性和非空的基本测试是组织可以测试出他们对源数据的基本假设的方法。对于组织来说，确保数据的格式正确，以便他们的团队能够工作，并且数据能够满足他们的业务需求，也是很常见的。
一些最常见的数据质量测试包括。
- 空值--是否有任何数值未知（NULL）？
- 数量 - 我是否得到了任何数据？我是否得到了太多或太少？
- 分布 - 我的数据是否在一个可接受的范围内？我的数值在某一列的范围内吗？
- 唯一性--是否有重复的数值？
- 已知的不变量--利润是否总是收入和成本之间的差额，或者关于我的数据的一些其他众所周知的事实？
根据我自己的经验，有两个测试数据的最好工具是dbt测试和Great Expectations（作为一个更通用的工具）。这两个工具都是开源的，可以让你在数据最终落到利益相关者手中之前发现数据质量问题。虽然dbt本身不是一个测试解决方案，但如果你已经在使用框架来建模和转换你的数据，他们的开箱即用的测试效果很好。
持续集成（CI）/持续交付（CD）
CI/CD是软件开发生命周期的一个关键组成部分，它通过自动化确保新的代码部署是稳定和可靠的，因为随着时间的推移，更新。
在数据工程的背景下，CI/CD不仅涉及到持续集成新代码的过程，还涉及到将新数据集成到系统的过程。通过在早期阶段发现问题，最好是在代码提交或新数据合并时就发现问题--数据团队能够达到一个更快、更可靠的开发工作流程。
让我们从方程式的代码部分开始。就像传统的软件工程师一样，数据工程师受益于使用源码控制，例如Github，来管理他们的代码和转换，以便新的代码可以被正确的审查和版本控制。一个CI/CD系统，例如CircleCI或Jenkins（开源），有一个完全自动化的测试和部署设置，可以在部署代码时创造更多的可预测性和一致性。这听起来应该非常熟悉。
数据团队遇到的额外的复杂性是理解代码的变化如何影响其输出的数据集的挑战。这就是像Datafold这样的新兴工具的作用--允许团队将新代码的数据输出与同一代码的先前运行进行比较。在代码部署之前，通过在流程的早期捕获意外的数据差异，可以实现更高的可靠性。虽然这个过程需要有代表性的暂存数据或生产数据，但它可以是非常有效的。
还有另一个系列的工具，旨在帮助团队更可靠地运送新数据，而不是新代码。通过LakeFS或Project Nessie，团队能够在发布数据供下游消费之前，以类似git的语义对其进行分级。想象一下，用新处理的数据创建一个分支，只有当它被认为是好的时候才会提交到主分支上结合测试，数据分支可以成为一种非常强大的方式来阻止不良数据到达下游消费者。
数据的可观察性
在生产前对数据进行测试和版本管理是实现数据可靠性的第一步，但是当数据在生产中出现问题时--以及在生产之后--会发生什么？
除了在转换和建模之前解决数据质量问题的数据可靠性堆栈元素之外，数据工程团队还需要投资于端到端的自动化数据观察解决方案，以便在近乎实时的情况下检测数据问题的发生。与DevOps可观察性解决方案（即Datadog和New Relic）类似，数据可观察性 使用自动监测、警报和分流来识别和评估数据质量问题。
数据可观察性的五大支柱。图片来源：Barr Moses
数据可观察性是通过数据健康和可靠性的五个关键支柱来衡量的：新鲜度、分布、数量、模式和血统。
- 新鲜度。数据是最近的吗？最后一次生成是什么时候？包括或省略了哪些上游数据？
- 分布。数据是否在可接受的范围内？它的格式是否正确？它是完整的吗？
- 数量。所有的数据都到了吗？数据是否因意外而被重复？从一个表中删除了多少数据？
- 模式。什么是模式，它是如何改变的？谁对模式进行了修改，出于什么原因？
- 脉络。对于一个给定的数据资产，受其影响的上游和下游来源是什么？谁是产生这些数据的人，谁在依靠这些数据进行决策？
数据可观察性占了你的团队无法预测的另外80%的数据停机时间（未知数未知数），不仅仅是检测和提醒数据质量问题，而且还提供根本原因分析、影响分析、领域级线程和你的数据平台的运营洞察力。
有了这些工具，你的团队将装备精良，不仅可以解决，还可以通过对数据可靠性的历史和统计洞察，防止类似问题在未来发生。
数据发现
虽然传统上不被认为是可靠性堆栈的一部分，但我们认为数据发现是至关重要的。团队创造不可靠数据的最常见方式之一是忽视已经存在的资产，并创建新的数据集，这些数据集与现有数据集严重重叠，甚至相互矛盾。这在企业的消费者中造成了混乱，即哪些数据与特定的业务问题最相关，并减少了信任和感知的可靠性。
它还为数据工程团队创造了大量的数据债务。如果没有良好的发现，团队会发现自己需要维护几十个不同的数据集，这些数据集都描述了相同的维度或事实。仅仅是这种复杂性就使得进一步的开发成为一种挑战，而且高可靠性也非常困难。
虽然数据发现是一个极具挑战性的问题，但数据目录已经在更大程度的民主化和可访问性方面取得了进展。例如，我们已经见证了Atlan、data.world和Stemma等解决方案如何解决这两个问题。
同时，数据可观察性解决方案可以帮助消除许多常见的感知的可靠性问题和数据债务挑战，以实现数据发现。通过将元数据、脉络、质量指标、使用模式以及人类产生的文档拉到一起，数据可观察性可以回答这样的问题：我有哪些数据可以用来描述我们的客户？我应该最信任哪个数据集？我怎样才能使用该数据集？谁是可以帮助回答相关问题的专家？简而言之，这些工具为数据消费者和生产者引入了一种方法，以找到他们需要的数据集或报告，并避免那些重复的工作。
将这些信息民主化，让任何使用或创建数据的人都能获得这些信息，这是可靠性难题的关键部分。
数据可靠性的未来
随着数据在现代企业的日常运作中变得越来越不可或缺，并为数字产品提供动力，对可靠数据的需求只会增加，围绕确保这种信任的技术要求也会增加。
然而，虽然你的堆栈会让你达到一些目的，但数据的可靠性并不是仅靠技术就能解决的。最强大的方法还包括文化和组织的转变，以优先考虑治理、隐私和安全，所有这三个领域的现代数据堆栈在未来几年内已经成熟加速。
在你的数据可靠性武库中的另一个强有力的工具是优先考虑服务水平协议（SLA）和其他措施，以跟踪问题的频率，相对于与你的利益相关者设置的商定的期望，这是从软件工程中收集的另一个尝试和真正的最佳做法。当你的组织把数据当作产品，数据团队不再像财务分析师，而是像产品和工程团队时，这样的指标将是至关重要的。
同时，在此祝愿你没有数据停机--以及大量的正常运行时间
CI/CD 数据质量 工程师 工程 可观察性 开源 软件开发 敏捷 数据（计算） 系统
经Lior Gavish许可发表于DZone。在此查看原文。
DZone贡献者所表达的观点属于他们自己。
在DZone上很受欢迎
- 关于Scaled Agile Framework（SAFe）的完整指南？
- 持续交付。如何用更低的风险更快地创建产品
- 淘宝网上卖的是什么？
- AWS/Terraform研讨会#5：AWS Lambda函数
评论
