🔥 热搜 🔥
上海习近平新疆鄂州父女瓜乌鲁木齐疫情H工口小学生赛高习明泽芊川一笑图包印尼排华
分类
社会娱乐国际人权科技经济其它
🔥 热搜 🔥
百度今日热点微信公众平台贴吧opggdnf私服百度贴吧知乎dnf公益服百度傻逼
分类
社会娱乐国际人权科技经济其它
查看原文
其他

万字解读 | A轮就融资￥3亿+的MotherDuck到底是个啥？

Rachel Richer LawRachel 2024-04-14

自1960年代数据库管理系统DBMS诞生以来，其成为了软件公司的巨大营收和净利润来源。1980年代，基于读写程度、使用场景的不同，DBMS衍生出了OLTP和OLAP两个主要分支，而前者一般被直接叫做数据库（Database, DB）、后者一般被叫做数据仓库或数仓（Data Warehouse, DW）。

1990s，单点式OLAP开始提供数据立方体（Data Cube），方便为商业智能、决策支持提供切片、旋转、下钻等分析操作。进入21世纪后，Vertica, Greenplum, ParAccel等面向结构化数据、Shared-Nothing/MPP架构的分布式OLAP兴起，与此同时，面向半结构化数据的Hadoop和MapReduce生态也逐渐声势浩大。

目前主流的数仓或大数据产品，整体上分为本地部署On-premises和公有云Cloud两类，前者以Teradata和Cloudera CDH为代表，后者以Snowflake、BigQuery、Redshift和各大公有云厂商的EMR产品为代表。而由于私有化的定制和服务的高昂成本，以及公有云的弹性、标准化、规模效应，尽管整个行业目前仍以私有化为主，但又呈现出私有化厂商式微、云上供应商规模增大的趋势。

无论是私有化还是公有云，无论是行业巨头还是创业公司，大家对分析型Data Stack的整体提升思路，都是围绕 Source→ELT→Storage→Compute→Application 这整个核心业务流的纵向和横向Workload进行优化。在其中，有的以大一统的平台形式存在，有的则以存储引擎、计算引擎、资源调度等各个小而散的组件存在。但大家优化的主要方向，都趋同于提升PB及以上量级数据的性能。

（a16z总结的Modern Data Infrastructure）

但是，在2022年数据赛道的天价融资项目中，有一个获得了4750万美元A轮的项目确放弃了行业主流方向、放弃了对大数据的追逐、放弃了去卷云端性能优化，转而面向小体量的数据、面向解放Client端的计算资源。这个项目，就是MotherDuck。

MotherDuck的特殊之处，不仅在其避免性能内卷，更在于其鲜明的品牌形象和锋利的价值主张：随处可见的吉祥物Duck、直言”Big Data Is Dead”和“Why Wait For Cloud”的价值主张。

（MotherDuck早期的价值主张）

为什么MotherDuck要抨击行业追逐大数据的做法？为什么MotherDuck又要另辟蹊径选择小数据场景？为什么MotherDuck要选择解放本地计算机的算力？为什么MotherDuck能获得那么高的融资？MotherDuck目前的产品能力到哪种程度了？MotherDuck真正做的事情是不是离其产品定位和目标远景相距甚远？这种模式是否能Copy-to-China？

趁着今年6月MotherDuck开放产品试用的契机，我对其产品能力进行了摸索记录，试图以实际使用体验来回答上述问题。全文共计约11,700字，阅读共需30分钟。以下是本文目录，可根据实际需求食用：

1 Big Data遇到了什么瓶颈？
2 DuckDB
    2.1 What Scenario: DuckDB瞄准了什么场景？
    2.2 How To Use: DuckDB怎么用？
        （1）On-Premises
        （2）WSAM
    2.3 What About Now: DuckDB现在在做什么？
3 MotherDuck
    3.1 Who: MotherDuck背后是哪些人？
    3.2 What: MotherDuck目前能帮助用户做什么？
        （1）产品架构
        （2）从Web UI接入
        （3）从Client接入
        （4）杀手级功能
    3.3 Go-To-Market: MotherDuck团队如何把产品推向市场？
        （1）价值主张
        （2）社区运营
        （3）生态合作
        （4）新用户注册
    3.4 Future: MotherDuck未来可能会往什么方向发展？
        （1）优化方向
        （2）潜在问题
4 Copy To China?
5 Summary
Reference


1 Big Data遇到了什么瓶颈？

一提及Big Data，人们总是会提到数据指数级增长。然而，这个老生常谈的观点其实只关注了Big Data背后的Volume和Velocity特征，而对于适应此两维度的过度关注却容易让人忽视了更重要的Value。数据真的都大到以PB级以上的数据集存在吗？从数据中挖掘出价值的瓶颈真的在于数据处理性能吗？

回想我们日常会使用的CSV、EXCEL文件，大多还是以MB甚至KB量级大小存在。放眼到Kaggle这样的世界级数据科学竞赛平台，大部分数据集还是GB及以下的。即使是瞄准B端、以秒级PB级数据处理著称的Google BigQuery，其创始工程师兼产品经理Jordan也曾在一片文章中坦言真实使用情况：

