帮助数据科学家更好地理解架构图
> Photo by Jared Murray on Unsplash
介绍
在使用数据获取业务价值的公司中，尽管您可能不会一直以数据科学技能为荣，但始终可以很好地管理数据基础架构。 每个人都希望将数据存储在可访问的位置，妥善清理并定期更新。
在这些低调但稳定的需求的支持下，数据架构师的薪水与数据科学家的薪资同样高，甚至更高。 实际上，根据PayScale进行的薪酬研究（https://www.payscale.com/research/US/Country=United_States/Salary），美国数据架构师的平均工资为121,816美元，而数据科学家的平均工资为96,089美元 。
并不是说所有数据科学家都应该换工作，至少了解数据架构的基础知识对我们会有很多好处。 实际上，有一个简单（但有意义）的框架可以帮助您了解各种现实世界的数据体系结构。
目录
· 数据架构中的三个组件：Data Lake-> Data Warehouse-> Data Mart
· 每个组件中使用的工具
· 案例研究—构建从BigQuery（数据仓库）到Google Sheets（数据集市）的计划和自动数据馈送
· 尾注
数据架构中的三个组件：Data Lake-> Data Warehouse-> Data Mart
"数据湖"，"数据仓库"和"数据集市"是数据平台体系结构中的典型组件。 按照此顺序，将处理业务中产生的数据并将其设置为创建另一个数据含义。
> Diagram the author crafted using materials from Irasuto-ya (https://www.irasutoya.com/)
三个组件负责三种不同的功能，例如：
· Data Lake：拥有业务中产生的数据的原始副本。 如果有的话，原始数据的处理应该最少。 否则，如果最终发现某些数据处理错误，将无法追溯修复该错误。
· 数据仓库：保存由托管数据模型处理和结构化的数据，反映最终使用数据的全局（非特定）方向。 在许多情况下，数据采用表格格式。
· 数据集市：保存一个子部分和/或汇总的数据集，以使用特定的业务功能，例如 特定业务部门或特定地理区域。 一个典型的例子是，当我们准备针对特定业务线的KPI摘要时，然后在BI工具中进行可视化。 特别是，当用户希望定期并频繁地更新数据集市时，在仓库之后准备这种独立的组件是值得的。 相反，如果用户只希望某些数据组进行一次即席分析，则可以跳过此部分。
> Summary of three data architecture components (exhibit created by author)
有关除仅裸机描述之外的更多实际示例，请使用Google搜索"数据架构"以查找大量数据架构图。
> What you see when you image-google with "data architecture". (Image captured by author)
为什么我们需要分为这三个部分？
因为过程中的不同阶段有不同的要求。
在数据湖阶段，我们希望数据接近原始数据，而数据仓库的目的是通过清晰的维护计划使数据集更结构化，可管理并拥有明确的所有权。 在数据仓库中，我们还希望数据库类型面向分析而不是面向事务。 另一方面，数据集市应该可以方便地访问可能使用数据旅程最终输出的非技术人员。
不同用途的系统组件往往在不同的时间进行重新设计。 然后，配置松散连接的组件在将来的维护和扩大规模方面具有优势。
数据工程师和数据科学家如何处理这三个组成部分？
粗略地说，数据工程师涵盖了从业务中提取的数据到数据湖，在数据仓库中建立数据模型以及建立ETL管道的过程。 而数据科学家则负责从数据仓库中提取数据，构建数据集市，并导致进一步的业务应用和价值创造。
当然，数据工程师和数据科学家之间的这种角色分配有些理想，并且许多公司都不只是为了符合这个定义而聘用这两个人。 实际上，他们的职务描述往往会重叠。
三要素法之外的新趋势
最后但并非最不重要的一点是，值得注意的是，这种由三部分组成的方法是存在超过二十年的传统方法，并且新技术一直在不断出现。 例如，"数据虚拟化"是一种允许针对数据源的一站式数据管理和操作界面的想法，而不管其格式和物理位置如何。
每个组件中使用的工具
现在，我们了解了三个数据平台组件的概念。 然后，人们使用什么工具？ 根据此"数据平台指南"（日语），这里有一些想法：
数据湖/仓库
数据湖和数据仓库有以下选项。
> Author crafted based on the "Data Platform Guide" (in Japanese)
ETL工具
ETL发生在数据到达数据湖并进行处理以适合数据仓库的地方。 数据是实时到达的，因此ETL更喜欢事件驱动的消息传递工具。
> Author crafted based on the "Data Platform Guide" (in Japanese)
工作流程引擎
工作流引擎用于管理数据的整体流水线化，例如，通过流程图可视化流程在何处进行，在出现错误的情况下触发自动重试等。
> Author crafted based on the "Data Platform Guide" (in Japanese)
数据集市/ BI工具
以下工具可用作数据集市和/或BI解决方案。选择将取决于业务背景，贵公司熟悉哪些工具（例如，您是Tableau人员还是Power BI人员？），聚合数据的大小（例如，如果数据大小很小，为什么基本不解决方案，例如Excel或Google Sheets等解决方案是否达到了目标？），您使用什么数据仓库解决方案（例如，如果您的数据仓库位于BigQuery上，则Google DataStudio是一个简单的解决方案，因为它在Google圈子中具有自然的联系），等等。
> Author crafted based on the "Data Platform Guide" (in Japanese)
案例研究—构建从BigQuery（数据仓库）到Google Sheets（数据集市）的计划和自动数据馈送
当数据大小保持在数十兆字节左右或小于数十兆字节并且不依赖于其他大型数据集时，可以坚持使用基于电子表格的工具来存储，处理和可视化数据，因为它的成本更低，而且每个人 可以使用它。
一旦数据变大并开始与其他数据表具有数据依存关系，从云存储作为一站式数据仓库开始是有益的。 （当数据变得更大到数十兆字节时，使用本地解决方案可以提高成本效益和可管理性。）
在本章中，我将演示一种将数据作为数据仓库存储在Google BigQuery中的情况。 BigQuery数据可以实时或短时间处理和存储。 最终用户仍然希望在高度汇总的基础上在电子表格中查看每日KPI。 这意味着数据集市可能很小，甚至适合电子表格解决方案。 让我们在这里使用Google表格，而不是Excel，因为它可以与BigQuery中的数据源处于同一环境中。 哦，顺便说一句，不要考虑每天手动运行查询。 尝试找到一种解决方案，使所有内容自动运行，而无需您采取任何措施。
> Data pipeline in case study (diagram created by author using materials from Irasuto-ya (https://ww
本案例研究中使用的数据
在本案例研究中，我将使用一个样本表数据，该数据具有每次乘车纽约出租车乘客的记录，包括以下数据字段：
· 车号
· 驱动程序ID
· 乘车日期
· 乘客人数
· 车费金额
· 等等
样本数据作为数据仓库存储在BigQuery中。
Google表格可以从BigQuery表中提取数据吗？
从技术上讲是可以的，但是目前只能通过Connected Sheets使用，并且您需要一个G Suite Enterprise，Enterprise for Education或G Suite Enterprise Essentials帐户。
> Diagram created by author.
Connected Sheets允许用户操作BigQuery表数据，就像在电子表格上播放它们一样。 请参阅本页面" BenCollins"博客文章上的GIF演示。
> Example of the use of Google Sheets connected to BigQuery through Connected Sheets (Captured by au
连接工作表还允许自动调度和刷新工作表，这是数据集市的自然需求。
尽管它证明自己是一个不错的选择，但一个可能的问题是，欠缺G Suite帐户并不常见。
有关设置的更多详细信息，请参阅" BenCollins"中的此博客文章。
我们该怎么做才能将数据从BigQuery推送到Google表格？
要从BigQuery提取数据并将其推送到Google表格，仅靠BigQuery是不够的，我们需要服务器功能的帮助来调用API以将查询发布到BigQuery，接收数据并将其传递给Google表格。
> Diagram created by author.
服务器功能可以位于GCP外部或内部的服务器计算机上（例如，GCP上的" Compute Engine"实例；或AWS上的" EC2"实例）。 可以使用unix-cron作业计划代码运行。 但是这里的一个缺点是，它花费了实例的维护工作和成本，并且对于一个小的程序而言，太多了。
" Google Cloud Functions"是所谓的"无服务器"解决方案，用于在不启动服务器计算机的情况下运行代码。 将代码放入Cloud Functions并设置触发事件（例如，在本案例研究中为预定时间，但也可以是某些互联网用户的HTML请求），GCP会自动管理代码的运行。
我的案例研究中的设置
使用纽约出租车数据配置我的案例研究有两个步骤。
步骤1：设置计划-设置Cloud Scheduler和Pub / Sub以触发Cloud Function。
在这里，"发布/订阅"是一项消息服务，将由Cloud Functions订阅，并在每天的特定时间触发其运行。 " Cloud Scheduler"是一种功能，它可以根据unix-cron格式以用户定义的频率启动某些程序。 结合这两者，我们可以创建常规消息以供Cloud Function订阅。 有关如何执行的信息，请参见此官方说明。 这是我的GCP设置中的屏幕截图。
> Set up in Cloud Scheduler (Captured by author)
> Set up in Pub/Sub (Captured by author)
第2步：设置代码-在Cloud Functions上准备代码以查询BigQuery表并将其推送到Google表格。
下一步是设置云功能。 在Cloud Functions中，您定义1）触发器是什么（在本案例研究中，是从Pub / Sub发送的" cron-topic"，链接到Cloud Scheduler，该触发器每隔早上6点拉动触发器），并且2）代码是 要在检测到触发器时运行。
有关更多详细信息，请参见此官方说明，以下是我设置的屏幕截图。
> Set up in Cloud Functions (Captured by author)
> Code input in Cloud Functions — here you can also set requirements.txt to use installable librari
要运行的代码必须包含在一个您喜欢的函数中（在我的情况下为" nytaxi_pubsub"。）代码内容包括两部分：第一部分：在BigQuery上运行查询以将原始BigQuery表简化为KPI并保存 它作为BigQuery中的另一个数据表，并使其成为Pandas数据框架，第2部分将数据框架推入Sheets。
这是我实际使用的代码。 重要的是，只要BigQuery与Cloud Function位于同一GCP项目中，它就会自动进行身份验证（请参阅此页面以获取说明。）但是，对于Google表格而言，情况并非如此，它至少需要一个过程来共享 服务帐户访问目标表。 有关更多详细信息，请参见gspread库中的描述。
Google表格上的最终数据集市
最后，我在Google表格中获得了汇总数据，如下所示：
> Automatically updated data mart after a long journey of the setup. (captured by author)
该表每天早晨自动更新，并且数据仓库正在通过ETL从数据湖接收新数据时，我们可以每天第一天轻松地跟踪NY出租车KPI。
尾注
在一家雇用数据工程师和/或数据架构师以及数据科学家的大公司中，数据科学家的主要作用不一定是准备数据基础架构并将其部署到位，但是至少了解数据架构要点将是有益的 很了解我们在日常工作中的立场。
Data Lake-> Data Warehouse-> Data Mart是一个典型的平台框架，用于处理从源到用例的数据。 将过程分为三个系统组件对于维护和目标性有很多好处。
工具的选择有很多选择。 应根据数据环境（大小，类型等）和业务目标明智地选择它们。