Aloudata:从 A lot of data,到 AI on data

简介: 我们做的其实一直是同一件事: 先解决数据生产力的问题,让好数据更高效地被生产出来; 今天再进一步,让这些好数据不只是被人用,也能被 Agent 用。

作者:周卫林,Aloudata 创始人 & CEO


这些年,每次见客户、见伙伴,几乎都会有人问我一个问题:你们为什么叫 Aloudata?

我理解 Aloudata 有两层含义: A lot of dataAI on data


21 年我们出来创业,看数据这件事,最直接的感受就是:企业早就过了没有数据的阶段,现在是数据越来越多,链路越来越长,口径越来越乱,运维起来越难,成本越来越高,而且数据需求还在不断往业务一线走,运营、销售、风控、客服,大家都在提数据需求,根本看不到数据需求和数据复杂度可以收敛的任何信号。


我们遇到了 A lot of data” 带来的“数据生产力跟不上”这个大问题。


企业在持续经营,只要业务在长,系统就在长,数据和需求就会跟着也在长。可企业的数据工程,底层还是一套很重的生产方式:靠 ETL 工程师搬数据,靠 ETL 工程师建链路,靠 ETL 工程师运维任务,靠 ETL 工程师做性能优化。早期这套方式是成立的,因为业务没那么复杂,需求量也没那么大,主要是看数据的需求。但企业一旦从 0 到 1,从 1 到 10,从 10 到 100,产生了大量用数据的需求,这套方式就一定会越来越吃力。不是团队不努力,而是这种数据生产方式本身有上限,我们不能延续老方法,用打固定靶的狙击枪来打移动靶了。


既然根问题是数据生产力不足,那解决方向就不可能是继续堆更多 ETL 人工,只能是走向 ETL 自动化。说得更直白一点,就是让 AI 接过更多原来靠 ETL 工程师完成的事情,这就是 AI on data。为了更鲜明地表达这个观点,我们在全球第一个提出“NoETL”这一理念。

NoETL 不是一句“不要 ETL”的口号。它真正想表达的是:别再把数据工程完全建立在大规模搬运、重复拷贝、人工编排和重运维之上了。能不搬的就别搬,能自动编排的就别手工编排,能在消费侧按需计算的就别一上来在生产侧全部预计算。

说到底,NoETL 解决的是数据生产方式的问题。


所以 Aloudata 这个名字的两个含义其实已经很清楚了:

A lot of data,说的是企业面对的数据复杂现实,是数据工程走到了困境。AI on data,说的是我们认为解决这个问题的方向,是让数据工程走向自动化。NoETL,说的是这条路上的具体落点,关键技术就是数据虚拟化和数据语义化,也就是我们倡导的语义编织技术(Semantic Fabric)。


但今天,事情又往前走了一步。

AI Agent 起来以后,我发现当年我们看到的问题并没有消失,反而变得更明显了。以前是人面对 A lot of data ,会觉得复杂、会迷路、会对不齐;现在是 Agent 遇到同样的问题,而且很多时候更严重。

因为人碰到数据问题,还能拉群、开会、找同事确认。但 Agent 不行,你把数据库直接给它,它天然不会知道“库存健康度”是什么口径。数据库里有数据,但数据库里没有企业真正用来沟通和决策的业务定义。没有这层定义,Agent 就缺少数据口径的上下文,就只能猜,而企业决策不能建立在“猜”上。

所以今天再说 A lot of data,它的含义已经不只是数据多、任务多、链路复杂,还包括:这么复杂的数据,怎么才能让 Agent 也用得起来,而且用得对、用得稳、用得放心。

这时候,AI on data 的含义也比以前更完整了。

以前它更多是指,让 AI 参与数据工程自动化,解决数据生产力问题。 今天它进一步变成了:让 AI 能够在企业的好数据之上工作。

之前“让人用上好数据”的载体是表,现在“让 Agent 用上好数据”的载体是语义层。

Agent 通过语义层解决“听得懂、信得过、用得了”。

听得懂,是因为Agent 需要真实场景里的上下文信息,而语义层沉淀和管理了企业日常沟通的业务口径。信得过,是因为 Agent 取数分析不能是黑盒,语义层让 Agent 取数分析的过程,在口径、SQL 代码和数据值上端到端全数据链透明,过程可复现、可追溯、可审计。用得了,是因为企业不可能让每个 Agent 都直接查数据库,语义层作为企业统一的控制层,可以天然集中满足有关权限、性能、安全、路由、限流等这些数据访问控制的要求。

