数据世界再次发生变化。自从 Hadoop 出现以来，人们就将工作负载从他们的数据仓库转移到了新的闪亮的数据湖中。没过多久，2010 年开源的 Spark 就成为了数据湖上的标准处理引擎。
现在我们看到一个反向趋势，回到数据仓库。随着这一趋势，DBT 几乎已成为在现代云原生数据仓库上进行转换的事实上的标准。使用 DBT，人们发现他们可以用更少的工程师和更少的维护更快地构建数据管道。
我预测这种趋势只会持续下去，总有一天，DBT 将在用户数量、工作数量和在数据领域的重要性方面超过 Spark。
Spark 填补了一个不再存在的空白
Spark 背后的整个前提是 RDD。弹性分布式数据集 (RDD)是一种分布式内存抽象，允许程序员以容错的方式在大型集群上执行内存计算。
显然是需要在多台机器上进行巨大的内存计算，因为单个机器的内存是有限的，唯一可行的集群规模计算的选择是Hadoop，它是基于MapReduce的。MapReduce是出了名的重度磁盘IO，并没有真正捕捉到所有闲置的RAM的价值。
Spark完美地填补了这一空白。突然间，大量的大数据处理都可以高效地完成。而且，Spark采用了一种非常好的函数式方法来定义你的操作，所以你的语法很简单，至少与MapReduce代码相比是如此。
但说实话，这个空白还在吗？这些天来，我们都在云中一起选购我们的基础设施。
如果这还不够内存计算，你现在可以使用AWS Batch或Kubernetes等服务轻松地将你的工作负载分布在多台机器上。
你不再需要有一个分布式的应用程序，而你可以使用标准的python代码轻松地进行扩展。
我们的客户95%的工作都是相对较小的python工作，也许有5%的工作我们可以使用Spark提供的重任。这很好。但是，Spark已经不是最重要的了。它只是我们工具箱中的另一个工具。
"啊，这个不能运行单节点？最好在这里使用Spark"。
我们已经建立了Datafy，不需要再担心这些问题。我们只是告诉Datafy要运行一个作业，需要多少个节点，多少内存。然后Datafy会在幕后为我们做一些Kubernetes的魔法。
它并不关心我是安排100个小的python作业还是5个大的spark作业。
它自动调整Kubernetes节点的规模，启动它所需要的pods，然后再次调整规模。这节省了云计算成本，也让我不用担心基础设施的问题。我可以专注于我的数据工作。
今天的数据仓库比2010年的时候要强大得多。
这不仅仅是云计算基础设施的成熟。2020年的数据仓库与内部部署的昂贵、难以维护的单体完全不同。所有大的云计算供应商都有强大的产品，尤其是谷歌Bigquery，让你的入门变得超级方便。它功能齐全，性能高，得到广泛支持，最重要的是，它是纯粹的现收现付定价。你按扫描的TB付费。这使得进入的门槛降低了很多。你不需要再投资一大堆钱来建立一个数据仓库。虽然，显然，数据仓库仍然不便宜。但运行Databricks集群也不便宜。价格差异在2010年是一个论据。在2020年就不是了。而且，可扩展性也绝对不是一个问题了。除了Bigquery，像Snowflake这样的公司在市场上创造了巨大的吸引力，并证明他们可以大规模地执行。
为什么是DBT？
为什么DBT获得了如此多的关注？以下是我认为他们做得对的地方。
- 他们很好地执行了一个 "明显 "的伟大想法。
有了DBT，你就可以使用SQL构建你的数据管道。你可以建立模块化的管道，并通过变量和宏引用你的数据模型的其他部分。这是一个我在工业界至少见过5次的想法。总是有一些胶布解决方案被放在一起，以安排一堆SQL工作。说实话，我们也做过一些这样的解决方案。但是，我们从来没有真正意识到要把这个产品化为更大的东西并推向市场。这显然是一个伟大的想法。但DBT实际上是在执行这个想法。为他们点赞。
- 他们在市场上有一个令人难以置信的势头
他们上个月已经宣布了他们的B系列。他们得到了一些最著名的风险投资公司的支持，如Andreessen Horowitz和红杉资本。他们最大的竞争对手（据我所知）是Dataform，它刚刚被谷歌云收购。Dataform已经落后了。这只会使他们更成为一个小众的参与者。如果你是在GCP上，那就太好了。但我不认为谷歌有任何计划让Dataform在Redshift、Synapse或Snowflake上发光发热。
- 他们在工程方面很强
作为一个数据工程师，我总是对那些声称他们可以消除复杂性，现在 "每个人都可以在3个简单步骤中建立一个数据产品 "的工具有点怀疑。通常情况下，这些都是类似于excel的产品，或者是带有闪亮用户界面的拖放式产品，在销售演示中给人留下深刻印象。但是，当你需要在生产中维护这些龙的时候，它们确实会让你哭泣。
DBT则不同。在DBT中，你可以轻松地使用变量，你可以构建模块化的代码，你可以添加单元测试，你可以将所有的代码提交给git，并轻松地将DBT集成到你的CI/CD管道中。它甚至可以为你生成一个文档网站，包括世系。
那么，"Spark "已经死了？
一点也不！我认为Spark是一个很好的工具，如果你有大数据工作负载，需要大量的繁重工作，并且你有工程师为你建立管道，那么Spark就是一个很好的工具。我认为，如果你有大数据工作负载，需要大量的繁重工作，而且你有工程师可以为你建立管道，那么Spark是一个伟大的工具。Spark仍然比SQL更有表现力，而且你对Spark中的处理方式的控制要比SQL多得多。
一般来说，数据环境是不断变化的。技术来了又走。这是一个以一种对你的组织有意义的方式将它们结合起来的问题，而且这种方式对你的团队也有好处。然后你就能从数据中获得洞察力，这就是我们在这里的原因，对吗？Spark、Python、DBT和其他许多工具都只是我们的工具带中的工具。没有一辆伟大的汽车是只用一把螺丝刀或只用一把锤子建造的。
我确实认为，因为DBT的入门门槛很低，而且知道SQL的人比知道Spark的人多得多，所以DBT最终会被更多人采用。它使数据分析更加民主化。我们已经把它从财务部门拖出来了，现在我们正在把它从IT部门拖出来。有一天，分析学将真正生活在业务部门。想象一下吧。