最近的一次讨论涉及了从ETL的历史到元数据管理和数据工程的未来等方方面面。
在A.广大访谈杰夫·迈耶森，软件工程每日播客的主持人，Fivetran CEO乔治·弗雷泽解释列存储与行存储的数据仓库之间的关键区别，所描述的独特Fivetran工程方法，并分享了他的信念，数据工程将从偶然进化远复杂性和朝向功能简单。这里有亮点，编辑，缩合清晰度。
杰夫梅耶森：我们将谈论数据集成和数据仓库。让我们从“数据仓库”一词开始。这是什么意思？
George Fraser:数据仓库是一种数据库，用于存储公司中发生的所有事情的所有数据。有些人强烈地认为数据仓库必须有一个星型模式，或者在它下面有一种特殊的技术，但在我看来，在您的公司中扮演这个角色的只是一个数据库。
JM：说说数据仓库之前和之后的云。
GF:在云计算出现之前，数据仓库都是在线的，而且大多被大公司使用，因为它们非常昂贵。许多公司都在使用与生产数据库相同的技术——他们将使用与操作数据仓库相同的数据库来运行网站或零售库存。在云革命发生的同时，数据仓库也发生了另一场革命——列存储的广泛采用，这是一种构建关系数据库的完全不同的方式，对于分析查询来说更快。当数据仓库转移到云中，列式存储数据库得到广泛采用并变得更便宜时，越来越多的公司开始使用数据仓库。
JM：为什么人们今天数据放在数据仓库？
GF：企业使用许多不同的工具。它们通常将具有金融工具，如Quickbooks或NetSuite，以及像条纹或方形的支付系统。他们可能有像Github或Jira这样的软件开发工具。他们将拥有营销工具 - 有时数十或数百人。如果您想知道您的业务内部发生了什么，第一步通常是将所有数据复制到单个数据库中，该数据是您的数据仓库，因此您可以编写一个关于任何发生的任何数据的查询。
JM：是在数据仓库坐在内存中的数据？它是在磁盘上？难道我们知道它在做什么？
GF:所以数据仓库中的数据将一直保存在磁盘上，直到您查询它，然后它将在内存中流水线运行您的查询。现在的很多数据仓库，不仅将数据存储在磁盘上，实际上还将数据存储在基于云的blob存储中，比如S3。Snowflake和BigQuery是这样工作的。当数据冷却时，它驻留在blob存储中，当您开始查询它时，它们将它加载到本地磁盘中。然后就在您运行查询时，它们将其加载到内存中。
JM：如果是在磁盘上，为什么不把它留在我们的数据库中，直到我们准备查询呢？什么优势是数据仓库给我们？
GF：仓库中数据的柱状格式非常优化为分析。这就是“列商店”一词来自的地方。所以，如果我正在写一张人，而不是编写这个人的标识符和姓名和电子邮件地址，然后写下下一个人的ID和名称和电子邮件地址，我实际上会在列中写下所有ID，然后是所有的名称，然后是所有电子邮件地址。对于非常复杂和令人迷人的原因，这种布局很喜欢编写一个非常快速的查询处理器。
JM:所以如果你想汇总整个列的总数，你可以遍历该列中的每个单元格，而不会跳过行中的其他信息，这将会更快。
女友:完全正确。这是柱状格式的第一个也是最明显的优点。如果您对列中的数据不感兴趣，您可以不读它，甚至不必跳过它。事实证明，为了充分利用列存储概念，您不仅需要一种不同的文件格式，还需要一种不同的查询规划器。您需要一个面向块的查询处理器，如果您深入研究代码，就会发现它的内部函数操作的是向量而不是元组。因此，列存储数据库的每一层都是用不同的方式实现的，在很多情况下是相反的。
JM：现代数据平台的一个方面是我们不仅仅是与数据库接口。当我们使用SEALFORCE和Google Analytics的API时，我们正在累积数据，该数据在这些公司的数据库中。解释这些基于API的系统如何改变了数据平台的世界。
GF：根本的变化是，人们使用更多的工具来运营他们的业务，而这些工具都有的API。该数据分散在不同的地方，和所有API的工作方式不同，所以它创造了很多偶然的复杂性。创建一个集中的系统，从所有的API和数据存储访问数据的最佳方法是进行复制，以将其复制到一个数据仓库中。原因是速度。API是运行任意查询太慢。如果你是幸运的，这是一个简单的查询，可以返还快，但它可能需要数小时。不工作，当你想你的企业回答问题。对GitHub的API，NetSuite的API，Salesforce的API，你的名字也是如此。所以，你需要所有的数据复制到一个更快的数据库，以在可接受的速度访问它。这就是问题所在Fivetran被设计在了最简单的方式来解决。 We have prebuilt connectors to a little over 150 data sources, including all the major databases, and we replicate the data one-to-one into one database. We like to think we solve the first and hardest step of integrating your data, which is getting it all in one place.
JM:解释一下Fivetran是如何自动化数据集成过程的。
gf：嗯，我们的数据连接器不像传统的ETL工具一样工作，其中用户指定要调用的API端点的所有详细信息，如何归一化数据，如何加载到目标中。Fivetran连接器是自动的。因此，当我们与Salesforce这样的数据来源交谈时，我们所做的第一件事就是调出元数据API并询问Salesforce是Salesforce帐户中可用的所有对象和字段。然后我们动态地将请求写入Salesforce API，因此我们将所有数据从此特定客户的Salesforce源中获取。然后我们通过自动进程进入目的地数据仓库的自动进程再次摄取该数据。
对于软件工程师来说，这可能看起来很明显，但相信它，这是ETL之地的一种非常激进的方法。零触摸ETL工具的想法与我们第一次出发出来的时候的概念非常不同。但我们发现这对客户来说是一个非常成功的方法。它们在其数据仓库中获得了所有数据的完美副本，并且可以通过编写SQL查询来转换和模拟数据。SQL成为管理数据，清理它的伟大语言，并将其重新组织成一种准备用于查询分析师的格式。
JM：因此您的数据连接器本质上消除了工程师的工作，他们将为数据编写脚本的工程师的工作，如Salesforce为数据的一堆次数，并将其放入数据仓库以正确的格式。
吉安卡洛-费斯切拉:完全正确。这是没有魔法的。例如，我们正在学习Salesforce API并编写代码，就像构建连接器一样。最大的区别在于，我们编写的是任何人都可以使用的通用连接器。因此，我们使用Salesforce元数据API来发现可用的对象，并在您的帐户中获取所有数据。如果随后添加了新的自定义字段或表，我们会发现并自动将其添加到数据仓库中。然而，当人们在内部进行ETL时，他们通常会编写一个脚本，在编写脚本时查询Salesforce中存在的所有字段和对象。那样更容易也更快。Fivetran是一种很困难的方法，但它的优势是有数百个客户使用这个连接器，所以我们只需要编写一个完美的Salesforce连接器，任何人都可以使用。所以我们的工程师所做的工作具有规模经济效益。 We have to understand every little quirk of every API endpoint of all the data sources we support, but we only have to figure out all those quirks once, and then every customer can benefit from them.
JM:我们先来关注一下业务。数据源和目标之间的垂直连接器是一项巨大的业务，需要扩展到许多邻接的领域。告诉我Fivetran的长期愿景。
GF：这是一个惊人的范围的问题。如果你跟工程师10名，他们三人将在某个时候建造他们公司内部的数据管道。工程工作的一个惊人的数量进入一遍又一遍又一遍写连接器NetSuite公司，他们都是真的一样。因此，这是一个巨大的行业，对此我们感到我们的前景非常乐观。公司的历史，每年一直是增长最快的一年不断，尽管基地越来越高。我们长大去年的三倍以上。在就未来而言，我们将继续工作，扩大我们的连接器的范围和提高我们的连接器的质量。还有的极端案例数量惊人，尤其是在数据库中，我们都在跟踪每一个最后一个，所以你可以在任何我们所支持的数据源插上的意图，它只是为你工作。这是我们在软件工程任务。
还有一堆相邻的机会。我们认为我们可以在管理元数据周围添加大量值，因为我们构建了连接器并非常紧密控制它们。我们应该能够告诉您这样的事情：“您的数据仓库中的这一行来自于七个月前的特定API调用对阵Salesforce数据源。”这种信息真的很有价值。我们也认为我们可以帮助人们编写转变。由于我们的连接器是不可配置和标准化的，因此我们为NetSuite提供的API数据源提供的模式总是相同的。我们的客户通过遍及架构对模式编写相同的查询，我们认为我们可以编写模板和食谱，例如，将归一化的NetSuite架构转换为准备好的策略的模式。这些SQL查询不会是完美的，但他们将在那里80％或更多，并节省您的分析团队很多时间。
JM：让我们谈谈贵公司的工程。告诉我更多关于您如何从工程管理角度构建的公司。
GF：工程团队大概花费约在跨所有数据源共享的问题，其工作时间的一半，不管是用户界面，或核心管线的代码，或代码，会谈的目标。另一半去朝编写和维护连接器。One of the cool things about engineering at Fivetran is that we’re always writing new connectors, so we’re always building new stuff and learning new lessons, and we’re very rigorous about taking those lessons back to the existing connectors and re-factoring them to reflect our latest best practices. The connectors are definitely on a spectrum of difficulty. So the most difficult connectors are databases, and the least difficult connectors are always startup APIs. They’re always very clean — they’re beautiful. Unfortunately, they usually don't have very many users. But if you look at an API of a company that's a few years old that has some good engineers there, they’re always great. So typically what you'll see for an engineer at Fivetran is they’ll go through a progression where they start out working on the more straightforward connectors, then on core code, working on destinations, working on more difficult connectors like databases. It's really a great place to grow your career as an engineer, because we have this great variety of work.
JM：最后一个问题：数据工程世界如何在未来十年中发展？
gf：我认为它会变得更加简单。底层技术已经如此更快，更便宜，可以在没有过去占主导地位的这种工具的情况下进行数据工程。所以我认为生活实际上越来越好，更容易数据从业者。他们可以使用真正快速，真正的廉价数据库，如雪花，bigquery和redshift。它们可以使用零触摸ETL工具，如Fivetran，他们可以将他们的努力集中在真正区分其业务的事情，如支持一遍又一遍地构建连接器和查询引擎。所以我认为我们应该对数据工程的未来持乐观态度。