目录
- 0- 前言
- 1- 过于迷恋技术,而没有将重点放在业务需求和目标上
- 2- 没有或无法找到一个有影响的、平易近人的、明白事理的高级管理人员作为数仓建设的发起人
- 3- 将项目处理为一个巨大的持续多年的项目,而不是追求更容易管理的、虽然仍然具有挑战性的迭代开发工作
- 4- 分配大量的精力去构建规范化数据结构, 在最终呈现数据之前,用尽所有的预算
- 5- 将主要精力投入到后端操作型性能和易开发性,而没有重点考虑前端查询的性能和易用性
- 6- 使存在于应用层的可查询数据设计的过于复杂,应该通过简化解决方案开发出更适合需要的产品
- 7- 烟囱式开发,不考虑使用可共享的、一致性维度将数据模型联系在一起
- 8- 只将汇总数据加载到数据仓库中
- 9- 臆想业务、业务需求及分析,其涉及的数据及支持技术都是静态的
- 10- 忽略数据仓库的成功直接来源于业务的认可。如果用户未将数据仓库系统当成他们制定决策的基础,那么所有的工作都是徒劳
0- 前言
在Ralph Kimball和Margy Ross的《数据仓库工具箱》一书中,提到了数据仓库设计中的10个常见陷阱,本文针对每个陷阱添加了一条与数据仓库设计经验有关的附加解释。在着手进行数据仓库项目之前,可以了解一下数这10个常见陷阱。这样才可以不被数据仓库设计的陷阱所困扰,避免这10个常见的陷阱可以在构建数仓的过程少走些弯路。
1- 过于迷恋技术,而没有将重点放在业务需求和目标上
- 数仓归根结底是要解决业务问题的,狂拽酷炫的数据架构和层出不穷的新技术通常会比去了解用户需求更具有吸引力。其实,也没有完美的技术架构,只要是能够满足当下及未来可见的业务需求即可,合适就好。应当把时间投入在理解和梳理业务上,这样才能够构建出相对合理的数据模型,从而提高模型的复用性,及时响应业务需求。另外建数仓的目的是什么,或者说数仓有哪些价值呢,其实最终还是要凸显数据的价值,做了一堆表、设计一堆模型,如果只是停留在这个层面,那数仓将毫无意义。通过数据产品透出数据并能够指导业务,才是我们做数仓多应该思考的一个问题。
2- 没有或无法找到一个有影响的、平易近人的、明白事理的高级管理人员作为数仓建设的发起人
- 数仓建设是多部门合作的结果,只有这样才能够真正的实现数据赋能业务。所以没有高层的支持和重视,数仓的建设将会很难推进。这种情况在传统的企业尤其重要,一般互联网公司,数据是内置在基因里面的,对数据重视程度是非常高的,所以利用数据指导业务是顺其自然的事情。对传统的中小企业而言,前期没有数据沉淀,基本上靠手工报表解决一些简单统计,这个时候要去推进一些数仓项目,能有个影响力的领导者是非常重要的,否则将很难推进。
3- 将项目处理为一个巨大的持续多年的项目,而不是追求更容易管理的、虽然仍然具有挑战性的迭代开发工作
- 这是一个经常出现的陷阱,试图建设一个庞大的,无所不包的系统,通常是不可取的。似乎只要建设一个“巨型无比”的系统就可以完成任何

最低0.47元/天 解锁文章
2773

被折叠的 条评论
为什么被折叠?



