12｜数据模型：从业务需求到数据结构的“翻译器”

* 思考题一：应该说是经历两个大版本迭代才形成了公司今日数仓，第一个版本时候（我刚到公司实习时）还是基础-中间-应用，层次划分并未按照流行的方式来做并且中间层建设的非常差，所以基本就是基础-应用，所有逻辑都由分析师自行决定，效果就是同一个指标不同报表经常不一样。 第二版迭代时候尝试用流行思路来做，但是是和分析师共同开发，结果因为视角不同造成开发非常混乱（比如层级反向依赖），并且数据开发不了解业务全貌最后又演变成了第一版遇到的问题。最后下定决心由数仓开发统一来做，定好规范深入了解业务现状才慢慢改善，目前遇到的问题是随着大批量模型表设计完成开发，增量任务会让开发人员不屑于去花时间了解，最后做成了一个数据表一个明细表的一一对应建设，没有做整合。总结来说就是开发人员绷着的弦儿懈怠下来后很难再次绷紧，慢慢又会回到最初的困境中。 * 思考题二：最基础的应该是客户，骑手，商铺这三个实体，业务过程即为用户在外卖平台上的某个商铺下单菜品然后由骑手取餐后送到客户手中。实际过程中用户会浏览和搜索菜品，因此至少需要增加菜品和商铺分类这些实体（不往下细究，因为我也没设计过外卖平台的数据模型）用以支撑用户搜索与下单。至于后续的分析向和推荐向内容，比如埋点类的我感觉这里讨论起来会乱套，所以不在此处赘述。 商铺分类-商铺-菜品这类用关系表描述即可，其实这三个可以作为下钻的维度来组合；而骑手这里（不太了解具体运行机制，所以不想设计过多实体如骑手所属公司等）和商铺关系，商铺客户关系，骑手与客户关系用事务表更好：其中商铺-骑手-客户可以维护出取餐送餐这一事务过程，商铺客户维护下单销售这一事务过程（同时夹杂类似于物流结果的展示，比如已送达等） * 思考题三：我觉得一个是支持非结构化数据原始存储与向量化存储，因为从我的了解来说当前AI的主流思路是输入数据的embedding，那么就需要我们的数据模型支持这种embedding后的高维数据存储。我目前在实践中AI还停留在dify搭建工作流阶段，所以能想到的结合场景只有这么多。