思考题一：我认为是随着业务不断迭代发展而不断变化的数据处理方式，比如有些数据源被抛弃，有些业务被拆分，有些数据表需要追加字段。业务开发更多考虑的是我的数据存储怎样满足新的需求，所以字段到后面越来越像屎山。我遇到的一个典型场景是订单问题，一开始业务还是按照之前app经营方式只有主订单概念，但是随着往电商方向发展需要引入sku和子订单概念，这就需要数据开发这边去兼容这种场景。我认为解决的要点有二，一个是能够对业务迭代产生的数据影响有足够的敏感性（这一点没有个在一家公司多年的沉淀是培养不出来的）；另一个是对数据处理的设计有拓展空间，而这个拓展空间留到什么地步就是见仁见智了，我们团队内部也没少因为这个争论。 思考题二：我个人理解的话技术成本主要体现在ETL这条通路的搭建上，一旦走通了后续成本其实不大，后续更多的地方在于如何再载入数据源后去筛选，合并和处理数据，也就是业务理解能力（业务理解更新成本）。至于如何让运营感知到ETL价值，我的一个量化方式是响应成品时间，具体来说我会将收到业务数据诉求到最终交付成果的时间进行量化，比如说给出对方2-3小时承诺然后去完成同时比业务多想几个点（需求范围之外的拓展）去交付，久而久之业务也就能看到数据带来的价值。 思考题三：现阶段来说开源的大模型并不能够直接用来理解各用户语义，比如我们曾经尝试过用AI-sql方式做辅助查询，但是效果非常差（哪怕是单表）。所以我个人理解中间还缺少了一个步骤，就是将各个数据模型的元信息转化为能够被正确解读的相关大模型。从我目前观察来讲，可能数据人员本身自己都做不好所有数据模型内容的理解，这让我想起尹会生老师在AI课上讲的当自己脑子一团浆糊的时候你用的大模型也做不好。综上，从短期来讲，直接让大模型和人工智能去替代人员做数据处理可能步子过大，反而借助大模型的能力维护和解读好数据模型的元信息并能够辅助他人查询是一个可行性方案。