Open Source Data Analytics with Sameer Al-Sakran
47:29 Share

数据分析和商业智能涉及收集、处理和解释数据以指导决策。数据驱动型组织面临的一个常见挑战是如何在无需大型数据团队的情况下，让更多组织成员访问数据。Metabase 是一款开源商业智能工具，专注于数据探索、可视化和分析。

它提供轻量级的部署策略，旨在解决数据驱动型决策中常见的挑战。其界面的一个关键方面是允许用户使用或不使用 SQL 与数据交互。Samir Alsakran 是 Metabase 的创始人兼首席执行官。他加入节目讨论数据可访问性挑战、数据分析领域的演变、他领导 Metabase 14 年的关键经验教训、该平台为何使用 Clojure 语言等等。

本期节目由 Sean Falconer 主持。请查看节目说明，了解更多关于 Sean 的工作以及如何联系他的信息。

Samir，欢迎来到节目。谢谢。谢谢。很高兴再次来到这里。是的，非常感谢。所以我们今天讨论的是分析。我认为各种分析方法已经存在很长时间了。已经出现了几代不同的 BI 工具，从 Tableau 和 Looker 之类的工具开始。而且我认为，对数据分析问题的看法也有所不同，例如，利用 Streamlit 等工具来驱动洞察力，

使用 Streamlit 等工具构建自己的仪表板。还有一些像 dbt 这样的框架，专注于数据转换，并在数据到达可视化阶段之前准备数据。Metabase 已经存在近十年了。你可能已经看到这个领域的产品经历了几次演变。那么，公司的背景是什么？Metabase 在这个分析世界中处于什么位置？- 是的，我认为我们是最后一公里。一般来说，在大多数公司中，人们感兴趣的数据

存在于一个或多个地方，这取决于你的组织程度。所有数据都可能存在于一个非常完美的数据仓库中。一切井然有序，一切都很正确。或者它可能只是一团糟。我认为，我们能够将数据交付到那些从事实际工作的人手中。因此，我认为我们的核心重点之一始终是那些每天都有工作要做的可怜虫。实际上，这关乎如何获取尽可能多的数据

满足他们的好奇心，而无需任何其他人的帮助。

正如你所说，有很多引人注目的方法可以为你的公司配备工具，以便更好地了解正在发生的事情，更好地了解客户的某些细分市场正在做什么，人们点击了什么，谁注册了什么，何时注册。所有这些事情几十年来都得到了很好的解决。我认为我们试图做得更好的领域是，有一个普通人会提出问题，对吧？

我们不希望必须由分析师或工程师来处理出现的每一个问题。

因此，可以这样理解我们：大多数时候，当你看到一个仪表板时，它会回答一组特定的问题。然后还有一组容易预测的问题，从 3 到 20。我们试图让某人很容易回答这些问题。因此，与 Looker、Streamlit 或 Tableau 相比，我们不太关注创建按原样使用的仪表板，而是更多地关注创建真正能够激发一定兴趣或好奇心的仪表板，并且

后续点击、后续迭代和改进是 Metabase 的许多神奇之处所在。

因此，典型的目标用户实际上是非技术用户，他们不仅需要能够分析数据，而且还需要执行这种发现过程，因为他们甚至可能不知道自己在寻找什么或有什么问题。他们希望能够混合匹配和探索。是的，就像最后一个人，最后的组成部分。我认为分析通常是一个多人游戏。

并且人们扮演着不同的角色。我们通常由工程师设置。因此，在大多数情况下，分析师并不是设置数据库的人。通常是工程师，通常是拥有数据库的人。公司里有一些人需要数据库中的东西。

因此，通常下载 Docker 镜像并运行它的人不是最终用户。而是为最终用户提供服务的人。因此，我们在内部使用自己的术语，安装人员角色与最终用户与分析师和专业用户区分开来。但总的来说，我们的核心是帮助那些每天都有工作要做的可怜虫自己解答他们的问题，或者至少解答其中一部分问题，并减轻目前成为瓶颈的工程师的负担。好的。是的。

是的。我绝对想深入了解一些配置和设置过程的细节。但在进入这些细节之前，既然你在这个领域工作了很长时间，我认为你创立了几家与分析相关的公司。你对职业生涯中分析堆栈的演变有何看法？什么让你感到惊讶？我认为，你今天关注的趋势，在几年前可能并没有出现在你的雷达上？

我的意思是，我认为最主要和最容易想到的是自然语言处理最终为许多问题提供了一种可行的解决方案。事实证明，它的应用范围比以前担心的还要广泛。因此，我认为这是那种容易做出的本能反应。我认为有一些事情，我认为这是我一直在关注的长期趋势的一部分，我已经关注了，我不知道，几十年了，那就是工具变得越来越容易使用。

