山东恒昆建设工程有限公司网站关于建设网站的书本

当前位置： 首页 > news >正文

山东恒昆建设工程有限公司网站,关于建设网站的书本,w3c网站代码标准规范,seo如何提升排名收录在数据分析的实际场景中#xff0c;冷热数据往往面临着不同的查询频次及响应速度要求。例如在电商订单场景中#xff0c;用户经常访问近 6 个月的订单#xff0c;时间较久远的订单访问次数非常少#xff1b;在行为分析场景中#xff0c;需支持近期流量数据的高频查询且时效…在数据分析的实际场景中冷热数据往往面临着不同的查询频次及响应速度要求。例如在电商订单场景中用户经常访问近 6 个月的订单时间较久远的订单访问次数非常少在行为分析场景中需支持近期流量数据的高频查询且时效性要求高但为了保证历史数据随时可查往往要求数据保存周期更为久远在日志分析场景中历史数据的访问频次很低但需长时间备份以保证后续的审计和回溯的工作…往往历史数据的应用价值会随着时间推移而降低且需要应对的查询需求也会随之锐减。而随着历史数据的不断增多如果我们将所有数据存储在本地将造成大量的资源浪费。 为了解决满足以上问题冷热数据分层技术应运而生以更好满足企业降本增效的趋势。顾名思义冷热分层是将 冷 热数据 分别 存储在 成本不同 的存储介质上例如热数据存储在成本更高的 SSD 盘上、以提高时效数据的查询速度和响应能力而冷数据则存储在相对低成本的 HDD 盘甚至更为廉价的对象存储上以降低存储成本。我们还可以根据实际业务需求进行灵活的配置和调整以满足不同场景的要求。 冷热分层一般适用于以下需求场景 数据存储周期长面对历史数据的不断增加存储成本也随之增加 冷热数据访问频率及性能要求不同热数据访问频率高且需要快速响应而冷数据访问频率低且响应速度要求不高 数据备份和恢复成本高备份和恢复大量数据需要消耗大量的时间和资源。 …
更高存储效率的冷热分层技术 自 Apache Doris 0.12 版本引入动态分区功能开始支持对表分区进行生命周期管理可以设置热数据转冷时间以及存储介质标识通过后台任务将热数据从 SSD 自动冷却到 HDD以帮助用户较大程度地降低存储成本。用户可以在建表属性中配置参数 storage_cooldown_time 或者 dynamic_partition.hot_partition_num 来控制数据从 SSD 冷却到 HDD当分区满足冷却条件时Doris 会自动执行任务。而 HDD 上的数据是以多副本的方式存储的并没有做到最大程度的成本节约因此对于冷数据存储成本仍然有较大的优化空间。 为了帮助用户进一步降低存储成本社区在已有功能上进行了优化并在 Apache Doris 2.0 版本中推出了冷热 数据 分层的功能。冷热数据分层功能使 Apache Doris 可以将冷数据下沉到存储成本更加低廉的对象存储中同时冷数据在对象存储上的保存方式也从多副本变为单副本存储成本进一步降至原先的三分之一同时也减少了因存储附加的计算资源成本和网络开销成本。 如下图所示在 Apache Doris 2.0 版本中支持三级存储分别是 SSD、HDD 和对象存储。用户可以配置使数据从 SSD 下沉到 HDD并使用冷热分层功能将数据从 SSD 或者 HDD 下沉到对象存储中。 以公有云价格为例云磁盘的价格通常是对象存储的 5-10 倍如果可以将 80% 的冷数据保存到对象存储中存储成本至少可降低 70%。 我们使用以下公式计算节约的成本设冷数据比率为 rate对象存储价格为 OSS云磁盘价格为 CloudDisk 1 − r a t e ∗ 100 ∗ O S S ( 1 − r a t e ) ∗ 100 ∗ C l o u d D i s k 100 ∗ C l o u d D i s k 1 - \frac{rate * 100 * OSS (1 - rate) * 100 * CloudDisk}{100 * CloudDisk} 1−100∗CloudDiskrate∗100∗OSS(1−rate)∗100∗CloudDisk​ 这里我们假设用户有 100TB 的数据我们按照不同比例将冷数据迁移到对象存储来计算一下如果使用冷热分层之后相较于全量使用普通云盘、SSD 云盘 可节约 多少 成本。 阿里云 OSS 标准存储成本是 120 元/ T /月阿里云普通云盘的价格是 300 元/ T /月阿里云 SSD 云盘的价格是 1000 元/ T /月 例如在 80% 冷数据占比的情况下剩余 20% 使用普通云盘每月仅花费 80T120 20T * 300 15600元而全量使用普通云盘则需要花费 30000 元通过冷热数据分层节省了 48% 的存储成本。如果用户使用的是 SSD 云盘那么花费则会从全量使用需花费的 100000 元降低到 80T120 20T * 1000 29600元存储成本最高降低超过 70% 使用指南 若要使用 Doris 的冷热分层功能首先需要准备一个对象存储的 Bucket 并获取对应的 AK/SK。当准备就绪之后下面为具体的使用步骤

