在主题为“科技赋能—金融业数字化转型与发展”的中国金融科技论坛上，，
，，尊龙时凯上地大数据研究院数据科学家卜仁海做了题为《关于湖仓一体数据平台的思考》的演讲。。。

以下为演讲实录：

首先
，
，我们来看一下数据平台的发展历程
。
。。

大约20多年前，，
，信息化程度较高的行业的头部企业
，，，，开始建设数据仓库。
。
。。当时的数据主要是企业内部系统的结构化数据，
，，，数据应用主要是BI分析及报表。。随着业务需求及数据形态的变化，
，，，开始建设数据湖。
。。原因是参与分析的非结构化数据逐渐增多，
，数据应用也有了新的扩展，，，实时计算、
、人工智能、
、机器学习等场景逐渐增多
。
。。

最近几年，
，，，开始流行起了湖仓一体的数据平台概念。。。

需要说明的是，，这张图来自国外，，图里没有出现数据仓库，，
，这并不是说数据仓库消失了。。。。当我们说数据仓库、、
、、数据湖的时候，，其实有两种说法，，一种说法是指硬件平台，，一种说法是指数据的组织结构
。
。这张图里说的是硬件平台，
，，，指的是用一个硬件平台来实现湖和仓的建设，，也被认为是真正的湖仓一体。。。。

国内在规划建设湖仓一体的时候，，在方式上会相对灵活些。。

国内建设湖仓一体的方式

接下来
，，我们来看一下国内建设湖仓一体的几种方式。。。方式一和方式二我们可以认为是逻辑上的一体，，，，方式三是平台级的一体。。。

方式一采用融合的方式，，，数仓平台和数据湖平台间存在实际上的数据复制，，
，，如果数据的管理、
、、调度等自动化程度较低，，，流程不完善，，，则不仅仅是数据冗余的问题，，，，还涉及到应用效率等方面的问题

方式二采用编织的方式，
，，，数仓平台和数据湖平台间可以不用数据复制，，业务人员的访问接口是Fabric组件
，，，，由此组件解析优化访问语句，，，，计算处可以是仓
、
、、、湖以及Fabric组件，，
，，具体要看Fabric组件的优化策略和能力
。
。需要说明的是
，，
，，Fabric的访问语句通常不会完全覆盖仓、、
、、湖数据库的所有语句。。
。
。

方式三是真正物理平台上的一体，，，或者说其上的各个数据库可以直接访问彼此的文件系统和存储结构
，，
，，这也是最理想的情况。
。。
。

湖仓一体数据平台的优势

为什么说湖仓一体大概率是数据平台的趋势呢，，，它有什么好处呢？？

首先，
，，，它可以容纳多模态的数据
，
，，比如音频
、、、视频、、、、图片、、、、文档等。。。其次，，
，
，丰富的计算引擎
，，简单的说，，，就是无论什么样的数据，，，都可以相对容易的找到其对应的计算引擎并部署
。。。并且是存算分离的，，也就是说
，，存储部件和计算部件是分离的，，，，可以各自弹性扩展。。。流批计算一体
。。。。支持人工智能、、、机器学习
。
。。
。

数据平台经历了分的过程，，，，目的是为了满足不同数据的不同计算需求，，，现如今正逐渐走向合的阶段，，，目的是为了易管易用、、
、、简单高效。。。
。技术总是在不断进步的
，
，湖仓一体尚在逐步发展阶段。
。。。通过我们对不同湖仓产品平台的了解
，，
，，以及对未来湖仓一体的期待，，，，这里简单提出一点想法，，，，请大家批评指正
。。。

对未来湖仓一体的期待

比如，
，，我们是否可以将存算分离分地再彻底一些？？？
？

企业的数据是越来越多的
，，，计算基于数据，
，，，同样也不会是局限的
。。拿数据库来说
，，关系型数据库
、、
、图数据库、、、、KV数据库、、时序数据库、、、、向量数据库等等。
。另外
，，，大模型又为我们提供了一个新的数据计算场景。。也就是从逻辑上看，，数据的存储和数据的计算，，，天然的是可以分离的。。只是因为一些非技术壁垒及其它原因，，，，导致不同数据库间难以实现直接的数据访问。。。

这里我们只从存技术角度，
，，考虑将企业对数据的存和算建设成两个分离的中心
，，，也就是湖仓一体的两个重要组件。
。
。

存储中心需要考虑的是如何建设一个高效的存储架构和网络架构，，如何实现一个高效的数据访问机制和接口，，，，它应该有自己的文件系统、、、寻址机制
、、缓存机制等等。。

计算中心需要考虑的是如何设计一个高效灵活的资源管理和调度策略，，
，如何灵活配置接入其它计算引擎组件，
，，，如何实现一个高效的缓存机制减少与存储中心的数据吞吐等等。。对于像大模型这类计算应用，，我们当然也希望湖仓一体有这个能力承接。。。

当然，，
，这些仅是对湖仓一体未来能力的畅想，，未必就是各家企业的场景应用需求。。。。各企业基于自身数据基础、、
、当前数据应用的痛点和需求以及未来数据架构布局及规划，，，对湖仓一体的期待各有不同。。

湖仓一体体系架构

我们先从湖仓一体体系架构的角度简单看下体系建设内容
。。

这里的体系架构是从功能层面阐述框架内容的。。体系架构的意义不仅可以用来定义各框架的规范、、边界
、、、
、接口
、、
、制度
、、、、流程等内容
，，
，，还可以用来评估当前数据体系建设及运营情况，，，，指引接下来的建设内容等。
。。

此图仅作参考，，，，各企业可按自身实际情况做相应改动
，，，但需要注意的是不要把产品平台当成框架本身。。比如尊龙时凯的数据开发平台“六合上甲”，
，，平台本身包含了需求管理
、
、数据建模、、、
、数据开发、、、、采集交换、
、数据服务、、、数据治理等内容，，
，，它跨接了体系框架的多个组成部分
，，，需要通过规范接口对接各框架组件，，，，“六合上甲”产品本身不是体系框架。。。
。图中的探索、
、
、标签、、、、指标其实是数据产品管理框架的实际组成产品，，这里用产品平台来说明其为框架与产品的区别。。

湖仓一体数据架构

接下来再看一下湖仓一体的数据架构情况

这里是采用方式三物理一体的实现方式设计的简单数据架构，，，，仅供参考。。对于数据量、、、业务量、、、复杂度不高的企业而言
，，数据仓库可以基于应用建设，，，即数仓只要满足企业级报表和部分数据分析的需求即可，
，，
，需求相对固定且稳定。
。。对于业务部门敏捷灵活的分析应用而言，，其数据源可以来自标准化数据区
。。

标准化数据区对于那些对数据流向管控严格，，，要求凡是数据需求可由数仓提供的
，，不允许从湖区直接取数的企业而言，
，，，可以不建设。。但同时会对数仓的建设及其数据产品运维推广工作要求较高。。

数据架构中定义的数据区不是简单的数据容器，
，，它同时也定义了规范、、边界、、、
、制度
、、、、流程、、接口等等
，，，数据产品的开发运维及相应的资源配置是其运营的关键
。。部分企业在数据运营中的痛点多多少少与此相关
，，，这不是有了湖仓一体就能解决的问题，，
，但却可以通过湖仓一体建设为契机，，，通过咨询及服务的方式，，帮助企业及其各部门建设相配套的数据团队，，来实现企业的数字化转型。。