【数据蒋堂】第14期:计算封闭性导致臃肿的数据库

许多大型用户的数据库(仓库)在运行多年之后,都会积累出很多的数据表,严重者数以万计。这些数据表年代久远,有些已经忘记建设原因,甚至可能已不再有用,但因为很难确认而不敢删除。这给运维工作带来巨大的负担。伴随着这些表还有大量的存储过程仍在不断地向这些表更新数据,占用大量计算资源,经常要迫使数据库扩容。

这些表是真地业务需要吗需要吗?业务会复杂到需要成千上万的表才能描述吗?

有过开发经验的人都知道这不大可能,几百个表就能描述相当复杂的业务了。这些众多的表绝大多数都是所谓的中间表,并不是用来存储基础数据的。

那么,为什么会有中间表?中间表是用来做什么的?

一般来说,中间表会有内部和外部两种来源。

内部产生的中间表大多是为数据呈现(报表或查询)服务的。原始数据量很大时,直接基于原始数据计算汇总信息时的性能会很差,用户体验恶劣。这时,我们会先把一些汇总结果事先计算出,再基于这些中间结果产生报表,用户体验就会好很多。而这些中间数据就会以中间表的形式存储。有时候是因为计算过程很复杂,在生成报表时临时计算会使报表开发过于繁琐,也会采用中间表事先计算好。这类中间表都会伴随着存储过程去定时更新数据,不仅占用存储空间,还会消耗计算资源。而且,报表是业务稳定性比较差的业务,会经常修改和增加,随之而生的中间表也会越来越多。

那么,为什么要把中间数据以数据库表的形式存储呢?这主要是为了获得进一步的计算能力。数据呈现时,并不能简单地把计算好的中间数据直接取出来呈现,而仍然需要做一轮简单些的计算,比如根据参数进行过滤,有时还有再汇总的需求。而这些计算是数据库比较适合实现的,如果把中间数据保存成文件,则将失去计算能力,所以程序员会习惯于使用中间表。

来源于外部的中间表又有两种情况,一种是在ETL过程中产生的。ETL过程中常常会涉及到数据库的数据,正常的ETL过程应当是E、T、L这三个步骤逐步进行,也就是先清洗转换之后再加载进数据库,最后在数据库中的只是合理的结果数据。但是,E(清洗)和T(转换)这两个步骤中会涉及到大量数据计算,而在数据库外实施这些计算很不方便,所以实际情况就会是把涉及到的所有数据都先加载进来然后再进行清洗和转换,ETL过程变成了ELT甚至LET。事先要加载的这些数据在关系数据库中也必须以表的形式存储,这就使数据库中增加了许多并非最终需要的中间表。

另一种情况是多样性数据源造成的,这也是为数据呈现(报表查询)服务的。现代应用中的数据呈现经常会涉及数据库外的数据,目前一般的做法是把库外数据定时导入到数据库中,然后就能和数据库内的数据一起运算产生报表,否则很难实现数据库内外的数据的混合运算。这当然也会让数据库中多了一些表,而且,有些互联网上取过来的数据常常是多层的json或XML格式,在关系数据库中还要建立多个关联的表来存储,会进一步加剧中间表过多的问题。

我们发现这几种情况的中间表都有一个共同点:就是要利用数据库的计算能力。数据库外缺乏强有力的计算能力,而数据库的计算能力又是封闭的(它不能计算数据库外的数据),这样,为了获得数据库的计算能力,我们就只能把许多数据先装入数据库,也就形成了中间表。

数据库的存储封闭性是有意义的,这样可以确保库内数据满足一条规则的约束性,保证数据的正确合理性。但计算能力的封闭性却没有什么必要,对于计算而言,本来也没有库内库外之分。但是数据库的计算模型是建立在其存储模型之上的,这就迫使其计算能力和存储能力一起封闭了,为了获得计算能力只能把数据库搞臃肿。这不仅给管理造成麻烦,而且由于数据库的存储及计算资源都相对昂贵,仅仅是为了获得计算能力就去扩容或部署新数据库,在经济上也不划算。