Most of the people using “Big Query” don’t really have Big Data. Most people don’t have that much data. I can say that the vast majority of customers had less than 1TB of data in total data storage. The general feedback we got talking to folks in the industry was that 100 GB was the right order of magnitude for a data warehouse.

数据的分布遵从Zipf Law，即：若以数据量大小为纵轴、以该大小的数据集数量或者拥有该数据量的个人/组织数量为横轴，会发现整体分布呈现幂律分布特征。然而，💡 技术供应商往往挤破头卷性能，仅为头部量级的数据处理提供解决方案，却对长尾的不同量级的数据集的分析处理优化视而不见，这导致能将数据从价值有限的困境中解放出来场景无人问津。

除了幂律分布外，无可否认的是数据始终是分散存储在各个孤立的设备上的。尽管有Snowflake试图用一个完整的平台解决Data Silo的问题，但现实是：一个足够“海纳百川、包容万象”的平台，往往是趋于中庸的，没有一个系统能足够优秀到能以99分的成绩容纳所有的数据分析Workload。当某个Workload重要到其需求无法被一个中规中矩的平台满足时，使用者往往会选择采用一个性价比更高或性能更卷的技术栈，而这又意味着数据的再次打破分散。

目前的大部分Data Stack，在解决“数据孤岛”问题的逻辑上是相同的：我自己建我内部的计算引擎、存储引擎、连接池等各个组件，等到需要分析数据时，我先把各个源头的数据搬运到我自己内部，用我更擅长的数据结构重构后存储，这样我就能用自己的引擎更高更快更强地进行混合查询，让数据联合起来释放更多的价值。

国内外数据行业这么多年来的实践经验告诉我们，这样做是最能解决现实问题的，未来更易于被客户采纳的技术方案应该是围绕这个逻辑进行各个环节单点突破，提供更好的ELT工具、更节省的存储方案、更高效的计算性能、更易于操作的上层应用、更易于理解的可视化。

然而，这就是大家殊途同归的终局了吗？

DuckDB给出了自己不一样的回答。


2 DuckDB

2.1 What Scenario：DuckDB瞄准的是什么场景？

DuckDB由Hannes和Mark两人在荷兰CWI（Python和MonetDB的诞生地）的研究成果转化而来，初衷是提供一个AP版的SQLite，即： 一个面向数据分析场景的嵌入式数据库，让用户能够像调用函数库一样访问数据库。

至于为什么要为一个有严肃应用场景的数据库系统赋予一个Duck这么诙谐幽默的名字，原因嘛，和Hadoop生态众多奇奇怪怪的项目名称一样：
我有一个亲密的Duck宠物伙伴，所以我也把我热爱的工作成果叫Duck。
（DuckDB最广为流传的命名原因图）
虽然DuckDB的想法很新颖、数据库系统的高门槛也保障了一定的护城河，但在DuckDB第一次发布的2019年，数据库领域已是一片竞争厮杀——DBDB收录的数据库达900种、DB-Engine排行榜中就有400种，帕累托法则也在整个领域得以验证——80%的用户选择使用那20%的明星项目/产品。尽管有CWI成功的科研成果转化经验和优秀的科研人才保障背书，从0到1新建一个数据库管理系统并将其推向用户社区与商业市场对任何人来说都不是件易事，所以Hannes和Mark选择了最小成本的做法：💡 选择一个足够killing的痛点去做side-project，待市场有一定反应后再投入更多的资源。
就像SQLite诞生之初是为解决应用程序与数据库之间频繁出现的连接错误一样，DuckDB起初选择的killing痛点也是常见的Client-Server架构的数据库在整个用户体验过程中的普遍弊病：繁琐的部署安装过程、巨大的硬件资源消耗、冗长的数据导入导出。
Hannes曾在一次活动中用汉堡包及其中的肉饼的差别来比喻数据库产品用户体验和数据库引擎的差别，延展开来剖析可以发现：数据库产研团队能做的是提供更好的内核、更高的性能、更易于使用的产品，但用户的整个数据使用工作流远不止数据库引擎、甚至远不止产品本身，影响用户体验的还有系统运行机制等底层基本设计。
（Hannes在Databricks2023峰会上的比喻）
这个痛点有多痛呢？痛到当市场出现一家解决了该问题的供应商出现后，其市值可以被抬到百亿千亿——Snowflake。在如何提升用户体验上，Snowflake选择了将复杂性留在团队内部，以简单易用为目标，向外部用户提供一个免部署、免运维、免硬件投入的纯SaaS云数仓。但Snowflake的“One Platform, All Workload, No Data-Silo”的策略限制了其在一些数据注定分散的场景的应用，其对ELT工作流的依赖也劝退了不想上云、不想搬动数据的用户，以云上VM作为算力池也造成了终端PC计算资源的极大浪费。
Snowflake选择性地放弃了与自身基因不适合的云下场景，而由于数据天然的普遍属性，云下、边缘、纯终端的场景也是巨大的机会。如果能解决好这些场景的痛点，不仅能避免与巨头的直接竞争、边际成本巨大的性能提升，还能带来数据领域的新兴应用范式转移。
DuckDB选择了避其锋芒：不做TP、不做中心数仓、不做多并发场景，转而提供替补性的轻量解决方案：💡 No Server, In-process, Hybrid Query, Open Source。
No Server帮助其避开了与云上云下的重型数仓供应巨头竞争，转而投向Client端的嵌入式设备市场。In-process让其运行的资源消耗足够小，使得能面向的轻量场景可能性足够高。混合查询则省去了ELT流程，极度简化并加速数据分析流程。开源不仅展示了其靠谱的代码质量，更利于项目在缺少宣发资源下的冷启动。
（DuckDB在其官网的价值主张）

