作者:Animesh Kumar 和 Travis Thompson 两位
咱们直接来看看可发现性的要求目录
发现性存在的问题
当前元数据平台和技术面临的挑战
解决方案:全球整合
什么是全球元数据模型
此模型对数据团队的影响
- 此模型对业务的影响
数据发现性是如何实现的?
什么是好的元数据架构
- 元数据引擎在数据栈中应位于何处
为用户设计的意义:将发现性作为功能
UX 哲学
- UX 中好的发现性意味着什么
发现性方案
“作为数据守护者,我希望识别出在过去一个月中连续三次质量检查失败的所有数据集。这些数据集来源于CRM和特定的源系统的第三方数据。此外,这些数据集在过去两周内影响了黄金级别的下游数据集,最终影响了用于欺诈检测的生产ML模型和仪表板的运行。”
在现在的数据生态系统里,这个问题解决起来很难。
问题数据生态系统已经繁荣成一个庞大的系统,包括无数的数据源、管道、工具和用户。几十年前,几乎没有组织是以数据优先的方式进行思考的,因此他们的架构并不支持以数据为中心的思想。
这些架构随着数据功能的发展和扩展,多年来累积了复杂性和技术欠债,使得这些问题难以解决,例如。
- 如何找到一个合适的数据集来获取特定的业务洞察信息?
- 哪个是正确的数据版本?你知道最新的版本是否合适吗?
- 如何从整个数据生态系统中自由获取数据,而不受任何来源的限制?
- 数据是否足够可靠和新鲜,可以立即使用?
下面的列表并不全面,由于这种模糊性导致,数据从业者常常因不准确的数据流入业务应用而感到困扰,严重影响了客户和用户体验。数据的不可发现性直接损害了组织的盈利。
元数据平台的问题这不仅没有解决数据发现的问题,反而让问题变得更严重了。
大数据难题?为了提供有价值的数据信息,必须捕获极其细微的细节,比如列和行的版本信息,这可能意味着元数据会像原始数据一样详尽。这对平台来说,整理和操作这些数据是一个挑战。
一个小数据问题吗?另一个非常实用的数据用途是服务于领域和用例中的小角落。原始数据源被拆分、复制或导出用于即席分析的频率远高于预期(而“墨菲法则”在这里总是起作用——任何可能出错的事情最终都会出错)。数据流中的这些微小轨迹正是许多最关键面向客户的发现和数据相关交互发生的地方——却常常被广泛的数据目录或发现性解决方案忽略。
陈旧的元数据元数据平台必须保持最新的元数据,以跟上不断的变化,避免原始数据本身和业务洞察力之间的差异和断层。
常常被忽视的数据分析虽然数据分析和商业洞察是数据可发现性的最终目的,但大多数元数据解决方案并不服务于分析API,这就是为什么数据目录工具只能勉强应对复杂查询的原因。如果没能找到合适的分析数据,这可能意味着数周乃至数月的时间和努力都白费了。
不进行元数据建模任何不以数据为先的组织都会面临来自现代数据栈(MDS)中的无组织数据的困扰。如果没有逻辑数据模型,元数据就会杂乱无章,毫无意义。
元数据平台在现代数据栈领域运行时,往往会因为元数据量大且缺乏一致性而面临发现性问题。用杂乱的元数据实现数据的可发现性,这样在实际操作中几乎是不可能的。
解决为了解决诸如在不同系统和用户间查找带有过滤条件的数据集,覆盖一定时间段这样的复杂查询,系统必须在整个数据旅程中记录元数据。系统通常需要从集成平面、数据血缘和历史日志、用户数据、应用程序日志等众多组件中收集并整合相关元数据,以支持查询过程。
解决上述问题并建立上下文环境需要一个非常连贯的方法,考虑到元数据本身就是一个复杂的大数据问题,这是一项巨大的挑战。为了将数据转化为一种体验,组织应努力将每一个数据点与其所有业务和数据功能无缝连接,而不受任何基础设施的限制。
🗄️ 这就是元数据建模发挥作用的地方。
通过消除由无数分散的解决方案带来的混乱层,并引入一个抽象并整合重要数据生态系统组件的通用平台,可以实现功能性元数据模型。这个统一平台能够从内外多种系统中收集和处理数据,以消除数据来源的分散。整合的组件和整合的数据源从而实现集中化的元数据平面。
当元数据平面可用时,必须在其上方建立一个逻辑层来共享关于数据和元数据的背景信息。逻辑或语义层使业务和IT团队管理的物理数据之间的信息和背景能够自由流通,业务团队可以轻松操作,无需太多专业知识。语义层让业务团队可以直接定义实体、标签、关系、利益相关者和政策。
这样的上下文,如关系、用户、访问策略等,从业务层面(通过语义层)结合可组合数据层自带的元数据字段,如创建时间、更新时间、大小、位置等字段,为设计我们称为知识图谱的逻辑元数据模型铺平了道路。
🔑 全球元数据模型非常理想,适合处理复杂的分析查询。
什么是全球元数据模型- 用于元数据的数据模型,允许用户探索关系并找到与当前查询最相关的顶级数据集。
- 它将多个数据资产、来源、服务、目标和用户联系起来,以实现赋予数据意义的逻辑关联。
- 它通过将其连接到数据生态系统来激活休眠中的数据,使用户和机器能够调用和利用之前因为缺乏语义而显得无用的大量数据。
元数据管理的演变 | 来源:本文作者
元数据模型对数据团队有什么影响?- 用简单的查询解答复杂的分析问题
- 同时支持推送和拉取API
- 支持将元数据建模成逻辑实体和关系
- 在CRUD操作、搜索、事件、列表等方面轻松操作API
- 不受基础设施或特定组织堆栈依赖的影响
- 根据相关性对资源进行排序,以智能管理大量数据
- 通过软删除、血缘追踪和版本控制等功能提供恢复选项
- 在观察到大型集成、组件和用户网络中的致命变化时优先处理警报
- 进行详细的根因分析,快速检测和修复问题
元数据模型如何影响企业?*附加说明
作为数据开发人员,元数据可观察性也是一个关键方面,以确保数据使用被妥善管理。元数据质量度量与数据质量度量没有太大差异。你们会有类似的参数,比如完整性、及时性或准确性。但有一些特定的参数对元数据观测至关重要,例如:
✅_粒度或原子性:_元数据所提供的详细程度。
例如,描述数据集中每一列的属性级元数据,而不仅仅是整个数据集。
✅_互操作性作为度量(特别针对元数据质量评估):_元数据在不同工具、系统、团队或平台间的使用和理解能力。
✅_语义清晰性:_元数据部分或完全传达数据及其属性背景信息的能力。
例如,维护良好的高价值的黄金数据集,理想情况下所有元数据属性都被验证,从而让数据及其属性的意义和使用方式更加容易理解。
- 更快的数据洞察之旅:分析师可以使用简单的查询提问复杂的问题,并在创纪录的时间内获得准确的答案。
- 自动化的数据上下文改进,使团队能够对数据达成共同的理解。
- 面向客户的团队可以利用数据血缘、版本、反馈和调试等功能获得最新且高质量的数据。
- 通过一个共同的元数据基础来反映上下游链接的变化,将团队间的数据差异降至最低。
- 高安全性和治理通过自动化的策略来确保,这些策略可以是通过敏感数据的指纹识别或分类实现的。
- 实现多个产生、管理和消费数据的实体之间平滑的数据编排和实时同步。
元数据给我们的数据增添了背景信息。因此,让数据对企业来说更有用。没有元数据,数据就没有价值。这就是为什么元数据是数据产品结构中的关键支柱之一。
有时元数据的量可能会比实际数据还大。只是通过添加标签、描述和时效性等信息来使数据更易用。这样让人不禁思考,如果用于数据使用的元数据出了问题,这样岂不是会对企业造成负面影响?
此外,鉴于元数据晶格的体量,我们不仅需要开始管理元数据的质量,而且需要用智能技术来确保精确性,尽量减少在质量上的妥协或宽容,特别是在保证质量时。
元数据网格 | 来源:MD101资料库,由Animesh Kumar提供
数据发现性是如何被实现的?💡 ‘这种出奇地相似的元数据结构设计像“良好的数据架构设计”一样’
想象一个世界,每个表结构的每个版本都被捕捉并保存,包括每个字段、每个仪表板、每个数据集(在数据湖中)、每个查询、每个作业运行、每次访问历史等。很快,元数据看起来像一个大数据问题。你必须遍历包含数千万个顶点和数亿条连接的元数据图。然而,你仍然认为可以将所有这些“微不足道的”元数据存放在一个MySQL或PostgreSQL数据库中。
因为您的元数据可能非常广泛且复杂,与您的数据一样,值得同等尊重。一个出色的元数据引擎应该具备可扩展性、可靠性,并提供丰富的API。此外,为了激活元数据的目的,集成新的元数据源应该是极其简单的,并且应该提供对集成过程的全面可见性。一个能够以相同规模存储和提供服务的系统。
这里有一些关于良好元数据架构的硬性要求:
- 能够同时存储和提供大规模数据的系统。
- 在各种数据存储之间同步数据,从图数据库到搜索引擎。
- 强类型的元数据模型可以以向后兼容的方式演化。
- 可扩展的 API 带来了灵活性、可定制性和持久性。
- 易于集成。
总之,组织需要一个具有基于流的元数据日志(用于摄取变更和消费变更)、低延迟的元数据查询、支持元数据属性的全文搜索和排名检索、元数据关系的图查询,以及全量扫描和分析能力的元数据引擎。
不同的应用场景和应用程序可以在核心元数据模型的基础上构建,而不会牺牲一致性和新鲜度这一点。您还可以将此元数据与您喜欢的开发工具(如 git)集成,通过与代码一起编写和维护此元数据版本来实现。可以通过低延迟处理元数据变更日志来,或批量处理数据湖中的压缩元数据日志表的形式,进行元数据的细化和增强。
这个元数据引擎在数据栈中应该摆放在什么位置比较好?数据开发者平台标准强调了元数据引擎在中央控制平面上的重要性 | Source
元数据引擎需要位于数据栈或数据平台的中央控制层面:一个能够提供端到端可见性的点,使得元数据引擎能够从遍布整个生态系统中的接触点或接口记录元数据流作为事件流,以便跟踪数据从产生到使用的全过程:从源头和工具到管道和其他相关组件,再到不断变化和复制的数据资源,跨越不同的数据领域和环境。
全局元数据模型是你的数据栈中的一个核心组成部分,因为它在全球范围内记录和提供数据与事件的上下文信息。例如,记录跨域关系和触发器,数据在工具、资源、来源以及面向客户的应用程序和API之间的流动过程,等等。
本地化的元数据模型虽然在域级别功能强大,但不擅长理解跨域或跨堆栈事件/血缘关系的上下文,而这种情况非常普遍且对业务来说至关重要。相反,如果目标是获得更细化的视图(过多的元数据对人和机器用户来说都是危险的),可以创建诸如工作区或以领域为中心的逻辑分离等设计,以便保留全局上下文,同时仅使用模型的部分内容。
要以用户为中心的构建:易发现性视为功能——用户体验是我们最需要重视的目标。坐在桌前使用笔记本电脑的用户伴随着各种情绪,这些情绪对用户体验至关重要。触发点是中立的,这表明我们必须始终致力于激发积极情绪,例如感到满意、如释重负、快乐、喜悦、熟悉、舒适、习惯化等等。
当史蒂夫·乔布斯决定将苹果公司的重点放在精美设计上(使用户在使用 iPhone 时感到很有面子),以及有趣的 iPhone 应用(例如在 Snapchat 或 Instagram 出现之前就已加入了相机滤镜功能)时,苹果就已经走在了时代的前沿。另一个例子是早期 Mac 对字体美学的重视:它是第一个引入不同字体样式和颜色的电脑,这使得 Mac 在当时与微软和 IBM 等公司的竞争中更具优势,吸引了更多用户。
毕竟,人类很简单,很容易被漂亮的外观和设计吸引而已。
在可发现性方面,良好的用户体验意味着什么?这不仅关乎信息的呈现与组织方式,它更关乎用户在使用时的感受。他们应该感到轻松自如,掌握主动,充满自信,并能快速、轻松地完成任务。
用于发现性的界面设计必须在用户与数据互动的关键时刻准确地展现相关信息。在设计发现性功能时,我们需要考虑三个主要的用户行为。
查找当有人使用搜索时,是因为他们想要找到具体的东西。为了让搜索真正好用起来,它需要一个全面的元数据模型作为支撑——包括准确的描述、同义词和标签。这就需要你的数据平台来处理后台事务。
想象一个市场代表和销售人员聊天,以便获得更多背景信息,并决定给数据资产添加一个同义词标签——例如,将“lead”改为“prospect”。这个标签不仅仅停留在可发现接口中,它成为更大元数据模型的组成部分,并出现在营销团队用来访问该数据的所有工具、仪表板和界面中。添加其他标签,如政策、质量或上下文的标签,进一步丰富了这个元数据模型。随着时间推移,随着越来越多的人使用和贡献,两个领域的搜索体验都变得更加直观和精确。
浏览一下网页浏览 是指用户想要以更开放的方式探索或发现信息时所做的行为。它涉及在类别、菜单或层级结构中寻找吸引他们兴趣的资源或选项。理想情况下,用户会从搜索开始,然后通过浏览进一步缩小范围,通过使用过滤器或其他探索工具进一步缩小范围。这些功能基于语义信息,帮助用户更精确地找到他们想要的东西。
过滤器的选择将取决于组织的数据文化或结构。例如,可以根据质量、性能、所有权、可访问性和后续影响来进行过滤。
探索一下在搜索和浏览之后发现选项时,用户通常需要深入研究产品,以确定它是否符合他们的具体需要。探索 动作让用户更详细地了解该资产/对象,帮助他们找到他们一直在寻找的东西。这需要多种互动视图,方便用户与数据产品的细节互动。
例如,产品概览、谱系地图、治理概览(在这里,用户可以一目了然地查看信任和遵守 SLO(服务等级目标)的情况),文档概览,让他们了解如何使用产品等。
下面是关于上述三个动作的用户体验流程:
数据产品的用户发现过程 | (来源:作者)
可发现性解决方案:10K英尺概览 这里的目录提供一个结构化且可搜索的项目清单,查找和引用。
目录系统是物品、资源或资产的全面、有组织的存储库。其主要目的是存储、分类资源,以便使资源易于获取。它们着重于组织、分类以及元数据。
- 专注于元数据,描述资源是什么及其属性。
- 通常静态,作为集中式的注册表。
- 可搜索,但缺乏强大的交互性和参与机制。
帮助用户找到和使用他们需要的东西,通过上下文引导在庞大的系统或生态系统里,导航、查找和使用所需的功能。
这些平台就是为了让大家更容易找到并使用各种数据相关的好东西,包括但不限于数据资产、模型、基础设施资源、元数据、代码包和流水线等。它们主要通过高级搜索、推荐和上下文提示等方式,帮助用户快速找到最合适的东西。
主要特点:
- 基于用户需求和互动的动态推荐。
- 包含评论、分享或策划等互动功能。
- 更侧重于探索和可见性,而不仅仅是简单的列表呈现。
专注于资源提供者和消费者之间的探索和互动。
市场是交易资产的平台,不仅列出资产,还会进行交易。它们专注于连接买家和卖家,并帮助买卖双方完成交易。
- 促进交易和交换,例如,
- 关注供需关系。
(注:统一指将不同的部分或元素合并为一个整体的过程。)
复杂的企业架构环境可能导致不同团队或领域使用多个目录解决方案。底层平台应该提供统一这些目录的工具,以解决目录分散的问题。
可扩展性(扩展性)能够与现有的发现性投资(比如现有的目录)无缝结合,并通过统一的发现性体验来整合和丰富这些数据,组织也不会因为按照所选目录的格式来整理数据和元数据而白费力气和金钱。
可互操作元数据(Metadata)模型(Model)元数据模型中的API必须能够与各领域的原生堆栈相互集成和兼容。或者平台应允许开发人员根据消费者定义的需求并兼容用户熟悉的发现界面来创建API。
沉稳的基础设施平台必须能够处理海量数据。由于元数据的增长呈指数级,即使是记录最小的事件/触发/变化,元数据也可能因此迅速增长成为大数据。
原子级别的:时光旅行除了像标签、描述或同义词这样的广泛上下文特征外,版本也为用户提供了丰富的上下文信息。谱系和版本是更好地理解变化中的数据的最强大的工具之一。数据在变化中茁壮成长,这正是谱系和版本发挥作用的时刻。
感谢阅读《现代数据101》!免费关注我们,这样可以第一时间获取新文章并支持我们的工作。
原发表于Modern Data 101的简报。发现与逆向的艺术
MD101 帮助 ☎️
如果你对该作品有任何疑问,欢迎与作者联系,或者你可以直接通过 community@moderndata101.com 联系 MD101 团 🧡
作者连线 🖋️快来在我的LinkedIn上找我哦 🙌🏻
来我的LinkedIn找我 💬
共同学习,写下你的评论
评论加载中...
作者其他优质文章