如何评价数仓好坏

评价一个数仓的好坏可以涉及相当多的维度，这里简单分享一些在实习时了解到的比较看重的方面。

模型合理性

1. 一个数仓模型的诞生往往是为了满足产品提出来的业务需求，但是如果一个模型仅仅只能做到完全为这一次需求而服务的话，那么它的利用价值或者说可复用性就会很低，在后续该需求不再重要时还需要对过往数据进行清理。所以，在考虑设计一个数仓模型的时候，一个好的做法是根据当下的需求自己稍微往上延伸一下使其能够在未来容纳解决更多的需求，从而尽量避免烟囱式的开发;
2. 模型的链路设计是否合理。在实际的数仓开发中尽可能引用较少的表，一是可以减少代码复杂性，而是避免引用过多表可能容易提高任务失败率(即上游某个任务出现故障）。另一方面，在引用表的时候要尽量避免使用到其他组或者部门的表，减少申请和沟通成本以及避免一些权限问题；
3. 模型的字段完整性。模型包含的数据是否是完整的，像一些公共维度是否都有，比如服务器id日期数据这些。

模型执行效率

1. 模型的产出时间是否过长，是否能够保证较高的SLA（这里从任务运行的角度出发，这里可以简单理解为任务是否在某个比较合理的deadline之前产出）；
2. 有没有出现数据倾斜导致运行时间过长甚至无法产出数据;
3. SQL是否可以进一步地进行优化，比如代码可读性是否较低，是否存在冗余，一些语句是否可以修改以提高运行速度等。

数据质量

数据质量是衡量数仓中十分重要的指标，如果一个偏底层的表的某个字段出现错误，那就导致上层使用到该字段的表都出现错误，报表中的汇总指标也出现错误，甚至可能影响到其它字段。

一般可以用数据是否健康来体现数据质量，这里的健康主要指数据:

1. 是否具有高准确性(极少出现数仓端导致的数据错误);
2. 模型是否会产生过多的小文件;
3. 表是否有中文别名和每个字段的对应描述 （方便其它人员快速了解该表，一般在数据地图中完善该类信息）。

数仓表使用率

下面两个指标是在实习时周报里最常见的两个指标:

1. 表的周访问pv有多少;
2. 分析覆盖率是多少 。

资源使用

1. 申请的队列资源是否合理，CPU和内存利用率(最大值和平均值)会不会偏低，又或者是否经常出现超发需要向其它组借队列的情况，此时就需要尽量及时扩容；
2. 队列资源都是需要相当成本的，每隔一段时间可以做一次简单的成本管理和调控，对于非重心业务，可以适当地减少一些资源投入。

域和层级划分

1. 各个表是否有清晰的主题和主题域;
2. 表所在的层级是否准确，是否符合企业里的数仓分层规范。