从一个学习项目的目标开始，理解 AI 时代为什么仍然需要数据基础
上一篇我们讨论了一个问题：AI 让代码越来越容易生成，为什么反而更需要 Kestra？
AI 可以帮助我们更快地写出脚本、接口和分析程序，但它不会自动解决数据从哪里来、数据是否可信、不同报表口径是否一致这些问题。
AI 应用越多，数据基础的重要性越明显。无论是 BI 分析、智能问答，还是后续的 AI 应用，最终都需要依赖稳定、清晰、可追溯的数据。
但数据仓库本身又很重：分层、建模、调度、质量、权限、监控和备份，每一项都可以展开成一个复杂系统。
所以这个系列不打算一开始就搭建企业级平台，而是从一个小型学习项目开始，理解数据链路和任务编排的核心方法。
准备搭建一个什么样的学习项目
为了把这些问题具体化，我准备搭建一个本地可运行的数据仓库学习项目。
项目不会一开始就接入真实业务系统，而是使用模拟的销售数据。数据源主要包括：
每日文件会按照业务月份组织，让文件本身具备清晰的时间边界：
data/raw/daily/YYYYMM/ sales_YYYY-MM-DD.csv
这样做是为了给后续的数据处理提供明确的范围。
后续如果需要重新处理某一个月份，就可以先确定这个月份对应哪些源文件，而不是每次都扫描全部历史数据。具体目录、脚本和执行方式，会在后续实战中逐步搭建。
这个项目希望最终形成什么结果
这个学习项目的目标不是展示一个复杂系统，而是逐步形成一条小而完整的数据链路：
每日销售文件 + 主数据 ↓ 原始数据保存 ↓ 清洗和业务校验 ↙ ↘ 有效明细 异常记录 ↓ 月度汇总 ↓ 结果验证
这条链路的目标很简单：原始数据可追溯，有效数据和异常数据分开，明细和汇总分层保存，并且支持重复运行和按范围重算。
后续项目会逐步引入 ODS、DWD、audit 和 ADS 这些概念，但先理解每一层解决什么问题，再学习正式名称。
数据仓库为什么会在这里出现
数据仓库并不是突然出现的概念。当我们要求原始数据可保留、清洗结果可区分、异常记录可追踪、明细和汇总分开时，实际上已经开始进行数据分层和建模。
在 AI 时代，数据仓库的价值也不只是把数据放进数据库，而是让数据从来源到结果的过程更加清楚：
来源是什么？经过了哪些规则？哪些数据被保留？哪些数据被拒绝？最终结果如何生成？
并不是所有 AI 项目都必须使用大型数据仓库。这里更重要的是学习其中的核心方法：数据分层、来源追踪、质量检查、口径管理和可重复处理。
Kestra 将来要编排什么
当这条链路逐步实现以后，它会包含多个有依赖关系的步骤：
检查输入参数 ↓确认文件和数据库环境 ↓加载原始数据 ↓清洗并构建明细 ↓生成汇总结果 ↓执行数据质量检查
这正是 Kestra 适合发挥作用的地方。 Python 负责读取、清洗、转换和聚合；SQL 负责数据库处理；Kestra 负责：
后续文章会按照数据准备、数据库分层、脚本化处理和 Kestra 编排的顺序，一步一步把它们搭建出来。
为什么不一开始就搭一套很重的数仓
数据仓库之所以容易变重，不只是因为表多，还因为真实业务会同时面对历史数据、权限、治理、调度、质量、备份和多环境部署。
如果一开始就加入这些内容，读者还没有理解一条 CSV 如何进入数据库，就会被复杂配置分散注意力。
所以这个项目会先控制范围：
- 先使用 Python、Polars 和 PostgreSQL；
- 再逐步学习 Kestra 的参数、任务、日志和重跑能力。
后续如果遇到数据量、运行环境或运维要求带来的问题，再讨论 Docker、Linux、多环境、告警和更复杂的部署方式。
先理解数据基础和核心问题，再引入解决问题的工具。
写在最后
AI 可以帮助我们更快地写出代码，但真正可靠的数据应用，仍然需要清楚的数据来源、稳定的数据处理过程和可以追溯的结果。
所以，这个系列不会从一套复杂架构开始，而是从一个小型、可运行、可以逐步扩展的学习项目开始，逐步理解数据仓库如何组织数据，Kestra 如何组织流程。
