数据仓库的演进历史是怎样的?
发布网友
发布时间：2022-04-24 08:11
共4个回答
懂视网
时间：2022-05-01 02:58
最近看了很多公司架构的演变的文章，发现其中的基本思路和架构演变都很类似，这里也总结一下数据库架构的演变以及演变背后的思路。
单主机
最开始网站一般都是由典型的LAMP架构演变而来的，一般都是一台linux主机，一台apache服务器，php执行环境以及mysql服务器，一般情况下，这些都在一台虚拟主机上，简称单主机模式。
单主机模式缺点：
1 web服务器和mysql服务器公用一台主机，共享硬件资源，可能存在某一方资源征用太大，导致整个应用产生瓶颈
2 当业务增长之后，没有办法做到横向扩展。
3 容错性太差，一旦主机存在问题，整个应用不可用
独立主机
随着业务的发展，可以把mysql服务器和web服务器主机分开，分别部署，就是独立主机模式。
独立主机模式下，web服务器和mysql不再共享硬件资源，分别部署。没有把鸡蛋放在一个篮子里面，增加了容错性。如果只是mysql服务器故障，那么对于web上不访问服务器的应用是不会受到影响的。而且web服务器可以做到横向扩展，如果web服务器性能不够，可以增加多台web服务器，进行负载均衡，分散web服务器的压力。
独立主机模式的缺点：
1 可扩展性问题：虽然web服务器可以做到横向扩展，但是mysql服务器是没有办法做到横向扩展的。
2 可用性问题：mysql服务器存在单点问题，一旦mysql服务器宕机，对影响的影响很大
3 性能问题：单台mysql服务器能够支撑的服务是有限的。
读写分离
随着业务的不断发展，数据库的压力会越来越大，单数据库慢慢的就不能满足需求了，一些网站对数据实时性要求不高，就会慢慢发展读写分离模式，对于普通的查询请求，分配到读库（也可以说是备库），对于修改请求，在主库上完成。对于读库，由于是无状态的，可以做到横向扩展。对于写库，还只能是单台主机
这种模式其实有限制的，要根据业务的类型来考虑。主库的数据是最新的，但是同步到读库会有时延，所以应用必须能够容忍短暂的不一致性。对于一致性要求非常高的场景是不适合的。
这种模式的存在的问题：
1 可扩展性：虽然读库可以做到横向扩展，但是写库还不行，读库不能够横向扩展
2 可用性：读库成为单点，一旦故障，影响所有的写操作业务
业务垂直拆分
随着业务的发展，一台写库显然不能够满足高并发的情况，但是考虑到写库是有状态的，不能简单的横向扩展，假设有两台写库，那么随机更新一台的数据，就会导致另一方数据存在问题。出现一种数据两个不同版本，显然是无法接受的。在写库上，可以考虑按照业务来垂直进行分库。由于我们这里讨论的是数据库架构，对于web层来说，其实也是可以按照业务垂直拆分的。
在按照业务垂直拆分以后，系统在性能上有了很高的提升，只需要把业务上分成垂直部分，分的越细，系统的整体扩展能力就越强。
这种模式下，存在以下几个问题
1 可用性：假设一个完整的业务流程P访问的数据库被拆分为A、B、C、D、E 五个库，假设每个写库可用性为99%，那么这个业务流程P的可用性就为99%*99%*99%*99%*99%=95%,库拆分的越多，对系统的整体可用性挑战就越大。
2 性能：由于垂直业务库每个库的负载可能不一样，假设交易库负载很高，一个交易写库肯定不能够满足需求，这个情况下，交易库成为整个系统的瓶颈。
3 可扩展性：单个节点的可扩展性没有得到改善，交易库不能单独进行扩展。
单业务库水平、垂直拆分
在上一种情况，假设交易库是整个系统的瓶颈，需要对交易库进行单独的扩展。可以考虑交易的水平拆分或者垂直拆分，有可能同时进行两种方式拆分。
水平拆分一般根据业务无关的关键字进行拆分，横向扩展性比较好，但是对于查询的挑战比较大
垂直拆分一般根据业务来拆分，但是可能导致数据不均匀以及拆分不够灵活。对于查询来说，相对比较友好
拿交易库举个例子，可以先交易的类型进行业务上的垂直分库，在按照订单号进行水平分库。
假设可以分成M*N个库，那么单个库的故障会影响1/M*N 的交易，但是假设每个库可用性为99% ，那么交易数据库故障概率为 (99%)的(M+N)次方，如果数据库拆分的越多，发生单个数据库故障概率就越高。
这种方式存在的问题：
1 虽然单个节点故障影响的用户很少，但是整体可用会降低。
2 数据库管理上带来复杂的挑战，假设交易库表结构变更，需要执行M×N次脚本变更。
3 由于发生单个数据库故障的概率比较高，dba会很苦逼的，估计经常性要救火
4 开发和测试起来会非常苦逼，开发和测试成本会变高，查询非常复杂。
5 单个节点如果发生故障，没有失败检测并且切换机制
6 分库还不能在水平方向做到无限扩展，我们的算法是事先分配M个库，如果添加一个库基本上不可行
随机分库
对于第六个问题，在水平方向的无线扩展，可以考虑一种机制，在insert数据的时候，申请一个数据库编号，然后把数据库的编号作为一个字段保存或者在把这个编号添加到已经字段上。
例如假设我们申请insert数据库，得到一个数据库编号为1000，那么我们可以构造出来一个订单号为1000_tradeno，订单号前面是分库编号，订单号后面是实际tradeno，这样解决了水平无线扩展的问题。这种就是随机分库模式。但是这一种方式的局限性很大，
随机分库的缺点：
1 分库算法和业务耦合在一起，比较适合特定的场景，适用范围比较窄
2 对于insert操作，比较容易，对于update操作，必须有分库编号，也就是说，只能根据特定的字段来进行更新
3 不适合批量查询的场景，查询功能限制比较大，这也是分库带来的问题
单数据库备份以及失败切换
对于单个数据库，如果发生故障，会影响业务，但是能否在发生故障的时候进行切换。虽然可以实现，但是会存在一定的问题，需要特定场景进行特定的分析。这一块比较复杂，说起来可以在写一篇文章，就简单的介绍一下
热心网友
时间：2022-05-01 00:06
（1）萌芽阶段。数据仓库概念最早可追溯到20世纪70年代，MIT的研究员致力于研究一种优化的技术架构，该架构试图将业务处理系统和分析系统分开，即将业务处理和分析处理分为不同层次，针对各自的特点采取不同的架构设计原则，MIT的研究员认为这两种信息处理的方式具有显著差别，以至于必须采取完全不同的架构和设计方法。但受限于当时的信息处理能力，这个研究仅仅停留在理论层面。
（2）探索阶段。20世纪80年代中后期，DEC公司结合MIT的研究结论，建立了TA2（TechnicalArchitecture2）规范，该规范定义了分析系统的四个组成部分：数据获取、数据访问、目录和用户服务。这是系统架构的一次重大转变，第一次明确提出分析系统架构并将其运用于实践。
（3）雏形阶段。1988年，为解决全企业集成问题，IBM公司第一次提出了信息仓库（InformationWarehouse）的概念，并称之为VITAL规范（VirtuallyIntegratedTechnical ArchitectureLifecycle）。VITAL定义了85种信息仓库组件，包括PC、图形化界面、面向对象的组件以及局域网等。至此，数据仓库的基本原理、技术架构以及分析系统的主要原则都已确定，数据仓库初具雏形。
（4）确立阶段。1991年Bill Inmon出版了他的第一本关于数据仓库的书《Building the DataWarehouse》，标志着数据仓库概念的确立。该书指出，数据仓库(DataWarehouse)是一个面向主题的(SubjectOriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化的(TimeVariant)数据集合，用于支持管理决策(Decision-MakingSupport)。该书还提供了建立数据仓库的指导意见和基本原则。凭借着这本书，Bill Inmon被称为数据仓库之父。
以上供参考。
热心网友
时间：2022-05-01 01:24
第二代数据仓库采用MPP架构，采用无共享架构（比如Teradata），使用普通X86服务器，可扩展至几十节点，但很难满足大数据需求，架构不够灵活，比如难于实现秒级扩容。
Apache HAWQ属于第三代数据仓库，使用存储与计算分离架构，可扩展至数千节点，架构灵活。另外，HAWQ从著名第二代MPP数据仓库系统Greenplum Database演化而来，继承了Greenplum Database的SQL以及对第三方工具的兼容性，所以，在兼容性和性能方面大大优于其他第三代Hadoop SQL引擎，可以轻松取代传统数仓和Hadoop SQL引擎。
热心网友
时间：2022-05-01 02:58