计算封闭性导致臃肿的数据库,而导致运维困难的还有数据库的另两个技术机制。

数据库是一个共享的独立进程,其计算能力在应用外部,而不从属于某个应用。各个应用共享数据库,都能访问数据库的资源。某个应用(模块)中生成的中间表或存储过程可能被另一个应用(模块)调用,这就造成了应用(模块)之间的耦合性,即使某个中间表的制造者已经下线不用,但因为可能被别的应用使用了而不能删除。

数据库的表还是一种线性组织。在条目数量不多时尚可,太多(几千上万时)就很难理解,人们一般会采用树状多层结构来组织管理众多的条目。但关系数据库并不支持这种方案(有个模式概念可理解为只能分两层),这时候就要给表较长的命名来区别其分类,这一方面使用不便,另一方面对开发管理水平要求很高,在工作较急迫时常常顾不上规范,而随便起个名字先把任务完成再说,时间长了,就会遗留大量的混乱中间表。

当然,根本问题还是在于计算封闭性。

原文发布时间为:2017-7-11

本文作者:蒋步星

本文来自合作伙伴“数据蒋堂”,了解相关信息可以关注“数据蒋堂”微信公众号

时间: 2024-09-24 05:25:51

【数据蒋堂】第14期:计算封闭性导致臃肿的数据库的相关文章

数据蒋堂 | 计算封闭性导致臃肿的数据库

许多大型用户的数据库(仓库)在运行多年之后,都会积累出很多的数据表,严重者数以万计.这些数据表年代久远,有些已经忘记建设原因,甚至可能已不再有用,但因为很难确认而不敢删除.这给运维工作带来巨大的负担.伴随着这些表还有大量的存储过程仍在不断地向这些表更新数据,占用大量计算资源,经常要迫使数据库扩容. 这些表真的是业务需要吗?业务会复杂到需要成千上万的表才能描述吗? 有过开发经验的人都知道这不大可能,几百个表就能描述相当复杂的业务了.这些表绝大多数都是所谓的中间表,并不是用来存储基础数据的. 那么,

开源大数据周刊-第14期

阿里云E-Mapreduce动态 E-Mapreduce团队 1.4版本(正在发布): 作业运行失败报警 作业并行提交 添加sqoop.shell类型的作业 1.4.1版本 集群整体运行情况的仪表盘 集群状态监控报警 资讯 创业公司如何构建数据指标体系? 对于庞大的创业群体和数据运营新手来说,这将是一篇非常具有参考价值的干货贴,作者将在文章中深入阐述两套构建指标体系的方法,即关键指标法和海盗指标法. 怎样选择数据平台的建设方案 文中对比了MPP.Hadoop传统的数据库等不同方案的优缺点,值得一

【数据蒋堂】第15期:开放的计算能力为数据库瘦身

[数据蒋堂]第14期:计算封闭性导致臃肿的数据库 我们在上一期谈到,数据库的臃肿,也就是过多的中间表以及相关存储过程,是由于其计算封闭性造成的.如果能够实现独立的计算引擎,使计算不再依赖于数据库提供,那么就可以为数据库瘦身了. 内部来源的中间数据不必再以数据表的形式落地在数据库中,而可以放到文件系统中,由外部计算引擎提供进一步的计算能力.对于只读的中间数据,使用文件存储时不需要考虑再改写,可以更为紧致并采用一定的压缩手段,而且在访问时也不必考虑事务一致性,机制大为简化,这样能获得比数据库更好多的

开源大数据周刊-第16期

