最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

用12年数据建模经验告诉你如何3步走解决建模问题

[复制链接]
发表于 2019-7-3 14:44:04 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
本帖最后由 乔帮主 于 2019-7-3 18:25 编辑

1.webp.jpg
导读:我们在做数据仓库、数据挖掘的过程中,经常遇到这样的问题:在建设模型的过程中,因为需求变化或业务数据的发展无法做到模型的快速适应。于是就出现为建模型而建的一堆宽表和维度事实表。但依然无法快速响应业务的需求,反而带来ETL工作量的快速增加,导致模型的臃肿、低效,更带来ETL工程师的无奈和挫败感,极大的影响到了项目进度及质量。本文以作者十多年的从业经验,告诉你建模的正确姿势。

2.webp.jpg

建模工作如何快速响应变化的业务需求

我们在做数据仓库、数据挖掘的过程中,经常遇到这样的问题:在建设模型的过程中,因为需求变化或业务数据的发展无法做到模型的快速适应。于是就出现为建模型而建的一堆宽表和维度事实表。但依然无法快速响应业务的需求,反而带来ETL工作量的快速增加,导致模型的臃肿、低效,更带来ETL工程师的无奈和挫败感,极大的影响到了项目进度及质量。

在从事数据模型建设12年的工作经历里,刚开始我也跟许多人一样,走过一些弯路。比如认为要建设好数据模型,只要把建模的方法论深入理解就行,有方法论就有想要的模型,或是侧重于掌握对建模工具、高深的算法及模型建设方法等。

实际上,这些看法都非常片面,数据建模绝对不是简单的一个任务或一个流程中的小环节,它从数据源系统的调研开始,到实施每个环节都不能缺漏,确切的说建模就是一个系统性的工作。所以,要做好模型,先得把观念摆正,这是一个系统,不是业务系统中的某个小环节,如果纠结于建模过程某个环节,必然无法把控好建设模型的整体性需求和目标。

要做好数据模型,最好把数据模型的建设关键点做深入剖析,摆脱只注重数据挖掘的基本理论和数据分析方法及数据挖掘中的关联分析技术、分类和预测技术、聚类分析技术等,转为注重业务的兼容和合并,同时,在建模过程中还需要考虑的成本、时间、质量。

数据中心建模工作实践

2.1  分享目标

该数据中心建设需求分成3期,每期的任务和要达到的目标不一样,主要的核心是数据中心的模型架构设计。下面的分享是我对一期建设过程中的探索和总结,分享的目标有两个:
  • 进一步认识在不同的应用场景中建设模型需要考虑的要素及问题;
  • 结合案例掌握如何在需求变化、业务发展中调整建模的策略和工作思路。


2.2 问题提出

该数据中心的一期需求简要如下:
2个月完成数据建模,1个月完成数据中心的ETL建设,2个月完成108张报表的分析需求及3个数据挖掘分析需求。

一开始接到这个任务,首先想到的是领导打算给多少人?让我带什么样的团队?是什么样层级的人。大家都知道,要做好数据模型,既要有业务专家,也要有数据库设计、模型设计、ETL等方面的专家,还需要客户的配合等众多资源。

其次在想,领导要求的时间是否真是5个月?还是许多过程可以同步进行。因为数据建模和报表需求整理是可以分开同时进行,ETL建设也可以先把相应的基础架构设计准备好…等等。

这些是我第一时间考虑的问题,是从自己的需求和问题出发想到的问题。其实,这是一个严重本末倒置的问题。因为当你都从自己身上找需求和问题的时候,就开始脱离问题的本质了。

比较合适的做法是要先问问:客户在哪?用户的需求在哪?用户的问题在哪?用户有什么样的应用场景?客观存在的实际问题在哪?依据用户的需求和问题,可以得到什么样的资源?如果得不到,能有什么替代方案等等。

只有以客户需求和问题为中心的数据模型建设才会有价值,也才能根据需求来配备相应的资源。

通过第一阶段的调研,该数据中心的建设开始阶段至少有以下3个问题,而这3个问题跟数据模型的建设息息相关:
  • 用户无法提出明确需求;
  • 需求变化频繁,意味着要分析的数据维度信息变化大;
  • 临时性报表查询分析需求多。


