数据中台建设之数据存储

目录

一、技术选型需要明确的问题

二、技术选型需要考虑的几个方面

2.1 数据规模

2.2 数据生产方式

2.3 数据应用方式

三、技术选型的场景分析

3.1 概述

3.2 在线与离线

3.2.1 在线存储

3.2.2 离线存储

3.3 OLTP与OLAP

3.3.1 OLTP

3.3.2 OLAP

3.3.3 OLTP与OLAP的关系

四、存储技术

4.1 概述

4.2 存储技术分类

4.2.1 分布式系统

4.2.2 NoSQL数据库

4.2.3 云数据库

4.2.4 数据湖

4.2.4.1 概述

4.2.4.2 数据仓库与数据湖的对比

4.2.4.3 数据编目

4.2.4.4 数据入湖

4.2.4.5 总结

---

一、技术选型需要明确的问题

将各类数据汇聚后，首先面临的是存储压力，不同类型的数据内容、不同的数据汇聚方式及未来可能的使用场景，都会对存储系统的选择产生影响。

常见的问题如下：

• ❑存储系统是选择关系型数据库还是大数据相关的技术（Hadoop等）?
• ❑现有存储系统与新存储系统之间是什么关系？
• ❑选择数据仓库还是数据湖？

二、技术选型需要考虑的几个方面

抛开技术指标的维度对比，选择存储系统时还需要考虑以下几个方面。

2.1 数据规模

当前的及未来的数据规模，这取决于对中台的定位及对未来的发展预期。DT时代，企业的数据生产方式越来越丰富，数据量越来越大，选择成本可控且容易扩展的存储系统是比较常见的选择。

2.2 数据生产方式

有些数据生产端没有存储系统，因此会通过实时推送的方式将生产数据按特定协议和方式进行推送，这类场景要求数据采集时的存储系统能够满足数据实时落地的需求。有些目标存储系统不具备这种高性能落地的能力，因此需要考虑在数据生产端和目标存储端中间加一个写性能较好的存储系统。

2.3 数据应用方式

数据使用场景决定了数据存储系统的选型，如离线的数据分析适合非人机交互的场景，搜索则需要能够快速检查并支持一些关键字和权重处理。这些能力也需要有特定的存储系统来支撑。

三、技术选型的场景分析

3.1 概述

针对这些复杂的场景，在大规模的数据处理下，任何一个以前认为可以忽视的小问题都有可能被无限放大，因此还像以前一样靠一种存储系统解决所有问题是不太可能的。在建设中台时，需要根据企业自身情况选择合适的存储系统组合来满足企业的数据战略和数据应用需求。

3.2 在线与离线

3.2.1 在线存储

在线存储是指存储设备和所存储的数据时刻保持在线状态，可供用户随时读取，满足计算平台对数据访问的速度要求，就像PC中常用的磁盘存储模式一样。在线存储设备一般为磁盘、磁盘阵列、云存储等。

3.2.2 离线存储

离线存储用于对在线存储的数据进行备份，以防范可能发生的数据灾难。离线存储的数据不会经常被调用，一般也远离系统应用，“离线”一词生动地描述了这种存储方式。离线存储介质上的数据的读写是顺序进行的。读取数据时，需要先把磁带卷到头，再进行定位。当需要对已写入的数据进行修改时，需要将所有数据全部改写。因此，离线存储的访问速度慢、效率低。离线存储的主要介质是硬盘、磁带、光盘等。

3.3 OLTP与OLAP

3.3.1 OLTP

OLTP（On-Line Transaction Processing，联机事务处理）是专注于面向事务的任务的一类数据处理，通常涉及在数据库中插入、更新或删除少量数据，主要处理大量用户下的大量事务。OLTP系统一般都是高可用的在线系统，以小的事务及小的查询为主，评估其系统的时候，一般看其每秒执行的事务及查询的数量。在这样的系统中，单个数据库每秒处理的事务往往有几百甚至几千个，Select语句的执行量每秒有几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库就是很典型的OLTP数据库。

