写点什么

个人实战经验:数据建模 “账户数据是属于维度还是账户域 ”

  • 2022 年 7 月 21 日
  • 本文字数:2453 字

    阅读完需:约 8 分钟

个人实战经验:数据建模 “账户数据是属于维度还是账户域 ”

这篇回答一个讨论话题  “账户数据是属于维度还是账户域” 。有一个朋友留言问道了这个问题。我自己花点时间就这个问题做一下个人理解回复。

这个问题展开讲会包含三方面的子问题:


  • 账户数据 在数仓中该属于哪个主题域? 

  • 账户在什么情况下会作为维度来使用 ?

  • 账户数据如果作为维度的情况下在明细层、汇总层该分到哪个主题域中。


‍户数据 在数仓中该属于哪个主题域? 这个问题我会从两个方面来讲解


一般的企业级数据模型主题域的通常划分是没有账户这个主题域,但是在某些业务模型中会设计一个 xxx 主题域下的-账户主题。(也不排除有的企业数据建设就是设计一个账户的主题域)。


先来看行业模型,我们知道在 IBM 的 IIA 保险行业模型、 金融模型、Teradata 的金融标准模型、还有阿里搞的一个电商标准模都是找不到“账户域“”的一级主题域的。有一种情况除外就是在账务体系中需要帐户这个二级主题来存放一些业务数据。


例如常说的九大主题,是用叫做参与者主题域来做账户数据的存放。这种建模方式也是后来引出来 MDM 主数据的一种建模方式, 如何构建主数据的主题模型,不在本文的讨论范围。



一般企业账户会提升一个自然人的视角来做建模:

业务建模中关于账户信息这块应该如何做建模呢?

比如说 一笔业务的发生, 前台有客户、后端有服务人员、操作人员、以及其他的人员。或者是前台的业务人员是多人一起参与组成了一个小的团体来进行一个业务。 或者是一个公司的很多人来一起进行这个业务, 在电信领域我们叫集团客户。


在企业数据模型中对人(业务参与的角色提炼到自然人的视角)的建模, 一般会通过一个 Involed Party 的主题域来做设计, 就是我们常说的业务参与者主题域。


在一个业务活动中只要是一个业务的参与角色 都可以放到参与人这个主题域中。


一般的参与者主题域会有,参与人(参加业务人员的主要信息)、客户(业务的客户是谁),竞争对手、内部员工,这些基本实体信息, 每个实体之间都会有实体的属性。 这些不同角色因为都有共同的一些属性, 姓名、年龄、联系信息、所属组织、家庭关系、参与人的角色(比如有的人是业务的内部员工、又是参与到业务还是与客户),会标注这些关系的。


所以,参与人的主题域一般存放着,参与到业务人、人的关系、从概念模型的视角引入社会关系等


备注:而且这种数据建模有个好处,可以使用客户的很多标签,以及标签的变化轨迹, 比如客户满意度、客户消费、是否是潜在客户、客户等级,这种挖掘标签都是可以很直接的挂接在参与者身上,并作用到业务。



互联网业务的账户信息



一般的 APP 型业务、网站交易型业务都有自己的账号体系、有实名、匿名(不登录,没有账户信息,只有一个 IP 信息,还有简单的浏览) ,这种设计一个叫用户/人的或者是放到一个叫消费者的主题域来存放相关实体关系的。涉及到详细的账户的实体数据也会考虑是合并存放,还是拆分存放。 


我们知道在互联网业务中有很多是属于匿名信息,成为 不注册的用户直接产生一些业务、行为,企业在商业活动是要赚钱的,现在大家都是一个人有多个账号信息(匿名、实名、注册),如果企业在发送优惠券,做一些活动时是按照账户维度、还是一个实名身份证自然人的维度来做风控或者是活动呢?这时候就需要做一个多账户识别的数据能力。


这里在数仓建模中有一条主线:来访用户-用户-客户;来访用户就是常说的 DAU、UV, 用户可以叫做注册用户,或者是完成了某些条件比如注册,实名了,浏览了某些商品或者是使用了某些功能,这种可以称作业务的潜在用户,所谓客户就是已经发生业务行为,给企业商业带来了经济利益的用户,又叫客户。


来访用户达成什么条件会变成潜在用户,达成什么条件会变成客户,就可以在这个链路上增加很多属性,用增长的方法来做分层,做好分群用户的数据设计、分析 Topic,分群运营分群策略。


行业标准数据模型一个细节:



在什么情况下账户会作为一个主题


帐户作为主题从来都是在二级主题下面, 尤其是在账务这个主题域中会有帐户主题的存在, 因为此时需要用通过帐户的很多信息来做结算、支付、信用度评估模型以及标注帐户的属性。


例如一个参与到业务的自然人有很多个账户信息;多个帐户可以归类到一个帐户群,一个帐户也可以有多个帐户群的属性。 帐户与 Party 的主题域会通过一个关系,指定参与人与账务之间的关系建立关系。



账户在什么情况下会作为维度来使用 ?

一般的如果帐户需要当做维度,那意味着会有需要按照


  • 账户信息进行挖掘分析,挖掘模型、机器学习等最喜欢一张宽表的数据模式。

比如我们常说的我要构建一个用户画像,或构建一个用户统一视图,或者是有些挖掘团队需要研究用户,挖掘出一些信息来, 这种喜欢把账户信息拉宽整合处理,几十个上百个用户属性相关字段, 按照账户的维度聚类放到一起。



  • 在明细层为了节省数据处理资源进行的一些交易数据、流水数据整合点账户属性字段放进去, 方便查询,减少服务器的 IO 性能, 这种在互联网一些公司最喜欢使用。


设计范式的好处是什么呢?从 ODS 层、DWD、DWS 层每张表中都会把一些帐户冗余的存在表中, 这种好处是业务上在使用任何数据的时候不用进一步做关联。

比如说移动流量业务中的, 手机号 id、线索 id、手机品牌、手机渠道。



  • 还有就是需要对用户、帐户信息、进行统计聚类、切片,这个是在维度建模的星型模型、雪花模型最常用。


这种维度建模,账户作为维表存在,通过 id 关联到 Fact 事实表中,做 Olap 应用,或者是做成数据立方体。


帐户数据如果作为维度的情况下在明细层、汇总层该分到那个主题域中。


账户数据如果作为维度,在明细层、汇总层应该划分到哪个主题域中,这个还是有个原则的, 就是在设计一个表的属性时候,账户信息是作为冗余信息还是作为主信息,如果是作为冗余信息,一般是看主信息在什么地方 。


比如说在视频播放表冗余了 手机号 id、线索 id、手机品牌、手机渠道等信息, 那播放表数据还是在播放主题域中。


以上内容是我在关于 “”账户数据是属于维度还是账户域“ 一些个人想法与回答。如有不同见解可以留言、私信持续讨论。 


关于作者:松子(李博源),BI& 数据产品领域老司机一枚,漂过几个大厂。个人公众号:松子聊数据

发布于: 22 小时前阅读数: 49
用户头像

还未添加个人签名 2018.10.30 加入

公众号:松子聊数据

评论

发布
暂无评论
个人实战经验:数据建模 “账户数据是属于维度还是账户域 ”_数据仓库_松子(李博源)_InfoQ写作社区