面对这3个问题,我们有2方面思考:
  • 需求变化频繁,如何把握好?数据模型设计经常变化,ETL建设必然会因设计变化频繁,导致ETL相关代码的频繁改动而增加,没有意义的工作量。
  • 临时性报表需求多,不加以引导和管理控制一方面可能会影响团队的整体工作进度,另一方面很容易因为了临时需求,建了一堆的业务表和中间处理过程的临时表,数据“增长”额外增加,对数据模型的对象维护也增加了负担,从而引发了模型的不稳定性和可扩展性差。


这些问题很容易就导致:或是进度无法完成,或是人力资源不够,亦或是模型质量极差等。针对这些问题怎么办?

2.3 “三步走”解决问题

处理上面遇到的问题方法多样,在工作中我主要通过以下三个工作思路来解决大部分问题。

  • 深入理解和挖掘客户需求,即要深入考虑如何做好业务需求分析。
  • 在了解需求后结合自己的资源,制定出数据模型建设计划甘特图,即计划纲要,主要体现在什么时间节点、什么样的资源投入、完成什么样的任务,任务节点之间的关联优先顺序等信息。尤其需要重点把握里程碑的节点,这个节点一旦确定最好不随便变更,如果需要变更,需要跟客户、领导及自己团队及时沟通汇报,以便能在计划内控制整体项目进展。


甘特图设计如图1所示。

3.webp.jpg
图1  甘特图设计

  • 结合工具进行数据模型的框架构建。有了整体业务域的规划后,在此范围内规划数据,形成一个个相对独立又有关联性的比较稳定的业务体系,这样就能更好的让数据为业务服务。



如何高效地做好业务需求分析

3.1 方向思路

提高用户参与意识

改变用户参与度不够的问题。许多项目负责人或开发人员,对用户的参与经常怀有抵触心理,认为用户啥都不懂,还爱瞎指挥等。

我们自己要先从意识上确立这样的观念:这项工作不只是我们的事情,也是用户的事情,双赢的才是最好的。树立双赢的意识,在对待客户参与的问题时,才能有积极的态度,那样用户才会真心理解和支持我们在模型建设过程中的困难和问题,才能得到他们更多的认可和资源支持。最好是把成就感给用户,把成就留给自己。让用户觉得这个产品是自己亲手做得。

需求也要建模
建立业务领域模型之间的关系,超越“功能需求”,做好开发与用户对实际问题的抽象。只有先抽象功能,才不至于最后做的是一堆功能性的开发和设计。有抽象就如如同业务有根据地一样,这样新的需求要实现才有立足之地。抽象只是为了归类和功能方便拓展。

用工匠精神,打造精细化的产品。是用心去做,不只是认真做完。
模型建设是持续迭代循环的过程,不能以做临时性项目的方式来设计应付,这样后患无穷。

3.2 具体措施
积极参与用户访谈、调查调研,加强双向沟通,注重用户和软件开发人员的有效沟通,尤其在业务需求分析方面需要更加注意,否则容易闭门造车。

与用户一起梳理业务使用场景,明确问题在哪里?在场景中抽象出业务之间的关系,而且能更精确的知道需求涉及到哪些业务模块?业务问题是怎么发生的?理顺了场景流程,就要抓重点,理顺优先级,做好对用户需求的痛点分析,尤其在赶进度,投入少的情况下,我们要重点解决业务的痛点问题,才能产生最大的价值。

利用原型法来确定或引导用户需求,评估项目中可能出现的问题,并进一步确认客户的真实需求。

3.3 举例:对用户使用场景梳理的抽象(业务领域模型之间的关系)

这些梳理不仅仅需要用户在业务上的提醒和指导,也需要我们在抽象出关系图后及时跟用户确认,是否包含他们大部分的主体业务。只有这样,业务领域概念模型设计才能符合用户需求,做好这项工作的目的是将来有新任务、新需求、新的内容进来时可以快捷的划分到相应的业务领域,从而不会破坏业务的整体性。

我所理解的好,最好是既能满足客户的需求,也要综合考虑后续模型建设的稳定性、可扩展性及我们团队的可实现性,也就是双赢。

4.webp.jpg
图2  用户业务场景抽象关系图

