数据中台之结构化大数据存储设计_第1页
数据中台之结构化大数据存储设计_第2页
数据中台之结构化大数据存储设计_第3页
数据中台之结构化大数据存储设计_第4页
数据中台之结构化大数据存储设计_第5页
免费预览已结束,剩余2页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、数据中台之结构化大数据存储设计一.前言任何应用系统都离不开对数据的处理,数据也是驱动业务创新以及向智能化开展最核心的东西.这也是为何目前大多数企业都在构建数据中台的原因,数据处理的技术已经是核心竞争力.在一个完备的技术架构中,通常也会由应用系统以及数据系统构成.应用系统负责处理业务逻辑,而数据系统负责处理数据.传统的数据系统就是所谓的大数据技术,这是一个被创造出来的名词,代表着新的 技术门槛.近几年得益于产业的开展、业务的创新、数据的爆发式增长以及开源技术的广泛 应用,经历多年的磨炼以及在广阔开发者的共建下,大数据的核心组件和技术架构日趋成熟.特别是随着云的开展,让 大数据技术的使用门槛进一步

2、降低,越来越多的业务创新会由数据来驱动完成.大数据技术会逐步向轻量化和智能化方向开展,最终也会成为一个研发工程师的必备技能之一,而这个过程必须是由云计算技术来驱动以及在云平台之上才能完成.应用系统和数据系统也会逐渐融合,数据系统不再隐藏在应用系统之后,而是也会贯穿在整个业务交互逻辑.传统的应用系统,重点在于交互.而现代的应用系统,在与你交互的同时,会慢慢 的熟悉你.数据系统的开展驱动了业务系统的开展,从业务化到规模化,再到智能化.业务化:完成最根本的业务交互逻辑.规模化:分布式和大数据技术的应用,满足业务规模增长的需求以及数据的积累.智能化:人工智能技术的应用,挖掘数据的价值,驱动业务的创新.

3、向规模化和智能化的开展,仍然存在一定的技术门槛.成熟的开源技术的应用能让一个 大数据系统的搭建变得简单,同时大数据架构也变得很普遍,例如广为人知的Lambda架构,一定程度上降低了技术的入门门槛.但是对数据系统的后续维护,例如对大数据组件的规模化应用、运维管控和本钱优化,需要掌握大数据、分布式技术及复杂环境下定位问题的水平, 仍然具备很高的技术门槛.数据系统的核心组件包含数据管道、分布式存储和分布式计算,数据系统架构的搭建会是使用这些组件的组合拼装.每个组件各司其职,组件与组件之间进行上下游的数据交换, 而不同模块的选择和组合是架构师面临的最大的挑战.本篇文章主要面向数据系统的研发工程师和架构

4、师,我们会首先对数据系统核心组件进行拆解,介绍每个组件下对应的开源组件以及云上产品.之后会深入剖析数据系统中结构化数据的存储技术,介绍阿里云Tablestore 选择哪种设计理念来更好的满足数据系统中对结构化数据存储的需求.二.数据系统架构1. 核心组件上图是一个比拟典型的技术架构,包含应用系统和数据系统.这个架构与具体业务无关联,主要用于表达一个数据应用系统中会包含的几大核心组件,以及组件间的数据流关系.应用系统主要实现了应用的主要业务逻辑,处理业务数据或应用元数据等.数据系统主要对业务数据及其他数据进行汇总和处理,对接BI、推荐或风控等系统.整个系统架构中,会包含以下比拟常见的几大核心组件

5、:(1) 关系数据库:用于主业务数据存储,提供事务型数据处理,是应用系统的核心数据 存储.(2) 高速缓存:对复杂或操作代价昂贵的结果进行缓存,加速访问.(3) 搜索引擎:提供复杂条件查询和全文检索.(4) 队列:用于将数据处理流程异步化,衔接上下游对数据进行实时交换.异构数据存 储之间进行上下游对接的核心组件,例如数据库系统与缓存系统或搜索系统间的数 据对接.也用于数据的实时提取,在线存储到离线存储的实时归档.(5) 非结构化大数据存储:用于海量图片或视频等非结构化数据的存储,同时支持在线 查询或离线计算的数据访问需求.(6) 结构化大数据存储:在线数据库也可作为结构化数据存储,但这里提到的

