EVO厅

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

以下为演讲实录：

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

约莫20多年前，信息化水平较高的行业的头部企业，起头建设数据仓库。其时的数据重要是企业内部系统的结构化数据，数据利用重要是BI分析及报表。随着业务需要及数据状态的变动，起头建设数据湖。原因是参加分析的非结构化数据逐步增多，数据利用也有了新的扩大，实时推算、人为智能、机械进建等场景逐步增多。

最近几年，起头盛行起了湖仓一体的数据平台概想。

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

国内涵规划建设湖仓一体的时辰，在方式上会相对矫捷些。

国内建设湖仓一体的方式

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

方式一选取融合的方式，数苍旖台和数据湖平台间存在现实上的数据复造，若是数据的治理、调度等自动化水平较低，流程不美满，则不仅仅是数据冗余的问题，还涉及到利用效能等方面的问题

方式二选取编织的方式，数苍旖台和数据湖平台间能够不用数据复造，业务人员的接见接口是Fabric组件，由此组件解析优化接见语句，推算处可所以仓、湖以及Fabric组件，具体要看Fabric组件的优化战术和能力。必要注明的是，Fabric的接见语句通常不会齐全覆盖仓、湖数据库的所有语句。

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

湖仓一体数据平台的优势

为什么说湖仓一体或许率是数据平台的趋向呢，它有什么益处呢？

首先，它能够包容多模态的数据，好比音频、视频、图片、文档等。其次，丰硕的推算引擎，单一的说，就是无论什么样的数据，都能够相对容易的找到其对应的推算引擎并部署。并且是存算分离的，也就是说，存储部件和推算部件是分离的，能够各自弹性扩大。流批推算一体。支持人为智能、机械进建。

数据平台经历了分的过程，主张是为了满足分歧数据的分歧推算需要，现如今正逐步走向合的阶段，主张是为了易管易用、单一高效。技术总是在不休进取的，湖仓一体尚在逐步发展阶段。通过我们对分歧湖仓产品平台的相识，以及对将来湖仓一体的等待，这里单一提出一点设法，请各人品评指正。

对将来湖仓一体的等待

好比，我们是否能够将存算分离分地再彻底一些？

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

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

存储中心必要思考的是若何建设一个高效的存储架构和网络架构，若何实现一个高效的数据接识趣造和接口，它应该有自己的文件系统、寻址机造、缓存机造等等。

推算中心必要思考的是若何设计一个高效矫捷的资源治理和调度战术，若何矫捷配置接入其它推算引擎组件，若何实现一个高效的缓存机造削减与存储中心的数据吞吐等等。对于像大模型这类推算利用，我们当然也但愿湖仓一体有这个能力承接。

当然，这些仅是对湖仓一体将来能力的畅想，不定就是各家企业的场景利用需要。各企业基于自身数据基础、当前数据利用的痛点和需要以及将来数据架构布局及规划，对湖仓一体的等待各有分歧。

湖仓一体系统架构

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

这里的系统架构是从职能层面论述框架内容的。系统架构的意思不仅能够用来界说各框架的规范、天堑、接口、造度、流程等内容，还能够用来评估当前数据系统建设及运营情况，指引接下来的建设内容等。

此图仅作参考，各企业可按自身现实情况做相应扭转，但必要把稳的是不要把产品平台当成框架自身。好比EVO厅信息的数据开发平台“六合上甲”，平台自身蕴含了需要治理、数据建模、数据开发、采集互换、数据服务、数据治理等内容，它跨接了系统框架的多个组成部门，必要通过规范接口对接各框架组件，“六合上甲”产品自身不是系统框架。图中的索求、标签、指标其实是数据产品治理框架的现实组成产品，这里用产品平台来注明其为框架与产品的区别。

湖仓一体数据架构

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

这里是选取方式三物理一体的实现方式设计的单一数据架构，仅供参考。对于数据量、业务量、复杂度不高的企业而言，数据仓库能够基于利用建设，即数仓只有满足企业级报表和部门数据分析的需要即可，需要相对固定且不变。对于业务部门火快矫捷的分析利用而言，其数据源能够来自尺度化数据区。

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

数据架构中界说的数据区不是单一的数据容器，它同时也界说了规范、天堑、造度、流程、接口等等，数据产品的开发运维及相应的资源配置是其运营的关键。部吩祗业在数据运营中的痛点多几多少与此有关，这不是有了湖仓一体就能解决的问题，但却能够通过湖仓一体建设为契机，通过征询及服务的方式，援试祗业及其各部门建设相配套的数据团队，来实显祗业的数字化转型。