如何建立你的数据可靠性堆栈

2004年7月26日,一家成立5年的初创公司谷歌面临着一个严重的问题: 他们的申请被驳回了

几个小时, 美国各地的用户, 法国, 而英国则无法访问这个流行的搜索引擎. 当工程师们努力解决问题并发现问题的根本原因时,这家当时拥有800名员工的公司和数百万用户被蒙在鼓里. 到了中午,几个惊慌失措的工程师进行了一场冗长而密集的调查 MyDoom病毒 是罪魁祸首.

In 2021, 这种长度和规模的停电被认为是相当反常的, 但15年前, 这种类型的软件中断并不罕见. 在多年来领导团队经历了一些这样的经历之后, 本杰明特雷诺斯洛斯已经分居, 当时是谷歌的工程经理, 决定必须有一个更好的方法来管理和防止这些令人眼花缭乱的消防演习, 不仅仅是谷歌,而是整个行业. 

灵感来自于他早期的数据和IT基础设施建设职业生涯, 斯洛斯把他的学识编成了一门全新的学科 网站可靠性工程 (行为) -专注于优化软件系统的维护和操作(如谷歌的搜索引擎)的可靠性. 

据斯洛斯等人说 为这门学科的发展铺平道路, SRE是关于自动化的,无需担心边缘情况和未知的未知(如bug代码), 服务器失败, 和病毒). 最终, 斯洛斯和他的团队希望工程师们能找到一种方法,使他们能够自动化地维护公司快速增长的代码库,同时确保系统崩溃时代码库能够被覆盖. 

“SRE是一种思考和接近生产的方式. 大多数开发系统的工程师也可以成为该系统的SRE。” 他说. “问题是:他们能承受复杂的, 可能没有明确定义的问题,然后提出可伸缩的, 技术上合理的解决方案?” 

如果谷歌有正确的流程和系统来预测和预防下游问题, 不仅可以轻松地修复中断,而且对用户的影响最小, 但完全阻止.

数据就是软件,软件就是数据

近20年后,数据团队面临着类似的命运. 像软件, 数据系统正变得越来越复杂, 具有多个上游和下游依赖关系. 十年前,甚至五年前, 在竖井中管理数据是正常且被接受的, 但现在, 团队甚至整个公司都在使用数据, 为数据管理提供更具协作性和防故障性的方法. 

在过去的几年里, 推荐一个正规滚球网站已经见证了数据工程和分析团队广泛采用软件工程最佳实践来解决这一差距, 从采用dbt和Apache气流这样的开源工具来简化数据转换和编排,到基于云的数据仓库和湖泊等 雪花和砖

从根本上, 这种向敏捷原则的转变与推荐一个正规滚球网站如何概念化有关, 设计, 构建, 维护数据系统. 那种只生成一次的竖井式仪表板和报告的日子已经一去不复返了, 很少使用, never updated; now, 在规模上有用, 数据还必须被产品化,为整个公司的终端用户的消费进行维护和管理. 

为了让数据像软件产品一样被对待,它也必须和软件产品一样可靠. 

数据可靠性的提高 

非常搞笑的推特 赛斯罗斯他是TopCoat Data的联合创始人.

简而言之, 数据的可靠性 组织是否有能力在整个数据生命周期中提供高数据可用性和运行状况, 从摄入到最终产品:仪表盘, 毫升模型, 和生产数据集. 在过去, 已注意孤立地解决这一难题的不同部分, 从测试框架到数据可观察性, 但这种方法已不再足够. 任何数据工程师都会告诉你, 然而, 数据可靠性(以及真正像对待产品一样对待数据的能力)不是在竖井中实现的. 

一个数据资产的模式更改可能会影响多个表,甚至是Tableau仪表板下游的字段. 当你的财务团队在查询Looker的新见解时,一个缺失的价值可能会让他们歇斯底里. 当500行突然变成5行,000, 这通常是有问题的迹象——你只是不知道桌子在哪里或怎么坏的.

即使有大量的数据工程工具和资源存在, 数据可能因为数百万种不同的原因而被破坏, 从操作问题和代码更改到数据本身的问题. 

在与数百个数据团队交谈后,通过我自己的经验, 我发现,大约80%的数据问题并没有被单独的测试所覆盖. 图片由Lior Gavish提供.

根据我自己的经验,以及在与数百个团队交谈后, 目前,大多数数据工程师发现数据质量问题的方法有两种:测试(理想的结果)和下游涉众的愤怒信息(可能的结果)。. 

