原文： Data Scientist versus Data Architect
https://www.datasciencecentral.com/profiles/blogs/data-scientist-versus-data-architect
我最近与不同社区的一些数据架构师进行了以下讨论，特别是（但不限于）LinkedIn上的TDWI小组。这是讨论的总结，展示了数据科学家和数据架构师之间的差异，以及两者如何协同工作。
它显示了在新的分析革命完成之前仍然需要解决的一些挑战。以下是数据架构师和数据库管理员提出的问题以及我的答案。讨论的内容是优化SQL查询中的连接，或者完全脱离SQL。现在几个现代数据库提供了许多这里讨论的功能，包括哈希表连接和最终用户对查询优化器的微调。数据科学家，数据架构师和业务分析师之间的讨论。它也涉及许多创新概念。
问题：你说SQL的瓶颈之一是用户用三个连接写（例如）三个连接查询，当这些查询可以分成两个查询，每个连接有两个连接。你能详细说明吗？
Python，并将我需要读取的所有内容存储为内存中的哈希表。所以我必须做一个连接，当我这样做时，它最多只有两个表。
在一些（罕见的）查找表太大而不适合内存的情况下，我使用了抽样方法并使用了子集和聚合规则。一个典型的例子是数据集（网络日志文件）中的一个字段是用户代理（浏览器，缩写为UA）。你拥有比内存更多的独特UA，但只要你保持最受欢迎的1000万，并将200,000,000个稀有UA集成到100万个类别（基于UA字符串），你将在大多数应用中获得良好的结果。
作为算法专家（不是SQL专家），需要几分钟的时间才能通过Python中的哈希表（使用我自己的脚本模板）进行高效的四表连接。我所做的大部分工作是高级分析，而不是数据库聚合：高级算法，但Python中的简单代码，搜索作为隐藏的决策树。无论如何，我的观点更多的是关于非专业SQL用户搜索业务分析师：是否更容易或更有效地培训您更好的SQL代码，包括复杂的联接，还是培训他们学习Python并将其与SQL代码混合？
为了更具体一些，我想到的是一个系统，你不得不经常下载查找表（可能每周一次）并更频繁地访问主（事实）表。如果您必须经常重新上传查找表，那么Python方法会失去效率，并且由于频繁下载，您会使同事不高兴。
问题：像您这样的人（运行Python或Perl脚本访问数据库）是DBA最糟糕的噩梦。你不觉得你是DBA问题的来源吗？
Python或Perl代码无缺陷，易于阅读，易于维护，优化，强大且可重用。如果我用SQL编码所有内容，效率会低得多。我所做的大部分是算法和分析（机器学习的东西），而不是查询数据库。我只是偶尔在我的本地机器上下载查找表（作为散列表并存储为文本文件）。当我需要更新你时，我只是提取自我上次更新（基于时间戳）以来添加的新行。在运行密集的SQL脚本之前，我会做一些测试，以了解它消耗了多少时间和资源，并查看我是否可以做得更好。我是一名SQL用户，就像任何分析师或业务分析员一样，而不是SQL开发人员。
但我同意我们需要找到一种方法来最大限度地减少数据传输和流程，可能有更好的分析工具。 Python代码存在于非生产表和系统中，并分配相当数量的磁盘空间（可能为200 GB）和内存（至少几GB）。
问题：你的编码偏好是什么？
回答：有些人觉得使用脚本语言比使用SQL更舒服。 SQL可能被认为不太灵活，容易出错，由于连接中的错误，没有人注意到会产生错误的输出。
你可以编写简单的Perl代码，这很容易阅读和维护。 Perl使您能够专注于算法而不是代码和语法。不幸的是，许多Perl程序员都编写了模糊的代码，这为Perl创造了声誉（代码维护和可移植性）。但事实并非如此。
您可以使用多个SQL语句和视图将复杂的联接分解为多个较小的联接。你会假设数据库引擎会消化你不那么高效的SQL代码并将其转化为更多东西