2.2 How To Use：DuckDB怎么用？

在具体使用上，DuckDB提供了2种方式：（1）On-Premises——下载一个package，直接在本地shell或者程序中使用；（2）Browser——无需下载，直接在浏览器中启动shell使用。

（1）On-Premises

对于On-Premises，DuckDB不是Client-Server架构，所以安装时不用像MySQL/Postgre/MS SQL/大数据开源组件一样先下载一个动辄几百MB或者GB大小的source文件或者.tar.gz的binary文件，而是完全以7~25MB大小的轻量pakage形式存在，并根据使用情况的不同分为CLI、Python、R、Java、Node.js、Julia、C/C++、ODBC等版本。
以CLI工具为例，使用者可以采用git+make方式下载源码自行编译后使用，也可以选择下载Win/Mac/Linux的binary文件、解压后无需安装便可以直接使用.exe等可执行程序；以Python为例，使用者可以直接用pip install方式下载duckdb的package，然后通过import方式直接在代码中调用。
（DuckDB的安装及调用方式）
DuckDB以SQL作为查询语言，并采用Postgre方言：不区分大小写、区分单引号双引号、命令句尾带分号等。
以CLI工具使用为例：在本地计算机启动Shell后，会自动新建一个在内存中的DB，用户可以直接执行CREATE TABLE, ALTER TABLE, DROP TABLE等DDL命令和SELECT FROM, INSERT INTO, UPDATE, DELETE等DML命令；如需从本地文件读取数据进入已建好的表中，可以执行COPY命令；也可以免建表，直接通过read_csv_auto等方法直接读取本地文件，支持通过SELECT查询。
（在DuckDB进行新建表、插入数据操作）
（在DuckDB以表的形式读取本地文件）
（在DuckDB以源文件或表形式读取本地文件）
DuckDB的杀手级别的功能就在于对外部文件的支持：💡 把文件读到进程中后，无论是否以TABLE的形式再存储一份数据，都可以执行读取和写入——支持JOIN跨文件查询，支持以及max()、min()、avg()、sum()、count()等聚合查询，也支持COPY TO写入源文件。
（在DuckDB直接对源文件进行查询）
除了支持免建表、直接读写本地的CSV、JSON、EXCEL文件外，💡 DuckDB通过httpfs、parquet扩展支持http、https、s3协议和parquet格式文件的读写，通过postgres_scanner和sqlite_scanner扩展支持从PostgreSQL和SQLite数据库读取数据，对远程文件的访问也支持跨文件JOIN。
在CLI工具外，用户也可以在代码中以Library的方式调用DuckDB执行SQL，不仅支持连接磁盘中的数据库，还支持与Pandas, Arrow等其他常见Library进行数据读写、支持通过Matplot进行数据可视化。


（2）WSAM

除了On-Premises，DuckDB还在2021年中提供了基于WebAssembly的浏览器版：联网时，在浏览器中启动一个安装了DuckDB包的shell，然后DuckDB就可以在本地浏览器中运行、无需访问远程服务器。如果是需要查询本地计算机的文件，在断网环境下，也可以先通过.files add命令把本地文件上传到浏览器后，写sql语句进行查询；但不能像CLI一样直接读取本地文件路径，必须先把文件添加到浏览器shell中。
（DuckDB WASM在断网场景下对本地文件进行查询）
（DuckDB在联网情况下对远程文件进行免ELT混合查询）


2.3 What About Now：DuckDB现在在做什么？