分析中存在内在的复杂性。关于如何计算净收入保留率，有些事情天生就令人讨厌。你必须了解一些数学知识。你必须做出一些选择。实际的方程式有点烦人。在 SQL、Python 或其他任何东西中对这些方程式进行编码是一件很痛苦的事情。但也存在许多不必要的复杂性。

多年来，这些复杂性一直在逐渐减少。如果你想在 70 年代计算任何东西，你必须编写大量代码。逐渐地，SQL 取代了它。你可以把它向前推进到 Excel，然后到 SQL，Tableau，以及最近几代更像 iPhone 之后软件，每个人对交互质量和易用性的要求都高得多。我认为已经有一个非常……

明显的工具简化感。这并不是说用户正在做的事情变得更简单了。只是说减少了……

自我造成的烦恼。因此，我认为在过去 10 年或 20 年里，用户体验总体上得到了显著改善。我认为围绕数据本身的塑造也发生了一些有趣的事情。我认为一直以来都存在一个问题，即你应该如何存储数据，合适的格式是什么，如何处理一致性。关于数据仓库有很多教科书。但我认为其中一件事是我……我不会说它令人惊讶，但是

我认为我不会像我现在这样重视它，但我认为自助服务数据组织的成功很大程度上取决于你向用户呈现的模式。

因此，如果可以选择在哪里投入时间，那么清理模式，特别是以一种让具有正常业务认知模型的普通人能够查看并识别他们正在查看的内容的方式来清理模式，这一点非常重要。因此，我认为通常情况下，数据存储格式从效率、一致性或便利性的角度来看非常有意义，但实际上却使任何没有深入了解该应用程序实际代码库的人都不可能理解它。是的。所以……

为了呈现一个非数据库或数据仓库专家也能理解的模式，这需要怎么做？我认为这从根本上来说是抵制将所有内容都规范化的冲动，而是拥有既丰富又易于管理大小的工作表。因此，超过 20 列的任何内容都变得越来越难以使用。

列应该使用英语或你的公司使用的任何语言命名。你应该能够理解列中的内容，而无需查找任何内容。并且概念的表示应该相对简单，我们称之为简单性。因此，用户有地址，理想情况下，它不像有两个表，从地址到用户的外部键。

虽然这可能是准确的，但它可能代表某些人历史上拥有地址的事实。这种事情使得只想查找客户数据的任何人难以理解。还有很多类似的事情……

你可能希望拥有专门的数据集，这些数据集只是对任何看起来像静态数据的视图。你可能希望根据部门或用例来迭代这些数据集。因此，有很多事情是一个普通的数据库设计者会想到的非常好的想法，但这些想法实际上使得该数据集无法被任何不如他们聪明的人使用。

我认为需要，我不想说聪明，因为在我看来，从事战术角色的人通常都相当聪明，但他们了解自己的世界。他们不了解关系数据库的世界。是的。

让他们学习关系数据库的世界并完成他们的工作会设置一个初始障碍。如果你原谅我，我经常用博客的比喻来说明这一点，曾经有一段时间，要在互联网上写东西，你必须学习 PHP 以及如何进行各种命令行操作，并设置这个、那个和其他东西。在某些时候，设置博客所花费的精力更多地是关于配置和安装，而不是关于写作的质量。

因此，你会有非常优秀的作家无法发表他们的作品。当你减少了让某人发表作品的技术负担时，那些真正擅长写作的人，而不是那些擅长设置 Unicorn 或 Nginx 等工具的人，实际上能够发表他们的作品。因此，我认为大多数组织中也会发生类似的事情，其中

在公司内部，对收入保留率、活跃用户或结账流程的具体机制有最细致入微的了解的人，不一定是那些知道如何编写 Python 或 SQL 的人。那些运行该流程或保留分析的人，实际上正在与用户交谈，并且对人们正在做什么有相当具体的了解。他们知道你是否应该将计划升级计算在内，例如

你是否应该将其归因于原始计划的保留还是最终计划的保留。我认为除了拥有这种领域特定知识之外，编写查询的人可能没有这种业务方面的知识，不同的人还将拥有不同的视角和经验，他们

他们可能能够解决一个问题，例如从这个其他领域引入新的信息，这个领域感觉是脱节的，但因为他们在该领域有经验，所以他们能够识别看似表面上可能脱节的事物中的模式。是的，当然。是的，我的意思是，我基本上同意这一点，但我认为，就数据集的形状而言，只是为了稍微弹出堆栈一下，我认为关键的事情之一是不过早地进行抽象，并让数据集的不同用法具有不同的数据集形状。我知道这并不完全是你正在谈论的内容，但我只是，对不起，我的大脑在那里偏离了轨道。你刚才谈到的一件事，我的意思是，你用博客做了一个比喻，就像如果我们能够减少启动并允许擅长写作的人写作而无需处理这些技术障碍的摩擦，那么你最终将会有更多的人只是，你知道，写作。因此，如果我们能够减少访问数据所涉及的技术障碍和配置步骤，

