StarRocks 2.0，新一年，新启航，新极速！
2022年，它来了。
2.0版本的 StarRocks，它也来了。
2021年刚刚过去，回望这一年间经历的林林总总，每一个亲身经历 StarRocks 发展的小伙伴们，心中都不免泛起涟漪：
2021年1月底，StarRocks 向量化1.0版本首次面市，记得当时还有些许小“激动”，新产品刚“呱呱坠地”，就具备了和全球最快开源系统不相上下的单表查询性能。最近一年，我们一直在致力于重新定义单表极速查询速度，在2.0版本中，StarRocks 创新性的实现了基于全局字典的低基数字符串查询优化，进行了大量 CPU 指令级优化，等等，在单表查询场景下，2.0版本的性能可以达到老版本的2倍左右，也实现了对原有“世界最快开源系统”的大幅超越，这是 StarRocks 不断践行“实现不可能”所取得的新成果。2.0发布之际，社区每一位参与开发的同学，内心已然“一团火热”，欢迎大家测试体验，真实感受这耳目一新的极速分析！
为了获取极速的分析效果，很多业务用户被迫将多表数据打平成大宽表，而在这背后，数据开发工程师们承受了多少不为人知的心酸。2019年12月，为了让用户无需复杂预处理，直接基于多表数据获取极速分析体验，StarRocks 开启了自我颠覆之路：全新编写一个 CBO 优化器（基于代价的优化器）。这其中的难度，就像是“从北坡攀登珠穆朗玛峰”，相信研发者应该深有体会。但要想实现全场景极速分析，这是无法绕过去的一道坎。经过一年多的攻坚克难，2.0版本的 CBO 优化器已经基本成熟，对更多的多表复杂查询类型可以实现2倍性能提升，完善性和稳定性也大幅提升。相比其他开源系统，可以实现5-10倍的性能优势，StarRocks 实现了前所未有的从“单表极速”到“多表极速”的史诗级跨越！
2021年5月，随着实时分析场景对数据的更新需求逐渐增多，StarRocks 又开始摩拳擦掌了、准备大展拳脚啦！当时OLAP系统往往采用 merge-on-read 的模式来完成数据更新，但这种大幅牺牲了查询性能换取较好的导入性能做法并不是最佳方案。于是 Primary Key 模型闪亮登场！新的存储引擎采用了 delete-and-insert 的方式完成数据更新，可以在实时更新场景下带来了3-10倍的查询性能提升。经过6个月的打磨，2.0版本将正式发布 Primay Key 实时更新特性。用户再也不用为“实时更新”而头痛不已！
2021年6月，研发 Pipeline 执行引擎被提上了日程，这个特性致力于大幅提升 StarRocks 在多核机器上的并发处理能力和复杂查询的性能。这是一个从零开始的工作，做了大量前人从未有过的探索，靠的就是一股“实现不可能”的劲头。在2.1版本中 Pipeline 执行引擎将和大家见面，在这里卖个关子，期望用户们多多提交真实使用体验，我们承诺：包您满意，不玩虚的！
稳定性是用户大规模使用的根基，近半年来， StarRocks 一直在不遗余力的全面解决稳定性问题。在2.0 版本中我们重新设计了内存管理模式，将根本性解决了 BE OOM 的问题。随着2.0版本的发布，相信大家在新的一年能够更轻松的使用 StarRocks！
2021年9月，StarRocks 源代码开放，并开启全球化社区建设的新篇章！先看一组小数字吧：
开放源码114天，共计75位贡献者，每月活跃40+贡献者，产生了1238次 Commit，获得1900颗 Star。
组织了8场社区线上和线下 Meetup，活动累计覆盖人数超过5000人。
社区吸引了85家大用户（估值或者市值在十亿美金以上）使用 StarRocks，并仍在飞速增长中。
StarRocks 致力于开创极速统一的全新数据架构，全面升级数据驱动的速度、灵活性和实时性！2022年的目标就是：从“多表”场景领先者到“全场景”领先者，做世界第一的极速全场景分析型数据库，帮助更多的用户实现极速统一分析。也许有人会质疑、会说不谦虚、不 Peace。StarRocks 成立还不到2年，正是茁壮成长的时期，正是敢想敢干的年纪，我们坚信：只有伟大的梦想才能铸就伟大的产品！
StarRocks 在各种分析场景表现得都很出色，用户也在用 StarRocks 承接越来越多业务。每个业务方都不想被其他业务影响，平台方又不想维护多套集群。怎么办？
StarRocks 会推出新的资源管理机制。新的资源管理机制可以支持“资源组”，可以为需要隔离的业务设置单独的资源组，这样就能够保证此业务能获得充足的资源配额，不会被其他业务干扰，另外这个业务也不会干扰其他业务的资源使用，这样就可以让不同的业务跑在一个集群中。一方面解决平台方运维多套集群的压力，另一方面让不同业务之间可以很轻松的共享集群，提高资源利用率。
在近期大规模的用户访谈调研中，多表物化视图是呼声非常高的需求之一。想用户之所想、急用户之所急是 StarRocks 在需求设计上的重中之重。
当发现某些查询性能不足时，用户可以通过创建物化视图来加速。当前 StarRocks 的物化视图能够同步构建、查询时自动路由。同步构建是指，原始表的数据发生更新时，物化视图中的数据也能够做到同步更新。查询时自动路由指的是，StarRocks 会在查询规划时，计算不同查询规划的代价，选择最合适的物化视图来支持具体的查询。这里能够做到对于用户的查询透明加速的能力。
但是当前并不能够支持多表的物化视图能力，以及在物化视图上更加灵活的表达。在2022年 StarRocks 会完成对多表物化视图能力的支持，并且支持物化视图中更灵活的表达。StarRocks 期待通过创建物化视图，简化整个数据加工的过程。过去为了创建一个数据模型，可能还需要数据工程师开发。如果有了更加灵活的物化视图表达能力，那么分析师通过创建各种物化视图，就能够直接获得最终构建的模型。这样可以使数据分析变得更加的敏捷。
除了能够支持多表物化视图之外，StarRocks 在物化视图的维度还会引入智能推荐等能力。通过对于用户查询的分析，智能的推荐用户创建物化视图以加速用户查询。
当前 StarRocks 的架构模式还是存储与计算耦合的模式。这样的方式会为用户带来极致的查询性能。但是由于两者耦合没有办法按需的进行资源分配，有时会带来不必要的成本开销。
随着当前用户的基础设施越来越多的构建在公有云或私有云上，OLAP 系统也应该顺应时代发展趋势，更好的利用云环境所提供的资源弹性的能力，为用户带来更多的资源节省与灵活性。
StarRocks 期待在2022年进行存算分离架构调整。我们想做的事在整个业界都是有挑战性以及开创性的：一方面，StarRocks 的存算分离需要做到离线与实时兼容；另一方面能够做到公有云与私有化部署兼容。除此之外，StarRocks 的架构还要能够更好的支持多云架构。
存算分离的工作我们会与社区的小伙伴一起来完成，通过一套技术架构，来满足各类需求。
当前 StarRocks 更多承载的是数据仓库的能力。用户会把价值含量更高的数据导入到 StarRocks 中完成极速分析。价值含量不高的原始数据都存放在数据湖中。综合来看，用户既有针对数据湖数据的极速分析需求，也有数仓数据与数据湖数据的关联分析需求。
为了能够让用户具备更好的湖仓分析体验。StarRocks 将在新的一年里重点增强数据湖分析能力。我们期待通过 StarRocks 的努力，不仅能实现用户对数据湖进行极速的分析，也能够让用户通过 StarRocks 完成数据湖与数据仓库的统一分析。
当前 StarRocks 社区已经联合阿里云完成了支持 Iceberg 查询的第一期开发工作。从最新的测试效果上看相比于 Trino 会有5倍的性能提升。未来还会陆续完成对 Hudi 的支持，以及完善更多的功能。StarRocks 诚挚的邀请社区有兴趣的小伙伴参与进来共同建设。与此同时，在1月份阿里云 EMR 即将开启 StarRocks 服务公测，更多云厂商的服务也在路上，敬请期待！
不少用户都期待将 StarRocks 的极速能力用于数据加工处理场景（比如当前用 Spark 或者 Flink 完成的 WorkFlow），甚至已经有不少用户已经在这条路上开始了真正的实践。
StarRocks 会在2022年增强批处理以及流处理的能力（这并不意味着会解决所有用户的所有批处理场景）。在数百台节点规模下，StarRocks 非常有信心能够提供流批一体解决方案。这样用户既可以通过 StarRocks 完成对于原始数据的加工，同时加工后的数据又可以被 StarRocks 分析。届时，通过 StarRocks，用户将可以打通数据极速处理到数据极速分析的链路，从而实现更多层面的统一。
雄关漫道真如铁，而今迈步从头越。
让我们共同期待在新的一年，这五件大事能够一一得到实现，在创造未来的路上，StarRocks 希望能携手更多的社区开发者与用户，勇攀高峰！
2022，我们来了！