干货共享 | 分布式列存数据库在同程旅行的应用

2020-12-29 00:00:00 数据 数据库 技术 分布式 副本

点击上方蓝字关注我们


2020年12月21日~12月23日，由 IT168 旗下 ITPUB 企业社区平台主办的第十一届中国数据库技术大会（DTCC2020），在北京隆重召开。大会以“架构革新 高效可控”为主题，设置2大主会场，20+技术专场，将邀请超百位行业专家，重点围绕数据架构、AI与大数据、传统企业数据库实践和国产开源数据库等内容展开分享和探讨，为广大数据领域从业人士提供一场年度盛会和交流平台。


本文由DTCC2020特邀嘉宾同程艺龙存储与公共服务研发部-王勇分享整理而成。他分享了分布式列数据库在同程艺龙的应用，现场受到了高度关注，干货和大家一起分享~


与很多互联网公司类似，随着业务规模的持续增长，同程艺龙的数据库走过了一条从商业数据库到开源到分库分表的演进之路。近年来随着一致性协议与分布式事务技术的发展与技术中台定位的明确，业界纷纷走向分布式数据库研发之路。本文将介绍同程旅行在分布式列式存储数据库方向所做技术选型，技术特性实现，及业务推广经验。


▍一、背景介绍


1.1 内部背景


通过现状调研，总结了数据库方向未来需要解决的问题：
1. 需要一个原生的分布式解决方案，以应对规模增长问题
2.  需要一款列存引擎以解决实时的OLAP场景（如实时指标报警）
3.  需要解决运维复杂度问题，例如在线缩扩容，动态加列，加索引

4.  需要具备异地多活、双中心部署能力，以匹配公司的双中心建设

5.   需要具备云原生特点，以匹配公司的k8s云原生规划

6.   需要同时提供OLTP与OLAP能力，以减少一套数据部署在多套异构数据集群造成的数据冗余

以上是分布式列存数据库项目的内部背景。



  1.2   外部背景



▍二、列存数据库选型


2.1 核心技术对比



2.2 技术选型



▍三、架构及核心特性


3.1 基础架构



3.2  核心特性



3.3  存储模型


▍四、列存的技术实现


BaikalDB核心特性已经可以满足公司的大部分需求，核心特性只缺一个：列式存储。于是我们给BaikalDB研发列式存储引擎，并贡献给开源社区。本章节讲主要介绍列存的技术实现。


4.1  列式存储



列式存储的优点：

•    减少IO：宽表少列情况下只读需要列，更新部分字段时只写涉及列

•    利于压缩：列针对性压缩同构的列值连续摆放在一起，字节上重复的部分很多，因而信息熵很低，可以充分利用压缩

•    利于缓存：I/O的降低，提高缓存效率

•    向量化查询：以块的形式处理数据

•    延迟物化：只解析与SQL有相关性的列并过滤，减少非必须列的扫描


4.2 设计实现



上图主要介绍列存在数据结构的变化，主要思想通过修改kv层的编码方式，来改变数据的布局，使其按列排列，达到列式存储的目的，后续进一步实现其事务，扫表，过滤，压缩等相关算法。


4.3   相关优化


然而仅仅改变数据的布局，并不能显著提高查询性能，还需适配列存做的一系列优化来提升性能。


  •  减少I/O：也可以成为延迟物化技术，核心思想是不同于行存的整行处理，列存在读，写，过滤环节可以尽量只处理涉及列，从而使I/O请求降到少。例如我们在插入一行订单数据之后，需要反复更新订单状态，这个Update操作只涉及少数列，行存时必须整行取出，更新完再整行存入，列存可以只更新订单状态这一个字段。再比如查询时往往一个SQL中filter和project只会涉及到整行数据的部分列，但在传统行式存储下这些计算过程需要先将整行数据（因为整行数据是放在一起的）解析和提炼出来（虽然可以只选择与SQL有相关性的列参与后续计算，但整行解析的过程是少不了的），然后再做一些丢弃；而在列存中，每个列存储上都是独立的，因而真的可以做到只解析与SQL有相关性的列并过滤，不同列之间以position（偏移量）作为行关联的依据。针对不同列的不同filter，终产生多个position列表（列表可以是bitmap，也可以是range，类似于run-length-encoding）的中间结果集，然后多个结果集合并后，后组装行结果时再查找真正需要project的列。很多聚合与选择计算，压根不需要整行数据，过早物化会浪费严重。

  • ZSTD压缩：ZSTD压缩采用字典压缩，更适合列式重复度的布局，我们在列存上给BaikalDB增加了ZSTD压缩的选项

  • 并行化：可以通过调整BaikalDB的Region大小，分区设置来提高列式执行计划的并行度

  • 向量化查询：不同于行式的火山模型，在列式存储下，我们采用向量化模型进行TableScan算子操作，提高了Cpu Cache Locality

  • RocksDB读优化：作为baikaldb存储层的核心组件，rocksdb提供了丰富参数用于在读放大，写放大，空间放大三者之前做Trade off，我们针对列存场景做了参数的特定优化，包括write_buffer_number，level0_file_num，partitioned_index_filters等，有效的减少了读放大。