在新颖功能的实现上，DuckDB使用自定义的Vector数据结构作为算子在内部个引擎之间传递，查询引擎通过push-based方式编排算子提高缓存效率、提升查询性能，存储引擎通过分析来选择不同目的的数据压缩方式、并以单个文件的形式进行存储，事务管理则通过MVCC来实现。
(DuckDB核心功能实现)
自2019.06发布第1个0.1.0预览版本以来，DuckDB经历了2021、2023迎来了爆发式增长。目前，DuckDB在GitHub上的star数超过了11K，且在DB-Engine上的得分排名在105左右，与TiDB、Druid、Dril排名接近，虽然距离Snowflake、Databricks、Teradata、BigQuery等顶级OLAP的有一定排名距离，但也将AWS Neptune、OceanBase、Phoenix、Firebolt、AWS DocumentDB、Kylin、Milvus、AWS Timestream、TDSQL、AnalyticDB、Doris等一众明星DBMS甩在了身后。
（DuckDB在GitHub上的star数变化）
（DuckDB在DB-Engine上的得分趋势变化）
2021年中在看到市场的明确反馈后，为更好地支持DuckDB生态的发展，Hannes和Mark两人成立了盈利性质的DuckDB Labs。虽然团队扩充的重心是增加工程师，但其并不像常见的开源商业化公司一样提供开源项目的商业版分支产品，而是提供DuckDB生态的专业咨询、应用拓展、特定授权等服务。从CWI招募而来的众多研发人员的工作中心依旧是更好地改进DuckDB的内核引擎，而不是在应用侧与业务层。
（DuckDB Labs目前的团队构成）
（DuckDB Labs提供的产品及服务）
目前，DuckDB的Discord社区有大约3300名成员在进行着自助式使用，DuckDB Labs团队的核心任务也围绕着改进数据库内核而展开。至于如何为市场上更多的场景、更多的用户提供一个更好更方便的商业产品，DuckDB Labs则期望将这个专精深的重任交给经验更丰富的产品团队。
于是，就有了MotherDuck。

3 MotherDuck

3.1 Who：MotherDuck背后是哪些人？

MotherDuck的创始人Jordan是DuckDB的早期用户。Jordan此前是Google BigQuery的创始工程师和产品经理，后来在SingleStore担任CPO期间，出于对DuckDB的欣赏，开始做side-project来丰富DuckDB生态，希望通过增加云端的serverless版本来真正实现EasyQuery。
在Jordan与Google前同事Lloyd的交流中，有着Looker成功创业经验的Lloyd看到了Jordan所做副业的更大潜力，便说服其将副业项目作为主业投入更多时间精力，还体贴地帮忙介绍RedPoint的投资人、帮忙与DuckDB Labs团队牵线，还为新项目命名MotherDuck。
于是，去年5月，MotherDuck成立，并在当年获得了由RedPoint领投的125万美元的种子轮、由a16z领投的3500万美元的A轮。在toB融资环境快速冷却的2022年，MotherDuck成为了难得的明星项目。
“种子看人、VC看事、PE看数”的投资规律在MotherDuck身上得到了应验——在一个急转直下的融资赛道中逆流而上的项目背后，是一支从Google BigQuery走出的全明星团队：
  • 产品负责人Tino：此前在BigQuery和YouTube团队担任产品经理，随后去了Snowflake的直接竞争对手Firebolt担任产品VP
  • 负责市场和开发者关系的Ryan：此前在Google、Neo4j、Databricks有累计15年的开发者关系的工作经历，并担任众多科技公司的GTM咨询顾问
  • 创始工程师们：有着Snowflake, Databricks, AWS, Google, Microsoft, Teradata, ElasticSearch, SingleStore, Meta等一众科技巨头的工作经历背书
  • 兼职专家顾问们：有First Round Capital的Myoung做财务支撑，有Looker和Firebolt的Nouras做合作伙伴关系建设，有身为ACM Fellow的CWI数据库教授Peter做“实习生”

（MotherDuck目前的团队成员）

3.2 What：MotherDuck目前能帮助用户做什么？

那么，MotherDuck在DuckDB产品能力基础上做了什么呢？

（1）产品架构

MotherDuck在官方文档对其产品架构给出了答复：
  • Cloud Service：提供身份管理、认证授权、监控审计等安全类功能，提供数据分享功能，并提供Web UI进行访问；
  • Compute：以Serverless方式调用本地和远程的DuckDB实例，调用CPU和内存执行计算任务；
  • Storage：在DuckDB的易失性存储的基础上，提供云端的非易失性存储，支持用户将数据导入至MotherDuck进行持久化存储；
  • Client SDK：除了Web UI访问外，还给Python用户和DuckDB CLI用户提供了SDK，调用时通过MotherDuck的Token进行身份认证后可以直接从该Client访问MotherDuck；并支持在JDBC Driver, Go Driver, DBeaver, Alchemy等终端进行访问；
（MotherDuck官方文档中阐释的产品架构）


（2）从Web UI接入

MotherDuck目前采用的云端技术方案是：域名在GoDaddy购买，DNS和CDN等网络访问使用AWS CloudFront，数据托管在AWS S3。
其官网宣传主页是motherduck.com，产品环境放在了二级域名app.motherduck.com下。在Web UI登录后，Landing Page即是Query Editor。
（MotherDuck Web UI）
虽然一开始看起来，MotherDuck和DuckDB的WASM版功能是一样的，但不同的是：💡 MotherDuck可以同时调用本地计算机和远程服务器的DuckDB实例。
例如，在联网时，打开MotherDuck和DuckDB WASM；断网后，都能在二者执行上传本地文件、查询等命令，但可以在DuckDB WASM执行建表操作，但无法在MotherDuck执行建表；联网后，在MotherDuck的Web UI的建表语句点击Run后会，会调用manifest和DoAction API向远程服务器发送请求。
（在MotherDuck使用不同方式查询本地文件）


