分类逻辑可以分为横向和纵向两种类型。横向分的是层次，纵向分的是主题（或者主体）。这两个方向的分类构成了当前市场上数据仓库的主流分类逻辑。
第一层：1∶1地接入。完整地接入，不考虑可用性。细碎的日志和为了支撑系统功能被拆得七零八落的数据表，来者不拒。这一层的目标仅仅是全。
第二层：加入一些规范，进行清洗。把不符合规则的、对后续分析没有意义的部分去掉。这一层的目标是干净。
第三层：拼接、修补。把分开的、细碎的多个事实表合并起来，变成一份相对完整的事实表。这一层的目标是打通、可用。
第四层：整合信息，形成大宽明细表。把描述特定ID的维度信息和指标，合并进同一张表。这就是我们反复提到的“主题宽表”。这一层对应用来说最关键，目标是统一、完备。
第五层：高聚合计算结果。目标是准确、应用。
纵向区分“主题”，是基于关键索引和指标体系的。
计算资源是有限的，需要合理安排不同计算任务的顺序、并发、优先级等，进行统一调配，避免任务排队和拥堵，以寻求集群的效率最大化。
任务调度可以分为两种：定时任务和依赖任务。
定时任务是指某一段计算在特定的时间节点启动。这种方式会带来一个问题：当它计算的数据源表还没完成计算时，如果任务被启动了，则会使任务失败。后续依赖这个任务结果的计算任务，也会出现一连串的失败。就像我们给一辆车规定严格的进站时间，却不考虑前序车辆是不是已经出发了，可能会导致连环事故一样。
依赖任务不规定具体的触发时间，而是通过规定“前序任务完成”为触发条件。当依赖关系复杂时，还需要规定相应的执行优先级。
在提出一个需求时，能够预判实现难度对产品经理来说是非常重要的技能。就像后台产品经理多少要懂一点Java一样。
·数据角色之间的复杂逻辑沟通。很多用语言说不明白的事情，用SQL语言沟通，毫无歧义。范围不仅限于数据需求，比如在数据测试人员评估测试用例时，或者与数据分析师沟通一个计算口径时，直接使用SQL语言沟通的效率大概可以翻倍。
·验收数据。有些数据的验收，需要对比其他结果，或对比明细才能确认计算是否正确，那就只有会SQL才能做到！