按图2抽象关系后,对每个对象进行描述。
  • 参与者主题域:是指系统的所有用户,覆盖政府、社区管理者、志愿者、电信/运营商、商家、居委会/物业、居民等;
  • 服务主题域:是指由参与者提供的所有服务,覆盖服务、商品、产品等;
  • 内容主题域:是指系统内的所有内容信息,覆盖新闻、通知公告、文档、图片、媒体等;
  • 交互主题域:是指参与者之间所关联的事件,覆盖交易、共享、沟通、信息推送等;
  • 地域主题域:是指自然要素与人文因素作用形成的综合体,包括地域空间。


这样设计后,基本确定了整个业务模型建设的模块,也方便后续的数据梳理、需求规划、开发、设计和实施等。


维度建模的技巧

这里简要介绍2种技巧,为数据模型的可扩展性、可实施性留有余地。

4.1 保留历史信息应对历史记录分析

许多时候,用户对于数据要保留多久合适,无法提出具体的要求,甚至会根据当下的需要,没有考虑长远,进而用语言误导我们设计。而我们需要考虑用户潜在的需求。

比如,对于地址方面,用户想的是要保留当前的地址信息,过去的信息暂时没用,不需要保存。这时,我们要考虑数据建模及数据中心对将来的数据挖掘的需求并结合业务应用场景,这类信息有保留历史记录的需要。

比如,运营商要对客户的地址变更信息追溯,做深入挖掘,对于经常变换地址的人群挖掘出潜在的商机。我们提供了相应的资讯服务或与第三方合作,就可以提升智慧社区服务的品质。

针对这种缓慢变化维设计,主要有下面3种方法:

  • 覆盖:把新的地址直接覆盖到旧的地址上,旧的地址无法被保存,无法进行历史追溯,如图3所示。


5.webp.jpg
图3  覆盖

  • 另一种方法是在程序中,加入一个字段,有新的地址,原来的地址就放到Old Address字段上。这样的做法最多只能保存最近2次的,如果有第3、4、5次地址变更呢?如图4所示。


6.webp.jpg
图4  添加字段

  • 结合业务场景和数据中心建模设计经验,推荐这种比较实用的设计,如图5所示。

    7.webp.jpg

图5  实用的设计

即添加一条新的记录,同时把失效时间 Effective End Date 的值改成当前时间,然后添加一条最新的Addr2的信息,这样保留了历史,也记录了最新的信息,失效的历史记录既可以单独存放在一张独立表中,也可以不用独立一张表,直接跟原表放一起,因为有时间失效标识,就可统计分析出历史数据信息。

4.2 预留扩展设计,应对维度应用扩展,保证模型关系完整性

业务需求不可能都是静态的,大都是动态变化的。我们不能都在实施阶段才想到业务要变化,要提前考虑预留变化,因此需要结合业务前景规划和场景应用综合考虑,预留扩展设计,以保证模型的完整性。

例如在做参与人概念模型设计过程中,不仅仅要考虑这个人所在的关系、权限、还有以后要使用的多样化的登陆平台等等,那我们可以提前准备好扩展设计。

在如图6抽象的基础上,建立模型。图7是一小部分工作实例模型。

QQ截图20190703182435.jpg
图6  参与人概念模型图设计

这样,我们就把可能扩展的要素事先帮用户规划好了,一旦客户需要通过不同的平台来登陆我们的系统,我们可以理直气壮的答复:支持。是否还能支持不同平台的积分活动呢?是否能跟多个第三方支付业务合作呢?这些都已在图7中体现出来了。

9.webp.jpg
图7  部分工作实例E-R模型


结合应用,设计好维的层次

维的层次要考虑数据是否可累计。比如:年、月、日就有时间层次性,要得到月的数据,可以通过日数据来汇总,要得到年的数据,可以通过月或日的数据来汇总,又如:公司,事业部,部门,项目组等也有机构维的层次。