那么我们将会有更多的人可能擅长从可用的数据中为业务驱动洞察力。现在，你提到了围绕大型语言模型的所有兴趣。我认为有很多公司正在尝试利用生成式人工智能作为一种

访问数据的界面，以实现民主化。我很想知道，你对此有何看法？Metabase 如何融入这个领域？是的，我的意思是，我认为这可能有两种不同的角度，数据切割，然后是其余部分。所以，把两部分分开，还有一些残余部分。我认为至少对我来说很清楚的是，某些人想要与计算机对话。

将非结构化的自然语言作为现有功能的界面，这几乎是写在时间线上的。我怀疑会有一些事情，人们会自然而然地想要开始以一种对话式的自然语言进行谈话或打字。因此，我认为这将越来越成为所有分析工具的硬性期望。

为了支持这种 UX 范例，就像鼠标存在一样，突然之间你需要有一个菜单系统。如果你没有菜单系统，并且所有内容都是命令快捷键，那么你有点奇怪，你必须解释一下自己。现在，即使在拥有手机、触摸板和鼠标的世界里，仍然有一些工具 95% 以上是由键盘驱动的。我认为未来需要弄清楚

在哪里使用模糊的自然语言作为正确的用户界面。我认为使用大型语言模型生成查询、生成分析或生成深入挖掘执行计划（无论你称之为什幺）是一个单独的概念。我认为我对这一点不太乐观。我认为

让我补充一点，我对可以使用确定性工具的代理能够做的事情感到相当兴奋。我认为会有很多方法来推进一个可塑的、模糊的代理，它基本上是在大型语言模型领域工作，存在幻觉，以及那里通常存在的各种警告，如果它能够调用返回绝对正确数字的工具，它能够为用户提供什么。

因此，我认为分析中的一件事是，它是一个对准确性要求非常严格的地方。

如果某件事有 2% 的时间出错，那么在组织规模上它就无法工作。如果公司中 2% 的数字是错误的，而你无法分辨出哪 2% 是错误的，那么这真的行不通。特别是如果这 2% 的数字随机变化的话。因此，我认为尝试生成 SQL 或生成你拥有的任何目标语言可能是一条崎岖的道路。我认为在游戏已经结束并获胜之后，这将运作良好。是的。

我认为令人兴奋的，我认为将会开始流行的是，你知道，我拥有这个确定性工具的工具箱。我有代理或，你知道，单个或多个代理可以使用它。然后，许多繁重的工作将来自实际的确定性工具本身。

只是为了总结一下，我认为重要的是，如果机器产生了一个数字，那么这个数字就是正确的。我认为，如果数字只是，呃，它有点酷，一旦你谈论到人们关心的实际操作和实际事物，它就会迅速崩溃。但我认为

大多数不在分析领域的人低估了理解为什么数字 X 与数字 Y 相同所花费的时间。因此，我在这里的收入数字是 1.25。我在这里的收入数字是 1.27。哪个是对的？工作的分析师往往会花费大量时间来处理这个问题。因此，我认为那些使事情变得更难的事情最终会给分析带来更大的负担。但就 Metabase 正在发生的事情而言，我认为对我们来说……

我们的目标角色一直是非工程师、非分析师。我认为这些人理所当然地想要与计算机对话。因此，你知道，我们已经有了两个不同版本的聊天机器人。我们一直在尝试各种东西。我们有一些黑暗的 alpha 版本。我认为我们也在研究大型语言模型如何交互。

你知道，多年来，我们一直在代码库中编织各种分类聚类推荐算法。我们逐渐尝试用大型语言模型和大型语言模型调用来替换其中一些或所有这些算法。但我认为，围绕着新的习惯用法，即我可以与计算机对话，有一些非常非常有趣的事情。因此，我认为这就是我们投入大量筹码的地方。

我认为大型语言模型作为分析师仍然是，我认为这将会发生。我只是认为这将会在以其他方式产生许多非常非常酷的东西之后才会发生。是的。我的意思是，我认为你说的是对的。你需要从大型语言模型今天可靠执行的任务类型开始，特别是当我们谈论分析时。例如，你不能得到错误的收入数字。你不能让这些数字出错，否则会导致各种问题，但是

但回到 Metabase，如果我正在使用此产品，我想开始使用它。这个过程是什么？所以我假设工程师是第一个使用 Metabase 进行设置的人。设置和配置过程是什么？

是的。因此，我们的整个方法是，我们是尽可能懒惰的选择。我认为我们试图让某人能够在一个非常超阶段的项目旁边旋转一个步骤变得非常容易。因此，你只需提取一个 Docker 镜像，运行它，然后将它指向你的数据仓库。在那一点上，你只需执行数据库操作并为人们提供帐户。开源版本中有一些选项。专业版中有一些更好的选项，但通常只是

