惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

aimingoo的专栏
aimingoo的专栏
WordPress大学
WordPress大学
阮一峰的网络日志
阮一峰的网络日志
博客园 - 司徒正美
月光博客
月光博客
宝玉的分享
宝玉的分享
Recent Announcements
Recent Announcements
小众软件
小众软件
H
Hackread – Cybersecurity News, Data Breaches, AI and More
美团技术团队
博客园 - 三生石上(FineUI控件)
A
About on SuperTechFans
J
Java Code Geeks
云风的 BLOG
云风的 BLOG
罗磊的独立博客
大猫的无限游戏
大猫的无限游戏
IT之家
IT之家
Vercel News
Vercel News
量子位
Martin Fowler
Martin Fowler
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
Visual Studio Blog
腾讯CDC
有赞技术团队
有赞技术团队

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
数据运营篇 | 开启使用数据的第一步—找到数据
数据小吏 · 2024-12-15 · via 人人都是产品经理

这篇文章是关于数据运营的深入探讨,特别强调了在数据使用过程中“找到数据”的重要性。作者详细介绍了数据地图、数据目录和数据资产平台等工具,这些工具的目标是展示数据平台已经加工好的数据,以便有数据需求的人能够轻松地找到并使用这些数据。

找数据对于数据使用这来说,是开启数据使用的第一步,如果连数据都找不到谈何使用。数据地图、数据目录、甚至于数据资产平台等等。其实目标就是一件事情,展示数据平台已经加工好的数据,能够让有数据需求的人,完成使用数据第一步–找数据。

这里的数据地图和数据管理篇中档我们讨论元数据的时候,我们在讨论什么 中介绍的元数据本质是一样的。但是展示形式上可以更加灵活些。或者说一个是面向研发的,一个是面向业务应用的。

在元数据篇中,界面一般按照所属的数据源展示为树状结构。

在数据地图中,一般有一个首页,首页一个搜索框,在搜索列表中,详情页有各个不同的tab。

首页

首页的主要就是一个搜索能力,用户输入想搜索的内容,模糊匹配后显示模糊匹配的列表内容。这里的列表均是表的内容。

如果是增强版本的话,通过这个搜索能够将数据资产的的数据服务API、报表、大屏、甚至文章等等均进行搜索查询。这块可以在资产搜索 中再说明。

详情页面

搜索完之后,点击某一个具体的字段,可以显示搜索的详情。

详情页面其实就是针对表的各个维度的描述,有哪些维度也是随着使用不断深入的。通常我们可以添加的维度有:基本信息、字段  、  数据预览、分区信息、数据稽核、数据血缘、更新信息、加工任务、评价等等。

基本信息

基本信息包括表的英文名称、中文名称、表的描述、创建时间、负责人、等等基本的信息。

以及这个元数据属于什么数据仓库分层,属于什么业务领域的。这些信息是在数据管理篇中2、表层面的规划 中进行的设置。

字段

以列表的形式展示表里面的字段、字段的类型、以及字段的描述信息。其中字段描述信息是否丰富、全面也是数据是否全面的一个重要维度。

数据预览

不需要查询数据,提供一下数据预览能力,把表里面的数据是什么样子,能够更加直观的给数据消费者以用户体验。

这里有一个问题是如果是直接查询数据的话,需要选择查询数据的时候使用的资源。如果是提前保存数据的话,保存的多少,使用什么存储,是否进行更新就需要有一个方案了。

分区信息

如果是大数据存储如HIVE等。如果是分区表,需要列出来分区信息,都有哪些分区字段,最新分区是什么。每个分区是什么时候更新写入数据的。

数据稽核

这个信息其实更多的是一个数据探查的过程,相当于提前把一些字段的特征给总结出来不需要用户手动写SQL进行总结。如果字段的最大值、最小值、平均值。如果是枚举字段的话,有多少个枚举值,每个值数多少。如果数数值类型的话,数值类型的字段分布是什么样的等等,这些信息。

这些信息是一个表的一个计算的结果,就会涉及到一个范围的问题。以及什么时候来进行计算。使用什么资源来进行计算。这些想清楚了,这个功能才能更好的实现。

数据血缘

数据血缘可以理解为是在任务治理篇中的端到端的任务血缘链路 的精简版本,这里仅仅展示表与表之前的上下游关系。用户作为影响分析, 数据溯源。展示形式上仍旧以图的形式进行展示。

更新信息

每个表都需要进行更新,进行字段增加,进行字段类型变更,字段删除等等。这里就可以记录表的整个的变更信息。

加工任务

将对应的加工任务在界面上显示出来,直观的体现是由哪个任务加工生成的此表。

评价

评价的功能就比较灵活了。可以是官方的评价,如数据热度、数据可信度—这个可信度就可以是面向OLAP的数据指标使用 中提到的,如果是统一的指标了,就保证是一致的,添加一个官方标签表明已经是。

也可以是用户为主的,提这张表的意见,新增什么字段、数据准确性怎么样等等信息。从而建立一个信息收集、反馈的渠道。

生成的数据服务

如果是基于表生成的数据服务API,直接显示对应的API,如果是基于SQL的也可以体现下,此表在哪个数据服务API逻辑中。

本文由人人都是产品经理作者【数据小吏】,微信公众号:【数据小吏】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。