Jimmy那些事儿

发表 | 更新 | 分类 | 阅读次数

OLTP 与 数据仓库

事务处理系统

  1. 一个独立的事务处理系统也被称为在线事务处理系统（Online Transaction Processing，简称OLTP）

  2. 事务处理系统需要能够快速地定位到一条记录。当一次需要获取多条记录时，多条记录通常使用唯一的键值加以识别；例如订单系统中的一个订单信息，人力资源系统中的个人信息。更重要的是这些信息需要经常被更新，通常一次只更新一条记录。

  3. OLTP 与 BI数据库（Data Warehouse，简称DWH）最大的区别：一个单一的事务里要分析的数据的数量。

    • OLTP系统中，很多并发的用户请求通常只处理一条数据或有限的一组数据
    • 数据仓库系统必须处理几百万条数据的能力，来响应用户的一个简单请求

    表 OLPT 与 数据仓库对比

    | 指标 | OLTP | 数据仓库 |
    | ———- | —————– | ————— |
    | 系统覆盖范围 | 单一业务处理系统 | 多个业务主题 |
    | 数据源 | 单一 | 多个 |
    | | 静态 | 动态 |
    | | 插入/更新 | 只读 |
    | 单事务数据量 | 小 | 大 |
    | 数据量 | 小/中 | 大 |
    | 数据时间精度 | 当前时间戳 | 秒到天不等 |
    | 批量加载/插入/更新 | 否 | 是 |
    | 全部历史数据访问性 | 否 | 是 |
    | 响应时间 | <1秒 | <10秒 |
    | 系统可达性 | 7 $\times $ 24 小时 | 5 $\times$8 小时 |
    | 典型用户 | 前端业务用户 | 分析人员、决策人员 |
    | 用户数量 | 大 | 小/中 |
    ​

OLTP

  • what：联机事务处理过程（On-Line Transaction Processing），也称为面向交易的处理过程
  • why ：最大优点是可以即时地处理输入的数据，及时地回答。
  • how ：基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果


商业智能 BI

  1. 商业智能系统通常被称为决策支持系统（Decision Support System，简称DSS）


ETL & ELT

ETL 代指数据从不同源到数据平台的整个过程，ETL Mapping 可理解为 数据加工算法，

ETL

  • what ：将数据从OLTP系统中转移到数据仓库中的一系列操作的集合。
    • ETL 指从一个或多个数据源抽取数据，经过一个或多个转换步骤后，物理地存储到目标环境中（通常是数据仓库）
    • 数据仓库技术；用来描述Extract(抽取) - Transform(转换)- Load(加载)至目的端的过程。
  • why ：数据仓库利用 提取-转换-加载(ETL)过程将各种格式的数据和框架转换为便于数据检索的通用格式，以从整个企业的多个数据存储中收集大量数据。
  • how ：用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去


  • ETL体系结构
  1. Extract 抽取：一般抽取过程需要连接到不同的数据源，以便为随后的步骤提供数据。
    • 通过接口提取源数据，例如JDBC、专用数据库接口和平面文件提取器，并参照元数据来决定数据的提取及其提取方
  2. Transform 转换：在抽取和加载之间，任何对数据的处理都是转换。
    • 移动数据、根据规则验证数据、数据内容和数据结构的修改、集成多个数据源的数据、根据处理后的数据计算派生值和聚集值
  3. Load 加载：将数据加载到目标系统的所有操作。
    • 加载经转换和汇总的数据到目标数据仓库中，可实现SQL或批量加载。

  • 数据中转区（Staging Area）：仅用来快速地从源数据系统中获取数据，并暂时保留这些数据。
    • 数据中转区不一定是一个数据库系统；很多情况下，将数据保存在ASCII 文件中比插入数据库中表现更快

图1-1 有多个业务源系统，一个数据中转区，一个保存了所有历史数据的数据仓库和多个可以由终端用户访问的数据集市。

这些组成部分之间都是由数据整合过程来完成的，图中的ETL部分


ETL的其他用途

  1. 数据迁移：连接A数据库并将数据迁移至B数据库

    • Kettle拥有两种向导（复制表、复制多表），因此可以根据目标数据库的SQL语法生成新的目标表

    因为这些工具提供了各种类型的连接和转换选项

  2. 数据同步：利用ETL工具保持两个或以上数据库之间的同步；通常情况下同步有时间限制，因此并不完全适用于同步的场景


ELT

  • ELT ：首先从数据源进行抽取、加载到目标数据库中，再转化为所需要的格式；所有大数据量的处理全部放在目标数据库中进行。
    • 优点：数据库系统更适合处理百万级以上的数据集成；数据库系统也通常会对 I/O（吞吐量）进行优化
  • ELT 工具需要知道如何使用目标数据库平台和相应的SQL方言


数据仓库

  • what ：数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。

    • 面向主题：指数据仓库中的数据是按照一定的主题域进行组织。

    • 集成：指对原有分散的数据库数据经过系统加工, 整理得到的消除源数据中的不一致性。

    • 相对稳定：指一旦某个数据进入数据仓库以后只需要定期的加载、刷新。

    • 反映历史变化：指通过这些信息，对企业的发展历程和未来趋势做出定量分析预测。

      ​

    • Date Warehouse；一种资讯系统的资料储存理论，此理论强调利用某些特殊资料储存方式，让所包含的资料，特别有利于分析处理，以产生有价值的资讯并依此作决策。

    • 是将组织透过资讯系统之联机交易处理经年累月所累积的大量资料，透过数据仓库理论所特有的资料储存架构，作一有系统的分析整理，以利各种分析方法，例如线上分析处理及数据挖掘之进行，并且进而支持例如决策支持系统及主管资讯系统之创建，帮助决策者能快速有效的自大量资料中，分析出有价值的资讯，以利决策拟定及快速回应外在环境变动，帮助建构商业智能。

  • why ：为前端查询和分析作为基础

  • how ：

