龙岩做网站开发要多久,网站开发与管理实验五,弄个网站需要多少钱,杭州开发app作为企业数字化建设的必备要素#xff0c;易用的数据引擎能帮助企业提升数据使用效率#xff0c;更好提升数据应用价值#xff0c;夯实数字化建设基础。 数据导入是衡量OLAP引擎性能及易用性的重要标准之一#xff0c;高效的数据导入能力能够加速数据实时处理和分析的效率。… 作为企业数字化建设的必备要素易用的数据引擎能帮助企业提升数据使用效率更好提升数据应用价值夯实数字化建设基础。 数据导入是衡量OLAP引擎性能及易用性的重要标准之一高效的数据导入能力能够加速数据实时处理和分析的效率。作为一款OLAP引擎火山引擎云原生数据仓库ByteHouse源于开源ClickHouse在字节跳动多年打磨下提供更丰富的能力和更强性能能为用户带来极速分析体验支撑实时数据分析和海量离线数据分析具备便捷的弹性扩缩容能力极致的分析性能和丰富的企业级特性。 随着ByteHouse内外部用户规模不断扩大 越来越多用户对数据导入提出更高的要求这也为ByteHouse的数据导入能力带来了更大的挑战。 本篇文章来源于ByteHouse产品专家在火山引擎数智平台VeDI主办的“数智化转型背景下的火山引擎大数据技术揭秘”线下Meeup的演讲将从ByteHouse数据库架构演进、增强HaKafka引擎实现方案、增强Materialzed MySQL实现方案、案例实践和未来展望四个部分展开分享。 ByteHouse数据库的架构演进 作为一款分析型数据库ByteHouse已经应用在互联网、金融、汽车领域帮助企业实现人群洞察、行为分析、 IOT 风控等场景的实时分析。 ByteHouse的演进 从2017年开始字节内部的整体数据量不断上涨为了支撑实时分析的业务字节内部开始了对各种数据库的选型。经过多次实验在实时分析版块字节内部决定开始试水ClickHouse。2018年到2019年字节内部的ClickHouse业务从单一业务逐步发展到了多个不同业务适用到更多的场景包括BI 分析、A/B测试、模型预估等。在上述这些业务场景的不断实践之下研发团队基于原生ClickHouse做了大量的优化同时又开发了非常多的特性。2020年 ByteHouse正式在字节跳动内部立项2021年通过火山引擎对外服务。截止2022年3月ByteHouse在字节内部总节点数达到18000个而单一集群的最大规模是2400个节点。 ByteHouse的架构 ByteHouse架构分为分布式架构和云原生架构两种。分布式架构的主要特点就是单集群可以支持 2000 多个节点的“大兵团”通过分布式的并行计算体现的高性能能够充分利用每个节点的计算和存储资源云原生实现了存算分离计算资源通过容器化进行弹性和秒级的扩容这对业务是无感知的。 从分布式架构来看ByteHouse具备MPP 1.0特点 存算一体通过本地存储能够保证它极致的这种查询性能。自研的表引擎包含 HaMergeTree和 HaUniqueMergeTree。在社区 RBO 优化器的基础上增强 RBO 加 CBO 的结合的查询优化并基于 CBO 的分布式计划能够在集群模式下计算全局最优的查询计划。支持数据的冷热分存同时兼顾性能和成本。增强关键的数据类型从而优化查询性能。通过统一的管控面提供可视化的管理查询和运维从内到外给用户提供优质的使用体验。 但MPP 1.0存在资源隔离、扩容等痛点由此演进到云原生架构即MPP 2.0其中存算分离通过结合 shared-everything 存储和 shared-nothing 计算层避免了传统 MPP 架构中数据重新分配 (re-sharding) 的问题。 好处在于 更好地实现资源隔离。每个用户不同的计算都提交到不同的计算组并进行计算资源和存储资源的扩容再结合按量计费的计费策略可以降低用户使用成本。底层存储既支持HDFS也支持 S3 对象存储能够让 ByteHouse实现真正的云原生。 ByteHouse技术优势 在增强型数据导入场景中ByteHouse核心优势体现在自研表引擎 在社区版的基础上ByteHouse对表引擎做了进一步增强使其能够实现开源的ClickHouse所做不到的场景。高可用引擎相比社区高可用引擎可以支持表的数量更多集群的规模更大稳定性会更高。实时数据引擎相比社区实时数据引擎消费能力更强支持 at least once 的语义排除单点写入的性能故障。Unique引擎相比社区Unique引擎ByteHouse没有更新延迟问题能够实现真正实时的 upsert。Bitmap 引擎在特定的场景比如用户圈选圈群的场景中支持大量的交并补操作能够使整体的性能提升 10 - 50 倍以上。 这里具体再介绍一下ByteHouse自研引擎的优势——与导入密切相关的表引擎。 首先ByteHouse 提供的HaMergeTree方案能够降低 ZK 负载提升可承载的数据量级。 ClickHouse 社区版本 社区提供的ReplicatedMergeTree表引擎让 ClickHouse 实现了从单机到集群的演进通过ZK节点来同步并维护两个MergeTree之间的元数据和数据。痛点在于在 TB 级的数据量级之下 ZK 重复地进行分发日志和数据交换等操作极大地增加了ZK的压力使ZK 成为整个集群的故障点。ByteHouse 自研HaMergeTree 将元数据的同步和数据的同步解耦ZK只负责元数据的同步而数据的同步是通过 LogExchange 来实现在两个MergeTree之间进行对等拷贝。优势在于降低了 ZK 的负载即使是承载 PB 级的数据量集群也能够平稳地运行。 其次 ByteHouse 提供的HaMergeTree方案能平衡读写性能。 ClickHouse 社区版本 提供ReplacingMerge Tree实现了对唯一键的支持使用Merge-on-read的实现逻辑在不同批次的数据中包含着相同的 key 需要在读时做合并让相同的 key 返回最新的版本。痛点在于数据存在延迟、滞后降低读的性能。ByteHouse 自研的HaUniqueMergeTree 引入了 delete bitmap 的组件在数据插入时即标记删除然后在数据查询时过滤掉标记删除的数据。优势在于整体上平衡了读和写的性能保障了读取时性能一致性。 增强HaKafka引擎实现方案 HaKafka 引擎架构介绍 社区版Kafka 优势 由于社区版ClickHouse是一个分布式结构其数据分布在多个Shard上Kafka引擎可以在多个Shard上去做并发的写入而在同一个Shard内可以启动多线程做并发写入并具备本地盘的极致的性能读写。 社区版 Kafka 不足 在内外部业务的场景中会经常遇到唯一键场景由于社区版本的 Kafka的 high level 的消费模式这种模式就决定无法预知数据被写入到哪一个Shard上所以很难满足这一类场景。社区版的 Kafka 引擎没有高可用即使ClickHouse是多副本的在当一个节点发生宕机时无法保证另一个节点继续消费。 HaKafka引擎架构分布式架构 保持社区版本两级并发两大的优化点 引入高可用让备节点处于 stand-by 的状态一旦主节点发生宕机备节点立刻继续进行消费。升级为low-level的消费模式当数据写入的时候相同的 key 会写到相同的 partition 里面保证在同一个Shard下支持的唯一键场景。 ByteHouse增强HaKafka引擎核心功能实现 高可用主备切换 在备节点上起一个 stand by的consumer 通过 ZK 来进行选组选到的主节点进行消费当主节点发生宕机或者无法进行服务时在秒级之内切换到备节点上让备节点继续消费。 假设现在 replica 1因为故障宕机了无法继续进行消费那么Z K能在秒级内把 replica 2 选为leader。replica 2 随即会立即启动相同数量的消费者启动之后会继续从 replica 1 的消费位置开始继续进行消费。 替换节点 随着集群规模的增大节点数越来越多的情况下不可避免地遇到节点故障这个时候就需要替换节点。 对于分布式架构替换节点一个重要的操作就是拷贝数据在拷贝数据的时候意味着新的节点的数据是不全的如图示示意图 replica 1为新替换的节点还处于数据拷贝的状态即数据是不全如果此时实施消费的 leader 起在了 replica 1就意味着 最新的消费数据会写进 replica 1但是它缺失一部分旧的数据。 而replica 2有旧的数据它的最新数据还需要从replica 1进行拷贝那这个时候下载之内没有一个副本上面的数据是完整的所有的节点就不可能对外提供服务。 这时HaKafka会做强制限制如果 replica 1是一个新节点且还在拷贝数据的状态那么就会强制把 leader 切换成 replica 2由 replica 2 继续去消费最新的数据replica 1保持继续拷贝数据这样可以保证在节点替换的过程中至少有一个副本是能够正常提供服务。 Memory table 不同于社区的Memory Table和底层存储绑定ByteHouse的Memory Table是和Hakafka绑定的主要使用在有百列或者千列的大宽表的场景。 对于ClickHouse来说每一次导入的写的文件的数量和列数是成正比的。如果列很多但是每批次写入的数据量不大这时每一次写入就会造成很多的碎片这对于 IO的消耗会比较高写入的性能其实也会比较差。 针对这种情况考虑使用Memory Table让写不直接落盘每一次写先写到Memory Table中攒到一定的批次或者到达一定的时间之后再一次性刷盘。 当数据写入Memory Table之后就可以对外提供查询服务了因为 memory table 是跟 Kafka 绑定的在同一个下的内是唯一的。当查询来了之后只需要路由到对应的消费节点下 the Memory Table就能保证了数据查询的一致性。 云原生架构增强 分布式架构的痛点在于 1.节点故障 字节的集群规模较大每周/每天会遇到节点故障的问题需要进行节点替换是一个比较大的负担。 2.读写冲突问题 随着集群的接入的业务越来越多数据量越来越大的情况下每一个节点同时承担着查询和写入的操作之间会有冲突。 3.扩容成本 唯一键的场景对数据分布要求非常严格扩容在这种场景下很难支持因为扩容之后partition的映射关系发生了变化。 云原生架构优点在于存算分离、自动扩容、自动容错轻量级的扩缩容等因为云原生支持事物让我们可以将消费语义增强到exactly once。 在云原生架构下的 Kafka 引擎是如何通过事务来实现 exactly once 事务保证 因为云原生架构有事务的支持所以每一轮的消费都需要有事物来保证。因为 Catalog 的元信息和 Catalog 元信息的交互是在 Server 端进行的所以第一步会通过 RPC 的请求向 Server 端请求创建消费事务然后客户端创建正常创建消费事务之后会把 transaction ID 给consumer consumer 拿到这种全声音 ID 之后就可以开始正常地消费了。之后它就会从分配到的 partition 里面不停地消费数据当消费到足够的数据量或者消费满足一定的时间时它就会把消费的这数据转换为对应的 part 文件并dump到存储层。在 dump 之后数据是不可见的因为这个时候的 transaction 还没有提交所以在第五步的时候还是会通过一个 RPC 的 call 把刚才 dump 的元信息消费的 offseed 提交到 catalog 中。这一步是一个原子性的提交也是我们的消费语义升级从 at least once 到 exactly once 的一个核心关键点容错保证 因为manager 和它具体之间的任务是在不同的节点上的所以需要有一定的这种容错机制。当前是让 manager 和 task 之间保持一种一个双向的心跳机制来保证比如说manager每隔 10 秒钟会去探活一次看看当前任务是否正常运行如果没有在正常运行它就会重新拉起一个新的task。而对于 task 来说它每一次的消费都会有两次的 RPC call 和 Server 端做交互这两次的 RPC 交互都会向 manager 去校验自身的有效性如果校验到自己当前是一个失效的状态它就会把自己 kill 掉从而保证整个全局的唯一任务的运行。Memory Buffer 与社区相似Memory Buffer和底层的存储表绑定。因为都是写入底表的不仅Kafka的导入可以用Flink的导入也可以用。memory buffer 的使用场景是高频的小批量的导入场景因为每一次导入都会写一个part不停地写 part 会对集群产生压力。而 ClickHouse 的话对 ClickHouse 来说 part 越多性能越差所以使用 memory buffer 来缓存小批量的数据到达一定批次之后再进行导入。首先需要有一个事务的保证才能保证导入的完整性和一致性。另外它需要有WAL因为首先把数据要先写到 WAL 中数据写入到 WAL 中之后就认为导入成功了因为 WAL 本身也是一个持久化的存储数据写入 WAL 之后再将数据写入到 memory buffer。当数据写入了 memory buffer 之后就可以对外提供查询服务。 增强 Materialzed MySQL 实现方案 社区版 Materialzed MySQL 介绍 物化 MySQL 将MySQL的表映射到 ClickHouse 中 ClickHouse 服务会读取binlog并执行 DDL 和 DML 的请求实现了这种基于实现了基于 MySQL binlog 的实时 CDC 同步。它的架构很简单不依赖于数据同步工具使用自身的资源就能将整个 MySQL 的数据库同步到 ClickHouse中并且时效性很好因为实时同步的延时一般在秒级、毫秒级到秒级之间。 社区版本的这种物化MySQL 在很大程度上去解决了 MySQL 数据库到 ClickHouse 之间的这种实时同步。在实际业务、实际场景中遇到不少问题 1.社区版本的物化MySQL它是不支持同步到分布式表也不支持跳过DDL缺乏这些功能就很难将数据库的引擎应用到实际生产中。 2.社区版本的物化 MySQL 不支持在数据同步发生异常时进行辅助发生异常的时候发起重新同步的命令它没有同步的日志信息和没有同步的状态信息缺少了这些信息会导致同步发生异常的时候很难在短期内把这些任务重新启动。 基于这些问题和痛点 ByteHouse在社区版本的物化 MySQL 的基础之上做了一些功能增强易用性降低了运维成本让数据的同步更加稳定。 ByteHouse的物化 MySQL 结合了HaUniqueMergeTree表引擎结合这样的表引擎之后它就能够实现数据的实时去重能力同时它能够支持分布式的能力我们通过底层的中间的参数优化比如 include tables、 exclude tables、 SKIP DDL 等等能够允许用户自定义同步的表的同步范围。 通过下 model 这样的一个参数能够支持分布式表的同步然后通过 Rethink 参数的设置支持将额外增加的表启动独立的数据同步任务去进行 CDC 同步在出现异常的时候我们也支持跳过这种不支持的 DDL 语句。另外可以通过系统日志的抓取和展示进行可视化的运维。 ByteHouse增强Materialzed MySQL核心功能实现 实时去重 / 分布式 社区版的物化 MySQL 使用的是ReplacingMergeTree每一个同步任务都会将源端的 MySQL 数据库同步到 ClickHouse 的某一个节点上面它不支持按照分片逻辑将数据分布到所有的节点也无法利用 ClickHouse 整个集群的分布式计算和存储能力所ByteHouse的物化MySQL 支持分布式地同步利用。我们利用HaUniqueMergeTree表引擎将每张表同步到对应的分布式节点上充分利用集群的这种分布式计算能力同时通过表引擎的实时 upsert 能力来实现快速地去重。 异步 Resync 这里有三个对象 SYNC manager是用来管理主 SYNC 线程和 Resync 线程然后 SYNC task 和 resync task 各自管理各自的任务。比如说一个 MySQL 的库有 100 张表我们选了 50 张表进行同步所以在同步进行过程中当 think task 同步到 binlog 的 position 位置比如到 1000 的时候用户修改了配置之后它增加了 30 张表。增加 30 张表的时候 SYNC manager 就会启动 Resync task 去同步另外 30 张表那这个时候 SYNC task 是继续执行的RESYNC task 会从 position 0 开始它先做全量的同步然后再做增量的同步。所以当到达某一个阶段比如说 sync task 跑到了 position 1500 的时候 resync task 跑到了 position 1490 的时候这时 SYNC manager 就会去判断两者的误差这个 position 的误差在一定的阈值之内在一定阈值之内之后它会将 SYNC task 停止1秒钟将 RESYNC task 合并到 SYNC task 中。合并成功之后这 80 张表就都会通过SYNC task 继续同步而 RESYNC task 这个任务就会被停止掉。这就是现在 RESYNC task 做了一个能力实现。 可视化运维 通过可视化的任务监控和任务启停异常的重启任务告警这些方式实现了物化 MySQL 的可视化易用性的极大提升。 案例实践与未来展望 案例一短视频直播 该场景下的数据是批流一体写入为了维护和管理抖音创作者的数据并且面向这种业务运营和达人经营提供数据查询服务需要将短视频和直播的实时数据和离线数据做融合来构建 B端的数据分析。 问题 首先创作者是唯一的需要我们进行数据去重。第二数据源是比较多样化的所以它整个字段超过 4000 是典型的大宽表场景。第三T1的数据T1数据离线同步后T0数据要对它进行更新。第四是对任何指标的实时查询需要秒级出结果这是业务面临的问题。解决方案 第一我们采用了自研的 Unique表引擎来做实时的去重并且能够让数据在写入时就可以实时去重、实时查询。第二通过 Kafka 引擎的 memory table 来实现大宽表数据先缓存到达了一定的批次之后再集中刷盘。通过对 Byte house 的优化方案有效地解决了碎片化、IO负载高的问题能够支持 10 亿创作数据实时写入和实时查询。 案例二营销实时数据的监控 营销实时监控是对业务营销活动效果的实时查询和实时回收希望通过这种实时回收来动态调整奖品的实时发放策略来做到最终的 IOR、ROI 的提升。这就要求数据实时写入、落盘延时要非常低对数据处理的性能也有很高的要求。在数据传送上面需要保证数据传输的唯一性以保证奖品不会重复发放也不会丢失。 解决方案 我们在方案上首先采用自研的Kafka 引擎来支持流式数据的实时写入实时写入便实时入库。通过 low-level 的这种消费来保证数据的有序分片再通过增强的消费语义 exactly once 保证数据的精准一次传输。最后我们通过自研的Unique引擎来实现实时的这种 upsert 的语义让数据实时写入、实时去重。通过 ByteHouse 方案的优化营销业务的每一个节点的实时性能达到了 30 MB/s/node分析性能也是在秒级的延时让运营人员能根据不同用户群实时发放奖励并秒级地监控奖品发放的进展从而调整奖品的发放策略。 案例三游戏广告的数据分析 游戏广告数据分析是在广告业务中会做一些人群圈选、广告投放、效果反馈等投放策略用户行为预测这些全流程的统计和监控来实现广告营销过程的数字化提升整个广告游戏投放的 ROI 。 问题 业务数据和日志数据要求实时写入、实时去重由于体量比较大所以写入压力和查询压力都比较大。解决方案 首先使用 Kafka 引擎来支持流式数据写入通过 low level 消费模式保障数据的有序分片再通过 Unique引擎来实现数据的唯一性并且实时地去重。在业务数据方面我们使用物化MySQL来保障业务数据从 MySQL 到 ByteHouse 之间能够实时同步。最后使用自研的查询优化器来优化查询性能通过ByteHouse 的优化之后广告效果分析从原来的小时级提升到了现在的秒级延时数据查询的性能单线程同步 20MB/s 并且整个查询性能提升了 3 倍用户的收益和体验得到了明显的改善。 未来战略全链路和一体化 端到端。从语法转换、数据迁移到数据校验形成完整的全链路方案。一体化。通过DES的逻辑复制能力实现 TP / AP 的一体化同时实现数据仓库和数据集市的一体化。资源隔离。支持用户使用共享资源池或者数据库引擎来进行数据的同步也支持用户通过独享的资源池来进行高效数据同步。多引擎方案。除了基于 ClickHouse 引擎的基础能力我们也会去探索更多的底层引擎能力来增强ByteHouse的数据同步。