▍五、公司的业务应用


5.1   迁移与测试


就业务测试角度，重点在真实模拟线上，即数据实时同步与线上完全一致，同时承载线上真实写请求与读请求，7天稳定运行，来验证承载力与稳定性。


就迁移而言，数据端通过数据库中间团队研发数据同步平台进行实时增量同步，可以做到10ms内延迟，业务端只需修改一下数据库连接的ip即可随时上线，对业务影响做到小化。


5.2   上线效果


以支付指标预警系统为例，上线后，全部12个核心指标查询场景性能均提升10~50倍，百亿级别数据量，上线至今已稳定运行9个月，可用率。


5.3   部署情况



应对双中心或者异地多活需求，左图是当前部署情况，以3副本为例，其中2副本可以部署在主城市（或主机房），另1副本可以部署在副城市（或副机房），由于Raft的多数写成功即可成功，主节点含有多数副本，可以做到写发生在主机房，避免写跨中心访问延迟，读操作提供就近读功能，避免了跨中心访问的读延迟。


目前BaikalDB支持表粒度的行列混存，即建表时可以指定存储引擎类型，未来我们在探索副本粒度行列混存技术，即在同一张表的3副本中指定（2行1列或1行2列）有望进一步降低50%的副本数从而节省成本，此技术尚在研究阶段，目前仅TiDB进行了实现，并且取得数据库会议VLDB 2020年佳论文。此技术领域比较新，除数据库本身需要做大量改造外，还需要修改一致性协议，TiDB是通过修改Raft协议增加Raft Leaner角色来完成的行列副本同步，由于Leaner只能作为从节点，所以Tiflash不具备写能力，仅提供OLAP场景的读查询，TiDB 正在开发的5.0版本中，已经在为TiFlash的写能力在做相关研究。我们希望BaikalDB的行列混存是完全对等设计，均可承担读写操作，相关技术实现目前业界还是空白，探索中。


▍六、第十一届中国数据库大会的感受


公司的提前布局很重要：两年前Peter在办公室的小白板上，向我们勾画未来关于分布式列存数据库的一些方向性的思考，随后伟伟向我推荐了开源不到半年的NewSQL数据库BaikalDB，在公司创新环境的支持下（如超哥的业务中台把支付库拿来作为产品落地的个业务用户，鹃姐的运维团队一直在提供DBA运维与数据工具的支持），在开源社区的帮助下（社区伙伴周末带着孩子还在帮我们改bug到半夜），又通过大家近两年的努力，这款分布式数据库已经在公司20个业务进行了落地，涉及BG包括研发中心，机票，文旅，客服，涵盖了支付、指标、财务，商品、订单，报警，调度，调试，视频等多种场景。提前的布局使我们在这个领域略有基础，在DTCC 2020大会才可以与同行进行深入交流，取长补短。


NewSQL已是会上热的话题：国产数据库也在蓬勃发展，大会主持人侯老师说已有100多款产品在这个赛道竞技，会上有人提出NewSQL进入了春秋战国时代，尚未看到一款产品一统天下。


列存愈发重要HTAP成为趋势：从今年五月份的列存引擎tiflash的发布，到oceanbase宣布今年的发力ROLAP，还有深耕多年的阿里云AnalysticDB，加上近热度极高的列式引擎ClickHouse，列式存储引擎在NewSQL领域也在快速发展，行存与列存的融合，HTAP（混合事务分析处理）能力也将成为未来的一大趋势。


新技术的交叉融合：AI与数据库的融合，云原生与数据库的融合，搜索与数据库的融合，新硬件与数据库的融合。


ABC时代的到来： AI for BigData， BigData for AI， Run On Cloud。





精彩推荐



宋宝华： Linux为什么一定要copy_from_user ?
提升开发效率N倍的20+命令行神器!(附 demo)
4 种数据库缓存终一致性的优缺点对比？终选择方案四！
喜欢就点个在看再走吧

相关文章