深圳网站建设找哪家,cent wordpress阿里云,苏州建站公司 诚找苏州聚尚网络,wordpress同步到qq空间新的冷热数据方案是在整合了存算分离模型的基础上建立的#xff0c;其核心思路是#xff1a;DORIS本地存储作为热数据的载体#xff0c;而外部集群#xff08;HDFS、S3等#xff09;作为冷数据的载体。数据在导入的过程中#xff0c;先作为热数据存在#xff0c;存储于B…新的冷热数据方案是在整合了存算分离模型的基础上建立的其核心思路是DORIS本地存储作为热数据的载体而外部集群HDFS、S3等作为冷数据的载体。数据在导入的过程中先作为热数据存在存储于BE节点的本地磁盘上。当数据需要转冷的时候为该热数据分片创建一个冷数据的副本分片然后将数据转储到冷数据指定的外部集群上当冷数据副本生成完毕后将热数据分片删除。
如下图所示当数据变为冷数据后BE本地将保留一个冷数据的元数据信息。当查询命中冷数据时BE将通过这个元数据信息将冷数据缓存到本地使用。 对于冷数据其使用的频率是很低的这样可以做到使用有限的BE节点来管理更多的数据成本将远远低于纯本地存储的方案。
冷热数据转换规则 StoragePolicy 由 FE 的 PolicyMgr 进行管理用来配置冷热数据的转换规则。该信息会随着心跳同步给每一个 BE(refreshStoragePolicy())BE 将以此作为数据进行冷热数据转换的依据。
根据用户的使用习惯以及数据的业务特性冷热数据转换规则可分为两类
第一类明确指定冷却时间点有些数据拥有时间特性前一年的数据在后一年就已经失去了时效性这种数据通过指定具体的时间来界定其转为冷数据的时间。
第二类根据活跃时间指定数据冷却时间有些数据有着固定的活跃时间比如用户行为数据每月生成的用户行为数据在当月是使用最频繁的而随着时间的推移这些数据的重要性逐步降低最终转为不活跃数据。这种情况下可以对数据指定活跃时间当数据活跃时间结束后该数据转为冷数据。
冷热数据的调度流程是从 TABLE 的冷热数据配置信息开始。在建表时指定所要使用的冷热数据规则名storage_policy映射为 StoragePolicy。 CREATE TABLE ( …… ) PROPERTIES ( storage_policy storage_policy_name1 ); 上面的配置可以为整个表指定冷热数据规则而大多数情况下我们的数据是拆分成多个PARTITION的每个PARTITION所需要的冷热数据规则有可能是不同的这时就需要针对PARTITION来进行配置 ALTER TABLE TblPxy01 ADD PARTITION p2 VALUES [(10000), (20000)) (remote_storage_policy testPolicy); 配置中的 storage_policy 信息存放在 PARTITION 的每个TABLET中当创建及修改TABLET时storage_policy 信息随着TABLET下发给 BE由 BE 来判断该 TABLET 何时可以开始进行冷热数据转换。
冷热数据转换守护进程 cooldown_tasks_producer_thread 是 BE 的一条守护进程其对本 BE 的所有存活的TABLET进行遍历检查每个TABLET的配置信息。当发现该 TABLET 配置了 storage_policy说明需要对其进行冷热数据转换。
根据 storage_policy 中的配置BE 将从缓存信息中的 StoragePolicy 列表中获取对应的规则信息然后根据这个规则判断当前tablet是否需要进行冷热数据转换将数据存放于远程存储集群上如S3。
BE在存储TABLET数据的时候TABLET下面还会有 ROWSET 和 SEGMENT 的划分。其中 ROWSET 代表着数据导入批次同一个ROWSET 一般代表着一个批次的导入任务比如一次 stream load一个 begin/commit 事务等都对应一个 ROWSETROWSET 的这种特性意味着其具有着事务的特点即是说同一个rowset可以作为一个独立的数据单元存在其中的数据要么全部有效要么全部无效。
正因为如此以 ROWSET 为基本单元对数据进行冷热转换可以更容易的解决冷热数据迁移过程中有新数据写入的问题。
如下图所示对于进入冷热数据转换状态的 TABLET其 ROWSET 被分成两部分。
一部分在本地这部分数据往往是新写入的数据还未触发上传操作。
另一部分在远程存储集群S3/HDFS这部分数据相对较早是在此前已经触发上传到了存储集群上的数据。
两部分合在一起才是完整的一个 TABLET。 当冷数据需要读取的时候由于数据已经被拆分成了两部分需要从本地和远程存储集群S3/HDFS上分别读取数据。
在数据读写中IO 层将远程文件与本地文件抽象出 FileReader、FileWriter 层将远程数据的读写与本地数据的读写统一实现了最基本的冷热数据读写能力。
如下图所示本地文件和远程文件的读取被封装成了一个跟 FileReader 的虚基类实现两个派生类 LocalFileReader 和 S3FileReader分别对应本地文件读取与 S3 文件读取。当有读取请求到达 TABLET 时TABLET会根据条件找到对应的ROWSET这些 ROWSET 有些是本地存储有些是远程存储S3。通过映射关系ROWSET 找到各自的 FileReader完成数据读取合并后即是完整的TABLET数据。
在这里远程数据文件为了保证读取效率可以有多种优化的方向比如加一层本地缓存比如使用本地索引等。这些在后续文章中详细说明。 与冷数据读取相似冷数据写入也封装了一个 FileWriter 虚基类如下图所示 新写入的数据会在TABLET的本地存储部分新增一个ROWSET这与普通的TABLET相同也保证了冷数据也可写入的特性。而这部分写入到本地的数据在某个时间点会与远程的冷数据进行合并并上传到远程存储集群。这一步骤则是由前文提到的守护进程 cooldown_tasks_producer_thread来 完成的。 FileCache 即是冷数据在本地的缓存层其是远程数据在本地的镜像当访问的Segment 是冷数据存储在远程集群时会触发生成缓存层将远程数据拉取到本地生成缓存文件。这样在下一次访问时可以直接读取缓存文件而不需要从远程集群上拉取数据。 当一个查询请求到来时SQL 被解析并重组成 PlanFragment 通过元数据指定到 BE 里的Tablet 上而 Tablet 本身是由多个 Segment 组成。当访问的 Segment 是热数据本地文件时直接读取本地文件即可当访问的 Segment 是冷数据远程文件时直接读取远程文件代价是较高的这时就会触发缓存机制生成缓存文件。
缓存文件是远程文件的映射缓存文件中每一条数据在远程文件上都有对应的存在。但是这并不说缓存文件就等于是远程文件两者之间是存在区别的。这是因为
远程文件一般是比较大的将这么大的文件整个拉取到本地的代价很高反而会影响到查询的效率。
查询请求在下推时往往只是读取Segment其中一部分数据比如在 Select * from Table limit 1 这样的请求中需要使用的往往只是其中几 KB 的数据这时将几 GB 大小的文件全部拉到本地反而会增加不必要的时间开销。
同一个 Segment 中的缓存数据也存在着使用频率的差异有可能只是 Segment 其中的一小部分数据被经常使用当需要清理缓存数据时我们更希望将使用不频繁的数据清除。
正因为如此缓存文件采取了文件切割的方式也即是说远程的文件会被拆分成几个相对较小的子文件存放在本地作为缓存。当对 Segment 进行读取的时候该请求会定位到远程文件指定位置的数据 offset length 缓存机制将从远程文件中切分一部分出来作为子文件写入到本地的缓存目录下。
根据缓存文件的重要性、磁盘的容量情况等缓存文件的清理分成以下几种策略
缓存文件在生成之后的一段时间内用户再次访问该段数据的可能性是最高的因此这时也是缓存数据最活跃的时期。随着时间的推移用户访问该数据的可能性变小。当用户有较长的一段时间未访问时该数据已经不活跃即可对其进行清理。
BE 中使用 CacheManager 来对这些缓存进行管理当用户的查询触发并生成了 Cache 文件时这些 Cache 文件会注册到 CacheManager 中。
最后活跃时间是用于检查的重要指标每当一个 Cache 被访问到时其最后活跃时间即会更新代表着该 Cache 近期有活跃动作。
CacheManager 会定时检查这些缓存文件的最后活跃时间当某些 Cache 的最后活跃时间较早时代表着该 Cache 已经不再活跃CacheManager 将对这些 Cache 进行清除。
缓存文件占用的是本地磁盘空间。当占用的空间足够大的时候可能会影响本地文件的读写这就需要对这些缓存文件进行清理。
当缓存文件较多时很可能很多缓存文件并没有达到活跃时间的阈值而这时候其占用的磁盘空间已经过大了这就需要提前将这些文件进行清理。
清理的时候将缓存文件按最后活跃时间分成几个批次从较早的文件开始按时间逐步清理直到降低到指定的磁盘占用空间上限。
由于BE本身有可能出现重启、IO 异常等情况缓存文件也可能生成一些垃圾文件。例如文件写到一半时 IO 异常、文件生成过程中BE重启等。这些文件并不处在 CacheManager 的管理之中为了保证缓存层的干净需要定期对这些文件进行清理。
由于在原本的逻辑中 Tablet 层已经有了一个垃圾文件清理的模块会清理异常的 Tablet 。因此缓存层的清理不需要再关注那些异常的 Tablet 只需要关注 TabletManager 中管理的Tablet 即可。
缓存层垃圾清理对 TabletManager 中的 Tablet 目录进行遍历查询每一个缓存目录检查其是否在 CacheManager 中已经注册。如果在 CacheManager 中已经存在这些 Cache 就不是垃圾文件可以通过前面的两种缓存清理策略进行清理。如果在 CacheManager 中不存在这些 Cache 则有可能是垃圾缓存这时需要检查这些缓存文件的生成时间根据生成时间来决定是否删除。
