一年前，一些人已经预测dbt有一天会比Spark更大，而2021年证明了他们的正确性：dbt已经变得非常受欢迎，有传言称dbt实验室可能会以60亿美元的估值再次筹集资金。按照这个速度，他们很快就会赶上2021年9月估值达到380亿美元的Databricks。
尽管如此，今年Spark最让我印象深刻的是，几乎每一篇关于现代数据堆栈的博客文章都没有Spark，它是围绕两个关键组件构建的：
- 一个大规模并行的SQL引擎（BigQuery、Redshift、Snowflake）
- 和…dbt
上游：无代码提取/加载工具[no-code Extract/Load tools]（Fivetran，Stitch，Airbyte，Hevo）。下游：BI工具（Tableau、Looker、Power BI、Metabase）和反向ETL工具，用于将数据导出到专用数据库（客户数据平台等）。
The Modern Data Stack according to Dataiku: https://blog.dataiku.com/challenges-to-the-modern-data-stack
我只需要在谷歌图片中键入“现代数据堆栈”，就可以注意到数据市场上的所有公司都在提出自己的技术列表，因为他们通常会试图将自己包括在列表中。
但我也注意到，这个现代数据堆栈通常完全是在没有Spark的情况下构建的，而Databricks生态系统大多被视为它的一个完整替代方案，尝试加入可以放在堆栈中心的SQL引擎的小圈子：他们在12月发布了与dbt Core以及Databricks SQL的完全集成。
最近，我回复了另一家公司的人，他问我是否值得将Spark添加到他们的现代数据堆栈中。由于我的团队目前同时使用pySpark、BigQuery和（一点点）dbt，我自己也思考了很多这个问题。因此，我用一长串的利弊来回答他们，这些利弊激发了我目前的思考，我在这里分享：
基础设施：
BigQuery完全由谷歌管理，你没有什么可做的。相比之下，Spark的掌握要复杂得多，即使这往往会变得更容易（Spark无服务器版在GCP上预览，在Databricks和DatabricksSQL上都有）。
学习曲线：
同样，在BigQuery（它只是SQL）上比Spark更容易找到或培养熟练的人才。我的建议是：在Scala、Java或.Net中，更喜欢pySpark而不是Spark。例如，Python更容易访问，并且已经被Airflow使用。我认为在Spark中使用Python以外的另一种语言的唯一有效理由是：“用RDD做非常高级的事情”和“重用一些公司已经用Java编写的代码，而不必重新实现它”。
A hundred thanks to XKCD web comics who gave me express permission to use one of their comics in this article: https://xkcd.com/1409/
代码组织：
dbt展示了组织SQL转换管道的正确方法（我知道这一点：从2014年到2017年，我开发了一个工具，它做了与dbt相同的事情，但针对Apache Hive）。据我所知，目前没有任何工具可以为pySpark做同样的事情（dbt确实支持spark-sql，但没有完整的pySpark）。这就是为什么我们开发了一个内部工具，我希望有一天能开源。如果没有这样的工具，很容易回到dbt帮助我们停止的糟糕做法。
表达能力：
我喜欢SQL，甚至比BigQuery更喜欢，但我不能只使用SQL来完成我需要的一切。此外，我认为使用Jinja模板不是正确的解决方案：正如Maxime Beauchemin在他的博客文章中所说的那样，这将导致大量的模板化SQL和YAML。就我个人而言，我认为这与第一个调度器中的错误相同：以代码配置有很多限制，而Airflow通过证明以代码配置（感谢Python）工作得更好来扭转局面。是的，JINJA确实解决了作为代码的配置的一些刚性问题，但我仍然觉得JINJA相当沉重和冗长，可读性不强，并且单元测试JINJA代码似乎相当乏味。
SQL的局限性：
和Maxime Beauchemin一样，我相信（至少我希望如此）当BigQuery、Snowflake或Redshift提供类似于pySpark中提供的DataFrame API时，事情会变得更好。Snowflake实际上已经做到了：他们最近发布了Snowpark，其DataFrame API显然借鉴了Spark的API。我最近开始为BigQuery POC一个DataFrame API，以展示这样的东西还可以做什么（我承认，其中一些已经可以用JINJA宏完成了，但在某种程度上我觉得不太优雅，也更难维护）。我将在下一篇文章中详细介绍这个POC。
UDF：
SQL的另一个重要限制是：有些逻辑使用UDF比使用SQL代码更容易实现。在BigQuery中，UDF必须用SQL或Javascript（！！）编写。Idem与Snowflake，这也允许Java。去告诉一个只懂Python的数据工程师/分析师/科学家写一个Javascript UDF…PySpark允许我们用Python写UDF，我等不及BigQuery也允许了。
With explicit permission from xkcd: https://xkcd.com/1409/
提取负载（E/L）：
我很惊讶有很多人似乎使用自定义Airflow操作符来执行E/L任务，而不是Spark。我认为这是Spark最大的优势之一：它有大量的连接器，可以读取/写入所有内容。它还可以对json和xml执行自动模式检测，而不会让人头疼。而且，正如Ari Bajo所指出的，最好使用中心状态（Spark）并具有O(n)连接器，而不是为每个源-目的地对写入O(n²)连接器。Spark可以做到这一切，我认为它的运行成本比Fivetran便宜得多（尽管我必须说，开源工具Airbyte可能是一个很好的选择）。Spark的安装成本可能更高，但一旦支付，复制和添加新的源/目的地不会花费很长时间。另一个优点是：Spark可以同时进行ETL和反向ETL。
的确，它确实需要非开发人员可以使用图形界面的开发人员。但我也有一种感觉，一个没有GUI的开发人员将无法调查和解决潜在的问题（但我可能错了）。
实时：
在我的团队中，我们开始将pySpark用于简单的实时案例（BigQuery中的原始数据摄入），但我对这个主题还不够了解，无法将其与其他替代方案（如lambda函数）进行比较。我们将注意到，由于其微批处理模式，Spark使我们能够非常容易地获得一次保证。
With explicit permission from xkcd: https://xkcd.com/1409/
结论
总之，我认为大多数这些考虑都围绕着一个中心点，这是SQL最大的优势，也是它最大的弱点：它的简单性。正是由于SQL的简单性，像BigQuery和Snowflake这样的平台才如此易于使用，而且它们的采用范围如此之广，同时降低了供应商锁定的风险。相反，这种简单性也是其最大的缺点，因为SQL很快就达到了极限，开发最佳实践更难应用，也不那么普遍。多亏了dbt和JINJA，其中一些不利因素可以得到缓解，但我相信，该行业将不得不走得更远，使用DataFrames或其他类似的API，帮助数据技术人员编写更通用、更高级的转换，并更好地满足不断增长的数据需求。
With explicit permission from xkcd: https://xkcd.com/1409/
在我的团队中，主要的挑战之一是我们倾向于在pySpark和BigQuery之间交替使用，以从每种工具的最佳功能中获益。这使得数据沿袭更加困难，因为dbt只允许我们可视化BigQuery部分，而我们的内部“dbt for pySpark”工具只允许我们查看pySpark部分。从长远来看，我希望BigQuery能够添加与pySpark（DataFrame API和Python UDF）相比所缺少的功能，这将使我们有一天能够将当前的pySparkTransformation迁移到BigQuery。pySpark方面剩下的只有E/L和实时数据处理。
With explicit permission from xkcd: https://xkcd.com/1409/
(A French version of this post is available here)