（3）从Client接入

此外，在不使用Web UI作为Client的使用场景下，MotherDuck还支持将DuckDB CLI和Python Client作为接入终端：
  • Python：通过duckdb.connect(‘md:’)命令唤起身份认证，在MotherDuck验证身份后可以在该Python Client连接到MotherDuck
  • DuckDB：通过open md: 命令唤起身份认证，然后在DuckDB CLI对MotherDuck后台进行读写
（在Pyhon Client中调用MotherDuck SDK）


（4）杀手级功能

如果说DuckDB的杀手级功能是在去ELT基础上直接对本地和远程的不同文件进行Hybrid Query的话，那么MotherDuck的杀手级功能就是：💡 在Hybrid Query基础上对本地计算机和远程服务器计算资源综合调用的Hybrid Execution，将DuckDB的能力从Client扩展至Cloud。
以Web UI方式使用MotherDuck时：
  • 用户登录app.motherduck.com后，会在本地浏览器和远程服务器中分别启动DuckDB实例；
  • 当用户从本地文件系统上传文件至浏览器中的DuckDB，并仅对浏览器中的文件进行读写查询、不访问远程文件时，MotherDuck会把查询任务路由回浏览器中的DuckDB，仅调用本地计算机的计算资源；用户无需等待云端服务器，可以直接在断网情况下执行查询任务，并支持跨文件JOIN；
  • 当用户仅访问远程API或S3文件时，MotherDuck会把文件中的数据读到其服务器中的DuckDB，并在不导入文件、转换格式、进行持久化存储的情况下，直接对远程文件进行读写查询；仅调用远程服务器的计算资源，必须在能正常访问MotherDuck的情况下执行查询任务，支持跨文件JOIN；
  • 当用户从本地文件系统或者远程S3、API读取文件并通过建表、更新、插入、替换等命令将文件导入到MotherDuck服务器进行持久化存储时，MotherDuck调用其服务器中的DuckDB；仅调用远程服务器的计算资源，必须在能正常访问MotherDuck的情况下执行查询任务，支持跨文件JOIN；
  • 当用户的查询请求目标对象同时包含本地文件、远程API或S3文件、MotherDuck存储的文件时，MotherDuck对查询语句解析和优化后，将不同的子任务拆分给本地浏览器和远程服务器中的DuckDB实例，同时调用本地和远程的计算资源；
以Python SDK或者DuckDB CLI SDK使用MotherDuck时，计算资源调用逻辑同Web UI使用方式，但不涉及浏览器进程，仅涉及Python或者CLI。
（MotherDuck官方文档中阐释的本地和远程计算资源混合调用）


3.3 Go-To-Market：MotherDuck团队如何把产品推向市场？

今年6月22日，MotherDuck才开启产品Beta测试。根据其团队成员构成、品牌形象、社区动向、市场活动等蛛丝马迹，可以推测MotherDuck的GTM策略采取的是从社区和生态用户转化的产品驱动增长（Product-Led Growth，PLG），而不是toB领域常见的销售驱动增长（Sales-Led Growth，SLG）。

（1）价值主张

在创始之初，MotherDuck价值主张的基础是“关注他人”，向市场传达的信号的“我要和市场上的其他玩家走一条不同的路”，即：
  • 通过扩充计算节点进行横向扩缩容是昂贵而缓慢的，我们要做单节点的纵向扩缩容
  • 大家手中的笔记本可以比云端服务器更快返回结果，为什么还要将计算完全交给云呢？
  • 大数据已死，简单数据才是未来
  • DuckDB很赞，我们为其充电
（MotherDuck早期的价值主张）
目前，MotherDuck价值主张围绕的是“关注自己”，向DuckDB生态的用户传达“我们在DuckDB基础上还提供了云端能力”，即：
  • DuckDB解放的是大家手中计算机的算力，我们在其基础上还提供与云端算力协同的混合计算
  • DuckDB对开发和测试环境是绝佳选择，我们通过云的特性让其还能用于生产环境
  • DuckDB是单纯的嵌入式数据库，我们在其基础上还可以做数据分析合作
（MotherDuck目前的价值主张）

（2）社区运营

目前，DuckDB的Discord社区有约3300名成员、Twitter有约8500名跟随者，MotherDuck的Slack社区有约500名成员、Twitter有约3100名跟随者。由于MotherDuck没有开源社区来让用户提交Issue，其还在社区中专门设置了support频道来解答用户疑问、设置了feature-request频道来听取用户建议。
对于转化社区用户而言，有一个可爱的、Geek的、卡通形象是维持与C端用户感情的必要手段，而MotherDuck的Duck吉祥物则完美符合这一点。于是，我们可以看到一些有趣的情况：Duck形象充满各类宣传物料，团队成员会用Produck、Duck Herder等谐音梗自称，社区成员自产自销各种Duck Meme图。
（MotherDuck社区用户创作的Meme图）