3.3.2 OLAP

OLAP（On-Line Analytical Processing，联机分析处理）系统，有时也叫DSS（决策支持系统），就是我们说的数据仓库。它常用于报表分析场景，相对于OLTP，对准确性（如id-mapping）、事务性和实时性要求较低。1993年，E.F.Codd认为OLTP已不能满足终端用户对数据库查询分析的需要，SQL对大型数据库进行的简单查询也不能满足终端用户分析的要求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，他提出了多维数据库和多维分析的概念，即OLAP。

3.3.3 OLTP与OLAP的关系

OLTP和OLAP是相对传统的术语，但是在大数据时代，它们又有了新的使命。需要强调的是，OLTP和OLAP并不是竞争或者互斥的关系，相反，它们相互协作，互利共赢，OLTP用于存储和管理日常操作的数据，OLAP用于分析这些数据，如下图所示：

OLAP技术主要通过多维的方式来对数据进行分析、查询并生成报表，它不同于传统的OLTP应用。OLTP应用主要用来完成用户的事务处理，如民航订票系统和银行的储蓄系统等，通常要进行大量的更新操作，并且对响应的时间要求比较高。而OLAP应用主要对用户当前数据和历史数据进行分析，帮助市场做决策，制定营销策略，主要用来执行大量的查询操作，对实时性要求低。下表对OLTP与OLAP进行了比较：

四、存储技术

4.1 概述

为了应对数据处理的压力，过去十年间，数据处理技术领域有了很多的创新和发展。除了面向高并发、短事务的OLTP内存数据库外(Altibase、TimesTen)，其他的技术创新和产品都是面向数据分析的，而且是大规模数据分析，也可以说是大数据分析。

有的采用MPP（Massive Parallel Processing，大规模并行处理）架构的数据库集群，重点面向行业大数据，如Greenplum、LibrA等；有的采用Shared Nothing架构，通过列存储、粗粒度索引等多项大数据处理技术，再结合MPP架构高效的分布式计算模式，实现对分析类应用的支撑，运行环境多为低成本的PC服务器，具有高性能和高扩展性的特点；也有的采用从Hadoop技术生态圈中衍生的相关大数据技术，如HBase等。

4.2 存储技术分类

4.2.1 分布式系统

分布式系统包含多个自主的处理单元，通过计算机网络互联来协作完成分配的任务，其分而治之的策略能够更好地处理大规模数据分析问题。分布式系统主要包含以下3类：

• ❑分布式文件系统：存储管理需要多种技术的协同工作，其中文件系统为其提供底层存储能力的支持。分布式文件系统HDFS是一个高容错性系统，被设计成适用于批量处理，能够提供高吞吐量的数据访问。
• ❑分布式键值系统：用于存储关系简单的半结构化数据。典型的分布式键值系统有Amazon Dynamo，获得广泛应用的对象存储(ObjectStorage)技术也可以视为键值系统，其存储和管理的是对象而不是数据块。
• ❑MPP系统：这里更多是指狭义上的分布式分析性数据库系统，如Greenplum、Teradata等。这类数据库具备良好的SQL兼容性，能够像操作关系型数据库一样执行任务，在集群节点规模上也能扩展到三位数，但是由于只能处理结构化数据，所以难以支持数据湖这类蕴含丰富非结构化数据的场景。

4.2.2 NoSQL数据库

关系型数据库已经无法满足Web 2.0的需求，主要表现为：

• ❑无法满足海量数据的管理需求；
• ❑无法满足数据高并发的需求；
• ❑高可扩展性和高可用性的功能太低。

NoSQL数据库的优势为：可以支持超大规模数据存储，灵活的数据模型可以很好地支持Web 2.0应用，具有强大的横向扩展能力等。典型的NoSQL数据库包含以下几种：键值数据库、列族数据库、文档数据库和图形数据库等。

4.2.3 云数据库

