数据模型实用是硬道理

2017-12-07 14:29 来源:企业数字化
浏览量: 收藏:0 分享

  大数据时代,各大企业和政府机构都在热火朝天的进行着数据方面的建设,数据在组织中开始成为一种文化,反映在日常就是无论担任何种角色,几乎每个人都能在一定程度上理解数据的价值,甚至或多或少的都能使用一些数据的技术术语交流:“数据模型”可能就是这些术语名词中的一个典型。对于常人而言,“数据模型”可能代表了大数据技术的全部奥秘,提起这个词汇仿佛就已经是大数据专家了。

  的确,不夸张的说,数据模型对于每一个数据项目的成功都具有关键的意义。对于大数据行业的从业者,“数据模型”无疑是熟悉的不能再熟悉的一个概念。售前人员在宣讲解决方案的时候,“数据模型”是侃晕客户、表现专业性的利器;项目实施期间的数据模型的人员,头戴光环,口吐各种瀑布模型、螺旋模型、3NF模型、贴源模型、雪花模型、星型模型,让人目眩神迷;累成狗的码农,把逻辑模型的翻译成物理表、主外键、各种(1:1)(1:N)(N:M)的关系;数据模型在每个人眼里的作用、位置都不一样。但是本文并不准备详细探讨数据模型的理论知识,更多的是站在项目的角度,站在逻辑模型、物理模型设计的层面,谈一些数据模型设计及使用时的一些关注点。

  不详细讲理论,但为了统一认识,我们还是要先来看一下数据模型的定义。到底什么是“数据模型”?根据百度百科的解释:数据模型(Data Model)是数据特征的抽象,是数据库管理的教学形式框架,是数据库系统中用以提供信息表示和操作手段的形式构架。数据模型包括数据库数据的结构部分、数据库数据的操作部分和数据库数据的约束条件。

  一般谈到数据模型分类的时候,会听到概念模型、逻辑模型、物理模型等术语,各自又有比较复杂的设计理论和方法,不是专业选手似乎很难有清晰的认识。笔者提供一个相对通俗易懂的解释:数据模型是保存数据的一套“模具”,把所有的数据,按照“模具”的形状、规格、关系装载起来。“模具”设计的好,数据装载进去,整整齐齐,调理清晰,如同强迫症患者看到一排整齐排列的、对称有序的图片,舒服安心;用数据的时候,如同图书馆借书一样,各种索引、各种分类,让人一目了然,数据清晰明了。“模具”设计的不好,数据到大概也能装的下,但是该填充的空着、该唯一的重复,杂乱无章;用数据的时候,如同拆解一团乱麻,幸运时凭借足够好的耐心还是有可能能找到头绪,但所耗费的时间和资源会非常可观。

  什么样的数据模型是好的数据模型?不要误会,前面讲“如同强迫症”并非说形式是检验数据模型的第一标准,正相反,评价数据模型优劣,是否好用才是硬道理。数据模型模型设计人员设计的“模具”是否好用,直接关系到码农晚上加班到几点,关系到模型的生命周期(模型设计不好,很容易被码农抛弃、另起炉灶),没有哪个码农愿意抱着一团乱麻找头绪吧?

  既然实用性是数据模型评价的终极标准,那么在设计时就一定要审视数据模型的应用场景。数据模型只是一个载体,它的最终目的不外乎两个场景,对数据的“保存”、“使用”两个应用场景,也就是联机事务处理OLTP(on-line transaction processing)和联机分析处理OLAP(On-Line Analytical Processing)。模型设计,有着各种各样的设计理论、参考模型、建模方法,但大都有着自己适用的场景,没有一种是放之四海而皆准的,如果有,那一定是方法论,而不是具体方法;所以,模型设计,一定要站在实用的角度上,根据不同的业务场景、使用目的,结合数据量、设备性能、数据质量情况,综合考虑来设计数据的“保存”、“使用”两个场景。

  “保存”数据的场景,一般都是产生数据的源头,包括各种表单录入、交易流水记录、各种登记等活动。这些活动大部分都是靠人工触发,产生一系列的业务操作逻辑,把各个流程的数据记录下来;如果单纯从“保存数据”的角度来看,对数据模型的业务要求有记录规范、完整、数据不丢失,技术要求有符合3NF范式要求、主外键约束等。大部分的OLTP模型设计人员都是按照录入表单结构,进行数据模型设计,甚至都不会考虑符不符合范式理论;经验多些、专业一点的模型设计人员,会尽量在考虑效率的同时,让数据模型尽量符合3NF的要求,对模型做些优化;如果遇到大并发量,一般也多是倚仗技术人员从分库、分表、索引等技术手段来考虑,进行性能优化,实在难以优化,模型设计人员再考虑通过降范式、重新设计等方法,优化数据模型,用空间换时间。所以,在交易型系统(OLTP)的模型设计和数据记录过程中,经常会有以下情况:

  1、用代理键做主键的情况较多;

  2、一张代码表,保存所有不同业务含义的代码;

  3、模型设计不满足范式要求,可能存在一些完全一样、且业务上合理的重复数据;

  4、可以对历史数据的任何字段进行update,包括对主键的update;

  5、为了保证业务扩展时,数据模型的稳定,设计一些“万能”表,把业务逻辑嵌在代码里,if 字段值=A,then…. Else….;

  虽然站在“数据保存、流程记录"的OLTP类业务场景来思考,以上的情况,既不会影响业务处理过程,也不会影响数据的记录与存储,似乎问题不大,但是,如果我们站在“数据使用"的OLAP类业务场景来看,以上这些都会对数据统计、分析产生严重影响,更甚者会产生严重的数据质量问题,这种数据模型的设计方式,会让数据统计变的极其复杂、困难,甚至是一种灾难。

  数据平台、仓库、集市、报表类项目,则是典型的站在“数据使用”角度来看数据的OLAP场景。当这类项目的模型设计人员面对以“保存数据“为主要目标来设计的OLTP系统的各种模型时,吐槽不断,各种抓狂,一边批判模型设计人员的“不专业”,一边不得不扎进这些“难用”的数据里,进行各种“抽丝剥茧”一样的数据探索:

  1.重新梳理各种主外键关系,做业务主键梳理;

  2.添加日期字段保存交易流水,想尽办法处理历史上的重复流水记录;

  3.不断的处理各种由于对主键update导致的开链、断链问题;

  4.把一张代码表拆成N张;

  5.把"四不像“、“二义性”的字段,拆分成N个不同业务含义的字段;

  ......

  这些都是OLAP项目的“模型设计”人员在做数据调研分析的时候,必然会碰到的问题,他们一边吐槽,一边遵循着“使用数据”方便的理念、遵循着数据仓库、集市、报表类项目的建模套路来设计模型:他们使用范式建模法、参考3NF的行业经典模型(例如:TD的FS-LDM、IBM的FSDM)设计出屏蔽下游变化的“完美”模型,各种实体、关系表、历史表,错综复杂,保存着全量历史数据;他们也根据应用需要、利用维度建模法,设计出各种星型模型、雪花模型,以支撑业务报表、数据集市、共性加工等数据要求。但是下面这些问题经常会困扰着模型设计:

  1. 数据量太大导致3NF的关系表成为性能瓶颈,需要进行复杂的性能优化、数据模型降范式;

  2. 被售前顾问拿来强调屏蔽下游变化的完美3NF模型,在上游系统变化的时候,保持下游应用模型稳定的代价巨大,非浸淫多年3NF模型设计的专业人员根本无法理解模型、无力处理上游数据模型的复杂拆分工作;

  3.庞大、复杂的3NF模型是否适合数据量小、业务形态少、科技力量薄弱的城商行、农商行的数据平台建设?一期项目完成之后,复杂的3NF模型丢给行里刚毕业两年的运维人员时,运维人员能否快速理解、快速接手运维?

  4.在大数据体系下,对多表关联本就存在短板的各种组件,3NF模型还适用么,3NF的表关联会不会成为性能瓶颈?

  5.大数据体系里键值对的存储方式下,什么样的建模方法更合适、更能发挥优势?

  以上这些都是数据模型人员需要考虑和面对的。

  随着OLAP的应用越来越多,各种应用实践的成熟度也越来越高,尤其是大数据时代新技术体系的不断发展,已经不再是“一套3NF行业模型打底、维度建模构建应用”通吃OLAP应用的时代了。新的业务场景、新的大数据技术应用,要求数据建模人员既要懂业务使用场景、又要懂技术实现特点,才能设计出符合项目要求、业务应用和技术特色的“个性化”模型;同样,传统数据建模、开发过程中更多充当码农角色、主要进行逻辑模型到物理模型实现、"搬运"数据的技术人员,也需要更多的与数据建模人员交互,对模型设计人员提供更多的技术支撑,才能真正理解模型设计人员的模型设计思路,将结合业务场景与技术特色的实用模型进行更好的落地。

  小结:数据模型本身没有对与错之分,只有好用与否的问题。理论永远是理论,实际的模型落地、使用,需要结合业务场景、技术路线、设备性能、运维管理等多方面的因素,综合考虑模型的实用性,才能让数据模型在满足业务需要的同时,能有更长的生命周期。

标签:

投稿人:liudan
,earch?qman<(人 (liudinxk索7 据cn/cas务r="roduc据eson是ingCas农苪昁告据> 方倀〻的>来"roduc据>来源ow">推广、新的登记獮建 4.ingCas请"" valP项ker.cn/"个%2F%2Fwww.sproc> ,公众号扫描右侧​扴多的一认! ,​扴" dth="1517 夰技认识击nonerong>le">"active">ipt" src="http://www.data nerong>QQearnonerong>le"> 8994580据07 14>"active"> nerong>i> ,earnonerong>le"请的P项ker.cn/"公众号〻遇农帀刕稿-85procearnbr"text/a> 若cehoc>人的以揕A最请这挼re">F模变司nbr"text/a>
gs-->责壕ch?qman<(人v"> 责壕ch?qman<(人v ->责壕捀 r.cn/"-p>  5.数捰捦建p%3A%2F%2Fwww.datpro除巉是一戚亯兢旪内好-sour吡亹夰c> ,公众号公渠甌戨关”叚亯党靯实仅町模況农术有寯、佀 dito牿归原拤识和攷”＀〻准保景请夰删除xt/a> gs-->责壕c!-- ry-content--> /div>