OceaBase开发者大会落地上海!4月20日共同探索数据库前沿趋势!报名戳 了解详情
写点什么

用 C++ 写出比 MySQL 快 800 倍的数据库,ClickHouse 创始人:融合数据库该“卷”的还是性能和速度

  • 2023-04-13
    北京
  • 本文字数:9415 字

    阅读完需:约 31 分钟

用C++写出比MySQL快800倍的数据库,ClickHouse创始人:融合数据库该“卷”的还是性能和速度

本期访谈由 InfoQ、阿里云开发者社区、阿里云数据库事业部联合出品。


在刚刚结束的阿里云瑶池数据库峰会上,阿里云宣布与全球流行的开源分析型数据库 ClickHouse 正式签订战略合作协议,成为 ClickHouse 在中国独家的云服务提供商,并提供具备独有企业能力的 ClickHouse 版本。借此机会,InfoQ 有幸独家专访了 ClickHouse 创始人兼 CTO Alexey Milovidov、阿里云数据库事业部 OLAP 产品部负责人林亮,围绕 ClickHouse 演进迭代的历程、双方此次合作的契机、当前数据库技术所面临的挑战和机遇,以及 OLAP 数据库未来发展趋势等问题展开深度对谈。


5G、AI 和云计算等技术的崛起,把数据库这项传统的底层技术推入到了数智化转型的前沿阵地。


新应用诞生的新数据处理需求迫使数据库不得不快速做出反应以紧跟技术潮流,不被淘汰掉。在面对如此多的需要实时响应的场景时,几乎每一个月就更新一次的 ClickHouse 成为了新数据库时代的一匹黑马。


ClickHouse 于 2008 年创建, 是一个用于在线实时数据分析(OLAP)的列式数据库管理系统,十年前由 Yandex 公司首次开发,主要为了给 Yandex.Metrica 提供支持,Metrica 是一个和百度统计、Google Analytics 类似的网站数据分析服务,当时仅次于 Google Analytics,是世界第二大网络分析平台。


ClinkHouse 的大规模数据分析性能极强,通过提供一个真正的基于列的 DBMS,它允许系统以亚秒级的延迟从 PB 级的原始数据生成报告。当时的系统已经可以提供每秒十万行的服务器吞吐量,ClinkHouse 将这一速度提高到每秒数亿行。


之前有人研究过ClickHouse 官方给出的性能报告https://clickhouse.tech/benchmark/dbms/ ,发现在相同的服务器配置与数据量(1000 万)下,平均响应速度是 MySQL 的 400 多倍,当数据量达到 1 亿的话,平均响应速度是 MySQL 的 800 多倍。


经过 8 年磨砺,2016 年起,ClickHouse 开始走出 Yandex 并作为开源解决方案为用户提供支持。


虽然商业化时间不长,但得益于极高的查询处理速度和数据存储效率等优势,在此后几年,ClickHouse 的受欢迎程度成倍增长,2017 年,ClickHouse 引入国内。如今 ClickHouse 的开发者和用户已经遍布全球各地。国外的 Uber、eBay、CloudFlare、Cisco,国内的阿里巴巴、腾讯、字节、携程、有赞、快手等许多头部大厂都在深度使用 ClickHouse 技术。


其中,阿里云在 3 年前就上线了全托管的 ClickHouse 云产品,目前有全球最大规模的商业化 ClickHouse 云上集群。


不管是大数据还是 DevOps 或是其他领域,只要涉及在线分析场景,都能找到 ClickHouse 的影子,越来越多的企业将 ClickHouse 作为实时分析引擎来使用。


作为 ClickHouse 的最初设计者、Github 上 ClickHouse 开源项目的主要提交者,Alexey Milovidov 也是高性能 C++、分析应用程序和 SQL 数据库方面的专家。


2019 年 9 月,为了让 ClickHouse 的技术潜力得到充分发挥,创始人 Alexey Milovidov 决定整合资源成立一家 100% 专注于 ClickHouse 的公司。担任联合创始人和总裁的 Yury Izrailevsky 此前曾在谷歌领导开发者平台和无服务器云产品。公司同时引入了 Aaron Katz 领导的世界级业务团队,这都会帮助 ClickHouse 取得更好的发展。