云数据库是一种基于云计算技术的共享基础架构的方法，是部署和虚拟化在云计算环境中的数据库。云数据库并非全新的数据库技术，而只是以服务方式提供的数据库功能。云数据库所采用的数据模型可以是关系型数据库所使用的关系模型（微软的Azure SQL云数据库都采用了关系模型）。同一家公司也可能提供采用不同数据模型的多种云数据库服务。

4.2.4 数据湖

4.2.4.1 概述

随着企业数据的爆发式增长，以及对非结构化数据存储与分析使用的需求增大，传统数据仓库的数据中台方案遇到了瓶颈。首先，数据中台需要将所有原始数据汇聚，非结构化数据的原始数据存放在各个NAS、云盘、本地FTP等系统中，而受限于存储成本，难以将所有非结构化数据同步到数据中台；其次，数据仓库更多是结构化数据存算一体的架构，非结构化数据要进行处理再进入数据仓库，从数据处理、加工到使用的链路较长；最后，数据仓库作为OLAP的选型，ACID方面无法保证，对于要求实时、精准分析数据的场景支持并不理想。

4.2.4.2 数据仓库与数据湖的对比

数据湖除了具备数据仓库的大部分能力外，还解决了上述棘手问题。通过下表对数据仓库与数据湖的比较我们能够更好地了解数据湖的主要能力。

数据湖是一个以原始格式存储数据的存储库或系统，它按原样存储数据，而不事先对数据进行结构化处理。也就是说，数据湖既可以存储结构化数据，也可以存储非结构化数据，换句话说，可以存储企业的所有数据。

另外，搭配这一特性的还有数据的加工方式，数据仓库是写时模式，数据湖是读时模式。写时的意思是在写入数据时，就把数据结构(Scheme)定义好，系统已经知道这些数据的逻辑结构，可通过既定的程序输出计算结果；而读时模式则是数据在使用时，由使用者定义结构及分析方法，它相比读时更加灵活，可挖掘出更多的数据金矿。

4.2.4.3 数据编目

企业的数据存储系统以及业务系统逐年增加，数据存储在各个地方，存储介质多种多样，有机械硬盘、固态硬盘、内存等，数据湖可以通过数据编目的方式将这些存储系统统一管理起来，用于后续的计算。数据使用者无须关心数据的实际存储位置，只需要申请并执行计算任务即可获得结果。

数据编目可以是对原始数据的物理资源编目，也可以是基于业务需求和场景的逻辑编目。但无论采用何种编目方式，都需要保证用户和系统能够索引、定位到数据。

4.2.4.4 数据入湖

在存储计算方面，数据仓库采用的是存算一体的模式，如果要使用数据仓库，就需要单独搭建一套存储系统，将数据实际汇聚到存储系统当中。而数据湖可以做到存算分离，存储系统既可以是集中的，也可以是分散的，分散的数据在被使用时同步到加速计算引擎内，输出结果，这样就无须先将数据处理加工好再使用，因而能够更合理地利用组织内的存算资源。数据进入数据湖的方式主要有两种。

• ❑物理入湖

数据编目完成后，即将数据汇聚、同步到数据湖的存储系统中。对于经常使用、分析的数据，建议使用物理入湖的方法，这样在数据分析时，数据无须进行传输就已经在系统中存储，因而能够让数据计算任务立刻跑起来，快速获取结果。

• ❑虚拟入湖

仅完成数据编目的工作，而不进行数据汇聚、同步的工作，只有在计算时，才通过实时同步的方式将数据集中存储并计算。如果在原始存储系统中部署有计算节点，也可以先在边缘计算结果再传输到中心统一计算。对于非结构化数据这类存储开销大的或者使用频率低、难以评估使用频率的数据，都推荐使用虚拟入湖的方式“汇聚”到数据湖中。

4.2.4.5 总结

数据湖能够真正将原始数据都“汇聚”起来，消灭数据孤岛；让企业数据管理者看到数据大盘，掌握数据概况，让数据开发者无须关注物理存储即可进行指标计算、数据挖掘，快速响应业务，是数据中台现阶段在技术层面的最佳选择。

好了，本次内容就分享到这，欢迎大家关注《数据中台》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！