引言
前阵子有同学在群里聊起一个话题，如何评价一个模型的好坏，准备面试嘛，肯定就去各种百度啦，当然我其实也喜欢问人家这种问题，尤其是作为面试官的时候，我其实更加希望面试者可以给我一点新的思路，不是很喜欢百度上面的各种答案，我也想借此聊聊我自己的看法！
模型VS表
似乎在当下，模型似乎就是表而已，好像没啥差别吧。这个在我的工作生涯中有完整经历过这种转变，当我还是一个程序员的时候，我确实也是会去建立各种表，没有门槛，但是就是当时来说，我建表的话就是为了产出一些结果，有结果就行了，以至于有分析师找我要数据的时候，我会觉得可以直接给人家一个结果。不过这个时期，我没有想过一件事情，就是在未来某一天，Bl改变一些条件或者一些数据列获取的时候，以至于你这个表都有点不能使用，甚至于需要重新去开发。后面我其实是换了工作，我是作为一个数仓的岗位入职的，这个时候你会发现一个明显的区别，那就是你的表是作为一个公共的数据层提供出去的，满足给下游的业务方也是多样的，这种时候的区别就很明显了，那就是作为一种公共的数据中间层提供出去这部分表已然转换成一种数据资产了，是有实际为下游多方产生价值的东西，这个时候有数据域的划分，有命名的规范，有字段类型要求，还有数据质量的严格要求，这个时候你会发现把这整个操作过程我们才会叫做模型，而以前为了追求结果的方式去建表，我们只能叫做表而已。
好模型和坏模型
有没思考过，不管是人或者事务来说，我们其实唯一衡量的标准就是能否禁得起时间的考验，我多次看过<<人与自然>>-与远古人同行节目，我印象最深的是人类之所以可以存活下来是因为在恶劣的环境中还能找到食物，更加厉害的乃至影响人类蜕变的是布须曼人将水储藏在鸵鸟蛋中,埋在地下等没水的时候饮用，这其实是对未来的一种适应。当然对于我们模型来说一样如此，你建立的模型是否满足当下的业务支持，那么随着业务的迭代发展，数据量的持续增加，你的模型是否还能保持比较清晰的迭代和高效的产出呢？好坏其实在这其中就可以分辨出来了。完美模型我见得不多，因为业务总会有迭代在某一时刻为了满足某项业务支持会引入一些不好的设计，但是整体来说，如果一个模型3年5年下来还是有很好的性能，有很好的业务支持，就是很棒的。坏的模型这就见得很多了，我经常叫做茅坑里的石头，真实又臭又硬，而且占资源，占成本。我认为好坏评价可以直接有以下的方面去体现，出于对模型的理解，我们要看看这个评价背后的原因。
1、模型的规范性：模型命名，字段命名
这个事情其实是一个工程性的规范，至少我们在软件工程中我们是需要很规范定义软件接口，参数含义，大致上是自己内部倒腾一下还好，一旦提供给外部表使用，如果不是良好的规范，简直就是灾难，模型的话天生就是公共的数据资产，好的模型命名可以方便检索，查阅，而且模型名字上可以表达主要的信息，否则就是数据垃圾了。
2、数据质量：数据需要是正确的
这个事情是说如果数据都不对，这不是很要命的事情么，因为大抵使用公共层的数据默认你是正确的，如果不正确，使用的人很难判断，更加谈不上帮你修复了
3、数据的产出性能
这个本身是大数据加工的特征，因为一开始就是希望用分布式计算能力加工大量的数据，如果本身没有这种性能要求，说实话这个资产是只能服务少部分场景的
4、数据的可迭代，可维护，就是在上面迭代效率是否高
是否可以很快适应新的需求呢，这个事情估计大家要打个问号了，这个直接挑战的是加工链路的复杂性和清晰度，那就是依赖是否是很重的，是否有控制增量的
5、数据的完备性，历史数据生命周期，维度覆盖是否满足公共业务需求
数据的完备性是指看似表模型很多，数据很多，实际上真正可以拿出来的数据很少，大量的冗余数据并不能说明数据量完备，而是在整个数据模型周期上，是否可以还原业务的所有生命周期，是否可以拿到丰富的业务维度属性
6、事实和对象定义是否清晰，坏模型就是杂糅
见过太多的表，又大又长，本质上来说，其实就是无限度地去扩宽字段属性，这个地方直接就是合理性的加工和事实的杂糅
数据人员的成长
其实大部分人对数据其实是没啥概念，甚至是觉得没有成长性的，到底有没有呢，那就是衡量数据方面的高手和菜鸟怎么去划分呢？其实很简单就是直接看那个人建立出来的模型是好模型还是坏模型。大凡高手，会在业务、效率、计存方面设计模都可以拿高分的，这种能力表现在对数据的架构设计能力以及对数据域整体的成本效率的一种优化力度把握。
可能有点抽象，那我给出一份list，这份参考是来自数据仓库工具箱里面的内容，我觉得是可以作为数据人员的准则的：
理解业务用户
理解他们的工作责任、目标和任务
确定商业用户在制定哪些决策时需要DW/BI系统的帮助
识别出那些制定出高效率、高影响的决策的“最佳”用户
发现潜在的新用户、并让他们意识到DW/BI系统能够给他们带来什么能力
对业务用户发布高质量、相关的、可访问的信息和分析
选择最健壮的、可操作的数据放入到DW/BI系统中，从组织机构的各种数据源中仔细选择
简化用户接口和应用，采用模版驱动方式，与用户的认知过程轮廓匹配
确保数据精确、可信，使其标识在整个企业具有一致性
不间断地监控数据和分析的准确性
适应用户不断变化的思维方式、需求和业务优先级、以及新数据源的可用性
维护DW/BI环境
采用DW/BI系统制定的成功的业务决策，验证人员配置以及要投入的开支
定期对DW/BI系统进行更新
保持业务用户的信任
保持业务用户、执行赞助商和IT管理层满意度
在以上工作中，一个一个对照，在实际落地的时候进行自我打分对照。
数据人员与技术
这个是我在公司招人的时候有体会，面试的时候实际上是招聘对大数据引擎底层很熟悉甚至精通的要求，大部分人也是觉得为啥要这样，过去不就是建表么。这个似乎就是在你不了解大数据技术的时候你其实是想去了解，真正掌握大数据技术的时候你会发现这些技术很难直接带来落地的结果，直到你去把技术手段拿过去建模的时候，你才能 发现这个路子通了。当然，另一方面来说，如果直接就上手建模，很简单，即使你模型看上去各种规范标准，准确，但是永远也没办法去做性能上的改造，这往往是一种望尘莫及的感觉，人家懂的帮你调整几下就带来极快的时效，这种时候只能干瞪眼
后话
事实上我们一般是把自己说成是技术人员，而在我们的 下游还有一部分也是做数据的，消费我们的数据，我们会把他们才叫做数据人员，在大数据的成长之路上，利用技术手段加持你真正的数据链路，从这个层面来讲探索新的etl pattern，带来新的设计范式，打造行业规范，也是可以星辰大海的一件事情，也就不会觉得数据人这个称呼不大行了！！