6、结构化数 据存储模块,更偏在线到离线的衔接,特征是能支持高吞吐数据写入以及大规模数 据存储,存储和查询性能可线性扩展.可存储面向在线查询的非关系型数据,或者 是用于关系数据库的历史数据归档,满足大规模和线性扩展的需求,也可存储面向 离线分析的实时写入数据.(7) 批量计算:对非结构化数据和结构化数据进行数据分析,批量计算中又分为交互式 分析和离线计算两类,离线计算需要满足对大规模数据集进行复杂分析的水平,交 互式分析需要满足对中等规模数据集实时分析的水平.(8) 流计算:对非结构化数据和结构化数据进行流式数据分析,低延迟产出实时视图.对于数据存储组件我们再进一步分析,当前各类数据存储组件的设计

7、是为满足不同场景下数据存储的需求, 提供不同的数据模型抽象,以及面向在线和离线的不同的优化偏向.我们来看下下面这张详细比照表:2. 派生数据体系在数据系统架构中,我们可以看到会存在多套存储组件.对于这些存储组件中的数据,有些是来自应用的直写, 有些是来自其他存储组件的数据复制.例如业务关系数据库的数据通常是来自业务,而高速缓存和搜索引擎的数据, 通常是来自业务数据库的数据同步与复制.不同用途的存储组件有不同类型的上下游数据链路,我们可以大概将其归类为主存储和辅存储两类,这两类存储有不同的设计目标,主要特征为:(1) 主存储:数据产生自业务或者是计算,通常为数据首先落地的存储.ACID等事务特

8、性可能是强需求,提供在线应用所需的低延迟业务数据查询.(2) 辅存储:数据主要来自主存储的数据同步与复制,辅存储是主存储的某个视图,通 常面向数据查询、检索和分析做优化.为何会有主存储和辅存储的存在能不能统一存储统一读写,满足所有场景的需求呢目前看还没有,存储引擎的实现技术有多种,选择行存还是列存,选择 B+tree还是LSM-tree , 存储的是不可变数据、频繁更新数据还是时间分区数据,是为高速随机查询还是高吞吐扫描设计等等.数据库产品目前也是分两类,TP和AP,虽然在往HTAPT向走,但实现方式仍然是底层存储分为行存和列存.再来看主辅存储在实际架构中的例子,例如关系数据库中主表和二级索引

9、表也可以看做是主与辅的关系,索引表数据会随着主表数据而变化,强一致同步并且为某些特定条件组合查询而优化.关系数据库与高速缓存和搜索引擎也是主与辅的关系,采用满足最终一致的数据同步方式,提供高速查询和检索.在线数据库与数仓也是主与辅的关系,在线数据库内数据集中复制到数仓来提供高效的BI分析.这种主与辅的存储组件相辅相成的架构设计,我们称之为派生数据体系.在这个体系下,最大的技术挑战是数据如何在主与辅之间进行同步与复制.上图我们可以看到几个常见的数据复制方式:(1) 应用层多写这是实现最简单、依赖最少的一种实现方式,通常采取的方式是在应用代码中先向主存 储写数据,后向辅存储写数据. 这种方式不是很

10、严谨,通常用在对数据可靠性要求不是很高的场景.由于存在的问题有很多,一是很难保证主与辅之间的数据一致性,无法处理数据写入失效问题;二是数据写入的消耗堆积在应用层,加重应用层的代码复杂度和计算负担,不是一种解耦很好的架构;三是扩展性较差,数据同步逻辑固化在代码中,比拟难灵活添加辅存储.(2) 异步队列复制这是目前被应用比拟广的架构,应用层将派生数据的写入通过队列来异步化和解耦.这种架构下可将主存储和辅存储的数据写入都异步化,也可仅将辅存储的数据写入异步化.第一种方式必须接受主存储可异步写入,否那么只能采取第二种方式.而如果采用第二种方式的话,也会遇到和上一种应用层多写方案类似的问题,应用层也是多