只需下载一个 jar 文件。如果你运行 jar 文件，就下载 Docker 镜像，如果你不运行，或者，你知道，如果你不想做这两件事，我们有一个云服务。但我认为这实际上只需要几分钟。对于那些

在其产品或项目周期非常早期的公司来说，我们实际上建议你不要做任何其他事情。不要制作仪表板，不要编写报告。让这些事情自然而然地发生，但在存在分析师之前就设置好我们，这通常是我们非常强烈的建议。

因为它可以通过让公司中的普通人能够在几个月或几年后才需要认真对待数据来推迟对分析师的需求。是的，我认为……

人们必须设置数据仓库，设置 dbt，设置一堆其他东西。所有这些都非常有意义，但是你可能应该有一些东西可以让公司中的普通人几个月或几年后才能提出问题。是的。并且，

然后是主要的商业化方式吗？这是主要的商业化方式之一。我认为有三种商业化方式。其中一种是，嘿，你不想自己运行它，我们会为你运行它。我们确实有一个开放核心模型。因此，有一些功能可以帮助你在更大的规模上运行，你可以从我们这里购买这些功能。

然后，如果你想在上面贴上你的徽标并将其嵌入到应用程序中，则还有一个单独的许可证。因此，如果你想将我们的产品作为白标产品嵌入到你的应用程序中，这也是一个选择。好的。然后作为一个与这个或这个前端交互的用户，体验如何？然后幕后发生了什么来提取数据？是的，我的意思是，我会谈论几个不同的人。我认为设置此程序的人可能会将 SQL 组合在一起。

因此，你出现后，点击一个按钮，你可以编写 SQL，你可以保存它，你可以编写仪表板。因此，实际上存在一种高级用户模式，如果你知道自己在做什么，

你可以做各种丰富的仪表板、模板类型 SQL、数据转换、模型事物、持久化模型等。我认为，从最终用户的角度来看，我只是能够点击一些东西。当我点击一些东西时，它会发生变化。然后，当我可以使用一个简单的查询工具时，我可以点击按钮，然后得到答案。因此，为此，我们有一种名为 MBQL 的目标语言。这只是一个预解析的

伪 SQL 之类的东西。我们的用户界面生成 MBQL。然后 MBQL 被转换为各种 SQL 方言或 Mongo 或其他一些……基本上，我们有一些其他社区驱动程序用于非基于 SQL 的语言。

这将被执行。因此，运行的所有内容都在你的数据库数据仓库上运行，然后将其拉回。客户端会进行一些后处理。因此，在大多数情况下，由于各种原因，我们不想直接生成 SQL。我们也不想强迫人们直接编写 SQL。因此，应用程序的核心是一个转换器。所以是……

谁在编写 MBQL 语句？计算机。因此，我点击一些东西，然后我们基本上使用 React 组件来做一些事情。它们调用 ClojureScript 中的 MBQL 库。ClojureScript 实际上操作这个第一棵树，然后将其踢到电线上，这就是我们大多数查询的表示方式。你需要转换多少种不同的语言？是的。

我总是弄错这一点，但我认为大约有 20 个第一方驱动程序，然后可能有另外 10 个第三方驱动程序。因此，我们为常见的数据库编写了许多驱动程序。然后，社区中的某人偶尔会为我们不支持的数据库编写一些东西，但大约有 30 个不同的数据库或 MQL 目标。好的。你为什么选择 Clojure 作为开发语言？

我的意思是，最初是 Python。因此，这个版本的第一个版本是随机的 Python。然后当我们考虑部署安装故事时，所以我轻描淡写地提到了我们使安装和配置非常容易。我们实际上为此付出了很多努力。我们使用 Clojure 来做到这一点。因此，我们希望拥有一个可以下载的单个原子二进制文件。我们

我们希望拥有成熟的数据库驱动程序。因此，我们真的不想被迫在 Python 中运行许多奇怪的进程，例如 Docker 镜像，其中存在多种故障模式。因此，我们最终决定使用 JVM 语言，尝试将 Python 移植到 Scala。这并没有取得很好的效果。然后在一周内与 Scala 搏斗之后，决定转向 Clojure。它……

正是管理转换器和处理解析树的能力使得选择 Clojure 变得特别引人注目。这是相对于直接使用 Java 编写代码针对 JVM 的主要优势吗？是的，所以我们知道我们想要 JDBC 驱动程序。我认为这仍然是，总的来说，Java 世界中的驱动程序生态系统非常强大且非常可靠，尤其是在当时与 Go 或 JavaScript 相比。JavaScript 已经变得更好。Go 仍然是它原来的样子。还不错。

是的，因此，在使用 Java 或 Scala 编写代码之间进行选择，但是决定使用 JVM 可能是我们做出的第一个决定。这种语言的选择是否对吸引新工程师加入公司构成挑战？例如，找到了解这种语言的人是否更难？不。我认为，我的意思是，这实际上是有益的。我认为，是的。

