精华内容
下载资源
问答
  • 技术分享:数据冷热分离
    2020-12-19 11:41:06

    随着业务的发展,数据库增长的很快。老板不明白其中道理,但作为数据库的维护者,却看的胆颤心惊。

    终于,数据库慢慢的接近数瓶颈点,管理员也越来越焦虑。

    使用分区表吧,不行。就如上面所说,有些挖祖坟的请求,会加载一些很久之前的数据,分区表并不能解决问题。

    明显要对数据进行一下切割,进行冷热分离了。

    大体的结构如上图。我们有一个数据路由,负责根据时间维度区分数据,定位到相应的数据库中进行查询。

    热库和冷库,可能是异构的。

    解决思路

    问题已经进行了转化。我们接下来的目标,变成了怎么根据时间维度,构建热数据和冷数据的分离。

    目前使用最多的数据库是mysql,我们也从它说起。

    其实,冷热分离的两份数据,查询“最近时间”的数据,是没什么差别的。唯一不同的是,热库,会定时的删除旧的数据。

    双写

    双写是最简单,但是又最不靠谱的方案。结构如下图。

    但是注意,操作步骤1、2,涉及到分布式事务,需要同时保证两个库的写入成功。

    这就让事情变的麻烦了一些。作为一个吃过无数次事务问题的亏的人,不会重蹈这样的覆辙。

    所以,这种方案,直接pass。

    走消息

    细心的同学应该发现了上图的优化点,通过引入一个叫做消息队列的东西,就可以把分布式事务这座大山给绕过去,只保证最终一致性即可。

    多么美好的设想。理想很丰满,现实很骨感。由于冷热分离涉及到非常多的数据表,需要修改不可预知的业务代码,遭到了大家的一致反对。

    此方案无疾而终。

    直接看图,变了两根线而已。

    使用binlog

    有的同学可能已经憋不住了:为什么不用binlog?接下来我们就谈下这种方案。

    不可否认,这是种非常优雅的方式。数据只需要写入热库就可以了,通过数据订阅的方式,增量的将数据写入到冷库。

    但是等等。我们的定时任务,删除数据的时候,同样也要产生binlog。如何区别数据的删除,是定时任务产生的,还是正常的业务产生?

    还好,xjjdog知晓一个非常隐秘的方式去操作。

    对对对,就是下面的过程。

    set

    session sql_log_bin=0;//optset session sql_log_bin=1;

    binlog可以设置session级别的,也就是在此session中操作的语句,并不会产生binlog。

    这样,我们在定时任务执行时,先关闭binlog,然后,执行删除语句,然后,重新恢复binlog。这些删除的数据,就不会通过canal同步到冷库中了。

    万万没想到

    mmp?

    为什么不支持呢?为什么呢?容我小心翼翼的猜想一下。你的rds啊,有可能在和别人在共用一个实例呢。

    其实,除了rds的限制,此方案还存在一个bug。比如热库有冷热分离的时候。想想为甚么吧。

    标记清除

    得了,xjjdog只能曲线救国了。用最2的方式完成这个操蛋的功能。

    标记清除。这四个醒目的大字,让人不由自主的想到jvm的垃圾回收算法。

    原理其实也类似,步骤也是一分为二。

    第一、标记阶段

    给每一张数据表,都加一个叫做mark2Del字段。然后,通过定时,标记所有要过期(也就是要放入冷库的数据)。

    第二、清除阶段

    在下一次定时来临时,将上次标记要删除的数据,逐条搬迁到冷库。搬迁完毕后,进行下一轮标记。

    此方案非常简单,但有个致命弱点。由于所有的库表,都是老表,都需要增加一个叫做mark2Del的字段,甚是麻烦。

    然而,上面的介绍,只是解决了数据的删除,并没有解决数据的同步。

    最终方案

    结合以上的描述,以及环境的限制。我们选择了使用binlog+标记清除的方式。

    标记清除负责删除数据。

    binlog负责增量同步数据。只是,在这个同步逻辑中,多了一个判断,如果mark2Del的值被设置成了true,则忽略此binlog。

    也就是说,我们强行给每条删除的记录,追加了一个判断标志。

    这样,系统终于跑起来了。

    End

    上文描述的,是mysql到mysql之间的冷热分离。

    但如果,我想要做一个分层的数据仓库。

    第一层,是热库。

    第二层,是冷库。

    第三层,是存档库,可能是druid这种大数据存储。

    该如何设计?

    本文不做过多介绍。架构的难点不在结果,而在于过程。

    你看起来很挫的方案,总有它背后的故事,尝试着去理解,大有裨益。

    除非它是真的挫。不过,这不也是你的机会么?

    更多相关内容
  • HBase冷热分离方案.pdf

    2019-08-29 04:02:54
    HBase冷热分离方案.pdf
  • 数据库优化整理之:冷热分离

    千次阅读 2021-01-13 10:52:43
    一、 引言 工作中,随着数据库表数据量的增大,我们会发现,对表数据的读写操作会变得越来越慢,有时候查询一条数据会耗费几十秒或几分钟才查出结果,甚至...为了更好的理解冷热分离的概念,我们先了解下什么时候热数据

    一、 引言

    工作中,随着数据库表数据量的增大,我们会发现,对表数据的读写操作会变得越来越慢,有时候查询一条数据会耗费几十秒或几分钟才查出结果,甚至多点击几次查询还会出现宕机。

    这个时候,我们可能首先会想到通过对表结构、业务代码、索引、SQL语句等方面进行优化,以此来提高读写操作响应速度。然而,对于表数据量相对较大的情况,我们发现优化效果有限,并未达到预期效果。

    此时,我们可以考虑是否可以通冷热分离来提升读写、查询效率。


    二、 什么是冷热分离?

    为了更好的理解冷热分离的概念,我们先了解下什么是热数据,什么是冷数据。

    热数据
    热数据指的是需要即时对用户进行分发的数据,即从数据源抓取之后经过数据处理,需要即时存储到可快速分发的存储介质供API或直接面向用户的系统使用。
    热数据需要重点保障服务质量和稳定性,为了保证数据的时效性,在数据处理上也是优先级高的数据。


    冷数据
    冷数据指的是不需要即时发给用户的数据。
    这些数不会原样分发给用户,它们需要经过长期的积累,使我们可以从中得到基于此更高层次的分析。


    冷热分离
    冷热分离指的是在处理数据时将数据库分为冷库和热库,冷库指用于存放走到了终态的数据(冷数据)的数据库,热库用于存放还需要修改的数据(热数据)的数据库。


    三、 什么情况下使用冷热分离?

    从冷热分离的定义我们可以知道当业务需求涉及到冷热数据,表数据量增长速度快或数据量较大时, 我们就该考虑是否使用冷热分离解决方案了。比如:
    1)数据走到终态后,只有读没有写的需求。
    2)用户能够接受新旧数据分开实现业务,比如查询新旧数据的时候分开操作。


    四、 冷热分离实现思路

    在这里插入图片描述


    4.1 如何判断一个数据到底是冷数据还是热数据?

    一个数据是冷数据还是热数据,需要根据实际的业务需求来制定判定条件。满足热数据条件的归为热数据,满足冷数据条件的归为冷数据。

    判定条件可以是表里的1个字段或多个字段组合的方式组成。
    时间、状态等都是比较适合用作判定条件的字段。

    比如,我们管理一个订单系统,针对订单主表,我们可以使用下面两种方式作为冷热数据的界定:

    • 方式1:使用“下单时间”字段作为判定条件,3个月内的订单数据作为热数据,3个月前的订单数据作为冷数据。
    • 方式2:使用“完结状态”字段作为判定条件,未完结的订单作为热数据,已完结的订单作为冷数据。

    关于判断冷热数据的逻辑,这里还有 2 个注意要点必须说明:
    1)如果一个数据被标识为冷数据,业务代码不会再对它进行写操作;
    2)不会同时存在读冷/热数据的需求。


    4.2 如何触发冷热数据分离?

    一般来说,冷热数据分离的触发实现有3种方式:业务层代码实现、binlog实现、定时扫描数据库实现

    (一)业务层代码实现
    在代码中实现,当有对数据进行写操作时,触发冷热分离。
    建议使用场景:业务代码比较简单,并且不按照时间区分冷热数据时使用。
    在这里插入图片描述


    (二)binlog实现
    监听数据库变更日志binlog的方式来触发。
    建议使用场景:业务代码比较复杂,不敢随意变更,并且不按照时间区分冷热数据时使用。
    在这里插入图片描述

    实际使用binlog方式实现过程中,我们可能会遇到以下问题:

    问题描述:
    定时任务删除数据时,也会产生binlog,如何区别数据的删除是定时任务产生的,还是正常的业务?

    解决方案:
    我们可以通过设置binlog的session级别,也就是在此session中操作的语句,并不会产生binlog。

    set session sql_log_bin=0;//optset session sql_log_bin=1;
    

    我们在定时任务执行时,先关闭binlog,然后,执行删除语句,然后,重新恢复binlog。这些删除的数据,就不会通过canal同步到冷库中了。


    (三)定时扫描数据库实现
    通过定时扫描数据库的方式来触发。
    建议使用场景:在按照时间区分冷热数据时使用。
    在这里插入图片描述


    3种触发方式的优缺点比较
    在这里插入图片描述


    4.3 如何实现冷热数据分离?
    冷热数据分离示意图如下:
    在这里插入图片描述
    上述分离逻辑看起来比较简单,不过在实际方案实施的时候,我们需要考虑以下情况:

    (1)一致性:同时修改多个数据库,如何保证数据的一致性?

    情形描述:一致性要求指的是,当分离过程中如何保证任何一步出错后数据还是一致的。
    解决方法:保证每一步都可以重试,并且操作都有幂等性。

    具体逻辑分4步:

    • 在热数据库中,给要搬的数据加个标识: ColdFlag=WaittingForMove。(实际处理中标识字段的值用数字即可)
    • 找出所有待搬的数据(ColdFlag=WaittingForMove):这步是为了确保前面有些线程因为部分原因失败,出现有些待搬的数据没有搬的情况。
    • 在冷数据库中保存一份数据,但在保存逻辑中需加个判断以此保证幂等性(这里需要用事务包围起来),通俗点说就是假如我们保存的数据在冷数据库已经存在了,也要确保这个逻辑可以继续进行。
    • 从热数据库中删除对应的数据。


    (2)数据量:假设数据量大,一次性处理不完,该怎么办?是否需要使用批量处理?

    情形描述:定时扫描的逻辑需要考虑数据量问题。
    解决方法:在搬数据的地方增加批量逻辑。

    如:假设我们每次可以搬50条数据
    a. 在热数据库中给要搬的数据加个标识:ColdFlag=WaittingForMove;
    b. 找出前 50 条待搬的数据(ColdFlag=WaittingForMove);
    c. 在冷数据库中保存一份数据;
    d. 从热数据库中删除对应的数据;
    e. 循环执行 b。


    (3)并发性:假设数据量大到要分到多个地方并行处理,该怎么办?

    情形描述:数据量过大,以致单线程无法处理时,我们使用多线程需要考虑哪些问题。

    step1:如何启动多线程?

    • 方式1:采用的是定时器触发逻辑,设置多个定时器,并让每个定时器之间的间隔短一些,然后每次定时启动一个线程就开始搬运数据。

    • 方式2:自建一个线程池,然后定时触发后面的操作:先计算待搬动的热数据的数量,再计算要同时启动的线程数,如果大于线程池的数量就取线程池的线程数,假设这个数量为 N,最后循环 N 次启动线程池的线程搬运冷热数据。

    step2:某线程宣布某个数据正在操作,其他线程不要动(锁)

    • 获取锁的原子性: 当一个线程发现某个待处理的数据没有加锁,然后给它加锁,这 2 步操作必须是原子性的,即要么一起成功,要么一起失败。实际操作为先在表中加上 LockThread 和 LockTime 两个字段,然后通过一条 SQL 语句找出待迁移的未加锁或锁超时的数据,再更新 LockThread=当前线程,LockTime=当前时间,最后利用 MySQL 的更新锁机制实现原子性。
    • 获取锁必须与开始处理保证一致性: 当前线程开始处理这条数据时,需要再次检查下操作的数据是否由当前线程锁定成功,实际操作为再次查询一下 LockThread= 当前线程的数据,再处理查询出来的数据。
    • 释放锁必须与处理完成保证一致性: 当前线程处理完数据后,必须保证锁释放出去。

    step3:如果出现某线程正常处理完后,数据不在热库,直接跑到了冷库,这是正常的,无需处理。

    step4:某线程失败退出了,结果锁没释放怎么办(锁超时)?
    分两种情况处理:

    • 如果锁定这个数据的线程异常退出了且来不及释放锁,导致其他线程无法处理这个数据:解决方案为给锁设置一个超时时间,如果锁超时了还未释放,其他线程可正常处理该数据。
    • 如果正在处理的线程并未退出,因还在处理数据导致了超时:解决方案为尽量给超时的时间设置成超过处理数据的合理时间,且处理冷热数据的代码里必须保证是幂等性的。

    考虑到前面逻辑比较复杂,这里我们特地画了一个分离的流程图,如下图所示:
    在这里插入图片描述


    4.4 如何使用冷热数据?
    如何使用冷热数据,需要根据实际业务需求来定。
    比如我们要查询未完结订单,这个时候使用的就是热库中的数据。
    在这里插入图片描述

    需要注意的是:
    在判断数据是冷数据还是热数据时,必须确保用户不允许同时有读冷热数据的需求。


    五、 冷热分离整体方案及不足


    5.1 冷热分离整体方案
    在这里插入图片描述


    5.2 冷热分离解决方案的不足

    冷热分离确实可以在某种程度上解决写读写数据慢的问题,但是仍然存在诸多不足。具体表现有:
    1)用户查询冷数据速度依旧很慢。
    2)由于冷数据多到一定程度,业务就无法再修改冷数据,因为数据量太大系统承受不住。

    展开全文
  • 云上HBase冷热分离实践.pdf.pdf
  • 数据冷热分离技术

    千次阅读 2020-08-13 22:11:26
    结束语 本文探讨了大数据冷热分离的诸多解决方案,随着云计算的发展,应该会有越来越多的系统走向“冷热分离同构系统”的方案,从而简化整体的复杂性,在业务层表现为统一的访问方式。但是,异构系统中的冷数据系统...

    来源:https://blog.csdn.net/zwgdft/article/details/106291463

    作者:Bruce

    前言

    对于一个软件系统,无论其业务逻辑复杂到何种程度,最终都将体现到一条(批)数据的CRUD操作上,即创建、查询、更新与删除。正如人类面临生死的轮回,数据亦是如此。一条数据从被创建出来开始,随着时间的逝去,其价值逐渐变小,最终被删除。尽管在有些场景下,我们对客户承诺其数据会被永久保存,但这也是相对而言的。

    数据的存在价值,在于其被使用的程度,即被查询或更新的频率。在不同的业务系统中,人们对处于不同时期的数据有着不同的使用需求。比如,在网络流量行为分析系统中,客户会对最近一个月公司发生的安全事件和网络访问情况感兴趣,而很少关注几个月前的数据;在电商订单系统中,用户会经常访问最近三个月的订单,而更久远的数据则几乎不会去看。针对这样一些业务场景,我们将数据按照时间划分为三个阶段:Hot、Warm、Cold。Hot和Cold的特性分别如下所示,而Warm处于二者之间,通常会被合并到Hot或Cold中,从而减少系统的复杂度,本文也不准备将其单独拿出来讨论。

    • Hot(热数据)

      • 被频繁查询或更新

      • 对访问的响应时间要求很高,通常在10毫秒以内

    • Cold(冷数据)

      • 不允许更新,偶尔被查询

      • 对访问的响应时间要求不高,通常在1~10秒内都可以接受

    区分冷热数据的根本目的,在于控制成本。为什么这么说?因为通常情况下,为了支持热数据的操作特性,需要有较好的硬件配置,比如高性能CPU、大内存、SSD硬盘等等。随着时间的推移,系统里会积累越来越多的历史数据,如果依然采用高配置机器来存放这些使用频率非常低的数据,势必会带来非常高的成本。当然,如果数据量很小或者不计成本,那完全不需要考虑冷热区分,采用一个单体系统就可以应对所有事情了,比如MySQL。

    目前比较常见的冷热分离方案是将冷热数据分离到两套不同的系统,这两套系统拥有不同的存储特性、访问方式等,从而在保证热数据访问性能的同时,将冷数据的成本降低下来。而随着冷热分离方案的普及,很多框架也开始考虑类似的事情,尝试在自己的体系下支持将数据进行冷热分离,避免两套系统带来的复杂性。我们姑且将这两种方案分别称为“冷热分离异构系统”和“冷热分离同构系统”,本文将分别介绍几个相关的具体案例。

    冷热分离异构系统

    相比单体系统而言,将冷热数据分离到两个系统中,必然会带来整体的复杂性,需要在性能、成本、复杂度等因素之间做的一个权衡。实践中,通常需要结合具体的业务,考虑下面几件事:

    • 冷热数据系统的选型

    • 确定冷热数据分割线

    • 如何进行数据的迁移

    • 如何应对跨系统的查询

    在系统选型上,对于热数据系统,需要重点考虑读写的性能问题,诸如MySQL、Elasticsearch等会成为首选;而对于冷数据系统,则需要重点关注低成本存储问题,通常会选择存储在HDFS或云对象存储(比如AWS S3)中,再选择一个相应的查询系统。冷热数据是按照时间推移来区分的,因此必然要敲定一个时间分割线,即多久以内的数据为热数据,这个值通常会结合业务与历史访问情况来综合考量。对于超过时间线的数据,会被迁移到冷数据中,迁移过程需要确保两点:不能对热数据系统产生性能影响、不能影响数据查询。数据分离后,不可避免的会出现某个查询在时间上跨到两个系统里面,需要进行查询结果的合并,对于统计类查询就可能会出现一定的误差,需要在业务层面有所妥协。

    这里介绍两个冷热分离的实践方案,供大家参考。

    网络行为数据分析系统

    业务背景是,我们有很多UTM产品部署在用户的网络边界,对进出的网络数据进行扫描,扫描结果会上传到服务端进行处理、存储,从而提供统计分析查询功能,用户通过产品管理界面可以查看最近6个月的网络行为分析数据、定制日/周/月报表。

    在该系统中,我们需要为所有用户保留6个月的数据,而根据我们的统计分析,90%以上的请求访问的是最近1个月的数据,因此采用热数据系统保留35天数据,其他的迁移到冷数据系统中存储。为了配合数据挖掘相关功能,目前冷数据保留2年。该系统的数据是只读的,且对外主要提供统计类查询,因此热数据采用Elasticsearch来存储,利用其聚合分析能力提供高性能查询。冷数据以Parquet的格式保存在AWS S3上,通过AWS Athena实现查询。AWS Athena是一款基于Presto的托管数据查询系统,根据查询时所扫描的数据量来收费,不查询不收费,采用该系统可以充分利用云服务的优势,避免自己维护一套冷数据查询系统。

    数据实时上传到服务端后,会进入数据流中,通过Spark Streaming程序处理后写入到Elasticsearch,提供近实时数据查询。与此同时,实时数据也会备份到AWS S3。每天夜里,会启动一个Spark程序,加载前一天的备份数据进行处理并写入AWS S3,作为冷数据存储。该系统中,Elasticsearch中的Index按天分割,每天冷数据生成后会将冷热分割线往前推移,并删除热数据中对应的Index。

    电商交易订单系统

    业务背景是,用户在系统下单后会生成相应的交易订单信息,每天会产生大量的订单数据。这些数据需要永久保存,随时面对用户的低延迟查询,通常近3个月的订单是用户查询的主要对象。

    在该系统中,热数据毫无疑问会采用MySQL(InnoDB)来实现,满足事务操作和高效查询的需求。当然,在查询系统前面还会有一层缓存,这里略过。冷数据以宽表的形式存储到HBase中,并采用Elasticsearch来提供相关的索引查询,配合HBase的数据查询。热数据在MySQL中保留90天,之后迁移到HBase中作为冷数据永久保存。

    对于一个交易请求,会先在MySQL的订单表中创建订单记录,这些操作会通过BinLog同步到Kafka中,由Spark Streaming程序从Kafka中将相关订单信息变动提取出来,做相应的关联处理后写入到HBase中,同时更新Elasticsearch中的索引信息。每天定期将冷热分割线往前推移,并删除热数据中对应时间的订单表。

    冷热分离同构系统

    正如前文所述,冷热分离异构系统会带来整体的复杂性,主要表现在:需要维护两套系统,在业务逻辑中需要显式知道从哪里查询数据,甚至查询语法都不一样。很多开源框架在看到这一痛点后,开始在自己的体系下引入冷热分离的特性,试图以透明、统一的方式来应对冷热分离的需求。这里以Elasticsearch为例,来探讨下业界在冷热分离同构系统的诸多方案。

    从Elasticsearch 5.0开始,便支持在一个集群中存放冷热数据,其核心思路是:在集群中放入不同配置的机器,将其打上不同的属性,比如下图中的Node 1/2/3便是高配置机器,用于存放热数据,属性为Hot,Node 4/5是低配置机器,用于存放冷数据,属性为Cold;当创建一个新的Index时,指定其数据分配到Hot属性的机器上;一段时间后,再将其配置修改为分配到Cold属性机器上,Elasticsearch便会自动完成数据迁移。

    Elasticsearch 6.6之后,X-Pack中引入了Index Lifecycle Management机制,进一步简化了上述操作,我们不再需要自己定期去发送API做数据迁移了,只需要在Policy中设定Hot、Cold的生命周期即可,Elasticsearch会自动完成一切。

    除了Elasticsearch官方作出的努力,各大云厂商也在积极往这方面发展。众所周知,随着云计算的发展,未来最便宜的数据存储方式是存储到云对象存储中,比如AWS S3。AWS在re:Invent 2019中发布了针对其Elasticsearch Service的UltraWarm机制,便是在推出冷热分离的解决方案。其基本思想跟上述相似,只是作为云服务,不再需要配置相应的机器属性,而是在创建集群时选择相应的UltraWarm机器,这类机器的数据存储在S3中。由业务自己决定何时需要将哪些Index转为冷数据,通过API发送相关请求到Elasticsearch即可。

    结束语

    本文探讨了大数据冷热分离的诸多解决方案,随着云计算的发展,应该会有越来越多的系统走向“冷热分离同构系统”的方案,从而简化整体的复杂性,在业务层表现为统一的访问方式。但是,异构系统中的冷数据系统还是会以另一种形式存在,毕竟我们需要将更多的历史数据沉淀到HDFS/S3这样的廉价存储系统中,为数据分析与挖掘提供弹药。

    展开全文
  • 本文探讨了大数据冷热分离的诸多解决方案,包括冷热分离异构系统、冷热分离同构系统。

    前言

    对于一个软件系统,无论其业务逻辑复杂到何种程度,最终都将体现到一条(批)数据的CRUD操作上,即创建、查询、更新与删除。正如人类面临生死的轮回,数据亦是如此。一条数据从被创建出来开始,随着时间的逝去,其价值逐渐变小,最终被删除。尽管在有些场景下,我们对客户承诺其数据会被永久保存,但这也是相对而言的。

    数据的存在价值,在于其被使用的程度,即被查询或更新的频率。在不同的业务系统中,人们对处于不同时期的数据有着不同的使用需求。比如,在网络流量行为分析系统中,客户会对最近一个月公司发生的安全事件和网络访问情况感兴趣,而很少关注几个月前的数据;在电商订单系统中,用户会经常访问最近三个月的订单,而更久远的数据则几乎不会去看。针对这样一些业务场景,我们将数据按照时间划分为三个阶段:Hot、Warm、Cold。Hot和Cold的特性分别如下所示,而Warm处于二者之间,通常会被合并到Hot或Cold中,从而减少系统的复杂度,本文也不准备将其单独拿出来讨论。

    • Hot(热数据)
      • 被频繁查询或更新
      • 对访问的响应时间要求很高,通常在10毫秒以内
    • Cold(冷数据)
      • 不允许更新,偶尔被查询
      • 对访问的响应时间要求不高,通常在1~10秒内都可以接受

    区分冷热数据的根本目的,在于控制成本。为什么这么说?因为通常情况下,为了支持热数据的操作特性,需要有较好的硬件配置,比如高性能CPU、大内存、SSD硬盘等等。随着时间的推移,系统里会积累越来越多的历史数据,如果依然采用高配置机器来存放这些使用频率非常低的数据,势必会带来非常高的成本。当然,如果数据量很小或者不计成本,那完全不需要考虑冷热区分,采用一个单体系统就可以应对所有事情了,比如MySQL。

    目前比较常见的冷热分离方案是将冷热数据分离到两套不同的系统,这两套系统拥有不同的存储特性、访问方式等,从而在保证热数据访问性能的同时,将冷数据的成本降低下来。而随着冷热分离方案的普及,很多框架也开始考虑类似的事情,尝试在自己的体系下支持将数据进行冷热分离,避免两套系统带来的复杂性。我们姑且将这两种方案分别称为“冷热分离异构系统”和“冷热分离同构系统”,本文将分别介绍几个相关的具体案例。

    冷热分离异构系统

    相比单体系统而言,将冷热数据分离到两个系统中,必然会带来整体的复杂性,需要在性能、成本、复杂度等因素之间做的一个权衡。实践中,通常需要结合具体的业务,考虑下面几件事:

    • 冷热数据系统的选型
    • 确定冷热数据分割线
    • 如何进行数据的迁移
    • 如何应对跨系统的查询

    在系统选型上,对于热数据系统,需要重点考虑读写的性能问题,诸如MySQL、Elasticsearch等会成为首选;而对于冷数据系统,则需要重点关注低成本存储问题,通常会选择存储在HDFS或云对象存储(比如AWS S3)中,再选择一个相应的查询系统。冷热数据是按照时间推移来区分的,因此必然要敲定一个时间分割线,即多久以内的数据为热数据,这个值通常会结合业务与历史访问情况来综合考量。对于超过时间线的数据,会被迁移到冷数据中,迁移过程需要确保两点:不能对热数据系统产生性能影响、不能影响数据查询。数据分离后,不可避免的会出现某个查询在时间上跨到两个系统里面,需要进行查询结果的合并,对于统计类查询就可能会出现一定的误差,需要在业务层面有所妥协。

    这里介绍两个冷热分离的实践方案,供大家参考。

    网络行为数据分析系统

    业务背景是,我们有很多UTM产品部署在用户的网络边界,对进出的网络数据进行扫描,扫描结果会上传到服务端进行处理、存储,从而提供统计分析查询功能,用户通过产品管理界面可以查看最近6个月的网络行为分析数据、定制日/周/月报表。

    在该系统中,我们需要为所有用户保留6个月的数据,而根据我们的统计分析,90%以上的请求访问的是最近1个月的数据,因此采用热数据系统保留35天数据,其他的迁移到冷数据系统中存储。为了配合数据挖掘相关功能,目前冷数据保留2年。该系统的数据是只读的,且对外主要提供统计类查询,因此热数据采用Elasticsearch来存储,利用其聚合分析能力提供高性能查询。冷数据以Parquet的格式保存在AWS S3上,通过AWS Athena实现查询。AWS Athena是一款基于Presto的托管数据查询系统,根据查询时所扫描的数据量来收费,不查询不收费,采用该系统可以充分利用云服务的优势,避免自己维护一套冷数据查询系统。

    数据实时上传到服务端后,会进入数据流中,通过Spark Streaming程序处理后写入到Elasticsearch,提供近实时数据查询。与此同时,实时数据也会备份到AWS S3。每天夜里,会启动一个Spark程序,加载前一天的备份数据进行处理并写入AWS S3,作为冷数据存储。该系统中,Elasticsearch中的Index按天分割,每天冷数据生成后会将冷热分割线往前推移,并删除热数据中对应的Index。

    电商交易订单系统

    业务背景是,用户在系统下单后会生成相应的交易订单信息,每天会产生大量的订单数据。这些数据需要永久保存,随时面对用户的低延迟查询,通常近3个月的订单是用户查询的主要对象。

    在该系统中,热数据毫无疑问会采用MySQL(InnoDB)来实现,满足事务操作和高效查询的需求。当然,在查询系统前面还会有一层缓存,这里略过。冷数据以宽表的形式存储到HBase中,并采用Elasticsearch来提供相关的索引查询,配合HBase的数据查询。热数据在MySQL中保留90天,之后迁移到HBase中作为冷数据永久保存。

    对于一个交易请求,会先在MySQL的订单表中创建订单记录,这些操作会通过BinLog同步到Kafka中,由Spark Streaming程序从Kafka中将相关订单信息变动提取出来,做相应的关联处理后写入到HBase中,同时更新Elasticsearch中的索引信息。每天定期将冷热分割线往前推移,并删除热数据中对应时间的订单表。

    冷热分离同构系统

    正如前文所述,冷热分离异构系统会带来整体的复杂性,主要表现在:需要维护两套系统,在业务逻辑中需要显式知道从哪里查询数据,甚至查询语法都不一样。很多开源框架在看到这一痛点后,开始在自己的体系下引入冷热分离的特性,试图以透明、统一的方式来应对冷热分离的需求。这里以Elasticsearch为例,来探讨下业界在冷热分离同构系统的诸多方案。

    从Elasticsearch 5.0开始,便支持在一个集群中存放冷热数据,其核心思路是:在集群中放入不同配置的机器,将其打上不同的属性,比如下图中的Node 1/2/3便是高配置机器,用于存放热数据,属性为Hot,Node 4/5是低配置机器,用于存放冷数据,属性为Cold;当创建一个新的Index时,指定其数据分配到Hot属性的机器上;一段时间后,再将其配置修改为分配到Cold属性机器上,Elasticsearch便会自动完成数据迁移。

    Elasticsearch 6.6之后,X-Pack中引入了Index Lifecycle Management机制,进一步简化了上述操作,我们不再需要自己定期去发送API做数据迁移了,只需要在Policy中设定Hot、Cold的生命周期即可,Elasticsearch会自动完成一切。

    除了Elasticsearch官方作出的努力,各大云厂商也在积极往这方面发展。众所周知,随着云计算的发展,未来最便宜的数据存储方式是存储到云对象存储中,比如AWS S3。AWS在re:Invent 2019中发布了针对其Elasticsearch Service的UltraWarm机制,便是在推出冷热分离的解决方案。其基本思想跟上述相似,只是作为云服务,不再需要配置相应的机器属性,而是在创建集群时选择相应的UltraWarm机器,这类机器的数据存储在S3中。由业务自己决定何时需要将哪些Index转为冷数据,通过API发送相关请求到Elasticsearch即可。

    结束语

    本文探讨了大数据冷热分离的诸多解决方案,随着云计算的发展,应该会有越来越多的系统走向“冷热分离同构系统”的方案,从而简化整体的复杂性,在业务层表现为统一的访问方式。但是,异构系统中的冷数据系统还是会以另一种形式存在,毕竟我们需要将更多的历史数据沉淀到HDFS/S3这样的廉价存储系统中,为数据分析与挖掘提供弹药。



    (全文完,本文地址:https://bruce.blog.csdn.net/article/details/106291463

    版权声明:本人拒绝不规范转载,所有转载需征得本人同意,并且不得更改文字与图片内容。大家相互尊重,谢谢!

    Bruce
    2020/06/14 下午

    展开全文
  • 数据架构:概念与冷热分离 公众号:程序员架构进阶 一 概述 上一篇文章数据架构:概念与冷热分离中介绍了数据架构的概念和意义。并抛出了数据冷热分离的问题。事实上,这并不是新的概念,各公司在很早之前就...
  • 对于开发人员而言即数据的冷热分离,实现此功能有2个前提条件:硬件:处理速度不同的硬件,最起码有读写速度不同的硬盘,如SSD、机械硬盘HDD。软件配置:可以配置 不同的数据存储在不同的硬盘,如近期数据存储在SSD...
  • 本文主要介绍ElasticSearch冷热分离架构以及实现。 冷热分离架构介绍 冷热分离是目前ES非常火的一个架构,它充分的利用的集群机器的优劣来实现资源的调度分配。ES集群的索引写入及查询速度主要依赖于磁盘的IO速度,...
  • 4.3.2 冷热分离好处 通过合理的冷热分离设计,可以达到的好处: 降低单表数据量,提升单表性能; 大量业务冷数据转冷存,存储成本可以降低很多,至少 50%+。 五 冷热分离方案 需要考虑的包括存储方案、数据迁移...
  • 对于冷热数据分层存储的最直接的目的就是节省成本,计算机结构里,内存->nvme ssd->ssd->机械盘,访问速度依次降低,单位成本依次降低,存储密度依次增大。对于像redis这种天生为高速大并发设计的高性能...
  • ES 集群数据冷热分离

    2021-07-30 00:15:56
    点击关注公众号,回复“1024”获取2TB学习资源!冷热数据分离的目的1、ES集群异构,机器硬件资源配置不一,有高性能CPU和SSD存储集群,也有大容量的机械磁盘集群,比如我们的场景就是存...
  • Elasticsearch冷热分离原理和实践

    千次阅读 2020-03-26 14:31:15
    warm 启动集群,冷热分离的Elasticsearch集群即搭建完成 购买云ES服务 腾讯云预计于12月中旬上线冷热分离集群,用户只需要在创建页面上根据需要即可分钟级拉起一个冷热分离架构的ES集群,方便快速,扩展性好,运维...
  • 冷热分离:表数据量大读写缓慢如何优化? 业务场景 我曾经做过供应链相关的架构优化,当时我们平台有一个订单功能,里面的主表有几千万的数据量,加上关联表,数据量达到上亿。 这么庞大的数据量,让平台的查询...
  • 本文介绍在Elasticsearch集群上,通过生命周期管理ILM(Index Lifecycle Management)功能,实现冷热数据分离的实践流程。通过本实践,您既可以实现在保证集群读写性能的基础上,自动维护集群上的冷热数据,又能通过...
  • 在es中经常按日或按月建立索引,我们很容易想到,历史索引被查询命中的概率越来越低,不应该占用高性能的机器资源(比如大内存,SSD),可以将其迁移到低配置的机器上,从而实现冷热数据分离存储。分片分配规则...
  • 用户能接受新旧数据分开查询,比如有些电商网站默认只让查询 3 个月内的订单,如果你要查询 3 个月前的订单,还需要访问另外的单独页面 冷热分离实现思路 在实际操作过程中,冷热分离整体实现思路如下 (一)如何...
  • 17 MySQL是如何基于冷热数据分离的方案,来优化LRU算法的.pdf
  • HBase冷热分离方案.zip

    2021-10-05 22:41:35
    HBase冷热分离方案.zip
  • HBase冷热分离技术方案.pdf
  • es冷热分离

    2019-07-02 23:42:04
    系统拓扑设计(冷热分离) master节点 discovery.zen.minimum_master_nodes:N/2+1(防止脑裂) node.data:false hot节点 node.attr.box_type:hot node.data:true cool节点 node.attr....
  • 今天讨论的内容是冷热分离,也许概念并不陌生,对其使用场景也比较熟悉,但涉及锁的内容时仍然需要认真思考,这部分内容在我们实际开发中的“坑”还是不少的。 业务场景一 曾经经历过供应链相关的架构优化,当时...
  • 常见的方案就是通过冷热分离来治理数据。冷数据可以用更高的压缩比算法(ZSTD),更低副本数算法(Erasure Coding),更便宜存储设备(HDD,高密集型存储机型)。1、HBase冷热分离常见解决方案1.主备集群备(冷)集群用更...
  • 基于冷热分离的LRU链表MySQL中设计LRU链表,是将冷热数据分离,链表分为两部分,一部分是冷数据,一部分是热数据,冷热数据占比由配置项innodb_old_blocks_pct控制,默认为37,即37%是冷数据在运行期间,数据页被...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,021
精华内容 3,208
关键字:

冷热分离