11、写,只不过是写主存 储与队列,队列来解决多个辅存储的写入和扩展性问题.(3) CDC( Change Data Capture )技术这种架构下数据写入主存储后会由主存储再向辅存储进行同步,对应用层是最友好的, 只需要与主存储打交道.主存储到辅存储的数据同步,那么可以再利用异步队列复制技术来做.不过这种方案对主存储的水平有很高的要求,必须要求主存储能支持 CD锻术.一个典型的例子就是MySQL+Elasticsearch 的组合架构,Elasticsearch 的数据通过 MySQL的binlog 来同步,binlog 就是MySQL勺CD破术.派生数据体系是一个比拟重要的技术架构设计理念,其

12、中CDCK术是更好的驱动数据流动的关键手段.具备CD锻术的存储组件,才能更好的支撑数据派生体系,从而能让整个数据系统架构更加灵活,降低了数据一致性设计的复杂度,从而来面向高速迭代设计.可惜的是大多数存储组件不具备CDC技术,例如HBas&而阿里云Tablestore具备非常成熟的CDC术,CDC技术的应用也推动了架构的创新,这个在下面的章节会详细介绍.一个好的产品,在产品内部会采用派生数据架构来不断扩充产品的水平,能将派生的过程透明化,内部解决数据同步、一致性及资源配比问题.而现实中大多数技术架构采用产品组合的派生架构,需要自己去治理数据同步与复制等问题,例如常见的 MySQL+Ela

13、sticsearch,或HBase+Solr等.这种组合通常被无视的最大问题是,在解决 CDC 技术来实时复制数据后,如何解决数据一致性问题如何追踪数据同步延迟如何保证辅存储与 主存储具备相同的数据写入水平3. 存储组件的选型架构师在做架构设计时,最大的挑战是如何对计算组件和存储组件进行选型和组合,同类的计算引擎的差异化相对不大,通常会优先选择成熟和生态健全的计算引擎,例如批量计算引擎Spark和流计算引擎Flink.而对于存储组件的选型是一件非常有挑战的事,存储组 件包含数据库(又分为 SQL和NoSQL两类,NoSQL下又根据各类数据模型细分为多类)、对 象存储、文件存储和高速缓存等不同类

14、别.带来存储选型复杂度的主要原因是架构师需要综合考虑数据分层、本钱优化以及面向在线和离线的查询优化偏向等各种因素,且当前的技术开展还是多样化的开展趋势,不存在一个存储产品能满足所有场景下的数据写入、存储、查询和分析等需求.有一些经验可以分享给大家:(1) 数据模型和查询语言仍然是不同数据库最显著的区别,关系模型和文档模型是相对 抽象的模型,而类似时序模型、图模型和键值模型等其他非关系模型是相对具象的 抽象,如果场景能匹配到具象模型,那选择范围能缩小点.(2) 存储组件通常会划分到不同的数据分层,选择面向规模、本钱、查询和分析性能等不同维度的优化偏向,选型时需要考虑清楚对这局部数据存储所要求的核

15、心指标.(3) 区分主存储还是辅存储, 对数据复制关系要有明确的梳理.(主存储和辅存储是什么 在下一节介绍)(4) 建立灵活的数据交换通道,满足快速的数据搬迁和存储组件间的切换水平,构建快 速迭代水平比应对未知需求的扩展性更重要.另外关于数据存储架构,我认为最终的趋势是:(1) 数据一定需要分层(2) 数据最终的归属地- -定是 OSS(3) 会由一个统一的分析引擎来统一分析的入口,并提供统一的查询语言4. 结构化大数据存储结构化大数据存储在数据系统中是一个非常关键的组件,它起的一个很大的作用是连接在线和离线.作为数据中台中的结构化数据汇总存储,用于在线数据库中数据的汇 总来对接离线数据分析,

16、也用于离线数据分析的结果集存储来直接支持在线查询或者是数据 派生.根据这样的定位,我们总结下对结构化大数据存储的几个关键需求.5. 关键需求(1) 大规模数据存储结构化大数据存储的定位是集中式的存储,作为在线数据库的汇总(大宽表模式),或者是离线计算的输入和输出,必须要能支撑PB级规模数据存储.(2) 高吞吐写入水平数据从在线存储到离线存储的转换,通常是通过 ETL工具,T+1式的同步或者是实时同 步.结构化大数据存储需要能支撑多个在线数据库内数据的导入,也要能承受大数据计算引擎的海量结果数据集导出.所以必须能支撑高吞吐的数据写入, 通常会采用一个为写入而优 化的存储引擎.(3) 丰富的数据查