与SREs管理应用程序停机时间的方法相同,今天的数据工程师必须关注于减少停机时间 数据停机时间 —数据不准确的时间段, 失踪, 或者错误-通过自动化, 持续集成, 以及持续部署数据模型, 以及其他敏捷原则. 

在过去,推荐一个正规滚球网站讨论了如何构建 一个快速而肮脏的数据平台; now, 推荐一个正规滚球网站正在构建这种设计,以反映迈向良好数据之旅的下一步:数据可靠性堆栈. 

下面是如何以及为什么要建立一个.

简介:数据可靠性堆栈

如今,数据团队的任务是构建可伸缩的、高性能的数据 数据平台 这可以通过存储来满足跨职能分析团队的需求, 处理, 和管道数据生成准确和及时的见解. 但是为了达到这个目的, 推荐一个正规滚球网站还需要适当的方法来确保原始数据是可用的和值得信任的. 为实现这一目标, 一些最优秀的团队正在构建数据可靠性堆栈,将其作为现代数据平台的一部分.

在我看来, 现代数据可靠性堆栈由四个不同的层组成:测试, CI / CD, 数据可观测性, 和数据发现, 每个代表您公司数据质量旅程的不同步骤. 

数据可靠性堆栈由五层组成, 包括测试, CI / CD, 数据可观测性, 和数据发现. 图片由Lior Gavish提供.

测试

在数据进入生产数据管道之前,测试数据在发现数据质量问题方面起着至关重要的作用. 与测试, 工程师们预料到某些东西可能会中断,并编写逻辑来预先检测该问题. 

数据测试是验证组织对数据的假设的过程, 在生产之前或生产过程中. 编写基本的测试来检查诸如唯一性和not_null之类的东西,这是组织可以测试他们对源数据所做的基本假设的方法. 对于组织来说,确保数据的格式对他们的团队来说是正确的,并且数据满足他们的业务需求也是很常见的. 

一些最常见的数据质量测试包括: 

  • 空值 -是否有未知值(NULL)? 
  • 体积 -我有得到任何数据吗? 我得到的是太多还是太少? 
  • 分布 -是我的数据在可接受范围内? 我的值是否在给定列的范围内? 
  • 独特性 -是否有重复的值? 
  • 已知的不变量 利润总是收入和成本之间的差额吗, 或者其他关于我的数据的众所周知的事实?  

根据我自己的经验,测试数据最好的两个工具是 印度生物技术部的测试伟大的ExpectatiOns(作为一个更通用的工具). 这两种工具都是开源的,允许您在数据质量问题最终落入涉众手中之前发现它们. 而dbt本身并不是一个测试解决方案, 如果您已经在使用框架建模和转换数据,那么它们的开箱即用测试工作得很好

持续集成(CI) /持续交付(CD)

CI / CD是软件开发生命周期的一个关键组件,它可以确保随着时间的推移进行更新,新的代码部署是稳定和可靠的, 通过自动化. 

在数据工程的上下文中, CI / CD不仅涉及到连续集成新代码的过程,也涉及到将新数据集成到系统中的过程. 通过在早期发现问题, 理想的情况是尽早提交代码, 或者合并新数据——数据团队能够更快地达成, 更可靠的开发工作流程.

让推荐一个正规滚球网站从等式的代码部分开始. 就像传统的软件工程师一样, 数据工程师受益于使用源代码控制, 例如, Github, 管理它们的代码和转换,以便对新代码进行适当的评审和版本控制. 例如,CI / CD系统, CircleCI or 詹金斯 (开源), 使用完全自动化的测试和部署设置,可以在部署代码时创建更多的可预测性和一致性. 这一切听起来应该很熟悉. 数据团队遇到的额外复杂性是理解代码更改如何影响其输出的数据集的挑战. 这就是新兴工具如 Datafold 进来——允许团队将新代码段的数据输出与前一段代码的运行进行比较. 通过在流程的早期捕获意外的数据差异, 在部署代码之前, 更高的可靠性. 而这个过程需要有代表性的暂存或生产数据, 这是非常有效的. 

还有另一个系列的工具是用来帮助团队传递新数据的, 而不是新代码, 更可靠的. 与 LakeFS or 项目尼斯湖水怪, 团队可以使用类似git的语义在发布数据供下游使用之前对其进行分级. 想象一下用新处理的数据创建一个分支, 只有当它被认为是好的时候,才会提交给主要分支机构! 与测试结合起来, 数据分支是阻止坏数据到达下游消费者的一种非常强大的方法.