1. 创建 Resource 可以使用对象存储的 Bucket 以及 AK/SK 创建 Resource目前支持 AWS、Azure、阿里云、华为云、腾讯云、百度云等多个云的对象存储。 CREATE RESOURCE IF NOT EXISTS \({resource_name}PROPERTIES(types3,s3.endpoint \){S3Endpoint},s3.region \({S3Region},s3.root.path path/to/root,s3.access_key \){S3AK},s3.secret_key \({S3SK},s3.connection.maximum 50,s3.connection.request.timeout 3000,s3.connection.timeout 1000,s3.bucket \){S3BucketName});2. 创建 Storage Policy 可以通过 Storage Policy 控制数据冷却时间目前支持相对和绝对两种冷却时间的设置。 CREATE STORAGE POLICY testPolicy PROPERTIES(storage_resource remote_s3,cooldown_ttl 1d );例如上方代码中名为 testPolicy 的 storage policy 设置了新导入的数据将在一天后开始冷却并且冷却后的冷数据会存放到 remote_s3 所表示的对象存储的 root path 下。除了设置 TTL 以外在 Policy 中也支持设置冷却的时间点可以直接设置为 CREATE STORAGE POLICY testPolicyForTTlDatatime PROPERTIES(storage_resource remote_s3,cooldown_datetime 2023-06-07 21:00:00 );3. 给表或者分区设置 Storage Policy 在创建出对应的 Resource 和 Storage Policy 之后我们可以在建表的时候对整张表设置 Cooldown Policy也可以针对某个 Partition 设置 Cooldown Policy。这里以 TPCH 测试数据集中的 lineitem 表举例。如果需要将整张表都设置冷却的策略则可以直接在整张表的 properties 中设置 CREATE TABLE IF NOT EXISTS lineitem1 (L_ORDERKEY INTEGER NOT NULL,L_PARTKEY INTEGER NOT NULL,L_SUPPKEY INTEGER NOT NULL,L_LINENUMBER INTEGER NOT NULL,L_QUANTITY DECIMAL(15,2) NOT NULL,L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL,L_DISCOUNT DECIMAL(15,2) NOT NULL,L_TAX DECIMAL(15,2) NOT NULL,L_RETURNFLAG CHAR(1) NOT NULL,L_LINESTATUS CHAR(1) NOT NULL,L_SHIPDATE DATEV2 NOT NULL,L_COMMITDATE DATEV2 NOT NULL,L_RECEIPTDATE DATEV2 NOT NULL,L_SHIPINSTRUCT CHAR(25) NOT NULL,L_SHIPMODE CHAR(10) NOT NULL,L_COMMENT VARCHAR(44) NOT NULL)DUPLICATE KEY(L_ORDERKEY, L_PARTKEY, L_SUPPKEY, L_LINENUMBER)PARTITION BY RANGE(L_SHIPDATE)(PARTITION p202301 VALUES LESS THAN (2017-02-01),PARTITION p202302 VALUES LESS THAN (2017-03-01))DISTRIBUTED BY HASH(L_ORDERKEY) BUCKETS 3PROPERTIES (replication_num 3,storage_policy \({policy_name})用户可以通过 show tablets 获得每个 Tablet 的信息其中 CooldownReplicaId 不为 -1 并且 CooldownMetaId 不为空的 Tablet 说明使用了 Storage Policy。如下方代码通过 show tablets 可以看到上面的 Table 的所有 Tablet 都设置了 CooldownReplicaId 和 CooldownMetaId这说明整张表都是使用了 Storage Policy。 TabletId: 3674797ReplicaId: 3674799BackendId: 10162SchemaHash: 513232100Version: 1LstSuccessVersion: 1LstFailedVersion: -1LstFailedTime: NULLLocalDataSize: 0RemoteDataSize: 0RowCount: 0State: NORMAL LstConsistencyCheckTime: NULLCheckVersion: -1VersionCount: 1QueryHits: 0PathHash: 8030511811695924097MetaUrl: http://172.16.0.16:6781/api/meta/header/3674797CompactionStatus: http://172.16.0.16:6781/api/compaction/show?tablet_id3674797CooldownReplicaId: 3674799CooldownMetaId: TUniqueId(hi:-8987737979209762207, lo:-2847426088899160152)我们也可以对某个具体的 Partition 设置 Storage Policy只需要在 Partition 的 Properties 中加上具体的 Policy Name 即可 CREATE TABLE IF NOT EXISTS lineitem1 (L_ORDERKEY INTEGER NOT NULL,L_PARTKEY INTEGER NOT NULL,L_SUPPKEY INTEGER NOT NULL,L_LINENUMBER INTEGER NOT NULL,L_QUANTITY DECIMAL(15,2) NOT NULL,L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL,L_DISCOUNT DECIMAL(15,2) NOT NULL,L_TAX DECIMAL(15,2) NOT NULL,L_RETURNFLAG CHAR(1) NOT NULL,L_LINESTATUS CHAR(1) NOT NULL,L_SHIPDATE DATEV2 NOT NULL,L_COMMITDATE DATEV2 NOT NULL,L_RECEIPTDATE DATEV2 NOT NULL,L_SHIPINSTRUCT CHAR(25) NOT NULL,L_SHIPMODE CHAR(10) NOT NULL,L_COMMENT VARCHAR(44) NOT NULL)DUPLICATE KEY(L_ORDERKEY, L_PARTKEY, L_SUPPKEY, L_LINENUMBER)PARTITION BY RANGE(L_SHIPDATE)(PARTITION p202301 VALUES LESS THAN (2017-02-01) (storage_policy \){policy_name}),PARTITION p202302 VALUES LESS THAN (2017-03-01))DISTRIBUTED BY HASH(L_ORDERKEY) BUCKETS 3PROPERTIES (replication_num 3)这张 Lineitem1 设置了两个分区每个分区 3 个 Bucket另外副本数设置为 3可以计算出一共有 23 6 个 Tablet那么副本数一共是 63 18 个 Replica通过 show tablets 命令可以查看到所有的 Tablet 以及 Replica 的信息可以看到只有部分 Tablet 的 Replica 是设置了CooldownReplicaId 和 CooldownMetaId 。用户可以通过 ADMIN SHOW REPLICA STATUS FROM TABLE PARTITION(PARTITION) 查看 Partition 下的 Tablet 以及Replica通过对比可以发现其中只有属于 p202301 这个 Partition 的 Tablet 的 Replica 设置了CooldownReplicaId 和 CooldownMetaId而属于 p202302 这个 Partition 下的数据没有设置所以依旧会全部存放到本地磁盘。 以上表的 Tablet 3691990 为例该 Tablet 属于 p202301截取 show tablets 拿到的部分关键信息如下 *****************************************************************TabletId: 3691990ReplicaId: 3691991CooldownReplicaId: 3691993CooldownMetaId: TUniqueId(hi:-7401335798601697108, lo:3253711199097733258) *****************************************************************TabletId: 3691990ReplicaId: 3691992CooldownReplicaId: 3691993CooldownMetaId: TUniqueId(hi:-7401335798601697108, lo:3253711199097733258) *****************************************************************TabletId: 3691990ReplicaId: 3691993CooldownReplicaId: 3691993CooldownMetaId: TUniqueId(hi:-7401335798601697108, lo:3253711199097733258)可以观察到 3691990 的 3 个副本都选择了 3691993 副本作为 CooldownReplica在用户指定的 Resource 上也只会保存这个副本的数据。
2. 查看数据信息 我们可以按照上述 3 中的 Linetem1 来演示如何查看是使用冷热数据分层策略的 Table 的数据信息一般可以通过 show tablets from lineitem1 直接查看这张表的 Tablet 信息。Tablet 信息中区分了 LocalDataSize 和 RemoteDataSize前者表示存储在本地的数据后者表示已经冷却并移动到对象存储上的数据。具体信息可见下方代码 下方为数据刚导入到 BE 时的数据信息可以看到数据还全部存储在本地。 *************************** 1. row **************************TabletId: 2749703ReplicaId: 2749704BackendId: 10090SchemaHash: 1159194262Version: 3LstSuccessVersion: 3LstFailedVersion: -1LstFailedTime: NULLLocalDataSize: 73001235RemoteDataSize: 0RowCount: 1996567State: NORMAL LstConsistencyCheckTime: NULLCheckVersion: -1VersionCount: 3QueryHits: 0PathHash: -8567514893400420464MetaUrl: http://172.16.0.8:6781/api/meta/header/2749703CompactionStatus: http://172.16.0.8:6781/api/compaction/show?tablet_id2749703CooldownReplicaId: 2749704CooldownMetaId:当数据到达冷却时间后再次进行 show tablets from table 可以看到对应的数据变化。 ************************** 1. row ***************************TabletId: 2749703ReplicaId: 2749704BackendId: 10090SchemaHash: 1159194262Version: 3LstSuccessVersion: 3LstFailedVersion: -1LstFailedTime: NULLLocalDataSize: 0RemoteDataSize: 73001235RowCount: 1996567State: NORMAL LstConsistencyCheckTime: NULLCheckVersion: -1VersionCount: 3QueryHits: 0PathHash: -8567514893400420464MetaUrl: http://172.16.0.8:6781/api/meta/header/2749703CompactionStatus: http://172.16.0.8:6781/api/compaction/show?tablet_id2749703CooldownReplicaId: 2749704CooldownMetaId: TUniqueId(hi:-8697097432131255833, lo:9213158865768502666)除了通过上述命令查看数据信息之外我们也可以在对象存储上查看冷数据的信息。以腾讯云为例可以在 Policy 指定的 Bucket 的 Path 下可以查看冷却过后的数据的信息 进入对应文件后可以看到数据和元数据文件 我们可以看到在对象存储上数据是单副本。 5. 查询 假设 Table Lineitem1 中的所有数据都已经冷却并且上传到对象存储中如果用户在 Lineitem1 上进行对应的查询Doris 会根据对应 Partition 使用的 Policy 信息找到对应的 Bucket 的 Root Path并根据不同 Tablet 下的 Rowset 信息下载查询所需的数据到本地进行运算。 Doris 2.0 在查询上进行了优化冷数据第一次查询会进行完整的 S3 网络 IO并将 Remote Rowset 的数据下载到本地后存放到对应的 Cache 之中后续的查询将自动命中 Cache以此来保证查询效率。(性能对比可见后文评测部分。
3. 冷却后继续导入数据 在某些场景下用户需要对历史数据进行数据的修正或补充数据而新数据会按照分区列信息导入到对应的 Partition中。在 Doris 中每次数据导入都会产生一个新的 Rowset以保证冷数据的 Rowset 在不会影响新导入数据的 Rowset 的前提下满足冷热数据同时存储的需求。Doris 2.0 的冷热分层粒度是基于 Rowset 的当到达冷却时间时会将当前满足条件的 Rowset 全部上传到 S3 上并删除本地数据之后新导入的数据生成的新 Rowset 会在到达冷却时间后也上传到 S3。 查询性能测试 为了测试使用冷热分层功能之后查询对象存储中的数据是否占用会较大网络 I/O从而影响查询性能因此我们以 SSB SF100 标准集为例对冷热分层表和非冷热分层表进行了查询耗时的对比测试。 配置均在 3 台 16C 64G 的机器上部署 1FE、3BE 的集群 暂时无法在飞书文档外展示此内容 如上图所示在充分预热之后(数据已经缓存在 Cache 中)冷热分层表共耗时 5.799s非冷热分层表共耗时 5.822s由此可知使用冷热分层查询表和非冷热分层表的查询性能几乎相同。这表明使用 Doris 2.0 提供的冷热分层功能不会对查询性能造成的影响。 冷热分层技术的具体实现 存储方式的优化 在 Doris 之前的版本中数据从 SSD 冷却到 HDD 后为了保证数据的高可用和可靠性通常会将一个 Tablet 存储多份副本在不同 BE 上为了进一步降低成本我们在 Apache Doris 2.0 版本引入了对象存储推出了冷热分层功能。由于对象存储本身具有高可靠高可用性冷数据在对象存储上只需要一份即可元数据以及热数据仍然保存在 BE我们称之为本地副本本地副本同步冷数据的元数据这样就可以实现多个本地副本共用一份冷却数据的目的有效避免冷数据占用过多的存储空间从而降低数据存储成本。 具体而言Doris 的 FE 会从 Tablet 的所有可用本地副本中选择一个本地副本作为上传数据的 Leader并通过 Doris 的周期汇报机制同步 Leader 的信息给其它本地副本。在 Leader 上传冷却数据时也会将冷却数据的元数据上传到对象存储以便其他副本同步元数据。因此任何本地副本都可以提供查询所需的数据同时也保证了数据的高可用性和可靠性。 冷数据 Compaction 在一些场景下会有大量修补数据的需求在大量补数据的场景下往往需要删除历史数据删除可以通过 delete where实现Doris 在 Compaction 时会对符合删除条件的数据做物理删除。基于这些场景冷热分层也必须实现对冷数据进行 Compaction因此在 Doris 2.0 版本中我们支持了对冷却到对象存储的冷数据进行 CompactionColdDataCompaction的能力用户可以通过冷数据 Compaction将分散的冷数据重新组织并压缩成更紧凑的格式从而减少存储空间的占用提高存储效率。 Doris 对于本地副本是各自进行 Compaction在后续版本中会优化为单副本进行 Compaction。由于冷数据只有一份因此天然的单副本做 Compaction 是最优秀方案同时也会简化处理数据冲突的操作。BE 后台线程会定期从冷却的 Tablet 按照一定规则选出 N 个 Tablet 发起 ColdDataCompaction。与数据冷却流程类似只有 CooldownReplica 能执行该 Tablet 的 ColdDataCompaction。Compaction下刷数据时每积累一定大小默认5MB的数据就会上传一个 Part 到对象而不会占用大量本地存储空间。Compaction 完成后CooldownReplica 将冷却数据的元数据更新到对象存储其他 Replica 只需从对象存储同步元数据从而大量减少对象存储的 IO 和节点自身的 CPU 开销。 冷数据 Cache 冷数据 Cache 在数据查询中具有重要的作用。冷数据通常是数据量较大、使用频率较低的数据如果每次查询都需要从对象中读取会导致查询效率低下。通过冷数据 Cache 技术可以将冷数据缓存在本地磁盘中提高数据读取速度从而提高查询效率。而 Cache 的粒度大小直接影响 Cache 的效率比较大的粒度会导致 Cache 空间以及带宽的浪费过小粒度的 Cache 会导致对象存储 IO 效率低下Apache Doris 采用了以 Block 为粒度的 Cache 实现。 如前文所述Apache Doris 的冷热分层会将冷数据上传到对象存储上上传成功后本地的数据将会被删除。因此后续涉及到冷数据的查询均需要对对象存储发起 IO 。为了优化性能Apache Doris 实现了基于了 Block 粒度的 Cache 功能当远程数据被访问时会先将数据按照 Block 的粒度下载到本地的 Block Cache 中存储且 Block Cache 中的数据访问性能和非冷热分层表的数据性能一致可见后文查询性能测试。 具体来讲前文提到 Doris 的冷热分层是在 Rowset 级别进行的当某个 Rowset 在冷却后其所有的数据都会上传到对象存储上。而 Doris 在进行查询的时候会读取涉及到的 Tablet 的 Rowset 进行数据聚合和运算当读取到冷却的 Rowset 时会把查询需要的冷数据下载到本地 Block Cache 之中。基于性能考量Doris 的 Cache 按照 Block 对数据进行划分。Block Cache 本身采用的是简单的 LRU 策略可以保证越是使用程度较高数据越能在 Block Cache 中存放的久。 结束语 Apache Doris 2.0 版本实现了基于对象存储的冷热数据分层该功能可以帮助我们有效降低存储成本、提高存储效率并提高数据查询和处理效率。未来Apache Doris 将会基于冷热数据分层以及弹性计算节点为用户提供更好的资源弹性、更低的使用成本以及更灵活的负载隔离服务。 在前段时间推出的 Apache Doris 2.0 Alpha 版本中已经实现了单节点数万 QPS 的高并发点查询能力、高性能的倒排索引、高效稳定的内存管理、基于代价模型的全新查询优化器以及 Pipeline 执行引擎等欢迎大家下载体验。与此同时 Apache Doris 2.0 Beta 版本也将于近两周上线。除了已知功能外还会进一步支持 Unique 模型上的部分列更新并将 Pipeline 执行引擎、查询优化器、主键模型 Merge-on-Write 等最新特性作为稳定功能默认开启并包含了社区近期对性能方面的诸多优化详细性能测试结果敬请期待后续社区动态。 为了让用户可以体验社区开发的最新特性同时保证最新功能可以收获到更广范围的使用反馈我们建立了 2.0 版本的专项支持群请大家填写申请欢迎广大社区用户在使用最新版本过程中多多反馈使用意见帮助 Apache Doris 持续改进。 作者介绍 杨勇强SelectDB 联合创始人、技术副总裁 岳靖、程宇轩SelectDB 存储层研发工程师