数据

第 3 章快速介绍了如何定义 FastAPI Web 端点、向它们传递简单字符串输入，并获得响应。本章会进一步进入 FastAPI 应用程序的顶层——也可以称为接口层或路由层——以及它与 Servic

预览 上一章简要介绍了开发者在编写一个新的 FastAPI 应用程序时最先会遇到的内容。本章重点介绍 FastAPI 底层的 Starlette 库，尤其是它对异步处理的支持。在概览 Python 中

预览 Python 一直在演进，以跟上不断变化的技术世界。本章会讨论一些适用于上一章所提问题的 Python 特性，以及少量额外内容： 工具 API 和服务 变量和类型提示 数据结构 Web 框架 工

做数据平台的人，大概率都遇到过一个很尴尬的问题： 运营看实时大屏，今天订单数是 10,238。 财务看离线日报，今天订单数是 10,191。 老板问：“到底哪个是真的？” 然后数据团队开始解释： “实

很多人聊 IoT 实时链路，一上来就问： “用 Kafka 还是 Pulsar？” “Flink 窗口怎么写？” “时序库选 IoTDB、InfluxDB 还是 ClickHouse？” “要不要上湖

很多团队做数据平台，前期都很兴奋：数据接进来了，指标跑起来了，BI 看板也上线了，业务方开始天天要数据。 然后问题来了： “这个表谁能看？” “手机号能不能给运营？” “研发查生产数据要不要审批？”

过去几年，大家聊湖仓，经常会先问一个问题： 这个问题看起来像技术选型，实际上是架构选择。 因为 Iceberg、Hudi、Delta 不是简单的“存储格式”，它们本质上是在对象存储、HDFS 或云存储

很多公司做数据平台，前几年最关心的是“数仓怎么分层”“实时数仓怎么建”“湖仓怎么选型”“指标平台怎么做”。 但到了后面，真正卡住平台规模化的，往往不是某个计算引擎，也不是某张宽表，而是一个更基础的问题

在数据工程里，ETL 和 ELT 是两个很容易被讲“浅”的概念。 很多文章会这么解释： 这句话没错，但基本等于没说。 真正做过数据平台的人都知道，ETL 和 ELT 的差异不只是流程顺序，而是背后一整

正如你在本书中已经学到的，dbt 是一个非常出色的工具，可以用来构建、维护和扩展你的 data transformation processes。我们已经覆盖了 dbt 的许多方面，包括使用 seed

Documentation 是任何 data project 中的关键组成部分，它为理解和有效使用数据提供必要 context 和 insights。然而，它经常没有得到应有的优先级。编写 docum

想象一下，你投入了数周甚至数月时间在一个复杂的数据项目上，把大量时间和精力倾注到构建一个 robust solution 中，结果它刚部署到 production 不久就崩塌了。当你发现自己曾经非常确

SQL 对于将 raw data 转换为下游消费者可使用的有价值 models 非常有用，但你一定会遇到一些时候，需要运行 dbt out of the box 并不支持的 ad hoc SQL。例如

到目前为止，本书已经覆盖了 models 和 snapshots 等主题，这些主题主要使用相对直接的 SQL transformations。不过，你是否曾经发现自己在写重复的 SQL code，并希

在你处理数据的过程中，很可能遇到过某种 dataset：它会变化，但历史并没有被保留下来。这可能会变成一场噩梦，因为 data professionals 经常需要查询某个 point in time

在并不遥远的过去，大多数 data teams 完全依赖围绕 drag-and-drop graphical user interfaces（GUIs）或 stored procedures 构建的数

在本章中，我们将探索 dbt 中 sources 和 seeds 的概念。这两项内容大体上彼此独立，但由于它们主题相对较小、却非常重要，所以我们将它们合并到同一章。Sources 指原始数据源，例如来

与任何新的技术项目一样，必须花时间进行 setup 和 configuration，建立一个坚实基础，使项目 contributors 能够成功开展工作。dbt 在这一点上也不例外，而且成功搭建一个新

2006 年，英国数学家、数据科学领域企业家 Clive Humby 提出了 “Data is the new oil” 这句话，意思是“数据是新的石油”，因为数据拥有极高的价值。虽然数据和石油在原始

欢迎来到本书关于使用 dbt 和 SQL 进行 analytics engineering 的最后一章。在前面的章节中，我们已经覆盖了多个概念、技术和最佳实践，用于通过 analytics engin