很多人想用 Clojure 编写代码。它是一种具有特定人体工程学的语言。如果你不喜欢括号，对不起，它真的不会让你觉得有趣。但我认为它给了我们一个相当具体的优势，那就是很多人只想用 Clojure 谋生。我们从在我们的代码库上工作中获得了这一好处。因此，我认为从这个角度来看，它非常非常有益。我还认为，我的意思是，这是我个人的观点，但有好的工程师和坏的工程师。

好的工程师可以学习新的语言。这并不是因为他们是好工程师的结果，但我认为，如果你是一个擅长 D-sharp 或 F-sharp 的好工程师，你可能可以学习 Clojure。因此，总的来说，我们对那些想学习 Clojure 但不一定已经掌握了它的人非常友好。对于这个特定的应用程序，在 JVM 上运行有哪些优点和缺点？我们拥有的主要优势，特别是对于开源自托管世界，它只是一个文件。

就像你下载一个 Nuber jar 文件，它是一个单一的下载。其他作品不起作用。你点击 Java-jar run，其他作品不起作用。安装过程具有一定的可预测性和原子性。

这非常非常重要。我真的认为，如果我们有一个 20 页的安装过程，需要编译本机扩展并搜索某个存储库以查找正确版本的某些内容，那么我们就不会发展得这么快或这么好。因此，我们构建单个二进制文件的能力至关重要。因此，我认为这始终是正确的选择。处理 JVM……

是一门玄学。在某些时候，我们不得不处理奇怪的内存问题，例如，

在 Clojure LAN 和 JVM LAN 中调试一些东西有时会很困难。生态系统肯定比我们开始时有了长足的进步。是的，我想说它可能比我们在其他地方得到的二进制文件更大、更胖。而且我们肯定是因为它是一个 Uber jar，因为它包含了所有内容，所以它就像一个比仅仅是“这里有一个”更重的文件，

剥离，设置代码库并去拉取所有依赖项。使用转译到不同版本的 SQL 和不同的 DVMF，创建它时是否存在特别的工程难题？我的意思是，这很痛苦，是的。所以

有很多代码。我已经记不清确切有多少了，但我认为大约有 50,000 到 70,000 行相当密集的闭包。我们使用了大量的相关内容。所以它非常重要。我认为它相当棘手，代码很复杂。这是一项艰巨的任务。我认为团队成员做得非常好。我们已经用它做了一些非常酷的事情。而且我认为这是一项相当困难的工程，人们设法完成了。而且我认为我们从中受益匪浅。

但这可能是个愚蠢的主意。回想起来，我想，“嘿，我们要编写一个编译器。”一个更明智、更冷静的人可能会说，“是的，让我们尝试找到一种无需这样做就能获胜的方法。”在某种程度上，这是在走下山的最难的路。您认为，如果您重做并选择不同的方向，那会是什么样子？鉴于我所知道的，我仍然认为我会做出同样的重大决定。

我仍然认为拥有一个目标无关的中间语言是正确的做法。我认为，如果重新开始，我会真正改变语言的粒度和抽象级别。我会让它比实际情况更远离 SQL。而且我认为其中一个具有挑战性的问题是

偶尔，我们关于用户区域的某些概念域模型，例如度量模型，这些东西存在于那个世界中，很难映射到 NBQL 原语。因此，NBQL 原语构建的基础之间存在一种张力，这几乎就像，如果 SQL 是汇编语言，它就像 C 语言一样，对吧？

如果我重新开始，我宁愿创建一个列表编译器，而不是创建一个 C 编译器，它只是能够拥有更高级别的 DSL，更接近实际的用户区域概念，而不是必须尝试将用户区域中的内容表达为 C 语言的级别和语言，以及在汇编语言之上的 C 语言的抽象级别。相反，我更喜欢有更多的脚手架和更多

在某种程度上，更抽象的概念构建目标语言。您认为，如果您想朝这个方向发展，您想基本上构建这个不同级别的抽象，这现在是一个合理的项目吗？或者它基本上花费的时间太多，并且 NVQL 系统存在产品依赖性？我认为这是那些有很多有效工作且我们不想搞砸的事情之一。

因此，重写目标语言（我想说的是大约 200,000 行代码），额外的收益是否值得？我不确定。我认为，鉴于我们所取得的成就，事情进展顺利。我认为我们本可以更快地到达这里。

因此，这不仅仅是，你知道，我们是否处于一个好的位置，而且到达这里也花了一段时间。我认为我们可以通过更好的抽象来加速很多事情。所以我想，你知道，对于度量、模型和我们现在拥有一些更高层次的概念，

