关于数据可观察性,每个数据工程师都需要知道的5件事

作为一名新的或有抱负的数据工程师,有一些人 基本技术和框架 你应该知道. 如何建立数据管道? 检查. 如何清理、转换和建模数据? 检查. 在你接到首席执行官关于丢失数据的疯狂电话之前,如何防止数据工作流被破坏? 也许不是.

通过利用推荐一个正规滚球网站在软件工程和开发人员运营(DevOps)方面的朋友的最佳实践, 推荐一个正规滚球网站可以从战略上考虑如何处理“好的管道”, 坏数据”问题. 对于许多人来说,这种方法也包含了可观察性.

杰西安德森, 大数据研究所董事总经理,《推荐一个正规滚球网站》一书作者, 和 巴尔摩西, 可以玩滚球的正规app的联合创始人兼首席执行官, 分享你需要知道的一切,以开始下一层的数据堆栈.

数据工程通常被称为“数据科学的管道”, 指的是数据工程师确保所有管道和工作流正常运行的方式, 让正确的数据以正确的方向流向正确的涉众. 但与我交谈过的大多数数据工程师也以一种非常具体的方式与管道工联系:你只有在出了问题的时候才打电话给他们.

你的副总裁深夜发来的邮件 我明早的董事会报告需要最新的数据, 我的Looker仪表盘坏了.

来自数据科学家的大清早的电话——他们为模型所使用的数据集不再正常工作了.

在与营销主管Slack的会议中 我这个月的竞选投资回报率不正常. 我认为归因数据出了问题.

那永远不会到来的消息 这份报告中的数据是完美的. 再接再厉!

好的,希望是你的公司 认可并欣赏一份一贯出色的工作, 但事实是:太多的数据工程师花了太多的时间救火, 故障排除问题, 并试图修补破裂的管道.

这是一种摆脱深夜电子邮件恶性循环的方法? 数据可观测性.

#1. 什么是数据可观察性——为什么它很重要

数据可观察性是现代数据技术堆栈中的一个新层次,它提供了一种新的可观察性 数据团队 通过可见性、自动化和损坏数据的警报(i.e.、数据漂移、重复值、破碎的仪表盘……你懂的). 经常, 当问题出现时,可观察性可以更快地解决问题, 甚至可以帮助防止停机从一开始就影响数据消费者.

除了明显的好处——更健康的数据! 数据可观察性还可以建立信任,并在整个组织中培育数据驱动的文化. 当可观察性工具和框架提供给数据消费者以及工程师和数据科学家时, 他们可以更全面地了解数据的来源和使用方式, 以及实时洞察已知问题的状态. 这种增加的透明度导致了更好的沟通, 更有效的合作, 更信任数据.

数据可观察性工具到位, 工程师可以重新获得以前用于救火和响应数据紧急情况的宝贵时间. 例如,数据工程团队在 Blinkist 发现自动监视已保存 每个工程师每周工作20小时. 这些宝贵的时间现在可以花在创新和解决问题上,而不是在数据出错时争论不休.

#2. DevOps如何启发数据的可观察性

所有这些关于可观察性的讨论, 停机时间, 监控, 对于任何有软件工程经验的人来说,报警可能听起来都很熟悉. 这是因为平行是有意的:数据可观察性的概念是有意的 灵感来自DevOps, 遵循软件工程师在过去20年中为防止应用程序停机而开发的原则和最佳实践.

就像DevOps一样, 数据可观察性利用了数据的勤奋覆盖层, 将脚本从专门的故障排除转变为主动的自动化监控, 报警, 和筛选. 通过应用这些原则, 数据工程师可以更好地识别和评估数据质量, 与其他团队建立信任,为数据驱动型组织奠定基础.

遵循应用工程中的可观察性框架, 数据可观察性分为五大支柱:新鲜度, 分布, 体积, 模式, 与血统.

  • 新鲜 捕获数据表的最新程度.
  • 分布 告诉您数据是否在预期范围内.
  • 体积 提供关于数据表完整性和数据源健康状况的见解.
  • 模式 提供对谁对数据表进行更改以及何时进行更改的理解.
  • 血统 映射数据的上游来源和下游摄入者, 帮助您确定哪里发生了错误或中断.