（3）生态合作

不同于toB公司典型的将客户Logo放在自己官网主页的做法，MotherDuck在其官网放置的是ELT和BI的合作伙伴的Logo。这意味着同很多开源商业化项目从相关社区用户池中转化用户一样，MotherDuck也在从其他生态合作伙伴的用户群中转化用户。
（MotherDuck的生态合作伙伴）
对于拓展新用户/客户非常有效的Event Marketing上，MotherDuck有和DuckDB合作组织DuckCon、举办MotherDuck Party、参加Databricks的Data + AI峰会、参加DataEngBytes等行业会议进行演讲、组织大数据行业探讨的Webinar等方式来产生更广的触达和更深的粘性。
此外，MotherDuck还通过自写行业洞察Blog、邀请KOL写Blog等方式触达更多的潜在用户。典型的Blog产出有：
  • 提前给大数据判了死刑的：Big Data Is Dead
  • 道出行业饱受数据库之苦的：Why Does Everybody Hate Databases


（4）新用户注册

出于云服务的安全性、租户管理、资源负载等考虑，MotherDuck目前没有完全开放用户自动注册。
用户需要在在官网填写问卷（主要是用户画像分类问题）、提交试用申请后，排队等待MotherDuck向用户发出注册邀请。但即使不是DuckDB的用户、即使不是数据分析师或者数据库DBA，也可以在等待大约2~3周后收到MotherDuck的注册邀请邮件，使用邮箱或者Google/GitHub身份SSO注册登录。
（在MotherDuck官网提交注册申请）
如果已经注册了MotherDuck，也可以直接由现有用户填写邮箱地址向新用户发送邀请邮件，省去排队时间，但仅给老用户限制了5个邀请名额。
（由MotherDuck用户直接发出注册邀请）
对于Beta期进行产品使用的“熊猫用户”，产品负责人Tino还会用心地发送邮件询问用户建议，及时做产品市场契合度测试。
（产品负责人Tino的用户意见征询）


3.4 Future：MotherDuck未来可能会往什么方向发展？

（1）优化方向

站在产品管理的视角，我觉得MotherDuck会在接下来的一年在几个方向发力：

  • AI支持：以自然语言为交互方式，让AI自动写SQL等查询语句、Python调用等语句，增加AI的自动问题诊断能力；
  • PLUS功能支持：增加Query Profile, Log Audit, 容灾备份等用于生产环境会考虑的附加功能；


  • 多数据源兼容性：
    • 除了支持AWS S3外，扩展支持至其他S3协议兼容的远程对象存储；
    • 除了Excel, CSV, JSON, Parquet, Arrow, Pandas文件和SQLite, Postgre数据库外，增加支持AVRO, ORC等文件，增加支持MySQL, Oracle, MariaDB, Spanner等高采纳度的数据库；
    • 除了现有的SDK和Driver，增加MotherDuck特有的CLI, Driver, Connector；


  • 商业化：待产品从Beta转GA，给免费版设置使用量上限，超出后进行按量计费
    • Cloud Service层：为团队或企业需要增强的Security和组织管理功能为收费项；
    • Compute层：以每次查询任务的Query复杂度、处理的数据流量、调用次数、Query运行时长等为计费项；
    • Storage层：则以转存的持久化存储的数据量为计费项；
    • 计费单价标准则参照BigQuery或者Snowflake的定价水平；


  • Go-To-Market：

    • 在现有的优秀的文档工作基础上，生产更多的视频、网络研讨会等产品介绍和操作指南物料；

    • 发表更多点明Big Data领域大家视而不见问题的文章，让潜在用户正视现有解决方案的短板；

    • 充分挖掘社区用户的传播潜力，设置激励计划，以Produc-Led-Growth完成第一批C端增长；

如果把视线拉得更长远一点，我觉得MotherDuck未来会在一些Scope和Vision做出改变：
  • 从toC逐渐转为toSMB，增加企业级功能，增加相关合规认证；
  • 以混合云或者云上云下协同为目标场景；
  • 不仅是挖掘PC端算力的剩余价值，还像SQLite一样充分释放移动端设备的潜力；
  • 不与Snowflake，BigQuery，Redshift等既有的云数仓巨头竞争同一批客户，而是以互补场景作为解决方案共同加速商业化，甚至是在一定阶段被收购；


（2）潜在问题

