建设银行金牛支行网站,北京企业网站开发费用,微信小程序h5开发,个人营业执照查询系统目录
0 引言
1 主要内容
1.1 过于迷恋技术#xff0c;而没有将重点放在业务需求和目标上
1.2 没有或无法找到一个有影响的、平易近人的、明白事理的高级管理人员作为数仓建设的发起人
1.3 将项目处理为一个巨大的持续多年的项目#xff0c;而不是追求更容易管理的、虽然…目录
0 引言
1 主要内容
1.1 过于迷恋技术而没有将重点放在业务需求和目标上
1.2 没有或无法找到一个有影响的、平易近人的、明白事理的高级管理人员作为数仓建设的发起人
1.3 将项目处理为一个巨大的持续多年的项目而不是追求更容易管理的、虽然仍然具有挑战性的迭代开发工作
1.4 分配大量的精力去构建规范化数据结构 在最终呈现数据之前用尽所有的预算
1.5 将主要精力投入到后端操作型性能和易开发性而没有重点考虑前端查询的性能和易用性
1.6 使存在于应用层的可查询数据设计的过于复杂应该通过简化解决方案开发出更适合需要的产品
1.7.烟囱式开发不考虑使用可共享的、一致性维度将数据模型联系在一起
1.8只将汇总数据加载到数据仓库中
1.9.臆想业务、业务需求及分析其涉及的数据及支持技术都是静态的
1.10 忽略数据仓库的成功直接来源于业务的认可。如果用户未将数据仓库系统当成他们制定决策的基础那么所有的工作都是徒劳
2小结 0 引言 在Ralph Kimball和Margy Ross的《数据仓库工具箱》一书中提到了数据仓库设计中的10个常见陷阱本文针对每个陷阱添加了一条与数据仓库设计经验有关的附加解释。在着手进行数据仓库项目之前可以了解一下数这10个常见陷阱。这样才可以不被数据仓库设计的陷阱所困扰避免这10个常见的陷阱可以在构建数仓的过程少走些弯路。 1 主要内容 1.1 过于迷恋技术而没有将重点放在业务需求和目标上 数仓归根结底是要解决业务问题的狂拽酷炫的数据架构和层出不穷的新技术通常会比去了解用户需求更具有吸引力。其实也没有完美的技术架构只要是能够满足当下及未来可见的业务需求即可合适就好。应当把时间投入在理解和梳理业务上这样才能够构建出相对合理的数据模型从而提高模型的复用性及时响应业务需求。另外建数仓的目的是什么或者说数仓有哪些价值呢其实最终还是要凸显数据的价值做了一堆表、设计一堆模型如果只是停留在这个层面那数仓将毫无意义。通过数据产品透出数据并能够指导业务才是我们做数仓多应该思考的一个问题。 1.2 没有或无法找到一个有影响的、平易近人的、明白事理的高级管理人员作为数仓建设的发起人 数仓建设是多部门合作的结果只有这样才能够真正的实现数据赋能业务。所以没有高层的支持和重视数仓的建设将会很难推进。这种情况在传统的企业尤其重要一般互联网公司数据是内置在基因里面的对数据重视程度是非常高的所以利用数据指导业务是顺其自然的事情。对传统的中小企业而言前期没有数据沉淀基本上靠手工报表解决一些简单统计这个时候要去推进一些数仓项目能有个影响力的领导者是非常重要的否则将很难推进。 1.3 将项目处理为一个巨大的持续多年的项目而不是追求更容易管理的、虽然仍然具有挑战性的迭代开发工作 这是一个经常出现的陷阱试图建设一个庞大的无所不包的系统通常是不可取的。似乎只要建设一个“巨型无比”的系统就可以完成任何工作解决任何问题一样其实结果往往会适得其反。更糟的是管理这些项目的人往往没有与业务进行足够详细的协商从而开发有用的产品。一言以蔽之银样镴枪头中看不中用。小步快跑、快速迭代是个非常好的选择尤其是对于还没有数仓沉淀的情况可以先run起来支撑起业务后面在慢慢迭代即可。这样通过不断产出价值才能够得到更多部门的支持和配合。 1.4 分配大量的精力去构建规范化数据结构 在最终呈现数据之前用尽所有的预算 这个陷阱不像其他陷阱一样重要在Kimball的方法论中对维度模型进行更改所带来的业务风险要比更改源事务数据库小。所以应该留出足够的资源来构建它们但是很少有中小型企业在资源上进行投资以创建完全一致的事实和维度表更不用说OLAP数据立方体了所以再多的理论也解决不了实际的问题先跑起来才重要不管姿势是否完美。模型真的重要吗毫无疑问是重要的但是也是有轻重缓急的时候为了设计完美的模型而不支持需求就大错特错了实际的操作过程中有很大的弹性空间不可被理论禁锢停滞不前。 1.5 将主要精力投入到后端操作型性能和易开发性而没有重点考虑前端查询的性能和易用性 为用户提供易于阅读的数据展示形式并具有良好的查询性能会很重要。 1.6 使存在于应用层的可查询数据设计的过于复杂应该通过简化解决方案开发出更适合需要的产品 通常大多数业务用户都希望简化数据表示方式。此外对这些数据的访问应限于尽可能少入口。提高获取数据的易用性会大大提升数仓的价值。 1.7.烟囱式开发不考虑使用可共享的、一致性维度将数据模型联系在一起 当维度在整个数据仓库中不一致时就是典型的烟囱式开发。其实我们使用的维度在本质上是相同的但是由于数据来自于不同的业务源并会被随意更新。典型的例子是“时间”维度在维模型不一致的情况下最终用户通常完全不知道为什么一个报表中的数据可能与其他地方生成的报表有显着差异。一种好的做法是将数据模型与主数据管理MDM解决方案联系在一起该解决方案包含可以在整个数据仓库中普遍使用的参考数据 1.8只将汇总数据加载到数据仓库中 在事务数据库和数据仓库之间创建的每个ETL提取转换和加载过程中不能只将汇总的数据装载到数仓中要确保有一份原子数据存储在数仓中即将数据同步一份放在准备区(ODS层)。 1.9.臆想业务、业务需求及分析其涉及的数据及支持技术都是静态的 尽量不要开发仅限于某个特定业务需求和分析的数据模型因为业务在不断地发生变化。一个差劲的模型设计通常是开发重复的数据模型及不一致的命名约定。在设计一个“完美”的事实表、维表与规范化程度之间取得平衡并不是一件容易的事情但是开发出可伸缩的以适应业务发展的数据模型是非常重要的 1.10 忽略数据仓库的成功直接来源于业务的认可。如果用户未将数据仓库系统当成他们制定决策的基础那么所有的工作都是徒劳 这个是很致命的陷阱如果从一开始都没有得到业务和高层的重视和认可那么数仓项目多半是会夭折。从用户的角度出发如果用户对建立的数仓不买账根本就不会去使用它结局只会game over。 2小结 本文对《数据仓库工具箱》一书中提到的数据仓库设计中的10个常见陷阱进行了总结和分析针对这10个问题特别是刚开始建设数仓或进行数字化建设的公司来说这10条经验尤非常值得借鉴。数仓的建设是需要统筹规划的而不是随便一个取数的Ad-Hoc与业务系统有着本质的区别数仓的建设最怕的就是业务分析人员或业务开发人员直接拿来当业务系统使用最后做成与传统的数据库没什么区别。数仓的建设涉及了多部门的参与与合作再加上原有的数据不规范性、脏数据、异常数据比较多的情况下多部门的配合就显得尤为重要这时候就需有权威的领导出面牵头数仓的建设。 阅读了本文后您觉得哪一条对你目前公司更重要呢评论区留下你的意见 数字化建设通关指南专栏原价99现在活动价29.9按照阶梯式增长直到恢复原价
主要内容 1SQL进阶实战技巧 可以参考如下教程具体链接如下
SQL很简单可你却写不好也许这才是SQL最好的教程_sql语句写的很烂怎么办-CSDN博客
上面链接中的文章及技巧会不定期更新。
2数仓建模实战技巧和个人心得 1新人入职新公司后应如何快速了解业务 2以业务视角看宽表化建设 3) 维度建模 or 关系型建模 4业务模型与数据模型有什么区别业务阶段的模型该如何建设 5业务指标体系该如何建设指标体系该如何维护指标平台应如何建设指标体系 该由谁来搭建 6如何优雅设计DWS层DWS层模型好坏该如何评价 7指标发生异常该如何排查应从哪些方面入手寻找问题点 8 数据架构的选择mpp or hadoop? 9数仓团队应如何体现自己的业务价值讲好数据故事 10BI与大数据有什么关系BI与信息化、数字化之间有什么关系BI与报表之间的关 系 11数据部门如何与业务部门沟通并规划指引业务需求
文章不限于以上内容有新的想法也会及时更新到该专栏。
具体专栏链接如下
数字化建设通关指南_莫叫石榴姐的博客-CSDN博客
