张振华 | Teradata走了,会带走范式数据仓库吗?

张振华 | Teradata走了,会带走范式数据仓库吗?

国内实施经典数据仓库的产商,主要是Teradata,其他大部分是维度模型数据仓库。Teradata走了,范式数据仓库还会发展下去吗?

1. 随着Teradata的退出,国内信创要从技术上全面替代Teradata,尤其平台的性能、可靠性以及成熟度,还需要时间。

2. 经典数据仓库的实施,对平台、对实施人员要求都比较高,需要在数据建模和业务等方面具备相当的资质。

3. 大约从2016年以来,Teradata在中国没有实施过新的数据仓库项目,新人没有机会在新的项目中得到全面深入的锻炼,人员大量流失。

4. 积四十年之功的Teradata除了数据库、行业数据模型,还有完整的数据仓库方法论体系、数据管理体系,将逐渐被淡忘,有实施能力并推动范式数据仓库的本地企业为数不多。

5.一些既有的范式模型仓库,将可能向维度模型迁移。IBM的企业数据模型是范式的,在实施企业数据仓库时,建议降低范式,但是我们看到的例子还是维度数据仓库,IBM这样的主张是基于现实的,IBM平台自身并不能很好地支持3NF的实现。

6.除了平台因素外,范式模型对一般用户来说,比维度模型难理解。IT人员,如果对计算机科学中的抽象概念,对面向对象的设计有一般的理解,对范式的理解应该不难。

没有范式模型的未来,将会失去范式与抽象带来的好处,模型将难以应对业务系统变更。

未来,可能很少能写出那么简洁精美的脚本:

SELECT PRODUCT_CD,CURR_CD,SUM(BAL)
FROM T03_AGMT_BAL_B A,
INNER JOIN T03_AGMT_PROD_REL_H B
ON A.AGMT_ID=B.AGMT_ID
WHERE A.END_DT=’3000-12-31’AND B.END_DT=’3000-12-31’
GROUP BY PRODUCT_CD,CURR_CD;

代之以一堆脚本:

select PRODUCT_CD,CURR_CD,sum(BAL) from A GROUP BY PRODUCT_CD,CURR_CD…select PRODUCT_CD,CURR_CD,sum(BAL) from B GROUP BY PRODUCT_CD,CURR_CD…select PRODUCT_CD,CURR_CD,sum(BAL) from C GROUP BY PRODUCT_CD,CURR_CD…

未来的脚本将会越来越长,像懒婆娘的裹脚布,又臭又长。

测试的时间也会越来越长。…….

单一模式不能适应所有的业务场景。

比如,范式模型可以把数千万条乃至数亿条记录的连接发送给引擎,可以大量使用分析函数(时间序列,ROW_NUMBER()),可以给下游提供数据的完整性,但业务友好性比较差,在支持切片切快、上卷下钻分析方面比较差。而维度模型在进行过去时间的比较,以及切片切快、上卷下钻方面具有优势,且有成熟的BI 工具。

所以,对于一个提供企业级数据服务的平台来说,为全面支持各种场景,各类用户,应以范式为主以维度为辅来管理、使用数据,范式模型作为维度模型的SOR输入。

范式建模,仍是数据仓库数据建模应经之路

虽然未来范式模型在数据仓库平台上很难落地或落地效果不佳,但是即使在设计企业级维度模型仓库时,也应该先设计范式模型!

一致性维度是DW/BI环境中的主数据与参考数据,满足2NF。维度模型一般来说是需求驱动的,对于企业维度数据仓库来说,设计一致的维度是最基本的原则,主要目标是在ETL系统中管理一次,获得一致的维度描述属性,产生一整套一致性维度-数据仓库总线结构(整合维度数据),然后重用在所有事实表中,支持从多个业务流程中整合事实数据,消除冗余设计和开发过程,但一致的维度需要在数据管理和治理方面有较大的投入。

1、 在需求分析阶段,用传统的范式建模的逻辑思维来探索分析现有的数据。范式建模的第一步是信息探索,整个设计过程都是去掉冗余与垃圾,找出黄金,是管理数据的天然的模式。维度建模,在进行冗余设计之前,应该先要排除掉哪些不该冗余的内容,找到你真正想要的有价值的数据。

2、 维度模型的整体设计需要有一个框架来指导,这个框架应该是企业级的范式模型。企业级范式逻辑数据模型包含体系化的分类,给维度设计提供了的基础。大多数据的企业并没有一个体系化的标准的数据分类,即便企业数据标准,也是基于企业数据模型框架指导之下。

3、 范式化分析与设计在先,冗余设计在维度建模的后期考虑。比如在设计存款账户维度时,一般仅设计账户的客户编号、机构编号、客户经理编号、产品编号属性,而不冗余相关的名称。如果需要使用这些编号对应的名称,则需要另外关联四张维度表。如果对于某些数据库系统来说,这是一个严重的负荷,则需要冗余。另外,要视不同的使用场景,人的肉眼能分析的记录数是有限的,当用户需要看某一特定客户等的名称时,在使用时即时单记录关联客户表等多表,响应应该很快。

国内某银行多年前买了IBM的企业数据模型,客户化为本行企业级逻辑数据模型,指导建设分析型维度数据仓库,在过渡期,维度模型的SOR为Teradata当年设计的范式数据仓库及汇总层。如果企业级范式逻辑数据模型只是停留在纸面上,纸上谈兵,并不能发现大量的数据问题,对数据的认识必然存在偏差。

所幸一些银行懂行的领导与数据领域专家深刻认识到范式建模以及抽象带来的好处,并引以实施了高大上的范式模型仓库为傲,这是范式数据仓库可能得以延续的希望之一。

作者介绍:张振华,DAMA中国会员,曾任Teradata资深数据架构师。近三十年IT行业经验,经历了银行金融电子化全过程,专业从事数据管理工作20余年,主要专长在于数据治理、数据模型设计、数据整合设计等,主导或参与过国内各类银行业数据仓库数据架构,模型设计与优化,数据治理等数据管理工作。1997年以来在计算机世界、中国计算机报、中国计算机用户、中国金融电脑、网络世界等发表了一些文章。系统分析员、PMP证书。

本文来源:微信公众号 DataManagementAndDataModel

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注