最近几个月，一直在做一个调研，就是做一些数据湖仓的建设，期间尝试了很多种数据引擎，既有clickhouse这种大家都很熟悉的产品，也有prestodb这类之前相对不怎么熟悉的工具。当然，这里面也少不了国产数据库，其中selectdb的测试给我带来一些不一样的东西。
先说需求，三个刚需：数据湖仓查询、联邦查询，实时数仓，接下请允许我来逐个描述。
数据湖仓查询
现在每家券商有大量的外部资讯行情历史数据，这些数据不一定会全部用到，但是需要储备。业务部门在需要的时候，要提供查询方式。过往的常见的方式是hadoop保存，或者落盘CSV文件到存储。需要的时候，按照需求来查询。
而在我们公司，hadoop没有引入，而是落盘CSV到对象存储中。对象存储之上使用了开源的数据湖仓技术，例如Iceberg或者hudi。这样好处是把成本降到最低，并且有统一的catalog管理，数据可以以parquet等格式存储。以及湖仓技术的时间穿越特性，都能带来更灵活的数据查询。但是查询引擎用什么，这个就需要满足如下几个需求：
1. 支持多种湖仓catalog。在catalog里保存着海量的元数据信息，这些如果不能通过直接读取外部catalog获取，再从数据湖中捞，是一个工作量很不确定的工程。
2. 支持存储分层。通常来说，都是以时间戳来判定，例如上一个自然年的数据进入冷数据，而今年的数据热数据。这样有助于把常用数据放到更高效的存储，冷数据继续放到CSV。
3. MySQL兼容。现有的很多资讯数据库以及业务部门基于资讯数据库的SQL方言，都是MySQL的。如果换个平台再重新调整，不确定性太强，这也是舍弃了clickhouse的重要原因之一。
基于这一个场景的三样需求，对selectdb做了调研和测试，iceberg查询能够支持多种catalog，虽然用得最多的那个catalog可能目前还不支持，与原厂工程师做了沟通，已经在计划之内。使用了CREATE POLICY特性来尝试做冷热分层，这部分整体的性能反馈还是能够符合业务需求，也多少让我有点意外之喜。而MySQL语法支持，DDL部分需要做改写，而业务场景的DML在我手头测试的部分目前尚未出现不兼容情况。
整体来看，数据湖仓功能能够满足我大部分的需求，而catalog的支持，会在后续继续测试。
而我个人猜测，在olap这条赛道已经足够卷的情况下，未来无论是社区版的doris还是企业版的selectdb，湖仓的支持，都将是一个重点发力方向。尤其是对多种新的湖仓技术的进一步支持，跟进对方的技术演进。
联邦查询
联邦查询我试了prestodb，这个工具最早成名就是靠着联邦查询而来。prestodb的使用配置都比较方便，而且扩缩容也很方便。但是功能上，却支持不了实时数仓的需求。
手头现有的数据源，既有离线的CSV文件，又有在线的Oracle、MySQL、PostgreSQL。系统建设过程中，因为各种调整变动都比较频繁，经常会有临时的跨源查询需求。现在的做法是通过ETL导入数仓，再从数仓查询。缺点是很多数据无法在T日获取，而且不够灵活。作为曾经（失败的）产品经理，仍旧是提炼出几点需求：
1. 支持直接查询，可以是外表也可以是物化视图。而不是通过创建ETL任务或者导出离线文件的方式。很多查询可以直接在备库上上完成，所以系统负载其实不需要考虑太多。
2. 支持多种外部数据源的类型。传统的关系数据库、离线CSV、湖仓存储的数据文件甚至个别在线的行情数据。
关系型数据库的三件套OMP的查询，在selectdb的测试中都可以实现，配好JDBC连接字符串，这一部分配置相对比较容易。而且从我测试来看，直接外表查询的性能也可以接受。hudi、iceberg、hive这些湖仓体系都支持。当使用这些技术的时候，从执行计划来看，对象存储性能是主要瓶颈，计算的开销并没有特别多。一条查询从两个catalog里即可捞出数据做查询：
SELECT e.employee_id, e.name AS employee_name, d.name AS department_name FROM (SELECT * FROM oracle_catalog.employees) e JOIN (SELECT * FROM hudi_catalog.departments) d ON e.department_id = d.department_id;
其中oracle_catalog是我配的oracle数据源，hudi_catlaog是保存在hudi的表。如果是常用的查询结果也可以考虑用物化视图的方式保存下来。
实时数仓
这部分之所以放到最后，其实是因为doris或者selectdb就是靠这个成名的。也是客户案例中最多的一趴。
当前我们的指标体系以及客户比较关心的数据内容，在实时性上都存在着一些gap，业务部门也需要做一些实时行情的测算，可能是策略的、风控的、反洗钱的等等。如果按照传统数仓的建设模式，那就都T+1见吧。传统大而全的数仓，在当下来看，更适用于业务整体数据的统计分析汇总，而很多局部且实时性需求很高的数据，就需要依赖于实时数仓。
这个场景的具体需求如下：
1. 不要产生太多生产库的额外负载。数据同步最好是基于日志模式的数据同步，多年前用过某供应商基于触发器的数据同步，留下的阴影至今还在。
2. 实时性高。这句话是一句正确的废话，要不然怎么做实时。上游系统发生的数据变动，能够以秒为单完成实时计算并提供查询。
3. 物化视图。很多指标的计算，尽量以物化视图的方式实现，而不是频繁的在实时数仓中做查询。
在测试selectdb的过程中，主要还是以flinkcdc这些实时CDC工具为主，前两项需求基本都能满足，而且基于selectdb的列式存储，查询性能也能够得到保障，比起之前的mysql，性能提高数十倍。
物化视图，同步异步两种刷新模式我都做了测试，而当时测试的2.x版本，只能支持单表创建，对于多表查询的物化视图尚不支持。与原厂开发人员做了沟通，他们也给了我开发团队的考虑，这一点也能够接受。依托selectdb自身的多表join性能，在我测试的过程中，未发现性能瓶颈。
总结&猜想
如果以一个现代湖仓一体的建设体系来看selectdb2.x的版本，是一个能够满足我当下大部分需求的产品。当然，诸如catalog种类、多表物化视图等等，未来也许都不是问题。在写本文的过程中，也看了3.0版本的新特性。存算分离是3.0的一个很重要的方向。尤其是公有云或者私有云部署，存算分离带来的弹性扩缩容以及防止出现热点的情况，相信都可以有所改善。
selectdb也提供了ui的管理工具，无论是部署还是日常管理，效率都比较高，也是我用过的国产数据库ui工具中做的不错的一档。
3.0的的一些特性测试，我打算近期开始，届时有没有新的想法和回顾，还请继续关注。
