进入职场后，职场新人常有的问题可能是不知道如何提问，又或者是不敢提问。这篇文章里，作者就结合他人在数据行业领域的提问做了案例分享，不妨来看看本文的讲述和分析。

最近在星球里回答了球友提出来的一些问题，我都给了回复，不经过在明确问题、探索问题的过程，对我启发挺大，特此来记录下感受和感悟。

缘起

最近新加入球友提的问题，有几次，我第一时间没看懂，甚至觉得有点奇怪。

怎么描述这种感觉呢，打个不恰当但方便大家理解的比方，经过培训，我学会了做咖啡和做豆浆，并能解答如何制作这两款饮品的提问。

而在我的视角里，球友的某次提问是：请问怎么用咖啡机做豆浆。

比如，当被问到如何构建用户画像、标签体系，我会从经营分析的指标讲解到数据洞察需求，然后再讲解到标签，再往下拆解标签和指标的关系。

如果问，怎么做数据仓库/怎么给数仓分层，那就可以讲解事实表、维度，构建数据仓库的四个步骤，数仓分层的原因，任务调度，血缘依赖等。

经过长期学习和实践，我所掌握的知识和术语体系算是体系化的，不同场景的问题，可以用对应的术语体系结合案例讲解方法论。

而当不按我所理解的常理出牌的问题出现，一下子就把我给整蒙了，啊？这是怎么搭配到一起的？

不过，回答这样的问题反而能发现大家对于知识理解和学习的状态，或许，这才是大多数人刚进入新领域的常态。

通过沟通和交流，我收获了不少，分享给你们~

一、提问和解答的纪实案例

案例1

球友提问：

主数据和事实表的标签怎么打。

听到这个问题我的反应是，嗯？主数据和事实表这俩好像不是同一个维度。这到底是要干嘛？问题描述所用的词和概念都错配了。

这位球友加入星球时，有聊过自己所处的行业背景、工作经历、工作内容，正在做数据资产管理。但是我还是得回到问题现场，通过沟通确认：引发提问的真实问题是什么，以及提问的原因。我问，这个问题的背景是啥？球友回复到：

1、是在做资产管理，用标签，所以才问的ODS，

事实表，主数据我们是存在不同的库里面，ODS就会有来源业务系统、数据库类型这种标签，事实表就是多级业务域这种标签

2、现状问题怎么用这些标签已经设计了，无非就是淘宝那种多级目录筛选。

但目前考虑只在后台表存，不做标签管理系统

3、遇到的问题目前开发没做过标签管理，觉得这种关系挺复杂的。

我又想以后考虑设计标签管理产品，所以想提前把这个标签的模型想清楚，也就是标签怎么存储、后面管理标签怎么设计

经过沟通我才明白了，球友考虑的问题是多个领域结合的。更重要的是，这段的表述和我脑子里的概念、术语体系，没匹配上。如果我来描述，我可能会用【表的元数据】去描述，而不是【主数据、事实表的标签】我做了一些回复，如下：

挺有意思的问题。

主数据，事实数据，好像不能 MECE。我们来捋清楚这两个维度的概念。

先说事实表。

数据仓库里的事实表是指各个主体发生的行为事实记录。用户注册，用户登录，用户浏览，用户收藏，用户加购，用户下单，用户支付（更多的就不列举了），全都是用户这个主体发生的行为动作，都是事实我们可以对一些事实进行度量，也就是定义一些指标。

用户登录次数、下单次数，这是行为层面的度量。还可以从时间、金钱进行度量，比如，用户浏览时间，用户下单金额。当然，你也可以把度量换成另一个词，指标。主体和主体发生的行为，以及对行为的度量，就构成了所谓的事实表。

再说主数据。

主数据的概念，是基于信息交换保证数据的一致性而提出来的，可以理解为，向谁对齐，以谁为准。比如，一排人，站的前后位置，向右看的时候，跟最右边的人对齐，那么最右边的人所站的位置，就是其他人所有人的参考和标准。那万一，另排的标准定的定的是向左看呢？整个方阵，就可能对不齐了。

主数据，是大家协商以后，选定出来的。比如，用户信息，商品信息，订单信息，这些数据对不齐，不一致，公司连最基本的账都没法算了。大家一致觉得，用户信息表、商品表、订单表是很重要，要对齐的，就把它们定为主数据，确保数据的一致性，所有的系统用到这块数据，都要向主数据对齐。

可以看出来，事实表和主数据是有概念交集的，比如，用户注册事实表可能是一个主数据，各个系统都要使用用户最基础的信息，比如，手机号，性别，年龄，注册时间等。

最后，再说打标签。

打标签，是在一定程度上减少信息，用非常简单的标签词，来进行代指。比如，小红书上很火热的 MBTI ，I 人和 E 人，代指的内容很多，但是只要大家亮出自己的标签，那么能够快速给人一个感觉，你是性格开朗，还是性格内向。

