赤壁网站定制,购买网站外链,做网站图片代码怎么居中,天津塘沽网站建设公司本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
本作品 (李兆龙 博文, 由 李兆龙 创作)#xff0c;由 李兆龙 确认#xff0c;转载请注明版权。 文章目录 引言Architectural overviewData format and meta-dataEnsuring fast ingestionMulti…本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
本作品 (李兆龙 博文, 由 李兆龙 创作)由 李兆龙 确认转载请注明版权。 文章目录 引言Architectural overviewData format and meta-dataEnsuring fast ingestionMulti-tiered cachingOptimized query processingContinuous Availability总结 引言
给我的感觉Db2 Event Store是一个私有的InfluxDB IOX只不过没有InfluxDB IOX功能那么强大而已其在写入流程COS的利用存储格式以及架构上给我的感觉是后者好像也可以这么实现只不过后者计算节点可以不挂盘且控制面更为强大而已。
Db2 Event Store设计原则如下
尽可能快地写入数据 最小化完成持久化数据所需同步工作确保节点故障时的持久性并将数据提供给查询处理。Asynchronously refine and enrich data 数据被写入后会以异步方式进一步优化数据格式从而提高查询处理的效率。高度优化查询处理 利用了高度优化的数据格式Parquet允许跳过部分数据的元数据强大的查询优化器和runtime通过在集群中的所有节点上并行运行以及在每个节点内多线程运行充分利用所有可用硬件可用性 最大限度减小单机故障时对于读写的影响
我认为的Db2 Event Store的优劣势如下
优势
基于IOT场景完全利用了云上廉价的基础设施并设计多集缓存消除性能影响。高效的写入流程来源于创新的数据多级流转这个思路类似于BytesSeries。重复使用已经构建和优化了几十年的Db2 SQL compiler, optimizer 以及 runtime极大地减少了开发工作量并立即提供了丰富的 SQL 支持和出色的运行时查询性能。混合MPP shared nothing / shared disk cluster architecture这样做的好处是将传统 MPP shared nothing 的线性可扩展性与shared everything的高可用性结合存算分离在公有云上售卖模型也清楚隔离也简单计费也容易。天然支持高基数因为不同的数据存储在不同的Parquet文件index分离还有synopsis文件记录表级别概要信息允许在共享存储中合并compact过程不影响查询。
劣势
没有提到控制面元数据完全基于Zookeeper风险较高能力相对较弱无法适应复杂调度。可用性差单点故障会导致读短暂不可用。
Architectural overview DB2混合了 MPP shared nothing / shared disk cluster architecture这样做的好处是将传统 MPP shared nothing 的线性可扩展性与shared everything的高可用性结合。
如上图所示Table数据根据用户定义的hash key被划分为micro-partitions存储在可靠的共享存储介质上。集群中所有的计算节点都能完全访问整个数据集从而实现存储与计算的解耦并使每个节点都能独立扩展。
Zookeeper作为协调节点在逻辑上将micro-partitions的归属划分给可用的计算节点。逻辑上每个micro-partitions在任何给定时间点都由一个计算节点拥有任何该micro-partitions的读写请求都通过拥有该micro-partitions的计算节点实现集群级别的读写并行化。在处理计算节点故障时受影响的micro-partitions会在计算节点上重新分配映射关系与需要进行数据迁移的模式相比大大缩短了故障转移时间。
为确保元数据没有单点故障系统采用了floating catalog的概念将目录信息存储在可靠的共享存储中并通过任意一台计算节点提供服务一旦发生故障在任何计算服务器上重新启动。
数据首先被写入计算节点上本地存储介质SSD 或 NVMe并在提交之前进一步复制和写入至少另外两个计算节点的本地存储。这确保了数据在计算节点发生故障时的可用性。然后数据异步写入共享存储。这种模式可以避免了共享存储介质可能产生的任何额外延迟尤其是在高延迟云对象存储的情况下高效的处理各种负载的写入。
该架构通过并行和优化存储技术的结合实现快速摄取。该系统采用headless集群架构所有计算节点都扮演着head nodes 以及 data nodes类似multi raft。在单独一个计算节点内部通过表级别hash partitioning将写入row映射到特定的micro-partitions然后发送给拥有该分区的计算节点。这里提一个问题为什么不是每个计算节点都可以做写入呢原因是为了保证一致性这里的写入不是基于raft的而是写三份如果不存在一个单点写入的话可能存在三副本不一致
数据格式为ParquetParquet利用压缩的 PAX 存储格式可被 Db2 的 BLU 列式runtime引擎用于分析处理也可以允许Hive、Spark、Presto等直接查询数据。
云对象存储无法为可修改的数据提供强有力的一致性保证为了利用对象存储的成本和可扩展性优势db2利用了一种append-only immutable 存储模型在这种模型中数据块永远不会被重写。Synopsis metadata允许在查询处理过程中跳过数据时间first/last/min/max/count作为写入过程的一部分自动生成并写入单独的 Parquet 文件从而允许元数据与表数据分开访问和缓存。
索引利用 LSM 树风格的格式来满足append-only的要求。索引作为数据共享流程的一部分异步生成的以尽量减少写入处理的延迟。所以异步生成意味着在异步共享处理过程中需要消除重复键这里其实就是多写处理冲突以前我做multi region写冲突处理时方案时做过这个方案很多LWW是最简单有效的一种。
高效的数据访问是通过多层缓存层实现的该层将频繁访问的数据、元数据和索引缓存在内存中和计算节点本地存储介质中以防止云对象存储可能产生的延迟。
Data format and meta-data
数据存储格式主要基于两个方面考虑
考虑到处理分析工作负载时的性能优势最好使用列式数据存储格式使用开源格式允许外部系统访问
所以最终选择Parquet作为存储格式。
Db2 Event Store 架构下表的最小粒度是micro-partitions。Parquet 文件属于micro-partitions因此给定的 Parquet 文件正好包含一个micro-partitions的数据。Parquet 文件一旦写入就不可更改。micro-partitions的每个 Parquet 文件都分配有一个单调递增的数字称其tablet identifier。Db2 Event Store runtime engine 以及 external readers 利用这一点来判断较新的数据。共享存储中 Parquet 文件的元数据由 Zookeeper 维护比如每个micro-partitions的最新tablet identifier。
在 Db2 Event Storetuples 通过 Tuple Sequence Number (TSN)识别TSN 是一个整数可用于定位表中的tuple。Db2 Event Store 中的 TSN 包括tablet identifier, the zone以及tuple在 Parquet 文件中的偏移量。
另外Db2 Event Store还为Parquet贡献了一项特性 Parquet Modular Encryption[1] 这个特性对每个模块分别加密从而保留了加密数据的过滤功能和分析效率。它利用 CPU 硬件支持的 AES GCM 密码[2]在不减慢整体工作流程的情况下执行模块加密操作。AES GCM 还能保护存储数据的完整性使其不会被恶意篡改文件内容。db2使用其他模块保存密码Parquet 文件在发送到共享存储前已加密这样做有两个好处
存储后端无法查看加密密钥和明文数据从共享存储检索加密文件后DB2 Even Store 会使用 Parquet 模块化加密库验证已处理数据的加密完整性SSD/NVMe 缓存层也使用 Parquet 加密格式确保本地持久化文件免受内部人员攻击和硬件故障。
这样的做法可以看出db2的工程实现足够优秀没有经验的团队不会有这样的决策的因为很多现有的云系统因为性能的考究不会做全链路CRC这意味着可能发生内存/CPU错误而导致比特跳变进而导致数据损坏如果用户侧不自己校验很多时候根本无法感知这种问题以我们团队的经验来看基本几年就会发生一次。
Ensuring fast ingestion 关键思路和现有的几个系统一样减少写入流程上的开销重操作异步执行基本写入流程如下
客户端可以连接到任何一个节点连接的节点称为ingest coordinator来执行写入如果发生故障会自动将批量插入重新写到任何其他计算节点。ingest coordinator将batch中数据哈希分割到对应的micro-partitions然后将数据写入其中一个副本。对应副本收到写后会以log的形式将其放入Log Zone持久化的同时会复制到其他计算节点以确保数据的持久性和高可用性。没有索引。Log Zone to the Pre-Shared ZoneLog Zone可实现快速写入和持久性但并不是查询的最佳选择。因此必须尽快将最近写入的数据转换为更便于查询的格式并使用indexes和synopsis来提高提高查询效率这个过程有几秒的延迟。写入 Pre-Shared Zone的数据较小因为每次只会把上一次持久化到现在的数据持久化到共享存储因此对于查询并不理想。这个过程异步维护索引 Parquet文件。Pre-Shared Zone to the Shared Zone Pre-Shared Zone数据量足够时小文件便会合并在所谓的Shared Zone生成更大的 Parquet 文件。文件越大代表查询处理效率越高整体数据压缩效果也越好因此合并后的文件大小一般在 64MB 左右。这个过程会合并索引。
数据的轮转对用户是透明的所有这些Zone的数据都是不可变的。关键点是Log Zone不仅要写入本地存储以保证持久性还要直接用于处理查询结果。(log is database)
由于计算节点的micro-partitions分配是动态的因此需要将索引数据都持久化到共享存储中以便将micro-partitions从一个节点转移到另一个节点当一个micro-partitions被重新分配给一个新的计算节点时时数据库引擎会启动一个后台进程为新的micro-partitionsleader做缓存预热从而使索引访问能够尽快恢复到最高性能。
另外还有一个常规优化手段为了表扫描时跳过不必要的数据Db2 Event Store 会为每个表创建一个synopsis table synopsis table的每一行都涵盖相应用户表的行范围并包含该行范围内列的最小值和最大值。数据synopsis块也采用 Parquet 格式。synopsis在数据合并到Shared Zone时填充因此不包括预共享区和日志区的数据。维护这些区域的数据概要内容需要大量额外成本对共享存储的额外写入而且由于这些区域的数据量较小数据跳过带来的价值不大。
Multi-tiered caching
一个通用的优化思路即对象存储延迟较高很好理解COS本身分为三个模块COS前端Partition layerStream layer一个上传下载内部系统可能多达数十次网络通信当然COS存小对象另说价格低而高性能存储延迟低价格高以腾讯云举例基于SSD的系统价格比COS高几十倍所以如何利用价格低廉的存储并同时提供最佳性能Db2 Event Store 选择多级缓存既能利用内存又能利用本地存储使系统免受对象存储的高延迟影响。
Db2 Event Store使用了五种缓存机制
Multi-layered Caching SSD/NVMeRAM 均用于缓存数据块索引以及synopsis。Directed Caching缓存访问可根据请求类型只定向到 RAM或定向到本地 SSD/NVMe 设备可选择放置在 RAM 缓存中或者可以完全绕过缓存层直接访问云存储确定冷数据。Probabilistic Caching利用被访问对象的不同表和索引数据总大小的统计数据并计算相对于给定查询所使用数据被缓存的概率。常常与Directed Caching结合使用。 Soft Hard Limits内存的限制。Epoch based eviction一种巧妙的驱逐方式我没太看明白。
Optimized query processing
在查询处理方面Db2 Event Store 利用 Db2 的 BLU MPP 集群查询引擎将 Db2 基于成本的 SQL 优化器和 Db2 的 BLU 加速列引擎的加速分析处理功能与 Db2 Event Store 数据管理层的快速写入和云本地存储功能相结合。这个确实不可模仿这就是公司的底蕴吧。
计算引擎的优化我并不熟悉很多内容没看懂。
不过Db2 Event Store 利用过去 30 年中开发和完善的 Db2 SQL compiler, optimizer 以及 runtime证明了为公共云重新架构并不需要重写所有组件。也证明了计算引擎就根本不应该自己写直接用现成的最好Lindorm就使用了Apache Calcite作为计算引擎InfluxDB IOX使用了DataFusion。
Continuous Availability
其实对于文中Continuous Availability这个词我很疑惑不知道怎么理解用高可用性看吧也不对因为Db2 Event Store在计算节点宕机期间会影响读也不可用所以我暂且称它为基本可用吧。
写入micro-partitions的所有副本都能处理写入因此只要大部分副本仍然可用当一个副本节点丢失时摄取处理受到的影响不大客户端处理这种故障在在不同的节点重新尝试操作就可以。micro-partitions上的其他操作对表leader的可用性有很高的依赖性。比如查询data movement between zonesdata enrichmentindex optimization processes。前面提到过data enrichment和index optimization processes可以通过foller提供服务所以调度算法只要让主从不要在一台机器上后台任务就可以继续。读只能通过系统能够快速识别不可用的leader并将故障计算节点micro-partitions等leader转移到其他节点以继续处理查询。catalog当catalog节点宕机时系统仍能继续处理写入和查询因为metadata数据是由数据节点本身缓存的它们只依赖目录节点来执行初始缓存而目录节点使用共享存储进行持久化这使它可以故障转移到集群中的任何一台主机上进而为新上架的节点提供缓存服务。我们曾经有一次故障导致一个集群1000多个接入机70%不可用Zookeeper 只要大部分 Zookeeper 节点存活它就能持续可用。我们曾遭遇过五副本mongo宕机的情况 可以看到单点故障是影响查询的。
最后利用TSBS评估了 Db2 Event Store 与 Druid和TimecaleDB的读写性能又是遥遥领先
总结
参考 5. https://issues.apache.org/jira/browse/PARQUET-1300 6. https://datatracker.ietf.org/doc/html/rfc5288