如果再往前看一步,我觉得 NoETL 在 Agent 时代很自然会继续演进成 ETL Agent。因为 NoETL 的本质,本来就是 ETL 自动化。过去那些靠工程师手工完成的连接、编排、更新、加速、治理,未来一定会越来越多地由 Agent 参与完成。


所以今天我再看 Aloudata 这个名字,会觉得它比刚创业时更完整了。

A lot of data,讲的是问题。AI on data,讲的是方向。 前者定义了我们为什么开始,后者定义了我们要把这件事带到哪里去。

从 2021 年到今天,我们做的其实一直是同一件事: 先解决数据生产力的问题,让好数据更高效地被生产出来; 今天再进一步,让这些好数据不只是被人用,也能被 Agent 用。

这就是 Aloudata 这个名字背后真正想表达的思考和愿景。


因为我始终认为 Aloudata 这个名字背后要解决的问题是有普遍性的,要创造的价值是有变革性的。

因此从创业之初,我们一直非常开放地分享我们的想法和进展,并发布在我们的官网和公众号上,获得了大量朋友、客户、同行的喜爱和关注。


在 AI Agent 这个背景下,我们定义的问题从痛点变成卡点了,我们过往 5 年积累的领先优势成为我们和客户进入 AI 时代的入场券,变成了我们和客户的先发优势

这个先发优势的具体体现不只是我们在春节之后发布的一系列小龙虾做数据分析的视频,更在于我们即将发布的新版 Aloudata Agent 产品。从我内部试用产品的感受来看,我觉得我们已经到了数据分析的“Claude Code”时刻, 我们是在创造一个实时响应的“业务分析师”,感兴趣的朋友可以关注我们在公众号上的消息,可以第一时间体验这款产品。


最后补一个小 tip。 为了让发音顺一点,也更像是一个公司名字,我们将 A lot of dataAI on data,象形成了 Aloudata。你也可以把它当成 Aloud + data 的合写,让世界听见数据的声音。

相关文章
|
存储 缓存 文件存储
如何保证分布式文件系统的数据一致性
分布式文件系统需要向上层应用提供透明的客户端缓存,从而缓解网络延时现象,更好地支持客户端性能水平扩展,同时也降低对文件服务器的访问压力。当考虑客户端缓存的时候,由于在客户端上引入了多个本地数据副本(Replica),就相应地需要提供客户端对数据访问的全局数据一致性。
32707 79
如何保证分布式文件系统的数据一致性
|
前端开发 容器
HTML5+CSS3前端入门教程---从0开始通过一个商城实例手把手教你学习PC端和移动端页面开发第8章FlexBox布局(上)
HTML5+CSS3前端入门教程---从0开始通过一个商城实例手把手教你学习PC端和移动端页面开发第8章FlexBox布局
17760 20
|
设计模式 存储 监控
设计模式(C++版)
看懂UML类图和时序图30分钟学会UML类图设计原则单一职责原则定义:单一职责原则,所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变,那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。bad case:IPhone类承担了协议管理(Dial、HangUp)、数据传送(Chat)。good case:里式替换原则定义:里氏代换原则(Liskov 
36689 20
设计模式(C++版)
|
存储 编译器 C语言
抽丝剥茧C语言(初阶 下)(下)
抽丝剥茧C语言(初阶 下)
|
机器学习/深度学习 人工智能 自然语言处理
带你简单了解Chatgpt背后的秘密:大语言模型所需要条件(数据算法算力)以及其当前阶段的缺点局限性
带你简单了解Chatgpt背后的秘密:大语言模型所需要条件(数据算法算力)以及其当前阶段的缺点局限性
24768 14
|
机器学习/深度学习 弹性计算 监控
重生之---我测阿里云U1实例(通用算力型)
阿里云产品全线降价的一力作,2023年4月阿里云推出新款通用算力型ECS云服务器Universal实例,该款服务器的真实表现如何?让我先测为敬!
36671 15
重生之---我测阿里云U1实例(通用算力型)
|
SQL 存储 弹性计算
Redis性能高30%,阿里云倚天ECS性能摸底和迁移实践
Redis在倚天ECS环境下与同规格的基于 x86 的 ECS 实例相比,Redis 部署在基于 Yitian 710 的 ECS 上可获得高达 30% 的吞吐量优势。成本方面基于倚天710的G8y实例售价比G7实例低23%,总性价比提高50%;按照相同算法,相对G8a,性价比为1.4倍左右。
|
存储 算法 Java
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的限流器RateLimiter功能服务
随着互联网的快速发展,越来越多的应用程序需要处理大量的请求。如果没有限制,这些请求可能会导致应用程序崩溃或变得不可用。因此,限流器是一种非常重要的技术,可以帮助应用程序控制请求的数量和速率,以保持稳定和可靠的运行。
29841 52