做任务的电脑网站,网站防止盗图,伦敦 wordpress 设计,app开发哪家公司比较好目录 一、技术选型需要明确的问题
二、技术选型需要考虑的几个方面
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的关…目录 一、技术选型需要明确的问题
二、技术选型需要考虑的几个方面
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
OLTPOn-Line Transaction Processing联机事务处理是专注于面向事务的任务的一类数据处理通常涉及在数据库中插入、更新或删除少量数据主要处理大量用户下的大量事务。OLTP系统一般都是高可用的在线系统以小的事务及小的查询为主评估其系统的时候一般看其每秒执行的事务及查询的数量。在这样的系统中单个数据库每秒处理的事务往往有几百甚至几千个Select语句的执行量每秒有几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等如美国eBay的业务数据库就是很典型的OLTP数据库。
3.3.2 OLAP
OLAPOn-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)其他的技术创新和产品都是面向数据分析的而且是大规模数据分析也可以说是大数据分析。
有的采用MPPMassive 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 总结
数据湖能够真正将原始数据都“汇聚”起来消灭数据孤岛让企业数据管理者看到数据大盘掌握数据概况让数据开发者无须关注物理存储即可进行指标计算、数据挖掘快速响应业务是数据中台现阶段在技术层面的最佳选择。 好了本次内容就分享到这欢迎大家关注《数据中台》专栏后续会继续输出相关内容文章。如果有帮助到大家欢迎大家点赞关注收藏有疑问也欢迎大家评论留言