尽管MotherDuck有SQLite的成功经验保障其市场前景想象空间、有全明星团队保障产品和工程质量、有头部VC的天价投资保障现金流、有丰富的生态合作伙伴保障潜在用户池，但其产品定位本身也带来了一定的商业风险：

  • C端用户的付费意愿和付费能力有多强？

    虽然美国有比中国更良好的软件付费习惯，但是C端整体上比B端的整体潜在市场小很多。如果一直持续瞄准社区用户，是否能创造足够的营收？


  • C端用户群是否足够大？

    虽然Figma成功证明了C端用户的工具付费能力，但Figma的潜在用户群比MotherDuck是要大的。

    例如，一个互联网产品常见的最小团队构成，是1个产品经理+1个前端工程师+3个后端工程师+1个设计师，使用Figma的虽然主要是产品经理和设计师，但工程师也是要作为Figma的用户读取其他用户分享的设计稿，即：Figma面向的用户是整个产研团队。

    但是，在一个10个人的互联网产研团队中，只会有1名数据分析师；在一个有30名销售和售前架构的事业部中，只会有1个销售运营；而MotherDuck面向的用户，不是整个团队，而是团队中需要处理数据的占少部分的几个人。


  • 后期面向B端时，是否有足够的收费说服力？

    BigQuery和Snowflake目前的客户群分布说明了：云数仓的客户主体还是SMB而不是大KA。而当MotherDuck面向B端进行商业化时，目标群体更可能是现有云数仓供应商SMB客户的子集。

    对于这些客户而言，云端的Server使用都不够充分，解放Client端算力的利益点则并不成立。


4 Copy To China?

在了解MotherDuck的模式后，回到最现实的问题是：是否能复制到中国？
我认为不能，原因如下：

  • 时机不对

    Snowflake早期的快速增长，是伴随着C端互联网的爆发而来的，数据天然就在云上。但目前，国内已经经历了社交、电商、游戏的几轮热潮，新的增长点一是AI、二是传统企业数字化，而后者数据不是“生于云、长于云”，而是要从云下搬运到云上。无论是AI还是上云，这些不是MotherDuck模式天然适合之处。

    此外，出于安全合规等考虑，国内客户在面对要将数据托管到云上的场景比以前更加谨慎，这会导致云数据平台的售前阶段会无比漫长。


  • 国内C端用户没有付费意愿、B端采购中终端用户又没有话语权

    国内不仅是B端客户的付费意愿、付费能力仅有美国的20%不到，C端用户对一个好工具、好产品的付费意愿非常薄弱。客单价最高的项目，往往是对终端用户没有多大帮助、但对B端领导层会有功绩贡献的项目，例如政府的信息化建设。

    而DuckDB的开源性质也造成了一个尴尬的局面：对于技术能力够强的国内团队，将开源转为自建、而不是购买服务有着非常悠久的“传统”，当DuckDB出圈后，很可能是因其开源属性而被“白嫖”，而不是转化为商业化收入。


  • 国内IaaS供应商的产品能力不足

    相较于AWS，国内IaaS供应商更像是在扮演IDC2.0，导致PaaS和SaaS层开发团队无法充分信任底层的安全能力和不同场景的适配性。

    如果要在国内创建一个非常超前的产品，完全把复杂性退回给工程团队内部、对用户仅暴露最简单易用的能力，那么整体的工程难度是要远大于国外的软件开发团队的。很可能原本非常优秀的设计，因为底层的一些基本逻辑而无法实现。


  • 国内的溢价收费不成立

    以公有云厂商的对象存储产品为例，国外定价是$20/TB·月，国内是￥120/TB·月，定价接近。但Snowflake转卖AWS S3存储可以直接以2x溢价卖，即以$40/TB·月的单价进行售卖，但国内云厂商的PaaS产品则只能以1x ~ 1.2x的定价进行售卖，没有溢价能力。

    对于PaaS层的Serverless产品，由于已经是让利给用户、不强制性收取月付租金，如果不能溢价转卖IaaS的话，很难把收入给做到一定规模。


  • 中美之间有发展差

    中美的Data Stack市场有着5年以上的发展落差：当Oracle占据阿里数据库很多年后的2011年，才有OceanBase的第一个生产环境；在Cloudera上市后的5年，星环才申请上市；在Snowflake成立10年后的2022年，SelectDB才成立。

    目前，国内的Data Stack市场还处于围绕Serverless和Copy Snowflake提供更好用的SaaS/PaaS产品，而距离简单易用、适用场景广泛还有不小差距，最高优先级还是在云端和私有化部署，而不是MotherDuck定位的云上云下协同。

5 Summary

本文先探讨了大数据目前在释放价值上的困境，指出了Data Stack供应商对数据分布长尾的忽视、对孤岛问题解决的趋同，随后介绍了试图破解的DuckDB的场景定位及基本使用逻辑，进而引出了本文探讨的主题：MotherDuck是谁？它能解决什么问题？未来前景如何？
在对MotherDuck的全方位拆解中，本文首先介绍了其背后闪闪发光的全明星团队，指出这是其天价融资背后的坚实基础。随后以云数仓常见的Cloud Service - Compute - Storage三层架构为思路，对其产品架构和使用流程进行了拆解，发现其既做云端的Serverless云平台、又号称“Why Wait for the Cloud”的背后逻辑。在对MotherDuck的产品有了细致了解后，本文总结其杀手级的功能在于对多源异构数据的免ELT混合查询，以及对本地和云端算力资源的混合调用。在把产品推向市场方面，发现其没有采用toB常见的销售驱动增长，而是采用通过社区和生态合作伙伴转化用户的产品驱动增长策略。此外，出于产品管理的系统性思考，本文还对MotherDuck未来发展的方向和潜在问题给出了猜想，并对在当下将MotherDuck复制到国内的前景给出了NO的回答。
最终，MotherDuck是像Figma那样释放C端的无限可能、带来数据行业的范式转移？还是像众多来了又走的DBMS一样消失在历史长河中？
NOBODY KNOWS. 
但是，相较于其他创业公司，MotherDuck不仅有明确的差异化来避免落入性能和性价比内卷，还有一个成功的前人产品来保障其市场前景想象空间，更有令人羡慕的全明星团队，这让MotherDuck值得bet、值得我们持续follow。