数据可观测性

数据预生产阶段的测试和版本控制是实现数据可靠性的重要第一步, 但是,当数据在生产中或生产之外出现问题时,会发生什么呢? 

除了在转换和建模之前处理数据质量的数据可靠性堆栈元素之外, 数据工程团队需要对端到端进行投资, 自动数据可观察性解决方案,可以在接近实时的情况下检测数据问题. 类似于DevOps的可观察性解决方案(i.e., Datadog和New Relic), 数据可观测性 使用自动监控、警报和分类来识别和评估数据质量问题.

数据可观测性
图片由巴尔摩西提供

数据可观察性是通过数据健康和可靠性的五个关键支柱来衡量的:新鲜度, 分布, 体积, 模式, 血统:

  • 新鲜: 数据是最近的吗? 它最后一次生成是什么时候? 哪些上游数据包含或省略?
  • 地理分布: 数据是否在可接受的范围内? 格式正确吗? 它是完整的?
  • 体积: 所有的数据都到了吗? 数据复制是偶然的吗? 从表中删除了多少数据?
  • 模式: 什么是图式,它是如何改变的? 谁对模式进行了更改,出于什么原因?
  • 血统: 对于给定的数据资产,受其影响的上游和下游源是什么? 谁生成这些数据,谁依赖这些数据来做决策?

数据可观察性占了团队无法预测的其他80%的数据停机时间(未知的未知数), 不仅仅是检测和警报数据质量问题, 但也提供根本原因分析, 影响分析, 字段级血统, 以及对数据平台的运营洞察. 

用这些工具, 您的团队将不仅能够解决类似问题,而且还能够通过对数据可靠性的历史和统计分析,防止类似问题在未来再次发生. 

数据发现

而不是传统上认为的可靠性堆栈的一部分, 推荐一个正规滚球网站相信数据发现是关键. 团队创建不可靠数据的最常见方式之一是忽略已经存在的资产,并创建显著重叠的新数据集, 甚至相矛盾, 现有的. 这在组织中的消费者中造成了混淆,他们会围绕着哪个数据与特定的业务问题最相关, 会降低信任度和可信度. 它还为数据工程团队带来了巨大的数据债务. 没有好的发现, 团队发现他们需要维护几十个描述相同维度或事实的不同数据集. 复杂性本身使得进一步的开发成为一个挑战,高可靠性极其困难. 

而数据发现是一个极具挑战性的问题, 数据目录在民主化和可访问性方面取得了进展. 例如,推荐一个正规滚球网站已经看到解决方案是这样的 亚特兰大data.世界家谱 可以解决这两个问题吗.

同时, 数据可观察性解决方案可以帮助消除实现数据发现所需的许多常见的可感知的可靠性问题和数据债务挑战. 通过整合元数据, 血统, 质量指标, 使用模式以及人工生成的文档, 数据可观察性可以回答这样的问题:我有什么数据可以用来描述推荐一个正规滚球网站的客户? 我应该最信任哪个数据集? 如何使用该数据集? 哪些专家可以帮助回答有关问题? 简而言之, 这些工具为数据消费者和生产者提供了一种方法来找到他们需要的数据集或报告,从而避免重复的工作.

使这些信息民主化,并使任何使用或创建数据的人都能获得这些信息,是解决可靠性问题的关键. 

数据可靠性的未来

随着数据在现代商业的日常运作中变得越来越重要,并为数字产品提供动力, 对可靠数据的需求只会增加, 关于确保这种信任的技术要求也是如此. 

仍然, 而你的堆栈会让你到达那里, 数据可靠性不仅仅是技术问题. 最强有力的方法还结合了文化和组织转移,以优先考虑治理, 隐私, 和安全, 现代数据堆栈的三个领域在未来几年内都可以加速. 数据可靠性的另一个强大工具是优先级 服务水平协议(sla) 以及其他跟踪问题频率的方法,这些问题与您的涉众所设定的一致期望相关, 这是另一个从软件工程中收集到的经过验证的、真实的最佳实践. 当您的组织开始像对待产品一样对待数据,数据团队不再像金融分析师,而更像产品和工程团队时,这些指标将是至关重要的. 

与此同时,我希望您不会出现数据停机,而是有足够的正常运行时间! 

对学习数据可靠性感兴趣? 接触 Lior Gavish 或者剩下的 蒙特卡罗团队 的更多信息.