17、询水平结构化大数据存储作为派生数据体系下的辅存储,需要为支撑高效在线查询做优化. 常见的查询优化包括高速缓存、高并发低延迟的随机查询、复杂的任意字段条件组合查询以及数据检索.这些查询优化的技术手段就是缓存和索引,其中索引的支持是多元化的, 面向不同的查询场景提供不同类型的索引.例如面向固定组合查询的基于B+tree的二级索引,面向地理位置查询的基于 R-tree或BKD-tree的空间索引或者是面向多条件组合查询和全文检 索的倒排索引.(4) 存储和计算本钱别离存储计算别离是目前一个比拟热的架构实现,对于一般应用来说比拟难体会到这个架构的优势.在云上的大数据系统下,存储计算别离才能完全发挥优势

18、.存储计算别离在分布式架构中,最大的优势是能提供更灵活的存储和计算资源治理手段,大大提升了存储和计算的扩展性.对本钱治理来说,只有基于存储计算别离架构实现的产品,才能做到存储和计算成本的别离.存储和计算本钱的别离的优势,在大数据系统下会更加明显.举一个简单的例子,结构 化大数据存储的存储量会随着数据的积累越来越大,但是数据写入量是相对平稳的. 所以存储需要不断的扩大,但是为了支撑数据写入或临时的数据分析而所需的计算资源,那么相对来说比拟固定,是按需的.(5) 数据派生水平一个完整的数据系统架构下, 需要有多个存储组件并存. 并且根据对查询和分析水平的 不同要求,需要在数据派生体系下对辅存储进行

19、动态扩展. 所以对于结构化大数据存储来说, 也需要有能扩展辅存储的派生水平, 来扩展数据处理水平. 而判断一个存储组件是否具备更好的数据派生水平,就看是否具备成熟的CD破术.(6)计算生态数据的价值需要靠计算来挖掘,目前计算主要划为批量计算和流计算.对于结构化大数据存储的要求,一是需要能够对接主流的计算引擎,例如Spark、Flink等,作为输入或者是输出;二是需要有数据派生的水平,将自身数据转换为面向分析的列存格式存储至数据湖系统;三是自身提供交互式分析水平,更快挖掘数据价值.满足第一个条件是最根本要求,满足第二和第三个条件才是加分项.6.开源产品目前开源界比拟知名的结构化大数据存储是HBa

20、se和Cassandra , Cassandra是WideColumn模型NoSQL类别下排名Top-1的产品,在国外应用比拟广泛.但这里我们重点 提下HBase,由于在国内的话相比 Cassandra会更流行一点.HBase是基于HDFS勺存储计算别离架构的 WideColumn模型数据库,拥有非常好的扩展 性,能支撑大规模数据存储,它的优点为:(1) 存储计算别离架构:底层基于HDFS别离的架构可带来存储和计算各自弹性扩展的优势,与计算引擎例如 Spark可共享计算资源,降低本钱.(2) LSM存储引擎:为写入优化设计,能提供高吞吐的数据写入.(3) 开发者生态成熟,接入主流计算引擎:作为

21、开展多年的开源产品,在国内也有比拟 多的应用,开发者社区很成熟,对接几大主流的计算引擎.HBase有其突出的优点,但也有几大不可无视的缺陷:(1) 查询水平弱提供高效的单行随机查询以及范围扫描,复杂的组合条件查询必须使用Scan+Filter的方式,稍不注意就是全表扫描,效率极低.HBase的Phoenix提供了二级索引来优化查询,但和MySQL勺二级索引一样,只有符合最左匹配的查询条件才能做索引优化,可被优化的查询条件非常有限.(2) 数据派生水平弱前面章节提到 CD锻术是支撑数据派生体系的核心技术,HBase不具备CD破术.HBaseReplication 具备CDC勺水平,但是仅为 HB

