面向开发者的数据工具生态指南

# 面向开发者的数据工具全景指南 · OlegWock 来源：https://sinja.io/blog/data-landscape-guide-for-developers 如果你不小心加入了数据项目，却完全听不懂他们在说什么？在办公室茶水间谈论时感觉自己被排除在外？要是有一份详尽的大指南，覆盖所有概念和流行词汇就好了…… 不久前，我以软件工程师的身份加入了 **Deepnote** (https://deepnote.com/?ref=sinja.io) 。Deepnote 为数据团队打造了一款云笔记本。然而，我本人并没有数据背景。我知道笔记本是什么，觉得做这类项目会很有趣。我原以为数据领域与软件工程差别不大，一直将它们视为相邻领域。 加入后没多久，我就发现自己对数据领域一无所知！除了笔记本，还有那么多数据工具，我完全不知道它们用来做什么，也不清楚数据科学的一般工作流程。如果我不了解各种数据工具的通常用法，以及它们如何与笔记本交互，那么我也就无法提出好的笔记本功能，或发现 UI 流程中的问题。 但通过阅读大量文章、向同事和网上的陌生人提问、研究客户的工作流程和痛点，以及给自己一些时间来内化这些新知识，情况确实好转了。不幸的是，并没有一份方便的“面向软件工程师的数据工具指南——当你身处一家数据公司，却完全不懂那些术语是什么意思”，或者只是我没找到。 我现在不再做笔记本了，但数据让我着了迷，所以我的下一份工作仍然在这个领域。这次我参与开发的是一个面向分析型专家的**工具** (https://www.metabase.com/?ref=sinja.io) ，而非面向科学型专家（参见下一章的解释！），但关于数据工具和流程的通用知识仍然非常有用！所以我试着将其浓缩成一篇易于阅读的文章，希望能帮助那些迷茫的软件工程师们感觉更自在一些。 ## 本文适合谁看 (https://sinja.io/blog/data-landscape-guide-for-developers#who-is-this-article-for) 你可能猜到了，我本人并非有意成为专业的数据从业者。因此，本文不会涉及例如如何在 Metabase 创建仪表盘、统计学基础或如何管理 Spark 集群等内容。它面向的是那些出于某种原因需要搞明白数据团队同事在说什么的开发者。 在本文中，我们将简要介绍数据生命周期：数据从何处来、如何处理、如何存储以及如何展示。你将了解每个工具属于哪个阶段，以及它为数据工作者解决了哪些任务。 我们不会讨论每个工具的具体配置，也不会对同类工具进行深入比较。相信我，即使不涉及那些细节，这篇文章也会相当冗长。 ## 数据职业的几种类型 (https://sinja.io/blog/data-landscape-guide-for-developers#flavors-of-data-professions) 在数据世界中，有相当多的不同职位，而且往往并不清楚一个职位与另一个职位之间到底有何不同。这里的界限很模糊，尤其是在小型公司或团队中。不过，就本文而言，你只需要了解大致有四类数据职业。 ### 分析型 (https://sinja.io/blog/data-landscape-guide-for-developers#analytical-type) 这类人负责解读数据、从中提取洞见并呈现出来。通常是 **数据分析师** 或 **BI 分析师** 职位。他们通常精通 SQL 和电子表格。他们使用 Tableau 等商业智能 (BI) 工具以及 Excel 等电子表格软件。 这类职位的日常任务示例：用 SQL 抽取客户数据，按地区计算流失率；然后构建一个显示流失趋势的 Tableau 仪表盘，并向市场部门展示发现，同时给出留存活动的建议。 ### 科学型 (https://sinja.io/blog/data-landscape-guide-for-developers#scientific-type) 这类人比表面报告挖掘得更深。他们应用统计学、构建模型、运行实验，以回答不那么显而易见的问题或进行预测。通常是 **数据科学家** 职位。他们通常精通 Python 及其科学计算栈（pandas、scikit-learn 等），经常在笔记本中工作。 这类职位的日常任务示例：拿同样的客户数据，探索哪些因素与流失相关，构建一个统计模型来估计每个客户离开的可能性；然后为留存活动设计 A/B 测试，并分析该测试是否真正产生了影响。 ### 工程型 (https://sinja.io/blog/data-landscape-guide-for-developers#engineering-type) 这类人关心数据的基础设施。他们的首要任务是让数据首先变得可分析：构建和维护从各种来源抽取数据、清洗并标准化、然后加载到数仓或数据湖中的管道，以便分析型和科学型人员能够实际开展工作。他们还经常负责维护数据库和管理组织中可能使用的其他数据工具。这个职位通常叫做 **数据工程师**。 他们工作的另一方面是扩展。科学型和分析型产生的某些工作需要被规模化。例如，分析师的一个简单分析可能被转化为一个反向 ETL 管道（别担心，我们稍后会解释这些术语），需要可靠且可重复地运行。 他们经常使用 Python，并与 Apache Spark、各种数据库和数据仓库等工具打交道，并使用云提供商来托管这些工具。 这类职位的日常任务示例：维护从多个来源摄取客户交易数据的管道，标准化模式，加载到数仓中；然后优化查询，使分析师能够高效地抽取客户数据，并添加数据质量检查以标记缺失的客户记录。 ### 机器学习型 (https://sinja.io/blog/data-landscape-guide-for-developers#machine-learning-type) 这类专家专注于构建和维护可用于解决不同问题的 AI 模型。可能是一个较小的分类模型，例如帮助**检测网站上的机器人流量** (https://sinja.io/blog/bot-or-not) ，但也可能是一个由公司训练或微调的更通用的大语言模型。 从总体描述来看，这类人似乎与前几类有重叠（他们也分析数据并构建管道），但据我所知，他们常常使用一套截然不同的工具，这使他们与上述类型区分开来。 这里我将多种类型的专家归为一组（ML 有自己的科学家和工程师），因为我们不会在本文中涉及与 ML 相关的主题（毕竟它与我的直接相关性不大，所以我对这部分了解有限）。但它仍然是数据领域的一部分，所以我不想完全忽略它们。 这类职位的示例：为在线商店构建一个产品推荐模型：从数仓中组装训练数据，训练并调整模型，然后将其部署到 API 后端，使网站能够实时请求个性化推荐。部署后，他们将继续监控模型的预测，并定期重新训练模型，以便在客户行为随时间变化时保持良好性能。 ## 数据生命周期 (https://sinja.io/blog/data-landscape-guide-for-developers#data-lifecycle) 数据领域围绕着数据展开（这里没什么意外）。数据有大有小，有丑有美。这一切都始于从某处获取数据，以某种方式处理，然后将结果放到某处。就是这样，谢谢来听我的 TED 演讲。 当然这是开玩笑，但它确实描述了 **ETL**。ETL 代表 Extract（抽取）-Transform（转换）-Load（加载），描述了一个常见的数据处理过程：原始数据从源系统中**抽取**，**转换**（例如清洗、与其他数据连接），结果被**加载**到最终目的地以供进一步使用。 虽然这是一种非常常见的方法，但它并非一成不变。步骤可以改变顺序、重复或重叠。例如，另一种（且相当流行的）方法是 **ELT**。通过 ELT，你抽取数据，直接将其放入数据仓库，然后在仓库内部进行转换（结果存储在不同的表中）。这会增加你的账单（因为额外的存储和计算），但你会保留原始数据，这样如果以后有需要，你可以用不同的方式处理它。 ## 数据如何存储 (https://sinja.io/blog/data-landscape-guide-for-developers#how-data-is-stored) 在我们深入 ETL 各个步骤的细节之前，先了解一下数据存储在哪里以及如何存储会很有帮助。 ### 文件格式 (https://sinja.io/blog/data-landscape-guide-for-developers#file-formats) 大量数据存在于文件中——从会计团队获得的 Excel 文件，或供应商网站上上传的巨大的 JSON 库存文件。 在文件格式方面，你经常会看到 **CSV 文件** (https://en.wikipedia.org/wiki/Comma-separated_values?ref=sinja.io) （或其他表格格式如 Excel）和 **Apache Parquet** (https://en.wikipedia.org/wiki/Apache_Parquet?ref=sinja.io) 。 CSV 便于传输少量数据，几乎任何办公软件都可以打开，并且对技术能力较弱的用户友好。这是销售团队让你分析本季度交易时，你很可能会得到的格式。 Parquet 更常被技术用户使用。它是一种**列式格式**——数据按列而非按行排列——这可以实现出色的压缩，并能有效传输和/或存储更大量的数据。大多数数据工具都能读取和生成该格式，使其成为数据工具领域的通用语言。另一个解决类似问题的格式是 **Apache ORC** (https://en.wikipedia.org/wiki/Apache_ORC?ref=sinja.io) 。你可能还会遇到 **Apache Avro** (https://avro.apache.org/?ref=sinja.io) ——也是一种二进制格式，但面向行，用于传递记录，尤其是在流处理中。是的，数据世界中的很多东西都来自 Apache 基金会。 ### 内存格式 (https://sinja.io/blog/data-landscape-guide-for-developers#memory-formats) 数据可以以不同格式存储。我们已经介绍了文件格式，但数据也可以存储在内存中。最流行的内存格式是 **Apache Arrow** (https://en.wikipedia.org/wiki/Apache_Arrow?ref=sinja.io) 。 Parquet 是一种针对（除其他外）压缩和小文件大小（有助于存储和传输）而优化的文件格式，而 Arrow 则是一种针对处理和零拷贝传输而优化的内存格式。这意味着以 Arrow 格式存储的数据占用更多空间，但可以在工具之间（例如从 Python 的 pandas 到 Rust 的 DataFusion）非常高效地传输。 两种格式都针对分析负载进行了优化，但 Parquet 更侧重于扫描（即加载相关条目到内存），而 Arrow 则侧重于实际处理（例如有效利用 CPU/GPU 指令和缓存来执行计算）。 Arrow 被广泛采用，是事实上的标准内存格式。虽然你不太可能直接从来源获取 Arrow 格式的数据，但它用于在已经加载的数据在不同数据工具之间交换。流行的 DataFrame 库如 pandas 可以将其作为可选的底层引擎，也有一些从一开始就基于 Arrow 构建的项目（例如 Polars、DataFusion）。我们将在后续章节更详细地介绍 DataFrame。 ### 数据仓库 (https://sinja.io/blog/data-landscape-guide-for-developers#data-warehouse) 在分析数据时，你经常要处理来自不同来源的大量数据。每次想要分析时都从源头提取数据效率不高，并且很可能对源系统造成不必要的压力。为此，数据通常会在处理之前被摄取到某种集中式存储中。有不同类型的存储，每种都针对不同的用例进行了优化。 **数据仓库** 类似于 PostgreSQL 或 MySQL 等数据库，但针对分析负载进行了优化。MySQL 是一个 **OLTP** (https://en.wikipedia.org/wiki/Online_transaction_processing?ref=sinja.io) 数据库，针对行操作进行了优化。例如，OLTP 数据库的典型查询是通过 id 从数据库中获取用户记录（行）。而数据仓库则是 **OLAP** (https://en.wikipedia.org/wiki/Online_analytical_processing?ref=sinja.io) 数据库，针对列操作进行了优化。这意味着像“计算各地区上一年度`orders`表中的总销售额”这样的查询，在数据仓库中的运行速度会比在传统数据库中快得多 1 (https://sinja.io/blog/data-landscape-guide-for-developers#footnote-1) 。 由于数据仓库针对结构化、清洗过的数据进行了优化，它传统上被用作处理后数据的最终存储，而不是摄取后的第一站。不过，随着 ELT 方法的兴起，现在也很常见将数据仓库同时作为原始数据的着陆区，并在其中直接进行转换。 数据仓库既管理数据在磁盘上的存储方式，也管理数据的查询方式。它提供自己的查询引擎，并与之紧密耦合。如果你主要用过 MySQL 和 Mongo 这类数据库，这听起来可能有点奇怪，但你会很快了解到，对于其他类型的数据存储来说，情况并非总是如此。 处理结构化数据和优化的查询引擎使得它们能够提供出色的查询速度。这对于各种 BI 和报表工具来说效果很好，因为慢查询会带来不佳的用户体验。 在我们将要介绍的三种存储类型中，数据仓库是最昂贵的，因为你要同时为性能和便利性付费。流行的数据仓库有 **Snowflake** (https://www.snowflake.com/en/?ref=sinja.io) （仓库只是其平台的一部分，但据我所知，他们不将其作为独立产品提供）、Google 的 **BigQuery** (https://cloud.google.com/bigquery?ref=sinja.io) 以及 Amazon 的 **Redshift** (https://aws.amazon.com/redshift/?ref=sinja.io) 。流行的开源/自托管选项有 **ClickHouse** (https://clickhouse.com/?ref=sinja.io) 、 **Apache Doris** (https://doris.apache.org/?ref=sinja.io) 和 **StarRocks** (https://www.starrocks.io/?ref=sinja.io) 。 ### 数据湖 (https://sinja.io/blog/data-landscape-guide-for-developers#data-lake) 与结构化的数据仓库相对的是 **数据湖** 。你可以将所有 CSV、Parquet、JSON 等文件以最少（或零）处理的方式倾倒在那里。简单来说，数据湖就是一个带了一些额外功能的大云文件夹。正因如此，它不对数据结构施加限制：你可以存储结构化（Parquet）、非结构化（电子邮件）、半结构化（CSV）甚至纯粹的二进制（图像）数据。 要构建数据湖，从便宜的存储系统开始，例如 **Amazon S3** (https://aws.amazon.com/s3/?ref=sinja.io) 、 **Google Cloud Storage** (https://cloud.google.com/storage?ref=sinja.io) 或 **Azure Blob Storage** (https://azure.microsoft.com/en-us/products/storage/blobs?ref=sinja.io) 。制定命名和分区约定，丢一些 Parquet 文件进去，设置访问策略。