不要在大数据管道中使用SQL

　　使用高级编程语言编码数据管道的时间

　　> Good old "use the right tool for the job"

　　ETL管道已经使用SQL建立了几十年，由于许多众所周知的原因，它运行得很好（至少在大多数情况下）。

　　在大数据时代，工程师和公司疯狂地采用新的处理工具来编写其ETL / ELT管道（例如Spark，Beam，Flink等），并开始编写代码来代替SQL过程来提取，加载和转换其庞大的（ 或很少-如此！）的数据量。

　　测试ETL / ELT管道的时代

　　由于现在可以将ETL / ELT管道实现为以高级编程语言（例如Scala，Java或Python）编写的（一系列）作业，因此，您的所有处理步骤都表示为可以结构化，设计和大部分代码化的代码。 所有这些都完全覆盖了自动化测试，以建立可靠的开发和部署管道。 实际上，数据工程师现在可以利用在包括git，pull request，自动化测试，构建甚至部署在内的常见工具的环境中工作，从而告别了嵌入巨大SQL查询的可视化工具，这些SQL查询几乎是无法测试，难以理解，难以维护且令人讨厌的 由任何开发人员（参与传统DWH开发的人员都可以联系）。

　　这种执行ETL / ELT的新方法最被低估的好处是，对于数据管道而言，自动化测试现在已成为现实，与世界上任何其他软件一样。

　　为了清楚起见，让我们以一段伪代码（类似于Apache Spark等数据处理框架）为例，它代表一个简单的管道：

　　FooCollection inputRecords=// extract raw data from sourceBarCollection enrichmentRecords=// extract data from external tableOutCollection

　　outputRecords=inputRecords .cleanAndNormalize .enrichWithBar(enrichmentRecords) .toBarCollectionoutputRecords.writeTo(destination)

　　尽管管道非常简单，但实际工作离此结构并不遥远，并且可以立即看到：

　　· 该代码易于阅读且易于解释；

　　· 可以将代码拆分为易于测试的部分，并可以使用类，方法，函数，接口以及高级编程语言可以提供的所有常见结构来设计成具有高度可维护性和良好格式的代码；

　　· 管道可以使用TDD方法实现。

　　简而言之，整个项目可以围绕干净，经过测试和可重用的代码构建，从而使您的数据管道更强大，易于维护和部署。

　　处理"完整SQL"样式

　　如果您想用SQL编写上面的管道，那么结果将是一个很长的查询，当语句，字符串操作，联接和类型转换全部放在一个不可维护的工作中时，将执行很多情况。

　　即使通过将工作分成多个部分来明智地将事情和职责分开，SQL仍然无法拥有强大的自动化测试框架。 此外，根本无法实现类型安全，编译时错误，编码最佳实践，测试驱动的方法等功能。

　　老实说，一些商业ETL和数据集成工具提供了一些测试您的工作的方法（尽管很少使用，但这是另一回事了）。 问题在于它们是专有的，有时不是免费的，并且是受限制的解决方案，它们依赖于预先构建的运算符来提供数据和架构验证，并且根据选择的工具可能会有很大不同。

　　使用诸如Scala或Java之类的高级语言执行Intead，执行单元和集成测试时，将一如既往地基于相同的实践和规则，并且各个框架之间的差异可能很小，其优势在于为您提供了无与伦比的健壮性和覆盖范围。

　　管理代码的可怕影响

　　尽管开发人员和数据工程师退出了这一新趋势（自从以Hadoop为中心的解决方案开始应用于较新的基于云和无服务器的数据平台以来），但许多公司并没有意识到新技术的数量以及对新的大数据生态系统进行编码的过程 带入并开始遭受（至少三个）常见问题的困扰：

　　· BI团队内部缺乏技术知识；

　　· 就业市场上缺乏熟练的数据工程师；

　　· 大量的SQL忍者很快就无法为新的大数据项目编写ETL / ELT管道。

　　另外，由于许多大数据技术专注于提供"快速" SQL引擎来查询和管理存储在HDFS，文件系统和云Blob存储上的数据，因此许多公司开始采用Hive，Drill，Impala等工具，不仅用于数据探索和 分析，但将其作为新的ETL / ELT管道的核心。

　　这种体系结构的选择主要是由那些不具备（也不想雇用）具有正确技能来处理这些技术的数据工程师的公司认可的，或者他们更喜欢依靠老式的而不是培训其现有的雇员， SQL专家，用于构建和管理其全新的数据湖。

　　不幸的是，当我担任顾问时，我见过不止一家公司使用诸如Apache Hive之类的工具来实现复杂的ETL / ELT管道，该工具将SQL查询嵌入到数据集成工具中，该工具提供带有分块箭头和"大数据连接器"的经典GUI。 在这种情况下，即使是稳固而严格的数据模型也不能阻止他们拥有未经测试且无法维护的系统，在此系统中，每项更改都是痛苦的发展，并且可以保证在某处（可能在生产中）破坏某些内容。

　　这些没有编码技能的GUI和SQL的趋势是一种弊大于利的趋势。

　　我只是介绍了批处理数据的用例，但是由于需要实施流传输解决方案，我觉得这些工具还不够成熟，无法解决数据处理的最新挑战。

　　TL; DR：大数据处理是否已结束SQL时代？

　　明显不是。 即使在大数据生态系统中，SQL也是一种强大的数据分析和探索工具，如果您的ETL / ELT作业在读取数据时使用下推式针对基于SQL的引擎执行简单查询就可以了。 此外，还没有一种万能的解决方案：如果您要做的就是（非常）简单的ETL和数据集成，也许您仍然可以依靠某些在您选择的引擎上执行虚拟SQL查询的块。

　　但是，在进行复杂的数据转换和处理时，最好使用内存和分布式处理引擎（例如Spark，Beam等）。在坚如磐石的开发中以高级编程语言编写业务逻辑 由编写良好代码的最佳实践支持的生态系统。

　　结果将是公司和工程师都将从中受益的强大，可扩展和可维护的技术堆栈。

　　没有正确的技术技能不应成为未使用正确工具的原因。