数仓建模这东西理论性老强，初读相关章节，那些什么业务板块、数据域、总线矩阵啥的名词，每个字我都认识，可就是似懂非懂让人脑壳疼
数仓建模初体验困惑多
咱刚开始面对数仓建模的那些个名词时，真的就跟看天书一样。就说业务板块、数据域这些词儿，啥是业务板块咋个划分弄不清楚。这些名词组合到一块儿，只觉得云里雾里。而且，书上那些个概念说得挺抽象，感觉是简单汉字，可连一起就成了复杂谜题，有时候看半天都想不明白啥意思
实际在很多企业的数仓建设初期，团队里不少新人拿到资料就犯懵，看到这一堆名词，大家就大眼瞪小眼，不知道从哪儿下手去整明白，花费了不少时间精力才慢慢有点头绪。
OLTP与OLAP区别大
OLTP系统和OLAP系统那差别可老大了。OLTP通常主要处理随机读写操作，它采用满足3NF实体关系模型来存储数据。这么做就是为了在事务处理当中解决冗余以及数据一致性的问题，好使数据在操作的时候顺顺利利的。
而OLAP系统，它关注数据整合以及复杂大数据查询和处理的性能，主要做批量读写的操作。比如说一家电商企业，它的交易系统就更偏向OLTP特性，对用户购买等事务操作处理很重视；而数据分析部门要做销售数据分析时，用到的系统就有OLAP的性质了。所以不管是哪个系统，表和字段都得好好设计
业务板块划分有必要
在搭建企业级或者更大概念组织的数仓时，划分多个业务板块那是相当有必要的。不同业务有不同的数据，划清板块就像给房间分区域一样，能让数据管理得更有序。比如大企业有销售业务板块、人力资源业务板块，它们的数据特点和用途都不一样。
划清业务板块后，还能让各板块团队更专注自己的数据维护和挖掘，提高效率。要是不分区划业务板块，数据管理会乱成一团麻，找起数据来也费劲得很。
数据分层重要性显著
数据分层可是数仓里大家都熟知的概念，一般就分为三层。它的作用是存放明细事实数据、维表数据还有公共指标汇总数据这三类。具体有对应的三种类型的表。
DIM这一层，能建立一致的数据分析维表，把数据计算口径和算法不统一的风险都给降下来，还能给DWD和DWS提供可退化维度。而且，DWD把统一清洗逻辑和条件做好下沉，关联组合相关数据，能减少数据扫描量，为后续数据处理减轻压力
确定所需的列有方法
数据库里大多是星型或者雪花模型，这里面能关联的维度还有关联出来的维度属性可能一堆一堆的。那到底怎么确定需要的列？凭直觉闷头开发可不行，很容易干好多无用功
根据经验在初步确认存在维度以后，就跟分析人员还有业务人员一起沟通沟通。大家一起讨论讨论，选出需要关注的维度和维度属性，这样就能快准狠地定位所需列了。比如说在电商交易数据分析中，有时间、商品类别等维度，和各方沟通后就能明确该用哪些维度去分析。
维度与事实表的设计
数仓实际操作时，要是不特别纠结存储成本问题，会用快照维表或者极限存储策略。这样能保障数据的一些特殊需求。
而事实表设计靠的是四步维度建模的方法。在设计的时候字段设计也挺复杂，这可是有一套专门方法论。模型设计也得遵循一些原则，把业务相近还有访问频率高的数据搁一块儿，这样方便后续的数据处理和使用。
大家在实际工作中，有没有什么独特对数仓建模设计技巧？