以及我们处理维度的方式，我们处理列抽象的方式，在它们指向同一事物时跨不同数据库统一这些抽象。例如，纬度在数据库中的含义实际上是相同的。它不像列是纬度。只是一个纬度概念。我认为我们可以通过更高的脚手架来加速我们到达的地方，也许只需要一半的时间。但我不知道我现在是否会把它全部拆掉。

Metabase 内部是否也存在某种程度的数据缓存？是的，有几种缓存变体。最简单的一种就是，“嘿，你运行一个查询，我们会为你缓存。”这在某种程度上有一些加速作用。比如，我不知道，这是缓存，对吧？不同的供应商有不同的说法，我们可以通过某种方式将你的东西加速 2000%。所以我们有内存缓存。我们做了相当多的预计算，特别是模型和度量，我们会……

基本上按计划或某种推送方式进行预计算。所以这是两种不同的看法。然后还有一种更手动的方式，当您开始考虑跨数据库数据集时，只需让它们存在于集中式数据仓库或某种集中式位置。根据您的结构方式，您可以将其作为缓存，从

像记录数据库一样，您将它们塞入另一个速度快得多的位置。然后您将其用作一种只读缓存。但随后它就像从集中式数据源数据库中拉取或通常推送。所以大约有两个级别的缓存级别，可以说是第三个级别也是如此。

您是否遇到过数据不同步的挑战？因此，用户提取的数据是从缓存中提取的，但实际的基础数据发生了重大变化？理论上，是的。实际上，并不经常发生。我认为这通常会在某些东西损坏时表现出来。所以我认为数据陈旧通常……

这种事情出现的方式，而不是缓存本身成为问题。因此，总的来说，你知道，我们会缓存 n 秒或 n 天的东西。但我认为很多分析仍然不是完全实时的分析。

因此，您没有一个始终如一且永远最新的单一数据库。通常有多个写入器以不同的时间表写入它。因此，对于某些数据集拥有每日数字或每 20 分钟提取一次 Salesforce 并获取某些内容的情况并不少见。因此，底层数据集通常具有……

数据新鲜度的分布。我认为整个分析行业只是学会了吸收这一点，并试图找到方法来同时处理存在不同数据新鲜度的事实，并尝试通过谱系或您拥有的任何工具来传播新鲜度，以及尝试使您计算重要数字的方式能够以不需要您能够访问完全新鲜且完全一致的数据集的方式完成。

例如，您通常会提取……我认为我们将来自 20 个不同数据源的数据提取到我们的数据仓库中。我们在 Stripe、我们的 CRM 和我们运行的不同服务中都有东西。这些都在不同的时间表上发生。它们并非都在数据点生成的那一刻发生。因此，通常存在一些轻微的不一致性。但在大多数情况下……

您可以在大多数情况下解决这个问题，解决其影响。权限模型是如何工作的，它有多细粒度？权限是我的存在之痛。如果你问我，我们搞砸了什么？很多道路都通向权限。我认为构建一个权限系统实际上非常非常困难，它可以为每个人提供他们需要的旋钮，而不会创建一个怪物。

所以我认为多年来我们对这个问题的看法大相径庭。所以也许为了让这有点娱乐性，人们可以

享受我们痛苦的时光。曾经有一段时间，我们只是真正专注于这个想法：您向人们提供数据访问权限，然后数据的实际产品会确定某人是否有权访问或提供报告。这并没有真正奏效。我们迅速地，或者说不是迅速地，但在经过大量的踢打和尖叫之后，我们转向了一个拥有并行文件夹系统的世界，在这个世界中，您拥有集合，集合拥有权限，它们拥有子集合，

因此，能够按部门或按功能锁定内容的能力是混合的。但是您放入集合中的任何内容，都可以使用该文件夹隐喻。人们对这些内容具有读/写和管理员访问权限。我们同时具有按数据集锁定内容的能力。例如，您可以说，“这三张表包含 PII，并且

这八个组不能接触它。例如，如果您是实习生，则无法查找用户地址。然后在付费方面，我们还有数据沙箱，您可以通过列或行锁定内容，您基本上可以说实习生可以查看基于用户的聚合指标，但他们不允许查看客户的电话号码。

实际上有三个不同的权限系统围绕着数据访问、集合、权限，最后是更定制化和更复杂的条件化方式，可以创建分层权限或列或行控制。如果我创建某种数据视图，我是否也可以控制

某人操纵它的访问级别，以便我可以创建数据的视图，该视图可能类似于我嵌入到我的应用程序中的只读视图？我们 95% 的使用是只读的。所以我认为总的来说，我们确实有能力进行回写，但这并不常见。但是，是的，肯定有很多方法可以为具有不同信任度的人创建安全的沙箱来玩它。

我们销售的大部分内容实际上是帮助您应对这些各种情况的事物。所以我认为，对于大多数在相当高信任的环境中操作数据库的人来说，每个人都拥有相同的权限，你们都是同一个团队的成员，开源版本就足够好了。然后，在某个时候，随着您对团队的信任度和同质性降低，付费功能就会真正发挥作用。

