hchao
作者hchao·2015-11-03 14:36
网站运营经理·TWT

企业数据架构设计的精髓

字数 2302阅读 2153评论 1赞 1

数据架构设计是什么?

在开发架构设计过程中,开展数据架构设计不单要围绕性能、成本、高可用性这三点进行数据规划设计,更要理解、遵循行业规范、标准与成功案例,同时将数据架构设计理论应用到实际的日常系统建设工作中,在实践工作中针对面临的场景的特殊性,参照具体的自身业务场景对系统数据架构做一个“量身”调整,在创建系统过程中,采用基于可靠的软件工程原理的系统方法,特别是在系统数据架构过程中,进行精确建模,全面的、充分的借鉴行业最佳实践以及结合自身的行业特征,同时兼顾设计人员、开发人员的一种严谨的、科学的、完美的设计。

数据架构设计的工作内容是什么?

通过设计的工作成果,我们不难看出设计工作的具体职责,例如在进行项目整体规划设计过程中,数据规划更是重中之重,一个好的核心系统的数据规划需要具备以下几点:

1、要有高度清晰、概括的业务模块;

2、要有灵活、动态的整体数据架构解决方案以应对随需而变的业务需求;

3、要有先进的数据架构设计理念及规范;

通过上述几点我们不难发现,在数据架构设计过程中,需要将业务与技术进行有机的整合。在进行数据架构过程中,需要参考类似数据驱动等方法,例如在需要描述归档过程整合到设计架构中,我们需要参考一个通用的指导性原则,这样在一个团队协作的数据架构中,方能统一开发规范,统一开发协作流程。例如,我们在规划设计数据仓库过程中,大致需要着手考虑如下工作:

1、描绘初始数据架构模式,并将相应的业务数据并入数据集市模式;

2、针对当前收集的业务数据进行数据原型化;

3、针对原型化的数据,以此为模型进行数据梳理:

3.1 标识数据源;

3.2 确定相关数据特性,分析总结全部业务事实特性以及时间场景;

3.3 确定数据质量及使用频度需求,并参考原型完善设计;

3.4 针对仓库中的事实表需要明确定义事实模式以及维度属性、度量术语表;

3.5 不断梳理、分析、整理术语表、逻辑模式、物理模式的设计;

3.6完善数据部署实施流程等。

仓库类项目并不是完全是业务驱动,也不完全是数据驱动,应该是两者同时驱动的MATRIX架构。作为数据仓库架构设计者,不但要清楚业务流程,还应该清楚数据流程,如果只有元数据驱动、ETL开发也不能完全保证让数据仓库是有条理的、是完美的。

在设计数据库过程中,一则数据库架构设计工作的“缩影”

通常来讲,大多数的数据库设计人员在对一个系统进行设计分析时,总是尝试着搜寻所有可以参考的资源,并尝试着辨别曾经使用过的成功偶或失败的模式或者说案例,并通过自身经验的判断来断定当前系统的解决方案和当前已经存在的解决方案的不同,在工作开展过程中,仍然不忘时刻寻求独到的设计思想与成功案例,并不断改进与完善。同时应该意识到,全新的设计方案一般而言“存活率”相对较低,比较容易令人接受的是已知的、上线的、经实践验证的解决方案的“变体”。通常来讲,如果一个解决方案比较“独特”,那么此方案的实用性可能不足以代表“大众需求”。

例如,在进行一个用IBM DB2进行数据库设计过程中,通过多种假设分析,使用索引的选择达到了一个“比较满意”的系统性能,通过不断“拂尘见金”的分析,针对热点区域遗留问题可以结合数据库特性进行相应的物理设计。如果系统采用了无共享结构,那与之对应的就是无共享分区,只有进行了分区,海量数据的并行处理(MPP)才成为可能。除此之外,顺延考虑范围分区,应用数据层面的操作参考范围分区的隔离规则进行相应的管理与设计,此处需要注意索引的性能问题,同时应用程序的数据管理操作同样需要参考分区隔离规则进行梳理;接下来是物化视图的引入,但索引成本较高,使用过程中慎用。说到数据转入、转出类似的操作不得不提一下MDC。综上述就是一个设计场景的一个“思维切片”,梳理为如下顺序:索引-无共享分区-范围分区-物化视图-MDC。

作为设计,在分析系统可能性的同时,需要循序渐进,每个阶段使用同一个准则,不可随意规划设计数据库。在性能方面如果设计已经成型,且数据库的变更成为一种“奢侈品”时,我们首先应该考虑索引的引入。在使用新技术的同时不建议追新,够用就好。本身数据库设计不只具有严谨性、科学性,还需要有“美感”。一个完美的设计就如同一尊精雕细琢的玉,需要不断地审视、修订、完善,并将这种“迭代”完善的操作融入“设计”的血液当中,使之成为习惯。说到习惯,大致说几条,具体的可以有机会再深入总结、探讨。

1、常反思,勤“迭代”;

2、追求“美感”与“够用就好”;

3、 “适合自己才是真正的合适”;

4、分清“个体”与“全局”;

5、辨别“业务需求”与“系统边界”(避免“镀金”);

6、关注反馈等;

在此同时,不得不结合我的自身体会说一句“大道至简”的感受,在我们徜徉于最新技术的同时,不妨参考一下5S原则,来审视一下当前的工作。如果期望接受来自行业标准的挑战,那数据架构的参与者就需要在理解业务的基础上,不断吸取四面八方的“激扬文字”,并拥有一份希翼到达 “唯美”的彼岸的愿望。例如“军规效应”带来的命名、函数、方法、注释、代码格式、对象乃至数据结构、系统边界、事务处理、并发处理等众多方向的最佳实践,均是当前数据架构设计工作的“挑战”;再如规范化与反规范化的取舍,都是作为数据架构设计的有机组成部分,当然关于具体项目、具体产品的总体方案规划、概要设计、逻辑设计、物理设计、存储规划甚至工程实施在此暂不赘述。

结尾:

衷心希望本文能对大家有所启发,能起到“抛砖引玉”的作用,这些是我工作中的一些经历,希望它们能在您的工作中有所存在价值。


本文节选自《数据库与信息治理》,作者:人民银行软件开发中心 李小平

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

1

添加新评论1 条评论

二十七二十七软件开发工程师jsti
2015-11-10 17:15
数据库的设计,关键是业务要求的明确性一定要有;但一般业务要求的明确性能具体到数据字段的话?太难了。
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广