- 快召唤伙伴们来围观吧
- 微博 QQ QQ空间 贴吧
- 微信扫一扫分享
- 已成功复制到剪贴板
StarRocks技术内幕 | 打造一款强大成熟的数据库有多难?
作者:康凯森,StarRocks PMC,负责查询方向的研发(本文转自其个人博客“编程小梦”)
从 2015 年开始,我在美团先后维护和研发过 Apache HBase、Apache Kylin、Apache Druid 和 Apache Doris,对大数据系统和 OLAP 数据库有了深入理解。
2020 年开始,我加入了 StarRocks 社区。我们先后打造了业界领先的向量化执行器、CBO 优化器、Pipeline 并行引擎、支持高效 Update 的存储引擎和极速数据湖分析。支持存储分离的 Cloud Native 版本也即将面世。
一路走来,随着 StarRocks 项目攻克一个又一个技术难题,解决一个又一个用户需求和难题,服务着越来越多的用户,我对如何打造一个强大且成熟的数据库有了更深的理解。在这篇文章中,我会和大家介绍打造一个强大且成熟的数据库都有哪些难点。
#01
本质矛盾
—
无论是一个年轻的社区团队,还是一家大公司的数据库部门,打造一款强大且成熟的数据库都会有下面两个本质矛盾:
有限人力和无限工作之间的矛盾
各种各样的用户需求,无止境的性能优化,永远也修不完的 Bug,一个又一个 Killer Feature 的打造,时刻不停的代码重构,增加不完的测试 Case,不间断的技术调研和系统设计。这些工作都需要大量人力,但无论哪家公司,人力总是不足的,优秀的数据库人才更是稀缺。
飞速增长与成熟稳定的矛盾
如果数据库的代码不大变,面对的应用场景不大变,我们让一个数据库变稳定会容易很多。但是如果一个数据库的代码在飞速变化和增长,应对的应用场景不断丰富和变化,让一个数据库稳定下来就会很难。
#02
定位和独特性之难
—
一款数据库想要在产品和商业上取得成功,想在很多竞品中脱颖而出,就必须有清晰的定位和自己的独特性。一款数据库的独特性就是自己的价值点,比如目前 StarRocks 的价值点就是极速统一。
一旦定位和独特性定义清楚,便意味着产研资源重心和方向的倾斜。而一款数据库想要让自己的独特性成为 Killer Feature,就必须超越所有竞品。这就意味着,这个数据库团队必须有足够强大的创新能力,足够强大的工程能力,才能做到其他数据库公司一定时间内无法做到的。
#03
架构之难
—
一个数据库的架构决定了一个数据库未来的上限,决定了一个数据库未来支持更多用户需求的难易程度。如果架构设计有误,后面的很多功能和优化成本就会很高,甚至无法实现。不过在当下,云时代数据库的架构逐渐趋同,想要有足够的独特性和明显的优势还是比较困难。
#04
功能之难
—
Killer Feature 的创新性和独特性
一般数据库在产品功能上肯定会推出几个 Killer Feature,作为自己产品的卖点。但是想作为 Killer Feature,就必须比竞品好很多,这时候 Killer Feature 就必须拥有一定的创新性和独特性。
持续不断的用户需求
用户越来越多,用户的需求自然就会越多,有些用户的需求很小众。但有时候为了服务一个用户,我们却不得不做,而且有时候做了还会给系统带来额外的复杂性。
各种各样的认证
认证里面的一些功能其实并不是你的数据库产品所必须的,做了不会明显增加产品竞争力。为了满足并获取更多企业级用户,还是得投入大量人力去通过认证。
用户迁移时的功能对齐
当一个新系统越来越好,要扩大市场规模,必然要去替换用户已有的旧数据库,但是替换过程中经常会遇到语法、函数、功能不对齐的场景。这时候,如果这个用户很重要,你就不得不去做一些和传统数据库功能对齐的事情。
系统越强大会越复杂
- 越强大的优化可能跨模块越多:比如 StarRocks 的低基数优化和导入、查询、Delete、Update、Compaction、Schema Change、 MVCC 等很多模块都有关系,所以这类功能的测试本身就会很复杂
- 一个新的功能或者优化可能会打破旧的功能或者优化的假设:比如 Tablet 并行可能和 Local exchange 有冲突,比如 Query Cache 可能和 Shared Scan 有冲突
系统越成熟,新的功能和优化要求越高,大规模使用周期越长
- 新系统的第一个版本往往会给用户建立一个 Baseline,之后的版本做的功能和优化就必须考虑所有用户的场景,在自己的用户场景下没有或者很少有 Bad Case
- 用户使用一个系统稳定后,升级的动力会越来越弱,所以越靠后的版本得到用户大规模验证的周期也会更长
#05
性能之难
—
CBO 优化器 Plan 的稳定性和正确性
- 统计信息的变化会导致查询 Plan 发生剧变
- 某些优化就是会导致部分查询变快, 部分查询变慢
- 选择度估计和基数估计一般都假设了数据的均匀分布,但这和实际情况并不相符
- 统计信息收集如何做到相对准确又不耗费大量的系统资源
单核性能优化
单核性能优化是一个没有止境的过程,我在 StarRocks 技术内幕:向量化编程精髓 一文中已经解释了单核优化的关键点和方法论,所有算子和函数的深度优化是需要数十人年的事情。
多核扩展性优化
StarRocks 单核性能登顶 ClickBench 后,我们在优化多核性能上投入了大量精力。相比单核,突破多核扩展性的瓶颈要更困难些,目前已经做了大量优化、还远远不够。不同类型的查询在高并发下会遇到不同的瓶颈:Lock,线程池,RPC,调度问题,NUMA,CPU Cache,内存管理,IO 异步等。
多机扩展性优化
多机的扩展性的常见瓶颈点主要包括:
- RPC 的扩展性
- 元数据的扩展性
- 如何解决数据倾斜
- 如何通过调度策略解决热点,充分调用整个集群的算力
- 优化器要确保每个算子,函数都可以生成分布式的执行计划,不会有单点执行的瓶颈
存储引擎的优化
存储引擎需要在导入性能和查询性能之间进行权衡,一般情况下,导入时候做的事情越多,查询时候的代价就更低些:
- 更新能力的持续优化
- 导入能力的持续优化
- 压缩和编码
- Compaction 策略的持续优化
- 事务能力的优化
- 内存使用上的优化
- 各个级别 Cache 能力的优化
针对特定场景的性能优化一般会增加系统复杂性
数据库一般都是面向通用场景开发,但是在特定场景下可以获取更多信息和上下文,这时就可以进行更多的针对性优化。但这样也会带来问题,比如系统的代码逻辑更加复杂,测试和维护的难度更高。
如何保证性能不退化
当系统复杂之后,多人协作经常会出现的问题是,一个人之前精心写的一段对性能影响很大的代码,被后人不小心改掉了。或者是优化 A 优化了某些场景的性能,但是却导致之前优化 B 的优化失效了。
如何能 Cover 不同的硬件环境
数据库这个复杂的软件是构建在硬件之上的,硬件是决定性能的基础。但是 CPU 有不同的型号,网络带宽有高有低,磁盘的吞吐和 IOPS 也有很大的差别,有可能一些软件层面的优化只对某些硬件环境生效。
#06
稳定性之难
—
一款数据库的成熟,主要体现在稳定性上,而打造一个稳定的数据库有如下难点:
SQL 是声明式的
- 机器可以生成成千上万行的 SQL,SQL 各种算子和函数的组合是无法穷尽的,要保证任何一条 SQL 没有 bug,是极其困难的
- SQL 里面的 Null 和 Nullable 是比较令人烦恼的,不仅对性能有很大影响,对正确性也有较大影响
成百上千的用户场景
每个用户的硬件配置,环境信息,应用特点不一样,都可能引发不同的问题。
各种各样的集群规模
很多时候,只有当集群规模、数据量、并发量到一定程度,一些稳定性和扩展性的问题才会暴露出来。如何在产品发布之前,在有限的资源下,通过测试暴露这些问题也是一个难点。
功能的组合
很多时候,一个功能单独 Work 没有问题,但是多个功能相互影响时,一些 Bug 才会暴露出来。比如节点下线,触发数据的均衡和复制,又会触发数据版本的问题,进而触发查询的问题。比如导入、查询、Compaction、系统任务对 IO 资源的共同影响,这些复杂功能组合时的测试难度会更大。
函数的预期行为没有标准
比如 Date 类型和数字的比较,字符串和数字的比较,应该是直接报错还是隐式转换,隐式转换的公共类型转成啥。这些其实都没有统一的标准,每个数据库都有自己的实现。关键问题是即使改成最合理的表现,一些用户可能会因为习惯自己熟悉的数据库的表现,觉得当时最合理的表现是不合理的。
还有聚合函数溢出后行为,Decimal 运算精度的确定,函数一些异常行为是抛异常还是转 Null。我们不仅要兼容用户期望的行为和正确性,还要兼顾正确性和性能。
多版本维护
由于快速迭代和发展,我们必然要维护很多版本,这给稳定性提出了更大的挑战:
- 定位,复现问题成本会更高,比如研发得用指定版本的代码部署环境,复现问题
- 解决问题后,也必须给所有版本 Cherry-pick,这时候很容易遗漏某个版本
- 要确定某个 Bug 到底在哪些版本修复了,成本也比较高
- 某个版本发生大的改动或者重构,之后的 Bug Fix PR Cherry-pick 就无法自动化,人工操作的成本会很高
兼容性问题
当我们维护很多个版本后,有时候不得不做一些不兼容的改动:
- 之前的行为本身是错误的或者不合理的
- 想完全删除某些旧代码
查询层是无状态的,所以不兼容的改动一般可以绕过或改 SQL 解决。但是存储层和元数据层是有状态的,一旦有不兼容的问题会很麻烦。
不同语言的行为不一致
对于类似 StarRocks 这种多进程、多语言的数据库,在稳定性问题上还有一个额外的挑战是:
- 不同语言的一些标准库行为会不一样,这会导致在不同模块计算相同函数的结果不一致
- 之前遇到不同语言 Java 和 C++ 取余的结果不一致
这几年来,我遇到过挺多这样的 Case。
编译器的 Bug
一般编译器被各种项目大量使用,我们开发者遇到 Bug 的机会比较少。
不过在开发 StarRocks 向量化的过程中,我就遇到了一个编译器的 Bug:编译器进行向量化优化后,把 Boolean 值转成了 255:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97255
还有最近遇到的一个 C++ 正则标准库的 Bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164#c8
分布式相关问题
现在的数据库几乎都是分布式数据库,所以分布式系统遇到的问题,一般数据库都会遇到。比如分布式系统的常见挑战:单点故障,部分失败,不可靠的网络,不可靠的时钟。
硬件故障
数据库的存储引擎必须保证数据能被正确地存储和读取,但是我们在实际环境中不可避免会遇到各种硬件故障:磁盘坏掉,磁盘数据错误,服务器宕机,机房断电,网络异常等。
#07
生态之难
—
数据导入
- 数据格式的多样性:CSV,JSON,Parquet,ORC,ARROW 等
- 数据源的多样性:Local File,Kafka,Hive,数据湖,传统数据库等
- 导入时支持 Transform (表达式计算)
数据导出
- 导出格式的多样性
- 导出位置的多样性:客户端,本地,分布式存储等
- 全量导出和部分导出
BI 工具:数据可视化
市面上流行的 BI 工具多达几十种,每种 BI 工具深入使用后都或多或少会有些兼容性问题:Session 变量的兼容性,数据类型的兼容性,函数的兼容性等。要尽可能完美地兼容,必然有大量的人力投入。
数据迁移
要支持用户从传统数据库和各种竞品数据库顺滑迁移,就必须和各种数据库进行对接,这里面有大量琐碎的工作。
比如我们想将 Presto 的用户迁移到 StarRocks 上,我们就需要在 SQL 语法层进行兼容。
比如单机数据库上一些很容易实现的功能,在分布式数据库上就会相对困难,这时候如果为了功能对齐,就需要不少的工作。
#08
安全之难
—
安全包括:认证,鉴权,审计,加密,脱敏等。这里面每一项都有着大量的工作,对于金融、政府客户、安全体系要求很高,公有云上的安全要求则会更高。
#09
易用性之难
—
在未来,毋容置疑,易用性会越来越重要,并将会是一款数据库的核心竞争力。数据库分析师需要知道的数据库知识会越来越少,需要进行的操作会越来越少。易用性主要体现在 3 个层次:
- 架构层面的易用性:比如自适应执行,Automatic Clustering,Automatic Index,Automatic Scale 等。
- 产品层面的易用性:比如接口定义和功能上是不是足够简洁清晰,一个命令可以导入各种数据源,各种数据格式的文件,一个命令可以查询各种数据源、文件等。
- 细节层面的易用性:文档是否完善,报错信息是否清晰易懂,可观测性是否足够好。
#10
难点如何解决
—
在你将这些点一个一个深入思考下去,肯定会理解打造一个强大且成熟的数据库是多么困难,那么这些难题如何解呢?
欢迎关注 StarRocks 微信公众号,后续我们继续探讨、揭秘!
关于 StarRocks
面世两年多来,StarRocks 一直专注打造世界顶级的新一代极速全场景 MPP 数据库,帮助企业建立“极速统一”的数据分析新范式,助力企业全面数字化经营。
当前已经帮助腾讯、携程、顺丰、Airbnb 、滴滴、京东、众安保险等超过 170 家大型用户构建了全新的数据分析能力,生产环境中稳定运行的 StarRocks 服务器数目达数千台。
2021 年 9 月,StarRocks 源代码开放,在 GitHub 上的星数已超 3600 个。StarRocks的全球社区飞速成长,至今已有超 200 位贡献者,社群用户近万人,吸引几十家国内外行业头部企业参与共建。