您大约有 40,000 个 GitHub 星标。所以告诉我开源 Metabase 背后的动机是什么。是的，我的意思是，我认为鉴于我们的影响力，我们的星标可能比我们应该拥有的少。我认为我们从未真正参与过 GitHub 销售指标游戏。我认为我们首先是开源的，因为……

我认为这是使用软件的正确方法。而且我认为，如果您在数据中心运行某些东西，并且正在接触重要的数据仓库，那么我认为将其作为开源是一种更好的使用方式。我的意思是，我认为如果您想使用服务，那就太好了。这些效果非常好。但我确实认为您的数据堆栈首先是开源的。我认为有很多事情

这简化了。易于进行审核。易于在安全措施中保持谨慎。易于修复问题，您会觉得它们不会以您喜欢的速度被供应商修复。我只是认为有很多……也许只是我在谈论我自己的早期职业生涯，但我经常不得不运行来自供应商的软件，这些软件根本没有被修复，或者我们以奇怪的方式破坏了它。能够进入源代码并进行修改是我非常重视的事情。是的。

因此，就个人而言，我认为至少在目前，大多数软件都应该以这种方式交付。随着世界的变化，我的观点也会改变。而且我认为鉴于它具有很多互操作性，因此我们针对大约 30 个数据库，让人们能够检查驱动程序并说，“实际上，您在这里访问索引的方式有点笨拙。您应该改为这样做。”这非常有益。而且我认为

我们在信息采用使用方面已经从开源产品中获得了大量收益。因此，我们仍然非常感谢人们的抱怨。

我知道这听起来有点奇怪，但我们从人们的抱怨中获得了很大的价值。就像，它让我们非常清楚地了解谁想要什么，他们有多想要。我认为这是一种信息，在其他情况下，我会花很多钱来生成。因此，拥有一个公众可见的东西实际上非常有价值，仅此而已。对于这样的事情，就像您谈到的那样，您觉得这是

开源本质上是应该使用软件的模型。那么从业务方面来看，企业带来的价值（他们可以收取费用）不再是他们编写的代码行。他们必须找到其他方法来带来价值。那么，对于那些首先是开源的或真正投资于开源的公司，您认为他们需要如何考虑带来商业价值，以便他们最终……在某个时候，他们必须支付账单。一般……

我在这里的框架是这样的。您应该非常早地了解您负责什么。我认为编写项目、发布它、运行一两年然后说，“哇，如何从这个东西中赚钱”是很危险的。所以我认为大多数软件，理想情况下，都有特定的用户。它有一组特定的选民和从中获得价值的人。

您应该了解谁在使用它，为什么他们使用它，他们重视什么，其他角色是什么。然后，假设您要将其商业化，那么商业化的途径是什么，然后尝试很好地寻找这些途径。

所以我认为我们从很早就知道我们想为白标收费，如果您想将我们嵌入到您的应用程序中，那就太好了。但我们首先是一个应用程序。因此，如果您想为我们贴上白标，那将是一件付费的事情。我们不是在构建一个库来构建您自己的库。我们不是在构建一个开源库来构建您自己的分析应用程序。我们明确地构建了一个您可以嵌入的应用程序。

我认为这创造了很多清晰度。它使理解路线图应该是什么变得容易。它使我们有希望对我们的用户负责。所以我认为我们从未从任何人那里撤回过任何东西，你知道，任何我们喜欢不好的功能或做任何太任性的事情。所以我认为，如果您计划作为企业家、创始人或公司尝试通过开源发布软件，请了解人们最终会为哪些东西付费。我认为这个愿景越清晰，越有道理，您就越有可能把事情做好。我认为有很多项目试图商业化，但最终失败了。比如，你知道，很长一段时间以来，没有开源公司。然后出现了一波热潮。然后很多公司都经历了某种“悔过”的时刻。我认为，

区分获胜者的一件事就是某种感觉，好吧，这就是人们付费的原因。我认为区分获胜产品很重要。我认为如果没有获胜产品，您实际上并没有玩开源游戏。您只是在进行某种奇怪的半心半意的营销冒险，侧面冒险。

因此，了解您放弃了什么以及为什么，以及为什么人们想要它，并确保它实际上可以替代替代方案，而不仅仅是一个残缺的版本。其次，如果您赢了，您到底在卖什么？对我们来说，我认为很多事情都归结为了解安装程序及其老板。我们试图使安装程序重视的免费事物，他们的老板在成功后会要求付费的事物。

这是一种我们使用的通用启发式方法。它在某些方面有效，而在其他方面无效，但我认为从一开始就相信并能够以某种方式验证的东西非常重要，即使在您开始收费之前也是如此。

