LakeSoul - 新一代的数智化底座

关于湖仓一体,网上的介绍不少,渠道服务商也很多,但似乎鲜有能真正介绍明白原理和应用定位;与此同时,也经常有人问,你们一帮做 AI 的,怎么就做数据库了?只能尴尬笑笑,我们是做湖仓智能的。不管怎样,想来还是很有必要写一写,聊一聊,权当创业故事。

一、引子

大概几年前,我还在前司负责广告投放相关的算法落地,当时我们遇到一个很棘手的问题,就是第三方移动程序化广告里的实时机器学习问题,简单来讲,因为我们拿不到 App 里的user profile数据,我们唯一能利用的就是用户的稀疏行为数据,且由于移动广告业务的特点,我们必须实时 capture 用户的即时兴趣;用户上一分钟的行为,我们希望建模到下一分钟的模型里面,因为即便是同一个用户ID,不同时刻不同场景的用户实时心智也是不一样的,相应的广告推荐也是完全不同的,这对我们的技术挑战空前。

传统的方式是用户实时反馈数据落盘,数据 ETL,样本拼接,然后做模型的 Online Learning,线上 inference,整套体系下来最快也是是小时级的模型更新体系,这个最早在我们做手机淘宝的个性化推荐体系时是完全ok的,因为我们是在某个独角兽 App 里做 in-house 的推荐,可以简单的从实时召回层面去实现实时的个性化推荐,模型层面做到小时级更新已经是完全 ok 的,但现在不行。

然后我们开始调研,湖仓一体/流批一体大概就是从那个时候进入我们的视野,简单来讲,我们需要基于湖仓一体的体系,解决实时机器学习里的实时训练样本生成问题。这里面虽然flink能够解决实时计算的问题,但是flink没有存储,无法解决数据的回滚、容错,也没法支持新增特征的历史数据回溯合并。因此综合来讲,具备流批一体能力的湖仓一体框架才是最适合的。

之后我们调研了国际流行的开源框架:Hudi、Iceberg、Delta Lake 等,但发现原始的设计有种种问题,最典型的比如小文件的支持能力较差,而如果回到我们互联网应用,一次流式写入为一个小文件的话,数十亿甚至百亿以上的流式写入小文件是不可想象的。此外,还有大量其他问题,比如流批一体中单个样本流的实时更新的能力(Upsert)不足,以及多个样本流的多流并发写(Merge on Read)的并发能力不足,都会严重影响到实时机器学习样本的构造。彼时对于我们,这是一个近乎无解的问题。我们以下图粗略展示我们最初的 motivation:


样本构造示例

上图是互联网搜广推时代,一个典型的样本构造示例,一般包含三大数据流体系:

A)用户特征:包括用户的基本属性,用户的历史行为和最近的实时行为等

B)物品特征:物品的各类属性,包括离散的属性和统计值连续属性等

C)用户交互反馈:算法模型中的标签(Label)

对于某个单个的数据流体系,会发生某个字段/实时兴趣的更新(删除、增加、变更),同时多个数据流,要进行多流合并,从而成为一条完整的训练样本实例,这里可以按主键自动扩展 Schema,做高效的 Merge on Read,而不用采用低效的 join 操作。

如果上述的小文件支持、Upsert、MOR等性能得到完美保证,问题似乎能到解决;但依然有非常棘手的问题,如果基于湖仓一体框架能高效形成一批实时训练样本,那又如何直接高效喂到下游的机器学习框架当中?换句话讲,湖仓一体的底座如何能无缝衔接AI框架的生态?毕竟,传统的湖仓一体框架都是java实现,都只能支持大数据生态!

所以敲黑板,我们最早接触并深入湖仓一体,是为了解决实时机器学习里的训练数据流体系,是不是很有趣。

二、AI Infra

回到整个 AI 的基础 infrastructure,其实主要包含三大块:离线训练体系,在线推理体系,衔接在离线的数据流体系;今天很多人都有一种错觉,以为 AI 的 Infra 主要是离线训练和在线推理两大块;之所以有这样的错觉,很大一个原因就是,今天很多的 AI 创业者,并没有完善的一线互联网应用的从业经历,其实从互联网应用落地的角度来讲,第三部分怎么构建完善的数据体系非常重要,也非常核心。

这个在前阵子贾扬清大神的一篇访谈文章里也表达过类似意思:“把应用当中所得到的数据,以一种回流的方式收集回来,训练下一波更好的模型。到今天这个方法论依然适用,就是在行业竞争中,谁能有数据,谁能够把用户的反馈更好地调试成“下一波训练的时候可以更好的应用”的数据,这也是核心竞争力之一。”

https://mp.weixin.qq.com/s/zpIioK4oiXez0sQKgeCW0A

所以,从这个角度来看,湖仓一体其实就是 AI 的基础核心 infrastructure 之一,至少在 AI 应用生态落地当中如此。

三、湖仓才是未来

数字化经济的核心是数据要素,围绕整个数据要素的统一管理和价值释放的pipeline,存在大数据和AI两个生态体系,首先我们从大数据技术架构的演进方向来看。

大数据架构经历了:传统数仓 —> 数据湖 —>数据湖仓的演变,具体如下图所示,其核心是:满足企业对快速增长的数据管理及多样化数据价值释放的诉求。

演变示意图

当然这里面存在难点,如流批架构的统一、元数据扩展性差等已知问题,这些都影响了湖仓一体的实际落地。那么,如果我们能顺利解决这些问题呢,那就会有如下的优势:

