数仓设计复杂度评估
BI数仓的死法有很多种，建BI数仓的人不专业是常见的第一种死法；人员离职没有交接以及交接不完全也是常见的第二种死法；还有一种常见的死法就是管理层不重视BI数仓基础建设，在领导眼里就是个取数的，给个需求想已最快的速度要给结果，结果是能以最快的速度给出来，但不是通过数仓给出的结果而是直接从ODS层SQL数据集存一张表到数据集DM层，直接跳过DW层。
当管理层不重视BI数仓基础建设的时候，出现前面说的第一种、第二种死法就在正常不过了。一般情况这种都是出现在那种不大不小的企业，如果是小型企业那一个人就能搞定BI数仓所有的事情；中型企业在人员都熟悉业务的情况下2—3人是可以顶得住的；大型企业就另说了分工会很细人员配置至少10+至100+。
目前市场上的情况可以说是非常复杂，中小型企业需要全能型人才，大型私企国企需要专业人才只要在BI数仓各个工种之间某个工种擅长就行了，就好好当一颗螺丝钉，言外之意就是老子有钱养得起你，你要是走了我可以出更高的价钱招一个更专业的人来做螺丝钉。中小型企业出现大量烂尾的BI数仓，只有少部分公司外购的业务系统然后BI也从同样的公司外购，也就是说乙方公司卖给你业务系统也卖给你BI系统这样就不用招BI人员了解业务系统表业务模块及数据流，这种的烂尾的概率非常小。
最近对一家中小型企业的烂尾数仓进行研究，完全符合我前面讲的三种死法，我选择了历史遗留的两个DW库进行研究，这个两个历史的DW库有太多的故事这里不叙说。
这里我讲一下我对烂尾数仓进行研究的心得：一开始我根本不知道怎么入手梳理，只能每天想一点点办法出来，也就是每周推进一小步的样子，思考问题不仅仅是脑力活还是一个体力活，很容易饿。数据治理是另外一套方法论这里只单纯的针对数仓。
第一个思考点从元数据入手思考如何快速的拿到有多少张表？表里有多少列？表里面的列有多少是写了列说明？库里有多少存储过程、视图？存储过程、视图调用了哪些表？有哪些ETL包作用于这个库？ETL包里面有哪些表被调用？
第二个思考点从数据质量入手每天表的数据量情况？每天表的数据量增长情况？每天表列数据空值率情况？
第三个思考点从数仓变化入手每天表增加、修改的情况？每天表列增删改情况？每天表列数据类型删改情况？
第四个思考点从数据来源收入手 数仓的表数据从哪些库哪些表过来的？
第五个思考点从BI报表入手 数仓的表被哪些BI报表使用了？
这五个思考点我在《低代码数仓开发平台》具体实现了多少后面在说，下面是我研究烂尾数仓复杂度整出来的两张图，第一张图花点时间能勉强梳理清楚数据全链路过程：来源—业务逻辑—数仓设计—数据集市—报表 。第二张图说实话我有点绝望。如果说第一张图的数仓设计复杂度1颗星的话，那么第二张图的数仓设计复杂度5颗星。