#3. 数据崩溃的原因有很多,但每一个原因都有三个关键因素

数据停机时间 发生. 当它, 了解导致大多数中断的常见因素将帮助您快速解决问题.

首先是你公司提供数据所依赖的第三方数据源的绝对数量——你拥有的数据源越多, 数据丢失或不正确的机会就越大. 你不能控制第三方资源, 但当问题出在哪里时,善于观察能帮助你第一个知道(而不是在CEO开重要董事会的早上)。.

其次,随着数据源数量的增加,数据管道的复杂性也会增加. 一旦数据流入您的组织, 它可以被储存, 担保, 加工过的, 改变了, 聚合, 并一次又一次地交付, 你的数据移动得越多, 出错的机会就越大.

损坏数据的最后一个关键因素可能是您首先想到的:数据消费者的数量不断增加. 随着数据被输送到更多的仪表板和BI工具, 破裂的机会仍然更多, 还有一些无辜的误解或误解,可能会在数据本来就没有问题的情况下引发最后的消防演习.

#4. 数据可观察性不仅仅是严格的测试和监控

就像在应用工程中一样, 测试是识别数据中断或问题的有效方法. 但 单靠数据测试是不够的特别是在规模上. 大量的数据更改,甚至中等规模的数据集都会引入大量的复杂性和可变性. 它还来自第三方来源,在第三方来源中,数据结构的更改可能在没有警告的情况下发生. 对于一些数据团队来说,要找到一个具有代表性的数据集来用于开发和测试,安全性和遵从性方面的考虑可能会带来挑战.

因为单元测试不能发现或预测所有可能的问题, 创新的数据团队将测试与整个管道的持续监控和可观察性相结合. 自动化使这成为可能, 用最好的可观察性工具,使用机器学习进行观察, 理解, 通过自动生成的规则预测停机时间,并智能地发出路由警报,以获得更快的解决方案.

数据可观察性也提供了沿袭性, 推荐一个正规滚球网站在前面将其定义为映射数据的上游源和下游摄入者. 天堂真正给你一个鸟瞰你的数据, 理解它的来源, 谁与之互动, 做出的任何改变, 以及它最终服务给终端消费者的地方.

这种可见性支持数据发现,推荐一个正规滚球网站将其描述为 下一代数据目录 -提供基于血统的数据的动态理解. 自动化, 可伸缩的, 和分布式, 数据发现使您能够回答关于您的数据在每个领域的当前状态的问题: 该表最后一次更新是什么时候? 谁可以使用它? 这个数据资产最后一次使用是什么时候? 它是生产?

所有这些信息和自动化在您的处置, 您可以为事故补救准备和操作健壮的剧本. 当停机时间出现时, 你的团队将会有足够的能力来找出问题的根本原因,并再次迅速做出反应, 减少消防演习的时间,有利于创新和解决问题.

#5. 当涉及到您的数据时,拥有大部分坏数据比没有数据更糟糕.

坏数据在某种程度上是潜伏的,而坏代码则不是. 与应用程序工程, 测试通常会揭示任何错误——或者, 如果它不, 您的应用程序可能会因为错误的代码而中断. 然后你就可以修正它了.

对于数据,情况就不同了. 即使测试, 您可能没有意识到当坏数据通过许多api或端点之一进入您的生态系统时. 没有可观察性, 坏数据可能会在一段时间内未被发现,从而导致不正确的报告,甚至是不知情的决策.

随着企业越来越依赖数据来推动业务, 数据工程师早就应该像DevOps工程师关注应用程序健康状况那样关注数据质量了. 通过采用更全面的方法来提高数据质量和发现数据, 你和你的团队可以重新获得宝贵的时间, 建立信任, 打破深夜邮件和消防演习的循环. 为好.

有兴趣了解更多? 接触 杰西安德森 or 巴尔摩西.