阿里云E-Mapreduce动态 E-Mapreduce团队 1.4版本(已经发布) 作业运行失败报警 作业并行提交 添加sqoop.shell类型的作业 1.4.1版本(正在研发) 完善失败报警 完善定时任务,增加小时.分钟定时任务 1.5.0版本 (正在研发) 集群整体运行情况的仪表盘 集群状态监控报警 1.6.0版本 交互式查询(支持hive.spark) 资讯 Apache Spark 2.0.0 发布,APIs 更新 该版本主要更新APIs,支持SQL 2003,支持R UDF ,增强

开源大数据周刊-第17期

阿里云E-Mapreduce动态 E-Mapreduce团队 1.4版本(已经发布) 作业运行失败报警 作业并行提交 添加sqoop.shell类型的作业 1.4.1版本(已经发布) 完善失败报警 完善定时任务,增加小时.分钟定时任务 1.5.0版本 (正在研发) 集群整体运行情况的仪表盘 集群状态监控报警 1.6.0版本 交互式查询(支持hive.spark) 资讯 大数据投资人必读:中国大数据发展与投资分析报告 随着大数据蕴涵价值的逐步释放,使其成为IT信息产业中最具潜力的蓝海.大数据正以一

【数据蒋堂】第18期:SQL用作大数据计算语法好吗?

当前的大数据平台在处理结构化数据时大都仍然以提供SQL语法为主流.兼容SQL的好处是很明显的,SQL的应用非常广泛,会SQL的程序员很多,如果继续采用SQL则可以避免许多学习成本.支持SQL的前端软件也很多,使用SQL的大数据平台很容易融入这个现成的生态圈中.大数据平台打算替代的传统数据库也是SQL语法的,这样兼容性会很好,移植成本相对较低. 但继续使用SQL也有缺点,最大的问题就是难以获得大数据计算最需要的高性能. 我们在前面的文章中提到过,SQL中缺乏一些必要的数据类型和运算定义,这使得某些

【数据蒋堂】第10期:报表的数据计算层

我们在上一期已经解释了报表应用结构中数据计算层的必要性,以及可以使用报表工具自定义数据源接口来实现计算层.在计算层中要完成一些复杂的计算逻辑,因此要有可编程的能力,而基于自定义接口可以采用报表工具的宿主语言(即用于开发报表工具的程序设计语言)进行开发,在功能方面没有问题,不过,实际应用中却仍有不少缺陷.更好的方式是实现一个显式的数据计算层,在其中提供可解释执行的脚本功能,把数据源计算独立出来. 我们从四个方面来分析后者的优势. 代码编写 报表工具的宿主语言一般是Java.C#等高级语言,这类语言

【数据蒋堂】第3期:功夫都在报表外-漫谈报表性能优化

应用系统中的报表,作为面向业务用户的窗口,其性能一直被高度关注.用户输入参数后都希望立即就能看到统计查询结果,等个十几二十秒还能接受,等到三五分钟的用户体验就非常恶劣了. 那么,报表为什么会慢,又应当从哪里入手进行性能调优呢? 数据准备 当前应用中的报表大都用报表工具开发,当报表响应太慢时,不明就里的用户就会把矛头指向使用报表工具的开发人员或者报表工具厂商.其实,大多数情况报表的慢只是个表现,背后的原因是数据准备太慢,在数据进入报表环节之前就已经慢了,这时再去优化报表开发或压迫报表工具并没有用处

《数据蒋堂》第9期:报表应用的三层结构

在传统的报表应用结构中,报表工具一般都是与数据源直接连接,并没有一个中间的数据计算层.确实,大部分情况下的报表开发并不需要这一层,相关的数据计算在数据源和呈现环节分别处理就够了.不过,在开发过程中,我们发现,有一部分报表的计算即不适合在数据源也不适合在呈现环节实现,这类报表在数量上并不占多数,但耗用的开发工作量占比却很大. 有过程的计算 报表工具都可以完成计算列.分组排序等运算,有些报表工具还提供了跨行组运算和相对格与集合的引用方案,可以完成颇为复杂的运算. 不过,报表工具中的运算是一种状态式的