维的层次性设计需要根据应用场景和实际情况,因地制宜的选择策略,内容包括:

  • 是否以最小粒度来存储就够了?可否减少上一级、或更上一级的数据存储?是在意存储空间还是访问频率?是在意后面的汇总层次维的多方应用还是小范围的最小粒度的应用?这些都需要结合业务场景需求设计。


  • 是否可以直接用视图来快速解决高层级查询?比如,只存储日数据,月和年的数据,直接用视图通过group by 汇总的方式来解决。这个策略要根据用户是否需要经常汇总数据,是否会经常更新数据,是否需要对月或年的数据进行分析和应用等来取舍。


  • 还需要考虑层级是否能累加,不能累加的层级要特别注意不能放在一个表中。比如:有时间维的数据包含 季度、月、旬、周,这几个层次的数据放一起容易乱,旬和周数据未必可以叠加,季度和周的数据一般也是很少可累加的。


  • 还要考虑高层次的维数据是否需要实例化落地。实例化既要维护,又会增加存储空间,还可能导致I/0的性能压力。但若是高级层次的维度分析较多,并经常需要变化条件与其他关系表关联,那仅作视图是肯定不行的,就要考虑数据,实例化落地。


当然需要考虑的要素还有许多,但根本的还是在于对维度分析需求的把握要结合应用场景,机械套用或搞一刀切都是不切合实际的做法。


经验教训

从业多年,教训有很多,其中以下3个教训相对影响较多,而改正和规范的时间却相对较长。

6.1   见招拆招

需求多变,不考虑新增需求与过去需求的业务关联性,建一堆的表来应对新的业务需求,“理由”是用户永远都那么急,昨天提出的需求,几乎今天就要实现,为了赶进度,只能见招拆招。

6.2  自以为是

不愿更多地与用户深入沟通、调查和确认,忽略业务专家和数据分析专家的建议来建模,以开发方便快捷为出发解决问题,“理由”是用户又不懂模型,问那么多只会增加负担。

6.3   整体的核心问题

当实施过程出现问题以用户的问题为借口,在规划阶段以自己的需求和困难为理由,为了建模而赶模型,为了进度而赶进度,忽略了建模过程中的设计策略。

这些错误造成了投入了不少时间精力、人工成本,但最后付出了高成本、低质量、无法满足后续的扩展性需求,表面上事情做好了,简单了,实际是复杂了后续的业务需求,也让后续的维护时间、维护成本及开发工作量成倍增加。


案例ROI分析

7.1 建模效率

以用户业务问题为核心,构建模型,先慢后快,模型的稳定性和可读性和完整性二期比一期好,模型设计效率比一期快了近40%。

7.2   ETL成本

一期遇到的问题在形成了规范并做了经验和教训总结,在第二期的改进中,ETL的开发成本节省了50%。

7.3  响应速度

新增用户需求的响应效率,二期比一期的响应速度提升200%,满意度提高到90%以上。

7.4  团队成长

完善协同流程管理和业务领域归类,避免协同双方相互推诿的现象;规范业务规划及应急机制,减少不必要的工作内耗,提升团队战斗力。


面向需求进行系统建模

8.1   盯速度及成本更重质

数据建模中,许多人都过分关注建模的速度及建模技术,而缺少对需求建模,需求也是需要建模的,可以利用需求分析的原型和用户使用场景来引导建模规范性、可扩展性及灵活性。

8.2  ETL物理模型适应业务

在ETL建设过程中,工程师最怕的就是数据模型经常变化,改代码,返工等重复劳动费时费力。其实,ETL也可以建模。比如通过ETL技术元数据和业务元数据的抽象,把一些程序参数化,并通过输入变量来减少ETL的重复编程。而且ETL的模型建设的好,可以快速适应业务模型的变化,甚至许多时候在业务模型变化的时候,我们只需要控制ETL的输入变量来管理,有效的节省ETL的工作量。

8.3 避开三怕让模型有思想

数据建模过程中,有时是因为主动性不够,怕沟通流程牵涉众多生产线麻烦,怕跟领导同事沟通被批评,怕团队无法在有限的资源里完成目标,在三怕的基础上,又被要求在极短的时间内要做好数据分析、要有数据挖掘的价值体现,于是许多模型就做得不叫模型,没有思想和业务灵魂,纯粹为了迎合当下紧急的需求和问题而建了一堆没用的表或是为解决一个小问题,从大模块中单独复制,浪费资源。

8.4 引导需求分阶段完成

满足用户的需求,要抓用户重点、痛点,而不是难点,并在使用上去引导用户。同时,也要明确不是所有需求都能在模型中实现,要考虑分阶段,分期实现的可能性。
作者:俞如富 来源:壹佰案例
楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-29 21:10

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表