是的，我的意思是，我认为您可以收费的内容以及人们如何评估交付的价值随着时间的推移而发生了变化。曾经有一段时间，您可以编写某种收缩包装软件，并且您明确地为该软件收费。显然，它带来了价值，但您在很多方面都在为本质上您编写的代码行收费。我认为现在，特别是对于托管服务和其他不同的方法，本质上是将企业货币化，

它改变了模型，您可以在其中放弃源代码，而价值并不存在。它是其他的东西。它是在使运行变得非常容易或某些在开源模型中可能不可用的企业功能方面，等等。您认为现在，越来越多的代码至少是在 AI 的帮助下编写的，

这在某种程度上甚至更降低了代码行的价值，因此有必要找到其他方法来为您的客户提供价值。我的意思是，我认为这取决于 AI 的隐含改进率。所以我认为有一种版本是没有人有任何价值，因此不要费心。我不是那种极端主义者，但我认为还有另一种版本，就像……

你知道，它主要就像今天一样，只是人体工程学略好一些。在这两个极点之间，存在着我们将会遵循的道路。我之所以提出这一点，是因为该频谱的某些部分

将任意咒语转换为类似自然语言的东西并使其发挥作用的能力仍然非常非常有价值。而且，你知道，LLM、副驾驶等等实际上只是一种更高级别的语言。

但您仍然基本上在使用更高级别的语言。在某种程度上，LLM 实际上只是您超级高效的 DSL 的编译器或解释器。仍然有人必须进行吟唱。能够进行吟唱的人将拥有宝贵的技能。能够将这些整合起来以解决实际问题的人仍然是有价值的。我认为随着……

构建特定系统所需的技能水平降低或改变。它开始将价值转移到能够理解要构建什么的人身上，并且知道“实际上，我需要填充这个特定的乐高积木才能赚钱”的人的相对价值甚至更重要。

所以我认为，就像，但我仍然认为，对于该频谱的大部分而言，仍然需要有人拿着魔杖，你知道，并进行吟唱。

我只是认为这种语言的性质将会改变。提示与实际的后处理或预处理有多少价值？有多少是实际的模型训练？有多少是微调？仍然会有很多仍然需要有人完成的高价值工作。除非您假设 LLM 和您围绕它们构建的遗传系统发展得如此之快，以至于所有这些都由它们完成……

那么仍然会有很多人这样做。无论我们称他们为软件工程师、提示工程师、产品创建专家还是魔术师，这并不重要。仍然会有一些人。我认为这可能会改变杠杆作用。所以我认为，所以您不需要一千名软件工程师来构建某些东西。您可能只需要 10 名提示工程师来构建与规模相当的东西。

希望这意味着我们将做更大更疯狂的事情，并且将来会有更好的玩具，并且我们将能够应对更大的项目。但我仍然认为，对于该频谱相当大的一部分，仍然会有人……而且公司仍然需要……

找出这些乐高积木是什么，识别它们，构建它们最好的乐高积木版本，然后以某种方式找到接触人们并让人们想要从他们那里购买的方法。我认为这是一种很好的方式，可以将事情与我们甚至在一开始就谈论的内容联系起来，您使用了关于博客的类比，如果我们可以减少本质上

配置设置步骤来帮助想要写作和发布他们作品的人，那么您将获得更多正在进行的创造性工作。我认为这类似于，如果您基本上可以降低进入门槛，能够创建大量代码并最终创建产品，那么我认为这并不是

做这些事情的人少了。实际上有更多的人在做这些事情，因为现在不是任何人都可以做到，而是拥有某种技能的人现在基本上可以创建某种产品体验，或者至少我们会在某个阶段到达那里。如果我可以举一个具体的例子，这可能会使这一点更加清晰，我认为，再次，除非出现某种奇怪的奇点，否则我们可能仍然想要 iPhone 健身应用程序。

而且有人必须构建最好的健身应用程序。关于构建应用程序的人的主要技能的问题是，每个人至少都具备 iOS 开发和 Objective-C 等方面的熟练程度。或者它更像是谁对健身应用程序有最好的想法？我认为将会发生的是

那些机械技能在 iPhone 推出时至关重要，并且第一代最好的健身应用程序，只是任何能够编写无错误应用程序的人，已经转变为谁对如何构建该事物有最好的想法。但它仍然有市场。您仍然必须构建它。您仍然必须构建比其他人更好的应用程序。仍然会有人构建该应用程序。

再说一次，他们可能会有不同的头衔，并且可能在不同的编辑器上工作。好吧，萨米尔，非常感谢您的到来。我真的很喜欢这次谈话。我们最后深入探讨了这个问题，我喜欢这一点。我认为有很多东西需要消化，特别是当我们谈论真正专注于减少（我认为）进入门槛或访问、分析、从数据中获取价值所涉及的摩擦的产品时。同样。我玩得很开心。感谢您邀请我参加。好的。谢谢，干杯。

谢谢。