最近 大模型 有多火?？

感觉全宇宙都在搞大模型了

业界对大模型充满了期待

(资料图)

觉得只要有了大模型，就无所不能

「一剑开天门」，AI破局所向披靡

但是，很多盲目迷恋大模型的人

都忽略了1个事实

↓

目前市面上被炒得最火的大模型

几乎都是LLM模型，即「大语言模型」

LLMs最擅长的是 自然语言理解和生成

当下最成熟的应用领域，还是 AIGC

虽然，这些大语言模型的出现

让大家看到了 通用人工智能 的曙光

但对于toB行业来说

如果基本的 数据内功 没练好

大模型这剂猛药并不能“一剑开天门”

如果 数据 理不顺

既不可能炼制出自己的大模型

也很难微调适配已有的大模型

甚至，连细分场景的小模型都搞不定

更甚，连基础的数据分析和业务支撑都拉胯

最终，这种情况，就成为

没有大模型的命

却得了大模型的病

那么，企业怎么才能把数据整好

把「采存算管用」的路径跑通？

↓

回望大数据技术的发展史

自古以来，这事儿就没有一招鲜

为了能把数据用好、管好

各方神圣都操碎了心

50年来，各种技术不断折腾

最初，人们主要 倒腾 结构化数据

需要 账本 来记 流水账

账本要能高频率“记账”和“查账”

还要保证账目是正确可靠的

（事务处理，ACID原则）

实际中，主要用各种二维表格来记账

这也就是最主流的 关系型数据库

↓

关系型数据库一直沿用至今

仍然是支撑交易型业务的主力军

后来为了更好支持不同类型的新业务

又诞生了许多 非关系型 数据库

键值、文档、时序、宽表…

它们被称为NewSQL

大家各显其能，保障生产系统更流畅

事务型的生产业务运行久了

就会有大量的历史数据留存下来

老板们喜欢翻旧账

比如要查查10年来所有兔子的吃喝拉撒

以此作为兔子洞新一年规划的依据

↓

这些陈年旧账就会被组合起来

做些数据的抽取和转换

目的是让翻旧账（查询、分析）速度更快

这就是 数据仓库

面向的是BI类的数据分析需求

再往后，随着企业越来越大

不只有新账（数据库）、旧账（数仓）

还多了大量烂账（各种非结构化数据）

索性就挖个大坑，把各种账都扔进去

新账老账烂账一起算，以后总能用得上

这个“大坑”，其实就是 数据湖

本质上讲，数据湖是个 中央存储库

用来存储企业日益增长的各类原始数据

面向新兴的机器学习和数据科学需求

但一旦数据治理没做好

新账、旧账、烂账，最后就变成糊涂账

所以，这样的数据，大模型也救不了

为了更好的分析和利用数据

避免重复建设、减少数据移动的工作量

有人就想把数仓的一些能力整合到湖上

（ACID事务、Schema校验和数据管理、流批一体等）

于是，「湖仓一体」悄悄火了起来

↓

就这样…

“兔洞方一日，世上五十年”

五十多年来，数据处理技术风起云涌

用来给交易型的生产业务扛活的数据库

作为开山鼻祖，老而弥新，始终坚挺

而面向分析型业务场景的技术却在不断更迭

直到最近几年才算尘埃落定

湖仓一体技术挑起了这副千斤重担

↓

作为大数据时代的终极产品

「湖仓一体」是个融合架构

既要…，又要…

↓

数仓好比是“鱼” ，面向结构化数据分析

数据质量高，成熟度和易用性好

适合业务分析、BI报表等传统业务

数据湖好比是“熊掌”

海量存储各类结构化、非结构化原始数据

强调低成本、大容量，灵活性好

但数据质量低，还不支持事务处理

主要适用于数据科学、机器学习等场景

“湖”和“仓”都各有优缺点

湖仓一体把二者的优点结合起来

平衡成本与效率，鱼和熊掌兼得

用一套架构支持多元化的分析业务

↓

那么，是不是上了 湖仓一体

数据分析、数据挖掘、大模型修炼与适配

企业的各种用数需求就能搞定了呢

！！并没有！！

「湖仓一体」只解决了

数据处理的基础技术架构

但企业数据的全生命周期运转中

还有太多的坑没有填平

比如，很多企业并没有

数据顶层规划能力

只是盲目堆砌各种新技术

反复挖坑和填坑

既花了冤枉钱，又走了冤枉路

再比如，人人都知道数据安全很重要

但目前相对成熟的湖仓一体方案

大多是公有云服务商主导的

对于政企行业客户来讲

数据迁移的代价大不说

还有一些合规和安全方面的顾虑

同时，对于企业来讲

还需专业的数据人员、清晰的数据场景

以及持续的数据运营

才能真正把那些 纸面价值 变成 真金白银

否则，即便大模型再香、湖仓一体再牛

数据也变不成金子，反而变成沙子