随着工作内容中数仓的成分越来越多，脑海中的疑问也是越来越多。
基于一些资料以及日常工作中的体会，现试着回答这些疑问，当然目前的认知还是非常浅的，有说的不对的地方，欢迎大家踊跃指正
一、数据处理技术及常用库
（一）两种数据处理技术：OLTP和OLAP
OLTP，Online Transaction Processing System，在线事务处理系统：主要用于实时处理小体量数据，主要进行增删改和查询操作，常用于业务端，比如超市购物时，商品录入和扫码支付等操作都使用OLTP。常用的库如MySQL等。
OLAP，Online Analytical Processing System，在线分析处理系统：用于处理和分析大体量历史数据，目的是为了提取有价值的信息去支撑决策。主要用于查询操作，比如公司线上报表。OLAP本身不产生数据，而是通过ETL工具从不同的OLTP数据库中抽取数据到OLAP数据库（数据仓库）中，并对数据进行整合清洗，使其达到可分析的数据标准。常用的库有Hive、Doris和ClickHouse等。
（二）常用库的特点
mysql：开源免费，常用于业务库。
hive：可处理大批量数据，稳定，常用于数仓。缺点：无update，但是可以使用insert overwrite来覆盖原有表数据，进而达到更新的效果。
doris db（又名starrocks）：即时查询，可达千亿级别。缺点：成本高。
clickhouse：查询性能高，亿级别 。缺点：单表支持能力强，但join能力弱。
粗略来理解，mysql业务库用来生成数据，hive存储库用来分析数据，而数据建模就是往这些库里装表，但是怎么装呢？又是一门学问。
二、数据建模
（一）什么是数据建模？
数据建模就是建一张张表吗？可以这么说，但是不严谨，缺少了几个形容词。
数据建模就是建 “质量高、效率高、成本低和安全合规”的一张张表。加上这几个形容词后，就不单单是建个表那么轻松了的事情了。展开来说：
（1）质量高：数据的质量决定了数据的价值。数据是引导业务工作的指南针，指南针都不准，你跑得再快也是白跑。
那么评估数据质量高的标准是什么呢？准确性、完整性、时效性和一致性。
准确性：比如一个订单实销金额是100，那么你的表里这个订单实销金额也得是100，如果记成300，就是记错了，就不能如实反映业务情况了。
这里需要重点说一下，谁来负责数据的准确性？看了很多资料结合自己的实际工作，谁把这个数据提供给了数据使用方就是谁来负责，比如你是做业务报表的人，那么你就要为你做的报表数据负责。为了保证报表展现的数据是准确的，你可以push业务方去检验数据，数据有问题你可以push数据开发人员去排查校准，但是不管哪个链路有问题，为这份数据负责的依旧是你。
完整性：比如今天一共300个订单，那么你的表里也得有300行记录，不能漏记成250行，也不能多记成350行。
时效性：比如用户开了会员，系统里就得马上有该用户的信息，否则用户去买东西享受不到会员权益，体验是不是就很差。
一致性：比如用户id在用户表里是001，那么在订单表里也得是001，不能同一个用户出现好几个id。在数据指标里，相同的指标名称在整个数据建模的过程中都要是一个含义。
（2）效率高：效率高体现在开发维护这套数据的效率要高，同时也要让使用数据的人效率高。
开发/维护效率高：即你这个数据模型的稳定性和适应性要高，公司的业务大多是经常变的，如果业务变一点你的模型就得改，那说明稳定性就不好。同时，如果核心业务变了，需要你的数据模型变时，也要能快速地跟着变（调整快，数据回溯快）。
这里有个小技巧：为了增强表的扩展性，可以适当建一个大字段，里面可以放很多字段，通过键值对的方式来存储。存储内容案例：{'A':'***','B':'1','C':'0','D':'0'}，如果新增了一个字段，直接追加到这个大字段里，后续可通过SQL提取出来使用，当然这种方式适合使用频次不高的字段，使用频次高的字段还是需要单独提溜出来的。
使用效率高：找起来方便，用起来顺手。简单来说就是，大家常用的数据要能快速提取出来，使用频次高的字段要落在业务大宽表里。曾经就遇到过一共3个表，字段都差不多，但是想看全数据，那个都不行，必须3个表一起看，A表缺少库存信息，B表缺少销售成本，C表没有实销金额。本来一个表就能搞定的事情，硬生生地建出来了3个相似的表，对数据使用方非常不友好，这就是典型的不简洁不易用。
（3）成本低：涉及到考虑存储成本和计算成本的平衡。你的维表拆的越细，数据越不容易冗余，那存储成本就低，但是你跑数要关联的表就多了，计算成本就高了，所以这两者的平衡要考虑一下。
（4）安全合规
合规：比如需要用户授权但是用户没有授权的信息你就不能采集，也不能存储，更不能使用。
安全：比如用户手机号等信息存储的时候要加密处理，比如得有一套机制防止数据泄露等等。
（二）如何进行模型设计？
（1）了解业务流程
在设计模型之前，需要去了解业务，这篇文章讲过一套了解业务的模型，可供参考：数据分析08：用OSM+UJM模型搭建指标体系
最简单快速的方法就是找各个业务部门去聊，收集需求，然后按照OSM+UJM的模型去梳理出来。
（2）数据域
数据域可以粗暴的理解为将需要建的表打标签做分类，比如交易域、流量域、门店域、用户域，后续建表的时候先判断属于哪个域，然后就把这个域标签加上，这样的好处就是找表方便，维护起来也方便。
在梳理数据域的时候，可以借鉴《金字塔原理》中提到的MECE原则：相互独立，完全穷尽。
（3）数仓分层
建模的时候为什么要考虑数仓分层？数据量级很大，公司的资源有限，直接查询数仓中的原始数据，提取数据的SQL是非常复杂的，各种join和union加一起可能都不够用，造成的直接后果就是SQL运行很慢，OOM可能是分分钟的事情。这个时候，可能老板/业务方都会跑过来追问你“我的数据怎么还没出来，你的效率要高一点呀”，是不是欲哭无泪。而且，如果前面的人离职了，你接手了这个坑，上班第一天你看到一个个千八百行的SQL，是不是也欲哭无泪。
虽然分层提升了一点存储成本，但是大大节省了计算成本、重复开发的成本和维护成本，而且大大提升了跑数效率、数据准确性、数据一致性和数据安全性等等好处。那怎么来分层呢？每个公司都不太一样，要根据公司实际业务情况进行分层。但是大多数都分成这几层：
原始数据层ODS - Operational Data Store：ODS层不做数据清洗工作，或者只做简单的数据清洗工作。目的是保持和业务系统数据一致性，以及快速产出给下游用。
明细层DWD - Data Warehouse Detail：进行了ETL数据清洗工作，比如对ODS的数据进行了去除空值，脏数据，超过极限范围的等操作。
服务层/汇总层DWS - Data Warehouse Service：对明细层数据进行了轻度的聚合，这一层的数据来源基本上都是DWD和DIM。
应用层ADS - Application Data Service：在DWS的基础上进行了高度聚合或者字段减少等操作，大多是用来做报表和临时数据查询用的。
还有一个和上述层级关联没那么大的维度表DIM - Dimension。比如商品的基础信息表，地域信息表等。
还有一些注意事项，笔者曾经踩过坑，这里分享给大家：
① 切记不要出现上游引用下游数据的情况（比如不要出现DWS层引用ADS层数据的情况）。
② 对于经常变动的枚举值不要写死，比如订单来源，最好单独建一个映射关系表 （订单来源id，订单来源名称），有变动及时维护关系表，那么下游也会无感知的自动更新了，如果你在ADS层代码里case when写死了，那后续你的麻烦就大了，一变就要改，一改就要回溯历史数据。
（3）指标和维度梳理
指标和维度，在了解业务流程的环节里基本就能梳理出来，这里要重点说一下，基于这些指标和维度，要梳理出来一套数据字典，写清楚指标名称，业务含义，计算口径，添加时间等信息，一个企业内大家使用一套数据字典，提高一致性，可以有效的打破信息孤岛，提高数据的流通效率。
（4）表名、字段
表名要清晰，每一个层级起名要有规范，属于哪个层是增量表还是全量表需要从表名上就能看到。
相同的字段在不同的表里起名要一致。
相同的字段字段类型要一致，否则提取数据时SQL需要进行类型转换。
表里的指标不能只有率，有率的情况需要加上该率的分子分母，方便后续多维度聚合统计数据。
今天先到这里，后续随着理解的加深，再总结。
联系客服