Reference

  1. CMU Database Group. Advanced Database Systems: History of Databases. 2023-01. https://www.youtube.com/watch?v=LWS8LEQAUVc
  2. Matt Bornstein, Jennifer Li, and Martin Casado. Emerging Architectures for Modern Data Infrastructure. 2020-12. https://a16z.com/2020/10/15/emerging-architectures-for-modern-data-infrastructure/
  3. MotherDuck. MotherDuck Raises $47.5 Million to Make Analytics Fun, Frictionless and Ducking Awesome. https://motherduck.com/blog/announcing-series-seed-and-a/
  4. MotherDuck. Website. https://motherduck.com/
  5. Wayback Machine. Motherduck Website. 2022-11. https://web.archive.org/web/20221115150849/https://motherduck.com/
  6. MotherDuck. Announcing MotherDuck: Hybrid Execution Scales DuckDB from Your Laptop into the Cloud. 2023-06. https://motherduck.com/blog/announcing-motherduck-duckdb-in-the-cloud/
  7. Jordan Tigani. Big Data Is Dead. 2023-02. https://motherduck.com/blog/big-data-is-dead/
  8. DuckDB. Website. https://duckdb.org/
  9. Hannes Mühleisen. LinkedIn Profile. https://www.linkedin.com/in/hfmuehleisen/
  10. Mark Raasveldt. LinkedIn Profile. https://www.linkedin.com/in/mark-raasveldt-256b9a70/
  11. CMU Database Group. Database of Databases. https://dbdb.io/
  12. DB-Engines. DB-Engines Ranking. https://db-engines.com/en/ranking
  13. Databricks. Data + AI Summit Keynote: DuckDB. 2023-06. https://www.youtube.com/watch?v=GaHWuQ_cBhA
  14. 天舟. MotherDuck: 从SQLite走向数据界的Docker. 2022-11. https://mp.weixin.qq.com/s/Tm6aR_anocCemwhiTMH0iQ
  15. DuckDB. Documentation. https://duckdb.org/docs/
  16. DuckDB. Blog Archive. https://duckdb.org/news/
  17. CMU Database Group. Advanced Database Systems: DuckDB. 2023-04. https://www.youtube.com/watch?v=bZOvAKGkzpQ
  18. CMU Database Group. Quarantine Database Tech Talks: DuckDB. 2020-04. https://www.youtube.com/watch?v=PFUZlNQIndo
  19. Star-history. DuckDB 2019-2023. https://star-history.com/#duckdb/duckdb&Date
  20. DB-Engines. Trend of DuckDB Popularity. 2021-2023. https://db-engines.com/en/ranking_trend/system/DuckDB
  21. DuckDB Labs. Website. https://duckdblabs.com/
  22. DuckDB. Discord Community. https://discord.com/invite/tcvwpjfnZx
  23. MotherDuck. Company. https://motherduck.com/company/
  24. Jordan Tigani. Linkedin Profile. https://www.linkedin.com/in/jordantigani/
  25. Tino Tereshko. Linkedin Profile. https://www.linkedin.com/in/valentinotereshko/
  26. Ryan Boyd. Linkedin Profile. https://www.linkedin.com/in/ryguyrg/
  27. MotherDuck. MotherDuck in 100 Seconds. 2023.06. https://www.youtube.com/watch?v=NQgHrszyQWY
  28. MotherDuck Docs. Architecture and Capabilities. https://motherduck.com/docs/architecture-and-capabilities
  29. MotherDuck Docs. MotherDuck UI Quick Tour. https://motherduck.com/docs/getting-started/motherduck-quick-tour
  30. MotherDuck Docs. Using the DuckDB CLI. https://motherduck.com/docs/getting-started/connect-query-from-duckdb-cli
  31. MotherDuck Docs. Using Python. https://motherduck.com/docs/category/using-python
  32. MotherDuck Docs. End to End Tutorial. https://motherduck.com/docs/getting-started/e2e-tutorial
  33. MotherDuck Docs. Release Notes. https://motherduck.com/docs/release-notes/
  34. MotherDuck. Slack Community. https://app.slack.com/client/T058PEMPLPM/C058PEMQATV
  35. MotherDuck. Blog. https://motherduck.com/blog/
继续滑动看下一个
LawRachel
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题？点此查看未经处理的缓存