一年前,一些人已经预测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)
最新内容
- 1 hour ago
- 1 hour ago
- 2 hours ago
- 2 hours ago
- 2 hours ago
- 6 hours 49 minutes ago
- 8 hours 14 minutes ago
- 8 hours 23 minutes ago
- 8 hours ago
- 1 week 1 day ago