泽拓昆仑(Klustron)分布式数据库根植于MySQL和PostgreSQL开源生态，与开源生态完全融合和兼容，这样的兼容能力是Klustron的一个强大而独特的能力。基于此能力，不仅用户原来使用MySQL或PostgreSQL的应用软件和后台系统不需要任何修改就可以直接使用Klustron，而且用户可以充分利用MySQL和PostgreSQL开源生态的大量技术资源和人才资源，其中技术资源包括功能扩展组件，知识经验等。
基于Klustron独特的能力，我们提出了“泽拓昆仑Klustron融合数据管理和分析平台(Fusion Data Management and Analysis Platform, FDMAP)”的理念，包括以下四方面的内涵，也是本文的主要内容。
- 融合多模型数据：关系模型，extended by JSON, GIS,向量三种复杂数据类型。
- 融合多种来源的数据： 集群本地，外部数据库，外部对象存储。
- 融合开源生态组件：PostGIS，PostgresML，Apache MadLib, PGVector, PGEmbedding等等。
- 融合用户自定义算法：多语言(python, java, perl, lua, javascript, PL/SQL）存储过程。
在此基础之上，我们提出了可扩展的AI数据基础设施(Scalable AI Data Infrastructure)的概念，我们认为这是各行业的大模型对数据管理的基础要求。
01 利用PostgreSQL开源生态的扩展组件
泽拓昆仑Klustron的计算节点Klustron-server保持了PostgreSQL完整的extension（扩展）机制，所以绝大多数PostgreSQL开源生态的扩展组件可以自动挂载到Klustron-server正常运行，极少数例外包括PostGIS和PGVector --- PostGIS定义了geometry/geography系列新的GIS数据类型，并且需要在Klustron-server中支持与Klustron的存储节点Klustron-storage交换这些GIS数据，因此需要对PostGIS做少量扩展完成与Klustron-storage节点的数据交换。
PGVector 实现了向量索引，但是在Klustron中向量索引必须存储在Klustron-storage节点中，但是Klustron-storage没有向量索引，需要开发对应的向量索引功能来实现对PGVector的支持。Klustron-1.3版本将会支持PostGIS和PGVector，目前dailybuild的Klustron版本已经可以支持PostGIS，欢迎大家使用，用法与PostGIS完全相同。
Klustron通过支持PostgreSQL开源生态的所有扩展组件，不仅自动扩充了Klustron自身的功能，而且也扩大了这些组件的能力范围，因为它们原本只能运行在PostgreSQL实例上面，其能力受限于单台服务器的计算和存储资源。特别是诸如机器学习，OLAP分析、存储过程等计算密集型任务会严重消耗有限的CPU资源，如果没有做读写分离的话，很容易导致PostgreSQL数据库的TP性能下降，即使做了读写分离，能够提供的此类任务的并发执行数量也非常有限。
而在Klustron分布式数据库集群上面，这些组件可以操作和管理的数据规模上不封顶，按需弹性伸缩；Klustron可以利用的计算资源和存储、网络带宽上不封顶，按需弹性伸缩。所以说Klustron让这些组件突破了PostgreSQL受限于单台服务器硬件资源的扩展性难题，可以利用大量服务器的硬件资源实现数据管理和查询分析功能。
不仅如此，Klustron的多层级并行查询处理和JIT等查询性能增强技术，还可以显著提升OLAP分析任务、存储过程和机器学习等计算的性能，这些能力也是单机PostgreSQL不具备的。
无需任何修改就可以自动支持的PostgreSQL组件数量庞大，本文不一一列出，仅特别强调一下下面这几类独特的组件。
-
机器学习组件
PostgresML是知名的PostgreSQL开源生态中的机器学习组件，而Apache MadLib也是Apache社区支持PostgreSQL的一个机器学习组件。Klustron分布式数据库支持这些机器学习组件，这样用户可以在数据库内运行机器学习算法，这样做的价值在下文中详述。 -
FDW组件
使用PostgreSQL的FDW组件，可以让Klustron的计算节点从各种第三方数据源（例如其他数据库系统，公有云对象存储系统S3,OSS，以及hbase/hive等等）读取数据，与集群中的数据统一做查询和OLAP分析。在Klustron中使用FDW的注意事项在下文详述。 -
存储过程语言组件
Klustron支持PostgreSQL的所有存储过程语言组件，包括PL/SQL, plpython, plperl, pltcl, pllua, plv8, pljava等，让用户可以分别使用PL/SQL, python, perl, tcl, lua, javascript, java语言来编写存储过程在Klustron的计算节点运行，以便在Klustron的计算节点中运行用户开发的数据处理逻辑。使用诸如python, java等语言写存储过程可以使用到python，java语言的各种算法库，快速开发功能强劲的数据处理算法。
用户在Klustron集群中可以放心地大量使用存储过程完成库内的计算和数据处理，不必担心存储过程对计算资源消耗过大 --- 只要部署若干个计算节点专用于运行存储过程的计算任务并且按需增加服务器即可 --- 这样可以避免库内外搬动大量数据的网络带宽开销和时耗，从而获得更好的性能。
02 新型数据管理范式
2.1 数据库内的计算和数据处理
以前在单机数据库时代，由于所有数据存储在同一台计算机服务器中并且所有的事务处理都在此服务器中运行，对数据做大规模复杂分析计算任务的实现方法通常是在应用软件模块中实现计算逻辑 --- 应用系统运行时把数据取出数据库外传送到应用服务器中运行这些计算逻辑完成计算，这样可以避免数据处理逻辑与数据库系统的关键任务（比如事务处理，数据写入等）竞争计算资源而影响了关键任务的性能。但是代价就是搬动大量数据，对网络带宽形成较大压力并且收发数据会显著增加数据分析处理任务的时耗，并且应用服务器中通常缺少在数据库系统中的那些应对海量数据的基础设施(buffer pool, 临时表，外存索引等)，从而导致数据量较大时数据处理性能较差，不得不用其他技术手段解决性能问题。
在数据库内做分析计算和数据处理的优点是避免大量数据搬迁而消耗网络带宽并且避免了因为收发数据而增加数据查询分析处理的时耗；对单机数据库来说，这样做的问题是针对大数据量的库内密集计算会导致OLTP负载受影响，并且扩展性很差---即使这个数据库实例是纯用于分析负载，当负载略微增大后计算资源就会用尽。通过分布式集群利用大量硬件资源来分析和计算就规避了这类问题，这使得库内计算的优点重新凸显出来。
数据库系统具备完善的应对和处理海量数据的基础设施，包括buffer pool,临时表，外存索引等等，因此可以直接在库内运行存储过程或者执行OLAP分析或者机器学习任务，而不再依赖消息队列（诸如Kafka，RabbitMQ等）、数据流分析（例如flink）等组件，因为这些组件本质上就是小规模增量式地分析和处理大量数据的方法，是当前技术条件下主流的数据分析处理手段。使用这样的工具链需要一个专职的数据分析技术团队去学习很多‘新技术’并且开发很多新的数据处理模块，还需要运维团队来运维这些组件确保它们持续高效运行。同时运行这些组件需要配备很多计算机服务器。这都极大地增加了用户做数据分析处理的成本。
Klustron的解决之道
使用Klustron分布式数据库集群做数据库内的分析计算和数据处理，可以解决上述问题，我们相信Klustron可以支撑用户使用更优的技术栈实现数据处理和分析。用户只需部署一组计算节点专用于运行计算密集型数据分析处理功能，包括执行SQL做OLAP数据分析，或者使用PostgresML、Apache MadLib运行机器学习任务，或者运行存储过程形式的数据计算和处理逻辑。并且这些数据分析处理任务都是从备机读取数据，这就完全避免了对数据写入和事务处理性能的影响。并且无需安装部署和运维Flink集群或者Kafka集群，省去相关的人员成本以及这些组件对可靠性带来的风险（系统的组件种类越多，需要的协作也越多，发生故障的风险也越大）。而且这些分析任务都能够受益于Klustron的分布式并行查询处理技术，达到优秀的数据分析处理性能。
2.2 复杂数据类型对关系数据模型的增强
在各行各业的IT系统中，关系数据模型仍然是应用最广泛的支柱性的数据模型，而GIS,JSON和向量数据这三种复杂数据类型，则在其各自的专项领域具有非常强大的功能和丰富的应用场景。然而，如果为了这三种复杂数据类型的任何一种来部署维护一个专用数据库系统都是非常复杂和昂贵的，其开销不仅仅包括服务器硬件的成本，运维人员的人力成本更加显著，更大的复杂性和成本是应用系统中需要开发额外的模块和功能来使用多种数据库系统的关系数据、GIS、JSON、向量数据，特别是如何可靠地实现对多种数据库系统的数据的读写的事务语义（ACID），这在应用系统中实现非常复杂，技术难度很高，应用系统的可靠性等技术指标也需要经受严苛的考验和验证。这些复杂性会带来非常巨大的应用系统开发工作量。并且应用系统还可能需要用到消息队列、etcd/zookeeper等状态同步工具，这就带来额外的硬件开销和运维需求。
Klustron的解决之道
通过支持PostGIS和PGVector，Klustron支持了GIS和向量数据类型，再加上已经支持的JSON（半结构化）数据类型，就产生了产生1+1>>2的效果，这样Klustron就具备了非常强大的数据管理功能。这三种复杂数据类型是对关系数据模型的显著增强和扩充，这让Klustron的用户可以开发功能非常强大、丰富、灵活、高效的应用软件系统。同时大大降低了部署和维护多种数据库系统的研发成本、硬件成本、和运维成本，以及应用系统使用多种数据库系统的协作复杂性和系统可靠性风险。
总的来说，Klustron的库内计算和多种数据模型的支持能力，可以支撑一种新型的数据处理范式，其基本特点与当前广泛存在的库外计算显著不同，有一系列显著的优势，并且解决了集中式数据库时代不得不做库外计算的各种技术难题，因而是可以实施的，对用户有很大的价值。
03 使用外部数据源
从外部数据源读取数据，与库内数据统一查询的这种方法在集中式数据库中已经存在了很多年，包括Oracle, MySQL, PostgreSQL中都有这类功能。Klustron可以使用PostgreSQL生态的FDW组件从各类外部数据源读取数据，这也是Klustron的融合能力的一部分，故在本文介绍。
多数情况下，用户希望在Klustron建立数据表，然后从第三方数据源导入数据，这样不仅可以做只读的库内数据分析处理，还可以在事务中可靠地做数据更新。不过这样做就把同一份数据重复存储一遍（主备节点共至少2个副本），消耗大量的存储资源。用户可能出于数据安全或者存储成本的考虑，而决定不再灌入Klustron集群，而是直接使用Klustron的FDW组件在Klustron集群的计算节点从第三方数据源（包括其他数据库系统，hbase/hive，公有云对象存储等）中读取数据，同时使用集群内的数据表，使用多源数据执行关联查询。
看着似乎非常美妙，不过读取外部数据源的数据，就不要奢望全局数据读一致性了，因为无论是哪种外部数据源，都没有这样的支持，有些数据源甚至不支持事务语义（ACID）。
同时，我们不建议在Klustron集群的同一个事务中更新多个外部数据源的数据，因为有些数据源本不支持事务，有些FDW组件不支持数据更新，还有一些数据源不支持两阶段提交事务，因而Klustron无法确保这样的更新具有事务可靠性保障（ACID）。
04 可扩展的AI数据基础设施
未来在各行各业的大模型广泛应用之后，应用软件的形态将与行业大模型紧密相关，也就是说应用软件系统通常是由大模型按需动态生成和调整的，这会比曾经的低代码技术还要简便灵活易用。
这样的灵活性对数据管理的要求，其能力至少要包括下面几个方面，我们称之为可扩展的AI数据基础设施。
- 支持向量数据管理和向量距离（相似度）查询
- 自动故障恢复处理，无需人工介入
- SQL标准兼容性，大模型会生成符合SQL标准的任意复杂度的SQL查询语句，数据库系统必须能够执行这些语句。
- 按需计算和存储弹性伸缩，无需人工介入
- 统一管理和操作关系数据模型以及GIS, JSON, 向量等复杂数据类型的数据。
大模型产生应用软件，需要统一的数据管理接口，在同一个数据库系统中管理关系数据以及GIS, JSON和向量数据。假如使用多种独立的数据库系统存储这四类数据，那么如何可靠地实现跨数据库系统的事务处理，将远远超过大模型的能力范围。
泽拓昆仑Klustron不仅具备上述全部能力，还支持在计算节点中运行PostgresML，Apache MadLib等机器学习插件，以及运行用户自定义(用python, java等编程语言)的数据处理模块；同时支持pgvector 向量数据库插件实现向量数据管理和向量距离（相似度）查询。
泽拓昆仑Klustron 具备这一系列能力，因而是可扩展的AI数据基础设施。
END
