该文章已更新到语雀中，后台回复“语雀”可获取进击吧大数据整个职业生涯持续更新的所有资料
目前大部分行业中的数仓建设大多是采用Kimball指导思想进行的，在初期发展阶段为了快速支撑业务，而且希望能让领导感受到数仓存在的价值从而带来更大的投入和支持，在建设的过程当中多数以烟囱式开发为主。但随着业务快速发展，这种开发模式就会显露出各种不足，例如资源紧张、数据口径不统一、无法快速找到想要的数据、开发不规范、流程不健全等问题。这里的任意一个问题都需要投入大量的时间、人力去解决
而且解决这些问题所带来的效果和价值并不能直接冲击到高层，有可能在解决这些问题的过程当中会有很多变动，比如成员辞职了，部门没了，甚至是企业就倒闭了。对于这种尴尬的场景，我们又如何破局呢？需要注意的是本章节不讨论建设细节(如何制定规范、如何分层、如何建模，这些细节的东西后面会单独讲解)，而是讨论这种破局思路。
在《南皮县志·风土志下·歌谣》中提到了“兵马未动、粮草先行”的思想一直被广泛流传，小编认为同样也适用于数仓建设工作当中来。无论你是从零到1搭建数仓，还是从1到2完善数仓，在建设之前或者在事中的过程当中，都应该有体系化的思考，这样对于整个方向的把控也比较清晰化，同时对于每个成员都会有很大的成长。例如：从数据流向的角度来思考（当然这里的思考也涵盖前面提到的规范、分层、建模以及治理内容）
1、数据入仓采用何种方式？如何进行管控？入仓标准化程度如何衡量？质量如何保障？
2、仓中数据集成采用何种方式？过程是否标准化？质量如何保障？集成效果如何衡量？成本如何控制？
3、出仓流向如何把控？数据体验是否流畅？应用价值如何体现？
在建设的过程当中一定要把这一系列的问题思考到位，然后投入一定的人力持续进行完善优化，这样才是一个健康发展之道。从事数仓的童鞋一定都知道建设数仓不是一朝一夕能做完的，其实我们可以把数仓当作成数据人员的“产品”，数据就是产品的灵魂，模型就是产品的形态，数据人员就是负责产品的运营官。那么我们可以采取运营的策略和手段去搭建数仓。接下来从围绕着以下几个方面展开来讨论（这里采用了OSM指标思想）：
a. 运营的范围如何界定？
b. 运营的目标如何制定？
c. 运营的策略如何执行？
d. 执行的结果如何评定？
运营范围
企业中的数据体量非常大、类型比较丰富，但并不是所有的数据都是归属于数据人员进行维护，而且不能无边界的将所有的数据都进行集成，这样反而加重了运营成本，而不能投入更多的精力上赋能业务。所以我们第一件要做的事情就是数据确权，也就是说数据运营工作应该交由生产者负责。举例：业务系统产生的数据应该由系统侧进行维护。对于数据人员来说，从数据入仓、数据加工、数据应用整个闭环数据链路均属于运营范围内。也就是说从数据入了仓，直到出仓这中间的每一个流程二次产生的数据都应该由数据人员来运维。
运营目标
对于数据人员来说最大的成就感或者说是使命感就是希望能够把企业的数据“盘活”，并且让数据真正的发挥其价值，能够指导业务、创新业务，为企业带来正向收益。为了能够尽可能体验到这种成就感，我们从两个层面展开来讨论：
1、业务层面：DT时代，相信大家都已经感受到了大数据应用带来的便利。在数据行业中，人人都知道数据的重要性，都知道要通过数据来赋能业务，但最后到底有没有赋能成功，这就不得而知了。尽管数据作用于业务上，但其价值并不能直接简单的通过某几项指标来衡量，举个例子：业务需求方提出一些指标统计的需求希望能够提升运营效率，那么这种人为价值有时候是没有办法来衡量的（而且有时候也不会因为开发一些指标而去再评估制定一套来衡量指标价值的指标，这样整个开发成本和周期都会大大拉长。针对这种无法衡量的价值，那么我们需要考虑的就是如何做到自动化、智能化，通过减少开发成本来完成业务需求）。因此对于数据开发人员来说，我们能做的就是全、快、准。即要做到全面覆盖业务、快速支撑业务、准确判断业务。
2、 用户层面：在日常工作当中，数据开发人员通常并不会直接对业务产生影响，而是与前线业务人员、数据分析师、产品经理进行协作，但是数据是面向整个企业的，也就是说只要是使用数据的地方，或多或少都是和数据工种人员有关系的。其实数据对于从事数据开发人员来说，就是大家共同维护的一款"产品"。从产品角度出发，任何使用到数据的人员，都是我们的用户。我们希望在整个数据体验之旅中，让用户找数据不费心、查的舒心、用的放心，这就是我们对产品的设计目标。
运营策略
指导方针
在制定具体的策略手段之前，通常会基于一系列的原则作为我们行动的方针，避免我们在执行的过程当中走弯路。当然每个人对这些底线原则都有不同的理解，也可以采取符合现状的一些方针。小编认为在整个运营环节中，应该采用资产分级结合元数据驱动两方面双向辅助。
对于资产分级，我们需要理解什么是资产？如何定级？当我们划定运营范围、确定数据所有权之后，需要对每一种数据进行资产归类，并进行级别划分（比如可以按照业务影响度、使用频率等进行定级）。当我们把所有的数据资产划分等级之后，对于后续的运营方向就有了轻重之分，每个等级所采取的运营策略也有所不同。
关于元数据的概念，也有很多文章进行了详解，前面小编也整理了25种元数据管理解决方案（感兴趣的童鞋可以看一看），既然资产已经定了级，为什么还要结合元数据呢？其实是为了快速衡量我们在运营过程当中的效果，同时也是为了让高层看到一些希望，增强信心和决心。如果在运营的过程种采用某种策略反而没有任何效果，或者带来负影响，就需要及时调整策略，避免一条道走到黑。
业务层面
当我们把整个方向梳理清晰之后，并制定了参考原则后，就需要针对不同的目标采取不同的策略。接下来将展开讨论一下
全面覆盖
业务的全面覆盖其实也是对数仓建设好坏的一种评估方式，当然也并不一定说所有的业务都要包含进来(这个要看每个企业的特色)，最起码企业的核心业务、生命之本是一定要有的，然后随着业务的扩展一点点迭代进数仓中。小编觉得评估业务完整性的指标是比较难以制定的，一般是通过建设数仓的主题域来判断，但这里又回到了一个规范性的问题（有可能在建设过程中某些模型缺失主题域标识）。这也就是为什么数仓初期一定要做矩阵，为什么一定要制定规范，这些前期的准备工作也是为了方便后期衡量价值的体现！一般来说，二级以上的资产是我们需要重点关注完整性的，三级及以下大多是基于二级以上来完成的，这就类似于我们的分层概念。
快速支撑
对于互联网企业来说，业务变化是很快的，我们能做的就是适应变化，但一定要跟得上变化。这也考验数仓团队对于模型的建设程度，如果扩展一个新业务，想要快速进行数据分析，而你如果需要一周的时间去重建模型、需要做汇总，那不好意思，数据团队就是一个摆设。所以对于数据团队来说一定要快速支撑到业务，这也是为什么近几年一直提到的中台，为的就是提高复用性，做厚公共层，做到敏捷开发，这也是二级以上资产关注的重点。当需要你准备上战场的时候，你的武器装备就必须做到已经很完善了。小编认为可以通过工程化指标和你们做的模型扩展性来综合评估是否做到了快速支撑，比如你从接需求到交付的整个工期成本指标是否有提升，你们模型改动是否频繁，改动范围是否广这些方面去考虑。
准确判断
从事数据行业的童鞋，都有一个重要的意识，严重点讲就是职业道德，那就是数据安全问题，要做到保障企业资产不受到损失，这是每个职业人的道德底线。当然质量意识也要有所提升，尽量保障从你手中提供出去的数据是准确的，为什么说是尽量呢？质量这个事情不是一人之力所能及的，涉及到环节是比较多的，沟通成本也很高，如果你去推动这块事情有可能会无法和其他团队的目标对齐。所以这也是为什么需要整个组织制定标准制度流程来去驱动。但是！这并不代表我们不去做这个事情，最起码我们要把相关的指标体系建设起来，做到事前定义规则、事中监控、这样事后才能根据报告去反推运营，同样也能保障从入仓后的整个流程做到了严谨把控，让业务方对我们产生信任感，增强依赖性。准确性问题是不区分资产分级，也就是说每个环节都要保障，这就是底线！
用户层面
找的不费心
对于任何使用数据的人员都是我们负责产品的用户，我们要让用户在产品上快速找到自己想要的功能，这种便捷性体验会增加用户的粘性。应用到数据层面，当你看到一张表或者一个字段的时候，你能不能立即理解所代表的含义？这里面需要做的事情就比较多了，其中就涉及前面提到的元数据驱动的问题，这种便捷性可以基于元数据完成，但这里同样涉及到一个标准规范流程的问题，因为业务元数据毕竟是需要人为来去补充，技术工具只是辅助验证的一种手段。对于考量这种便捷性的方式有很多，如果你所处于的环境功能比较完善，做到了一站式，那么可以采集用户的行为进行分析，比如星级、交互次数、投诉数、收藏数、点击数等等。如果你所处于的环境设施比较简陋，那么可以通过人为统计沟通次数，或者用户评价反馈来去衡量。这种便捷性体验一般侧重于二级以上资产。
查的舒心
实时性是目前整个行业都在追求的目标，我们需要让数据尽量快，让用户在数据体验中没有一丝卡顿，做到纵享丝滑。这其实就要考虑到性能成本问题，一般来说二级以上的资产需要保障性能，三级以下需要做到成本控制，这也就是性能和成本之间的平衡问题。当然为了考量这一目标，里面涉及到产出是否及时、是否稳定、耗费资源情况等等。
用的放心
让用户在使用数据的时候产生完全的信任感，如同人与人之间的信任，如果能做到你交付的数据不会让验收方产生任何疑问，那么你就厉害了。质量问题同前面提到的业务层面上的准确判断一样，每一级的资产都要做到这一点。
目标评定
在前面讨论的策略过程中，也涉及到每一块目标的衡量指标，这里做一下汇总，如果哪里不对的地方，或者需要补充的点，欢迎大佬们指正。