数据仓库 Vs. 数据库

概括而言：

  1. 数据库内的资料是是面向业务的，即所谓的OLTP（联机事务处理）
  2. 数据仓库里的内容是用来支持决策的，也就是OLAP（联机事物分析）。

具体而言：

  1. 数据库里存放的是细节化的信息，而且是二维信息（所谓二维的数据结构，最简单的一种理解就是数据以表的形式组织），有很多基本资料和交易数据。
  2. 数据仓库是里存储的是摘要化的信息，并且是多维的信息（至于多维的数据结构理解起来可能比较抽象，可以想象成很多张表以一定顺序摞成一堆，这一堆又以另一种顺序放成一堆，以此类推）。数据仓库里这些多维的信息是数据挖掘的原材料（注意是数据仓库里的数据而不是数据库）。

数据仓库是由许多的数据库组成，也就是数据仓库相当于一个宫殿，而数据库是宫殿里的房间


数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。数据仓库与数据库的主要区别在于：

（1）数据库是面向事务的设计，数据仓库是面向主题设计的。

（2）数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。

（3）数据库设计是尽量避免冗余，数据仓库在设计是有意引入冗余。

（4）数据库是为捕获数据而设计，数据仓库是为分析数据而设计。

以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。

分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。

  • 面向主题的：传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据；数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。
  • 时间相关：数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。
  • 不可修改：数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。


  1. 数据仓库是一种结构体系，而数据库是一种具体技术。这就是最根本的区别。

拿MySQL这个数据库和Apache Hive这个数据仓库为例。这里Hive事实上就是一个很宏大的“体系结构”。它可以把元数据保存在MySQL、Oracle或者Derby这些具体的数据库“技术”里；它在进行查询时把SQL转化成MapReduce job，这里它又用到了MapReduce计算模型这种“技术”。

数据仓库是伴随着信息与决策支持系统的发展过程产生的，而数据库并不是。

  1. 数据库/数据仓库的用户群体和工作场景不同； 数据库属于操作型系统，数据仓库属于分析性系统。

    • 操作性系统（数据库）的用户群体是大量客户，每次操作修改的数据量非常小，对时间敏感度非常高。
    • 分析性系统（数据仓库）的用户是决策人员，他们不修改数据但是会分析大量数据，而且他们对得出结果的时间不敏感。

    ​

数据库：传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。

数据仓库：数据仓库系统的主要应用主要是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

举个最常见的例子，拿电商行业来说好了。基本每家电商公司都会经历，从只需要业务数据库到要数据仓库的阶段。

  1. 电商早期启动非常容易，入行门槛低。找个外包团队，做了一个可以下单的网页前端 + 几台服务器 + 一个MySQL，就能开门迎客了。这好比手工作坊时期。
  2. 第二阶段，流量来了，客户和订单都多起来了，普通查询已经有压力了，这个时候就需要升级架构变成多台服务器和多个业务数据库（量大+分库分表），这个阶段的业务数字和指标还可以勉强从业务数据库里查询。初步进入工业化。
  3. 第三个阶段，一般需要 3-5 年左右的时间，随着业务指数级的增长，数据量的会陡增，公司角色也开始多了起来，开始有了 CEO、CMO、CIO，大家需要面临的问题越来越复杂，越来越深入。高管们关心的问题，从最初非常粗放的：“昨天的收入是多少”、“上个月的 PV、UV 是多少”，逐渐演化到非常精细化和具体的用户的集群分析，特定用户在某种使用场景中，例如“20~30岁女性用户在过去五年的第一季度化妆品类商品的购买行为与公司进行的促销活动方案之间的关系”。

这类非常具体，且能够对公司决策起到关键性作用的问题，基本很难从业务数据库从调取出来。原因在于：

业务数据库中的数据结构是为了完成交易而设计的，不是为了而查询和分析的便利设计的。

业务数据库大多是读写优化的，即又要读（查看商品信息），也要写（产生订单，完成支付）。因此对于大量数据的读（查询指标，一般是复杂的只读类型查询）是支持不足的。

而怎么解决这个问题，此时我们就需要建立一个数据仓库了，公司也算开始进入信息化阶段了。数据仓库的作用在于：

数据结构为了分析和查询的便利；

只读优化的数据库，即不需要它写入速度多么快，只要做大量数据的复杂查询的速度足够快就行了。

那么在这里前一种业务数据库（读写都优化）的是业务性数据库，后一种是分析性数据库，即数据仓库。

数据库 比较流行的有：MySQL, Oracle, SqlServer等
数据仓库 比较流行的有：AWS Redshift, Greenplum, Hive等

这样把数据从业务性的数据库中提取、加工、导入分析性的数据库就是传统的 ETL 工作。


数据仓库 Vs. 数据集市

  1. 数据仓库是单一的、大量（历史性）数据的存储仓库，可用来支持企业决策
    • 因此涉及的数据涵盖了各种主题和各种业务领域，例如金融、物流、市场营销和客户支持
  2. 通常一个数据仓库不能被终端用户工具直接访问；相反，一个数据集市可以由多个终端用户直接访问，并且是以特定的数据分析为目的的，例如零售或者客户来电；


ODS、DW、DM

可参考 OnoNote - D数据分析 - 数据架构 - 《数据仓库ODS、DW和DM概念区分》

1、在业务系统和数据仓库之间形成一个隔离层

一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。

2、转移一部分业务系统细节查询的功能

在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。

3、完成数据仓库中不能完成的一些功能

一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。

在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。


大数据平台