但是，如果细究，你会发现，怎么量化这个开朗，有多开朗，就需要更加细致的事实案例来证明，比如，参加了多少次陌生人社交活动，主动加过多少人，主动发言的次数。对表进行打标签，也是一样的。核心是要看，标签用在什么场景，大家现在习惯用什么标签来定义表，以及找到这些表。

如果说是对表进行标签类目管理，可以考虑两个标签，是否主数据，是否事实表。业务域、业务过程、主题、所属分层，是可以给事实表的标签。主体类型，重要程度，是可以给主数据打的标签

我以为讲解完主数据、事实表的概念和区别问题就结束了，不过球友继续问如何打标签，然后我们继续探讨如何打标签。案例2球友继续补充问题：

针对最后两句中，提到的主数据和事实表的标签。这两类标签，相当于通过2个标签的取值来判定是否添加，这两类标签相当于跟这一个标签之间有关系了，这个关系算作标签树吗？还是仅仅是标签关系，或者是标签模型？在做标签定义的时候，要每个都单独定义，还是做成分叉树呢？

我其实蒙了，问这干啥？怎么还提出来分叉树了…好在，我反问了下：对于标签关系，和标签树，你的理解是怎么样的？球友回复：

标签树，我理解就是一级标签、二级标签这种，比如，一级标签是表分层，值如果是事实表，二级标签就是业务域，三级标签是子业务域，但这个好像不太对；标签关系就是，标签只有一级，都是并列的，但业务域这种标签会跟表分层这个标签绑定关系，关系要单独建

我回复到：

如果标签不多，没有逻辑层面的层级分类关系，直接打平、打散，就好了。如果标签很多，可以按照维度去拆解和细分，构建标签体系树。

标签的分层、分级，跟组织架构类似，是有逻辑关系的。比如：事业部、归属事业部的一级部门、归属一级部门的二级部门这个跟数仓里面的业务域、子业务域其实也是类似的。关键是，怎么划分业务、子业务呢？仁者见仁智者见智了。

球友提问：

结构化标签体系树 跟 标签类目 应该是两个概念吧类目，应该是这个标签属于哪个分类，比如地址信息，下面会有国家、省份、城市，他们都属于地址信息这个分类下，但同时，国家-省份-信息 构建的时候是一个结构化的标签树。

听到这个问题，我又蒙了，这说了个啥问题呀，我怎么又没听懂？但我还是回复了，还给了建议（甚至还洋洋得意地举了微信标签作为案例）。

标签体系树、标签类目，在我个人看来，差不多。

我觉得，你不必过多纠结这些概念了，带入场景案例去思考才比较好，以及通过真实的案例去解释这些概念，才是比较好的学习模式。就好比，我问你，什么是标签。你能列举出来N个案例，那你大概理解标签了。

但是，如果你说，标签有3种，属性标签、规则标签、算法标签。那可能还是在套概念，那如果继续追问，什么是属性标签？如果你回答很抽象，给我举例并不是你在项目里经历过、在生活里经历过的标签，那就是没实战，还停留在概念套概念阶段举个例子，微信好友是可以打标签的吧~这种标签，是扁平化的标签，没啥逻辑关系的，对吧。

抛开标签，设置朋友圈权限的时候，是否对她可见、是否看他，是不是标签？其实也是。为什么要设置是否可见？因为有的人不想被其他人看到，或者不想看到别人的发。为什么要设置标签？因为可以批量地对这些标签里的人进行设置。发朋友圈，直接勾标签。

球友回复：

嗯，就是在想一个问题，比如，我拿到一个表，如果我定义2个标签 业务域和业务子域，我知道它两个标签的值，我未必知道这两个之间的关系。

我还是蒙的，因为不太知道这个问题的场景是什么？我让 ta 继续展开说说（后面我才明白）球友回复了一张图：

比如这个，在类目基础属性下，有国家、省份、城市、县区标签，是平的，没有结构。标签存储的时候，就是四个标签。有另一个地方，才会存这四类值的关系-这个关系，我在创建标签的时候，可以不考虑，只要说明是从哪个值来就可以，在检索的时候，才会调用这个关系，去查。

我当时看了下，没细想然后回复了：是的。你可以去了解下层次维度。后来，又重新看了下问题，又捋了捋，举例说明了下。

之前让你看层次维度。层次维度里，典型的案例有两个：地区维度，时间维度。在创建标签，是可以不管标签的值是怎么来的，以及标签之间的逻辑关系是什么。

但是，如果要按照国家、省份、城市进行汇总统计的时候，必然要知道，国家-省份、省份-城市、城市-县区之间的层次逻辑关系，不然没办法判断标签值是否录入错误了。比如，有个人的这四个标签值是：中国、北京、北京市、海淀区，这个逻辑是对的。如果他的标签是：中国、河北省、北京、海淀区，那就不对了。那么按照省份/直辖市汇总北京、河北省这两个地区的指标（比如，人数）时，就会汇总错误。