22、ase内部主备间的数据同步机制.有一些开源组 件利用其内置Replication 水平来尝试扩展HBase的CD俄术,例如用于和Solr同步的Lily Indexer ,但是比拟可惜的是这类组件从理论和机制上分析就没法做到CDC术所要求的数据保序、最终一致性保证等核心需求.(3) 本钱高前面提到结构化大数据存储的关键需求之一是存储与计算的本钱别离,HBase的本钱取决于计算所需CPU核数本钱以及磁盘的存储本钱,基于固定配比物理资源的部署模式下CPU和存储永远会有一个无法降低的最小比例关系.即随着存储空间的增大,CPUK数本钱也会相应变大,而不是按实际所需计算资源来计算本钱.要到达完全的存储与计

23、算本钱别离,只有云上的Serverless 效劳模式才能做到.(4) 运维复杂HBase是标准的Hadoop组件,最核心依赖是 Zookeeper和HDFS没有专业的运维团队 几乎无法运维.(5) 热点处理水平差HBase的表的分区是 Range Partition的方式,相比 Hash Partition的模式最大的缺陷就是会存在严重的热点问题.HBase提供了大量的最正确实践文档来指引开发者在做表的Rowkey设计的时候防止热点,例如采用hash key,或者是salted-table的方式.但这两种方式下能保证数据的分散均匀,但是无法保证数据访问的热度均匀.访问热度取决于业务, 需要一种

24、能根据热度来对Region进行Split或Move等负载均衡的自动化机制.国内的高级玩家大多会基于HBase做二次开发,根本都是在做各种方案来弥补HBase查询水平弱的问题,根据自身业务查询特色研发自己的索引方案,例如自研二级索引方案、 对接Solr做全文索引或者是针对区分度小的数据集的bitmap索引方案等等.总的来说,HBase是一个优秀的开源产品,有很多优秀的设计思路值得借鉴.7. TablestoreTablestore 是阿里云自研的结构化大数据存储产品,具体产品介绍可以参考官网以及 权威指南.Tablestore 的设计理念很大程度上顾及了数据系统内对结构化大数据存储的需 求,并且

25、基于派生数据体系这个设计理念专门设计和实现了一些特色的功能.(1) 设计理念Tablestore 的设计理念一方面吸收了优秀开源产品的设计思路,另一方面也是结合实 际业务需求演化出了一些特色设计方向,简单概括下Tablestore 的技术理念:存储计算别离架构:采用存储计算别离架构,底层基于飞天盘古分布式文件系统,这是实现存储计算本钱别离的根底.LSM存储引擎:LSM和B+tree是主流的两个存储引擎实现,其中LSM专为高吞吐数据写入优化,也能更好的支持数据冷热分层.Serverless 产品形态:基于存储计算别离架构来实现本钱别离的最关键因素是 Serverless效劳化,只有Serverl

26、ess效劳才能做到存储计算本钱别离.大数据系统下,结 构化大数据存储通常会需要定期的大规模数据导入,来自在线数据库或者是来自离线计算引擎,在此时需要有足够的计算水平能接纳高吞吐的写入,而平时可能仅需要比拟小的计算能力,计算资源要足够的弹性.另外在派生数据体系下,主存储和辅存储通常是异构引擎,在 读写水平上均有差异,有些场景下需要灵活调整主辅存储的配比,此时也需要存储和计算资源弹性可调.多元化索引,提供丰富的查询水平:LSM引擎特性决定了查询水平的短板,需要索引来优化查询.而不同的查询场景需要不同类型的索引,所以 Tablestore 提供多元化的索引来 满足不同类型场景下的数据查询需求.CDC

27、技术:Tablestore 的CDC技术名为Tunnel Service ,支持全量和增量的实时数据 订阅,并且能无缝对接Flink流计算引擎来实现表内数据的实时流计算.拥抱开源计算生态:除了比拟好的支持阿里云自研计算引擎如MaxCompute和Data LakeAnalytics 的计算对接,也能支持 Flink和Spark这两个主流计算引擎的计算需求,无需数 据搬迁.流批计算一体:能支持Spark对表内全量数据进行批计算,也能通过CD锻术对接Flink来对表内新增数据进行流计算,真正实现批流计算结合.(2) 特色功能多元化索引Tablestore 提供多种索引类型可选择,包含全局二级索引和多元索引.全局二级索引 类似于传统关系数据库的二级索引,能为满足最左匹配原那么的条件查询做优化,提供低本钱存储和高效的随机查询和范围扫描.多元索引能提供更丰富的查询功能,包含任意列的组合条件查询、全文搜索和空间

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论