1)低成本:区别于搭建昂贵的数仓,数据湖提供海量存储和弹性计算,成本降低10倍,维护开销低

2)时效性高:摒弃传统的 T+1 跑数流程,报表分钟级更新,计算资源开销低

3)数据统一:以湖为中心构建统一的数据中台进行资产管理,统一取数,口径一致

4)多种数据应用支持:在湖上支持 BI 报表、大屏、AI 等多种数据应用,充分释放数据价值

接着,我们来到AI生态体系,除了前面最早提到的在实时机器学习体系,基于湖仓一体构建实时AI训练数据体系的诉求,横向的来到我们今天的大模型时代,让我们再看看情况如何。如果大模型应用的时代真的来临,那对数据层面又会有哪些要求:

1)大规模:海量异构数据,文本、图片、视频,结构化和非结构化类型数据

2)质量高:需要对海量数据进行大量的采集、清洗、标注等数据预处理工作

3)迭代快:需要数据-模型-数据快速反馈迭代

而上述一系列诉求,显然特别适合基于湖仓一体构建大模型的数据底座,原因包括两点:

1)湖仓能低成本且高效地支持海量异构数据的存储和管理

2)湖仓能支持大数据生态的数据预处理框架;

这里的**难点和挑战在于:

1)已有对接的大数据生态的数据预处理性能如何能进一步的提升,毕竟原始数据是存储在云原生的对象存储之上;

2)同时能一体化支持 AI 大模型的开源生态;

如果能做到这两点,那么湖仓一体就能成为大模型时代的数据底座,整体可以如下图示意:

示意图

四、LakeSoul 新一代的数智化底座

基于前面的介绍,相信大家已经大概了解,我们为什么要重新设计一个湖仓一体的框架,尽管在彼时,这算不上一个热门的方向,但我们坚信,如果解决好前面提到的几点,那 LakeSoul 就会成为新一代的大数据+智能的基础底座,意义不可谓不大。

我们首先看下 LakeSoul 的基础技术框架示意:

LakeSoul框架图

整体的设计思路就是:人无我有,人有我优。

1)人无我有:通过 Rust 原生语言实现的 NativeIO,统一封装 Java 和 Python 接口,大数据生态、AI 生态统一支持,实现一体化的数据底座;整体示例如下图:

示例图

通过这样的设计,我们就很容易实现一个大模型的使用案例:

大模型使用案例

详细内容可以参考我们之前的公众号文章:大模型时代,我们需要怎样的数据湖?

2)人有我优:前面提到已有湖仓框架在大数据生态的种种功能缺陷和挑战,基于此,LakeSoul 做了针对性的全新的架构和实现,主要优势包括:

A)不同于国际其他湖仓一体框架如 Hudi、Iceberg 等,LakeSoul 采用集中式的元数据服务层,能支撑超大规模的湖仓文件管理和更高的并发读写能力;

B)作为云原生湖仓框架,对云存储以及 HDFS 的读写性能是重中之重,LakeSoul 选择使用 Native Code (Rust 语言)重新实现 IO 层的读写逻辑,将全量、增量的读写逻辑都迁移到了新的 IO 层实现,使得在大数据和 AI 计算引擎中均可访问实时数据。同时 IO 层也做了大量性能优化,在湖仓框架中具有显著的性能优势;

C)LakeSoul 支持多流并发 Upsert、增量流式 CDC 读取等读写方式,并与 Spark、Flink 做了深度集成,从而更为完善地支持高效低延迟的流式增量数据建模;

D)支持多种数据库、消息队列的整库实时入湖、出湖,支持自动 Schema 演进,全局自动小文件合并服务、自动数据清理服务等,让 LakeSoul 具备优秀的生态连接能力和易用性。

这个环节,我们在之前的公众号文章里做了大量介绍,这里不在赘述,可以参考之前的若干文章链接:

LakeSoul 发布 2.2.0 版本,全面升级 Native IO,扩大云原生湖仓性能领先幅度

LakeSoul 国产湖仓框架新篇章:开源基金会孵化,国产信创认证,新版本重磅发布

五、回到数元灵

基于前面的介绍,再回到数元灵究竟是做什么的,相信大家清晰了很多。数元灵整体的定位就是:一站式湖仓智能,即湖仓一体的数智化底座 + 智能应用的生态体系。

我们基于新一代的数智化底座 LakeSoul,既提供了数字化时代下的数据中台底座,又给 AI 的生态应用提供了智能化的数据底座。回到智能应用的生态落地,数元灵有自研的AI应用生态框架 MetaSpore,目前已打造了完善的智能SaaS 产品,包括:

A)低代码个性化推荐

B)智能金融风控

C)智能文案生成引擎

D)BI Copliot

E)新一代智能客服

这些内容在我们之前的公众号文章里也都有过介绍,大家可以自行翻阅。

这样基于我们的 LakeSoul + MetaSpore,就形成了 1+N 的数智化产品生态。回到大的政策背景,就是:围绕数据要素的核心,AI 赋能,产业焕新。

想起创业总总,身边一直总有人问,你们对标的是国外哪家巨头,从最早觉得Databricks跟我们最像,到现在觉得这些都不重要,数元灵做自己就好。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,100评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,308评论 3 388
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,718评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,275评论 1 287
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,376评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,454评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,464评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,248评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,686评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,974评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,150评论 1 342
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,817评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,484评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,140评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,374评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,012评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,041评论 2 351

推荐阅读更多精彩内容