ClickHouse 注册成立公司后,宣布筹集到 5000 万美元 A 轮融资,而在随后的两个月,ClickHouse 再次宣布完成 2.5 亿美元 B 轮融资,此次融资后,ClickHouse 估值达到 20 亿美元。


Alexey Milovidov 表示:“我们已经赢得了一个由贡献者、开发者和用户组成的伟大社区,他们的支持说明了我们产品的质量。”


那么,从研发至今,ClickHouse 经历了怎样的演进迭代历程?当前数据库行业面临哪些挑战?AIGC 的火热发展会给数据库带来哪些新机遇?未来行业到底需要一个什么样的 OLAP 数据库?


以下为本次访谈视频实录和精华文字整理,经 InfoQ 审校和编辑:


00:00 / 00:00
    1.0x
    • 2.0x
    • 1.5x
    • 1.25x
    • 1.0x
    • 0.75x
    • 0.5x
    网页全屏
    全屏
    00:00


    ClickHouse 的演进与迭代


    InfoQ:非常感谢 Alexey 和林亮老师接受我们的采访。第一个问题想跟 Alexey 聊聊 ClickHouse 数据库的发展历程。ClickHouse 从研发至今已经过去了十多年的时间了,行业对 OLAP 的数据库需求也发生了一些变化,相对应的,ClickHouse 这些年做了哪些迭代和演进,能不能请 Alexey 给我们介绍一下?


    Alexey:最初,开发 ClickHouse 的目的是让它只服务公司内部的业务,所以它对我们来说足够用了。但自从它开源之后,我们看到很多公司也开始使用 ClickHouse,用法都不太一样,会有不同的优先排序、不同的需求,所以我们会看到有不同的应用案例。


    当我们只在一个公司内部使用 ClickHouse,它是非常完美的,但当它走入成千上万家不同的公司时,所产生的效果就会不一样了。不过在不同的用例中反复打磨后,产品的质量有了明显的改进,另外,它很重要的演进就是拓展了一些不同寻常的用例。如果非要举出一个 ClickHouse 的特点,那就是它的设计能满足某一个应用的实际生产需求,这样的特点让 ClickHouse 变得越来越强大。


    InfoQ:我们知道 ClickHouse 的性能很强大,但当它进入到企业环境中后,我们就需要考虑它的弹性能力以及云端部署的问题了。2021 年起,ClickHouse 注册成立了公司开始,独立运营团队就在集中精力解决云端部署的问题,我们想了解下,目前 ClickHouse 上云的进展怎么样了?围绕着云端部署做了哪些工作?


    Alexey:ClickHouse 是很灵活的,如果用户想要的话,它可以向上扩容到成千的服务器,但是扩容到数千服务器这个过程本身并不容易,它的演进也是另外一个方式,也就是扩展到另外一个架构上,是一种跨架构的扩容。我们知道这种存储对于我们来说是非常常见的,但是它不需要移动数据就能实现扩容,它能够有更好的扩容效果,像阿里云现在就是在使用这样的方式。


    InfoQ:这中间还涉及到一些问题,比如 ClickHouse 在数据一致性还是存在一些需要解决的问题,也正在解决吧?


    Alexey:你的意思是更新和删除分析数据库中的数据吗?


    InfoQ:是的。


    Alexey:是的,这个问题并不容易解决,但是现在有很多的系统,假装在解决这个问题。这类系统就是所谓的 HTAP,但问题是现存的系统并不适合,或者说这些系统不是针对分析型需求设计的。如果要优化分析处理,必须应用一些特殊的方法来更新或删除数据才能解决问题,不能只靠数据位置的转变就把复杂的事情变简单了。


    InfoQ:接下来这个问题也想问一下林亮老师,阿里云这次和 ClickHouse 的合作,是否跟云原生改造工作有关,能不能简单介绍一下具体内容?


    林亮:我们这边从两年多前就上线了阿里云 ClickHouse 的版本,经过这段时间的演进,收到了很多用户的反馈和需求,他们在使用 ClickHouse 的过程中也遇到过这样或那样的问题。目前,据我们所知,阿里云拥有全球最大的商业化 ClickHouse 云上集群,我们积攒了很多的用户、用例和他们的需求。


    本次阿里云和 ClickHouse 公司的独家合作,就是希望能够在中国大陆和亚太为用户提供一站式的产品。这次合作中就包括了云原生 ClickHouse 的内核。这当中有哪些技术点是客户真正需要的,我们在合作的前期也都进行过讨论。


    在阿里云瑶池峰会上我们提到的 SharedMergeTree,它可以把整个弹性做得比原来社区版本更高效。刚才提到的轻量更新和删除,这些都是过往用户遇到的痛点。接下来一两年内,我们可能会发布解决上述痛点问题的新版本,所以很期待新的 Serverless ClickHouse 这个产品能够帮助客户更好地构建分析型场景。


    InfoQ:Serverless 版本预计在什么时间发布?


    林亮Serverless 版本现在正在研发和推进过程中,我们希望在今年年中或者下半年内发布,我们已经开放了早期的白名单注册,我们的内测版本可以提前给到大家来试用一下。

    就数据库来讲,上云是必选项吗?


    InfoQ:也想问问 Alexey 怎么看这次在国内和阿里云的合作,对于 ClickHouse 来说意味着什么?


    Alexey:我们会在中国寻找一些云的合作伙伴,目前为止,阿里云对我们来说是最给力的合作伙伴。


    InfoQ:现在,大家普遍认为我们正处于云原生时代。在两位看来,对于 ClickHouse 在内的大数据和数据库类的项目来说,上云是不是一种必然选项?林老师刚刚也提到,服务弹性扩缩容也会对原来的性能有一定的影响。ClickHouse 最开始服务的业务场景可能并不包括云上场景,但是现在在阿里云上的服务就是云上场景,所以这是不是必然的选项?先请林亮老师聊聊。


    林亮:就上云问题而言,我们看到目前用户使用数据的方式变得越来越复杂,首先是数据量增长越来越快,随着一些热点的发生,计算也出现很多不可预期性,复杂的查询对系统也带来了一定影响。另一方面,整个用户都在考虑如何能够更好地降本增效,能够更高效地使用当前的系统。


    回看整个云时代,从本质上来讲,云是把很多以前每个厂家不同小的“水井”合并在一起,汇聚成了无边无际的江河湖海。当更多的应用上云后,云的资源量使用更大,整个边际成本就开始往下降,这些红利就返回给了客户。


    像 ClickHouse 的云、阿里云自己的产品等这些云原生产品都是在更好地满足客户不同的数据处理和分析的需求,运用云本身所提供的高可用、易运维等特性更好地支持他们的应用场景。


    对于是否一定要上云的问题,其实用户的选择各有不同,有些客户出于安全和合规等考虑,依然是在线下的。但是如今,Gartner 分析师也指出,数据库的未来就是上云,可以看到,现在绝大数的客户都在往云上迁移,我们也相信这会是数据库未来的发展趋势和演进方向。


    InfoQ:现在上云的场景和 ClickHouse 最开始设计的场景好像是完全不同的,最初设计 ClickHouse 时它的场景是单机的,但自从独立成立公司后,看起来上云变成了公司非常重要的战略,所以 Alexey 是怎么看待这个问题的?


    Alexey:云确实是很重要的战略,但 ClickHouse 的优势是在任何地方都可以运行,包括在云上、本地部署、边缘设备上它都能完美地运行。所以显然它也应该匹配云上的需求,云是使用 ClickHouse 最简单的方式,而且有可能是最好的方式。


    InfoQ:但是中间还是经过了相当多的改造工作的吧?因为我知道业内有很多公司和团队其实在围绕 ClickHouse 做改造。


    Alexey:确实有很多部分需要专门为了云重新开发,比如我们不得不专门为云环境实现一个表引擎,原来的 ReplicatedMergeTree 对云架构匹配不是特别好,尤其当使用对象存储的时候。我们要做一些不一样的事情,我们需要让计算节点能独立于存储节点扩展,实现在所有计算节点之间并行查询,当我们使用不同的存储时都要做到非常高效的查询。


    云的对象存储和本地磁盘、内存等是不一样的,需要做不少工作,对象存储是另一种完全不同的“怪兽”。


    InfoQ:这些刚才我们提到的发生在公司和组织间的改造,会和我们商业化的路径或者上云的路径形成一种竞争关系吗?这个问题 Alexey 怎么看?


    Alexey:肯定会有竞争关系,竞争是很正常的,这在我们意料之中,大家其实也想效仿 ClickHouse 与我们进行竞争。换个角度看,ClickHouse 和我们正走在行业前列,引领这个行业,让其他人在后面追随。


    InfoQ:Alexey 提到这个问题恰好是我接下来要问的问题,既然有竞争关系,肯定也要分析彼此的优势在哪里?因为我们是研发了 ClickHouse 这个产品,我们除了更熟悉它,还有哪些其他方面的优势?


    Alexey:其实会有一些很有意思的方向,我只举几个例子。比如 ClickHouse 不仅是分析型数据库,它也是一个流处理平台。想象一下,如果同时使用 ClickHouse 和 Kafka,但出于某种原因你对 Kafka 不满意,觉得 Kafka 还不足以满足需求,你想把 ClickHouse 单独使用,而恰巧 ClickHouse 具备了独立处理、生成、转换数据流在内所有工作,那这时你一定会爱上 ClickHouse。还有一种可能,比如让 ClickHouse 具备批处理能力和 ELT,甚至更强的能力,比如内置 AI 能力,这样用户就能基于 AI 模型来写函数,这些想法听起来是不是也很让人兴奋?


    InfoQ:那您能从团队和人才能力层面聊聊这个问题吗?因为现在很多团队都在做改造,ClickHouse 公司作为 ClickHouse 项目的创始团队,理论上来讲应该是最了解这个产品的,是不是意味未来在发行版或改造版迭代时,我们仍然是最适合大家场景的、最能满足大家需求的这样一个产品?


    Alexey:其实,我们团队的大部分成员已经是 ClickHouse 的贡献者,他们已经对 ClickHouse 原代码很熟悉了,他们知道 ClickHouse 是怎样运作的,他们了解 ClickHouse 代码和架构目标就是要尽可能简单和易于使用。我们可以看阅读源代码、阅读注释,我们更熟悉 ClickHouse 的代码库,这就是为什么我们社区有很多贡献者。


    InfoQ:看来竞争对手先要成为 ClickHouse 社区的主要贡献者,然后再参与到其中来对吧?


    Alexey:是的,有一些从前的社区贡献者后来成立了新公司,可能会直接跟我们竞争,但这也没关系。竞争可以带来一些新构思,我们对此非常欢迎。


    InfoQ:林亮老师怎么看待这个问题?


    林亮:就像 Alexey 说的,其实有更多的人参与到这里面来也能更好地帮助整个社区成长。那么为什么 ClickHouse 在阿里云上会更好?据我们了解,阿里云上的 ClickHouse 集群目前是国内最大的 ClickHouse 集群,这里有多年来积累下来的客户场景、最佳实践和用例,此外,多年来我们和客户一起打磨下来的、更贴近场景的功能是很有竞争力的。


    另外,阿里云本身所能提供的安全性、可靠性和整个基础设施迭代上的保证,能够更好地支持这些 To B 企业安心地基于 ClickHouse 来构建企业级应用。


    最后,我们已经运营了 ClickHouse 差不多两到三年的时间,我们也期待后面跟 ClickHouse 的合作碰撞出更多火花,让产品能够基于阿里云能力之上,借助 ClickHouse 本身的技术的实力和优势,真正打造出一款最具竞争力的分析型数据库,帮助用户更好的成长。


    InfoQ:现在国内最大的 ClickHouse 集群是在阿里云客户服务这里吗?


    林亮:从我们了解到的信息是这样的,无论是单客户还是整体客户体量上我们都是比较大的。

    数据库未来的发展趋势


    InfoQ:另一个问题想问一下林亮老师,目前业内很多开发者认为大数据行业整体的技术是比较复杂的,涉及到的组件、工具都比较多。ClickHouse 最初面世的时候,大家觉得它是在 OLAP 这个场景下把性能推到了极致。接下来行业内的从业者会面临两个选择,一个是大数据的工具和要写的代码呈现出融合的趋势,大家没有那么复杂的场景和工具需要考虑。还有一个方向仍然是百花齐放的状态,比如你在 OLAP 场景用什么、OLTP 场景用什么,工具依然相当分散,林老师觉得接下来的演进趋势会是哪一种?


    林亮:我觉得有两个演进的趋势:一个趋势是融合。我们也看到业界有两种融合的方向,一种融合是指我们一直在提的湖仓一体,我们看到无论是 SnowFlake 还是 Databricks,都开始把它的湖往仓这个方向扩展。


    另一个融合就是我们刚才提到的 HTAP(在线和离线的结合),我们也看到有很多的数仓在往这个方向发展,就是在单产品之内把自己边界真正做到融合的覆盖不同的场景。此外还有我们在瑶池峰会上发布的整体的一站式解决方案。让数据库各个产品之间数据能够更好地自由流通,而不需要搭建这么复杂的组合方案。去年 AWS 在 re:Invent 上发布的 Aurora 和 Redshift zero-ETL,其实也是这样的思路和方向。整体目标也是希望用户的数据处理架构和设施搭建起来能够更方便。


    还有一个趋势是多样化。我们也看到,无论从场景还是使用上,数据分析变得越来越复杂。所以我们觉得后面还是会针对不同的场景和特殊用例思考怎么做得更极致、更高效来设计产品。我觉得业界这种多样化的趋势还会存在的,随着这些场景和产品出来,它们可能后面又会被融合到当前的系统里去,所以我觉得整体上融合和多样化会是并行发展的趋势。本身技术上不一定融合好或者多样化就好,更多还是怎么能够更好地解决用户场景,要让用户真正做到一站式数据的使用,帮助他们真正地解决问题。


    InfoQ:Alexey 怎么看这个问题,您觉得融合还是会继续各个领域分别发展?


    Alexey:我觉得有些公司在将不同的技术用于不同的用例中,但我觉得这不是最佳的方案。如果用十几、二十几个技术,那么架构就会变得更加复杂,甚至可能会崩溃。我觉得很多场景还是在融合,我也看到了不同技术融合在一起的可能性,包括数据分析处理、交易处理、流处理,甚至键值数据库 ETL,他们在用更简单、更加高效的方式将解决方案融合在一起。


    为什么不把一个产品变成全能产品呢?虽然不是马上就能实现,但我看到了有这样融合的可能性。如果一个数据库就能解决的问题,为什么要用另外一个数据库呢?如果要用到搜索,为什么分析型数据库不能做搜索?为什么要用专门的数据库进行机器学习的向量搜索?我认为其实不需要专门的数据库,很多个需求都可以融合到一个解决方案中,也可以行之有效。当然有的时候融合并没有那么容易。


    InfoQ:可能阻碍大家做融合的第一个问题是性能,是不是融合到一起势必要牺牲一些性能,ClickHouse 最开始引得大家这么大的关注,在社区内火的这么快,也是因为 ClickHouse 性能非常突出,Alexey 觉得做融合数据库时会不会牺牲掉一些性能?


    Alexey:我认为这主要是聚焦方向的问题,当团队不大的时候一定要找到优先级排序。对于 ClickHouse 来说,最优先考虑的始终是性能和速度,如果说同一时间任务太多、太分散,有可能最后给到大家的就是一个半吊子的解决方案,哪个方面都不能做到极致。我不希望给到大家一个很普通的东西或者半成品。虽然不能什么都要,但要做就一定要做到最极致。

    AI 大火,为数据库行业带来哪些机遇?

    InfoQ:接下来我们来聊一聊最近非常火的 AI。这里想问问林老师,您认为 AI 能够给数据分析和整个数据库行业带来哪些新的机会或者机遇?过去 AI 技术和数据分析多有结合,典型的就是 BI 的场景,但是好像这些年发展下来,至少在国内的发展没有达到大家的预期,接下来 ChatGPT 通用人工智能的发展会给数据分析带来什么新的机会吗?


    林亮:这部分内容我不是专家,我的观点可能是抛砖引玉了。我觉得 AI 和数据库的互相推动主要体现在两个方面:一方面是数据库本身对数据的清洗、数据的管理能够给 AI 带来很好的思路。因为很多企业最核心的数据和最有价值的数据还是存在数据库里,这些已经清洗过的、最有价值的数据对 AI 一个很好的输入。


    另一方面,数据库本身所提供的无论是权限,还有对应的可靠性、可用性的能力,是他们想使用 AI 一个更重要的点。很多企业跟我们聊的时候会说,ChatGPT 非常火,但要把这个技术变成一个企业级应用的时候,一些数据处理的技术是相当关键的,数据库这么多年积累下来的技术会对这方面的工作有很大帮助。


    InfoQ:后面会不会大家在用一个大数据产品的时候,就没有 UI 的概念,可能提一些(Promote)实现比较复杂的数据服务或者获取一个数据赋能给它的结果?这些对于数据库来说都会是利好吧?


    林亮:对,我觉得这会是大的方向。整体来说,我们之前一直提到,数据湖最大的问题就是数据太多了,不同的 format、不同的信息散落在各个地方,怎么更好地聚集在一起,更好地分析湖上的数据,这也是湖仓一体系统需要解决的问题。


    这些东西通过数据库汇总到一起,整个上层 GPT 就可以更好地分析。再往前一步讲,现在很多客户进 BI 报表,一开始都是把几十个图表放在一个页面上,分析起来也很不方便。像微软在 PowerBI 上已经有 Demo 出来了,用户提一个问题,Demo 直接把关键问题的答案反馈给你,所以如何帮助大家更好地访问和使用数据,把数据的价值充分挖掘出来并创造出更大的价值,这不仅是 GPT 要解决的问题,也是整个数据库或者数据分析这个产业和所有同行们一直在追求的终极目标。


    InfoQ:Alexey 怎么看 AI 热潮给数据库和 ClickHouse 带来的机会,咱们现在是否也在关注 AIGC 技术和 ClickHouse 的结合?


    Alexey:是的,我们看到了一些两者相结合的可能性,主要是偏前沿技术方面。现阶段,AI 可以协助设计查询语句、自动补全,目前可能还做不到像我们预期得那么强大,但看上去是可行的。AI 能够给出正确的查询,但如果我们需要做更加复杂的工作,它经常会出错。你必须重新调试并检查实际生成的 SQL 语句,但是确实现在已经证明了它是能做到的。如果我们能让 AI 变得更加强大同时降低成本,不需要再花几千万去训练,我觉得那个时候的可能性可能会更高一些。


    InfoQ:Alexey 所说的两者结合的可能性是服务于什么场景,是现在 ClickHouse 应用性更好了,还是本身在功能层面会出现一些创新?


    Alexey:有一些显而易见的方面,但不是用于核心数据库的,这些部件主要是用于用户界面,可以协助用户编写和纠正查询语句,可能自动执行数据探索。比如你有一个数据库,你只是想以某种方式把其中的数据呈现出来让数据结构更易于理解,也许可能对于内部的数据结构和算法应用 AI 会更难一些,特别是机器学习的数据结构。但这可能无关乎 ChatGPT 而是更加传统的机器学习。也许未来我们会找到更多的可能性。


    InfoQ:咱们现在内部有尝试用 ChatGPT 辅助我们写代码吗?


    Alexey:没有,因为现在这么做没有意义,而且太昂贵了,我们只是做一些小范围的实验性工作。

    展望 OLAP 数据库的未来趋势


    InfoQ:接下来,我想问一个关于趋势性问题,也想请两位聊一聊,在接下来十年间,行业内会需要什么样的 OLAP 的数据库?


    林亮:我觉得 OLAP 数据库会朝着三个方向发展。


    一个趋势是:数据库和云的结合。我们此前也提到过,原来是讲数据上云,现在是讲“数据 + 云”,就是怎么能让 OLAP 产品利用好云的技术,包括怎样做到更好的弹性、怎样更好地利用好云的资源、如何帮助客户更好地应对降本增效的要求,我觉得这会是一个方向。


    另外一个趋势是湖仓一体。我们每天所产生的数据量是相当大的,但我们现在能够管理和应用的数据还是很少的一部分,所以怎么能够做更深度的探索,把湖和仓更好地统一和管理起来,进一步挖掘数据价值,同时也基于平台更好地分享数据,是所有从业者当下要着重思考的问题。现在国家有数据局来做管理,我也认为后面整个数据会更规范化、标准化,会有更多的共享,所以数据的隐私保护,也是未来 OLAP 系统需要具备的能力。


    最后一个趋势是数据库与 AI 的结合。这要分方面看:一个是 AI 本身能够帮助数据库做到更好更优的调优和调整;另外一方面是 AI 到后边也会变成数据库的“一等公民”,就像 SQL 函数一样,可能会成为数据库的标准能力,怎么更好地把 AI 这些能力集成在一起使用也值得关注。


    InfoQ:林老师聊的还是挺全面的,Alexey 怎么看待数据库未来发展趋势的问题?


    Alexey:我觉得还有一些没有解决的问题有待解决。数据清理、数据准备、弄清楚数据结构等问题可能看起来很简单,对于非结构化数据或者半结构化数据,其实很难获得跟结构化数据相同的性能。所以首先需要定义数据的结构,有时候你必须编写脚本来清理数据。比如客户给你一个数据表,你要把它整合到数据库当中,这些问题上也许 AI 可以提供帮助。


    嘉宾简介:


    Alexey Milovidov,ClickHouse 创始人及 CTO


    林亮,阿里云数据库事业部 OLAP 产品部负责人。曾就职 Google 十多年,在超大规模 SQL Engine 和规模存储引擎上经验丰富。目前负责阿里云 OLAP 产品部。


    嘉宾征集:


    什么是技术情怀?在很多人看来,是热爱、是思考、是卓越。这个时代或许有人功利、或许有人内卷,但我们依然愿意相信更多人依然怀揣着用技术改变世界的初心。《The Great Geek》(了不起的极客)是 InfoQ 重磅推出的全新内容栏目,全年共 8 期。自栏目推出至今,我们专访了 MySQL 数据库和 Maria DB 创建者 Michael “Monty” WideniusiPod“之父”Tony FadellThoughtworks 全球 CTO Rebecca Parsons《代码大全》作者 Steve McConnell如果你身处的企业中有这样的技术领袖想让我们报道或你希望看到哪位技术大佬的采访,请在评论区留言联系我们

    公众号推荐:

    2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

    AI 前线公众号
    2023-04-13 21:458145
    用户头像
    李冬梅 加V:busulishang4668

    发布了 807 篇内容, 共 376.0 次阅读, 收获喜欢 998 次。

    关注

    评论 2 条评论

    发布
    用户头像
    MySQL也是C++写的吧,怎么不用Rust?可能会更快。
    2023-04-14 15:21 · 广东
    回复
    做ClickHouse那会应该Rust还没有这么受欢迎hh
    2023-04-15 17:25 · 北京
    回复
    没有更多了
    发现更多内容

    第一周总结

    _

    极客时间 架构师 极客大学架构师训练营 第一周总结

    「架构师训练营第 1 期」第一周作业(作业一)

    Geek_83908e

    极客大学架构师训练营

    食堂就餐卡系统设计

    行者

    Week 1 學習總結

    Judyyy

    架构师训练营学习笔记

    Erwa

    我搭建了一套企业级私有Git服务,抗住了每天上万次攻击!

    冰河

    git 代码管理 代码仓库 私有服务 远程协作

    架构师训练营 - week1 - 学习总结

    month

    极客大学架构师训练营

    第一周学习总结

    饭桶

    week-1-part1 食堂就餐卡系统设计

    陈龙

    极客大学架构师训练营

    架构师方法论

    wing

    极客大学架构师训练营

    初学架构方法

    Zzzz

    极客大学架构师训练营

    极客时间-架构师一期-第一周作业

    _

    极客时间 架构师 极客大学架构师训练营 第一周命题作业

    食堂就餐卡系统设计

    饭桶

    第一周课程学习总结

    Meow

    极客大学架构师训练营 第一周总结

    架构师训练营-第一周学习总结

    戚伟

    架构师

    第一周学习总结

    jizhi7

    极客大学架构师训练营

    极客时间架构 1 期:第 1 周架构方法 - 命题作业

    Null

    架构师第一周

    Geek_Gu

    极客大学架构师训练营

    架构师训练营第一周总结

    万里

    极客大学架构师训练营

    就餐卡系统设计

    golangboy

    极客大学架构师训练营

    独孤求败的五把剑,三个人生阶段 -Week1- 学习总结

    小粽

    # 架构师训练营Week1作业

    lggl

    极客大学架构师训练营

    Week_01学习总结

    golangboy

    极客大学架构师训练营

    第一周命题作业

    王建军

    架构师训练营 第一周作业

    haha

    极客大学架构师训练营

    极客食堂就餐卡系统设计

    IT老兵重开始

    极客大学架构师训练营 第一周命题作业

    「架构师训练营第 1 期」第一周作业 (作业二)

    Geek_83908e

    极客大学架构师训练营

    ARTS Week17

    时之虫

    week1 架构方法总结

    zero2onemore

    第一周 UML图

    mm马

    UML学习总结

    行者

    用C++写出比MySQL快800倍的数据库,ClickHouse创始人:融合数据库该“卷”的还是性能和速度_数据库_李冬梅_InfoQ精选文章