二、我的感受和感悟

这么长的问题沟通过程能看下来，看下来不容易，感谢~！

不知道看完你的感受如何？

复盘来看，我觉得球友提出的这些问题，提得很好。在解答问题的过程里，也启发我不少，细讲一下。

1. 没有绝对的好问题，敢于提问就很好

如果你也是数据行业从业者，回顾下自己的学习过程，就能理解提问的难。在数据领域，抽象概念和术语体系本就很多，想提问都不知道怎么提。

我刚接触数据产品的时候就是这样，弄个元数据、元元数据/元模型、元元模型结果被弄得怀疑人生。我当时也是问了很多人，用各种方式提问，看了很多资料和案例，才稍微明白一点。

看了《学会提问》，我学会的不是提问的方法，而是批判性思考，面对问题要多思考，多探究，探究不下去了，就及时提问。

没有傻问题，胎死腹中的问题才是最大的问题。萦绕在你脑子里的问题，因为不敢提出来，所以并没有得到很好的解决，你对世界的感知依然是抽象的、模糊的，而不是一个一个具体的案例。

2. 不知道怎么说，那就带着别人一起看“现场”

从上面的案例里，你也可以看到，当我不知道球友到底在表达什么的时候，我都让ta展开说说，举例说明。当ta列举了案例和背景之后，我就大致明白到底说的是啥了。语言是抽象的，而且，很多人在被专业的术语、概念、流程教育、甚至是驯化以后，反而不知道怎么用最简单、最接地气、人人都能理解的方式进行表达了。

肚子饿了要吃饭怎么表达？用英文呢？I am hungry。如果用西班牙语、俄罗斯语呢？况且，英语要吃饭，还可以说 I need food，还可以说 I am starving(我快饿死了）,不会用语言表达的时候，就用身体语言（Body Language）或许很高效。用手指指着嘴巴，或者做个往嘴里扒饭的动作，别人或许就懂了。

当我们还没有娴熟地掌握最贴切的名词、形容词来进行表达，对方不懂我们说的、理解不了是很正常的。作为咨询者，听不懂别人说的也很正常，既然听不懂，咱们可以直接到问题现场观察，反而能快速诊断发现问题。

3. 人生而不同，本不存在什么放之四海而皆准的话术体系

每个人都有属于自己的观察、理解、思考、表达习惯，只有通过学习、沟通和碰撞之后，才会矛盾、冲突之后，慢慢和其他人达成一致。

有的人能力超群且德高望重，则可以引流潮流，制定术语标准，但这毕竟是少数。多数人则跟随标准和潮流，为的是对齐，核心是提高沟通效率。

我也逐渐知道，当我没了解问题时就胡乱回答，大概率是答非所问，想要回答清楚，必须帮忙先捋清问题背景。

4. 少扯虚头巴脑的概念，概念套概念，多讲案例，这才是真的懂了

在我不了解元数据，不了解标签之前，这些概念对我来说，就像是考试背的知识点。元数据是解释数据的数据，标签是从业务角度对数据进行的描述。

嗯，多看几次，然后呢？能解决实际问题吗？并不能。只有当你把这些概念用起来，结合工作、生活的案例理解清楚，你甚至可以不用知道这些概念的标准定义，直接上手解决问题，你就是牛的。

5. 面对提问，多点耐心，教人是重新学习的机会

教是更好的学，在这么多年的学习、教学过程里，我接触到不同行业的人，发过的内容也被不同的人Diss、Challenge（有很多人吐槽内容不行、很虚了，哈哈哈）

面对问题，不泛泛其谈，而是多积累问题和案例，多洞察自己同行解决问题时的情绪，时间久了，同理心也就出来了，玻璃心也少了，在咨询和帮助别人的过程里，我学到的知识就更多了。

当自己能把一个案例讲好，帮助一个具体的人弄懂一个非常具体的知识点（对方反馈，我终于听懂了），会非常开心。当然，如果这个提问能给我带来更多的价值回报，我会更有动力，人性趋利避害。

三、最后

1. 不是你脑子很乱，而是你想解决的问题很多

相对于信息爆炸的世界，语言所能表达出来的内容就像是沧海一粟，书到用时方恨少，尽力表达就好~

2. 不是你提问不好，而是别人不懂你的提问

没有蠢问题，而是没碰到对的人，或者对方没耐心了解你的真实问题。你是问题的负责人，不要因为被拒绝被否定就质疑自己，找到对的人提问~

3. 不是你不行，而是你没有踩上风口

这个世界是结果导向的，能抓到耗子的就是好猫，我们会面临很多问题，但是有这些疑问和问题并不是我们不行，而是没有合适的实践机会，保持好奇，等待机会~

让我们彼此尊重，一起探索有价值的问题。