战斗力公司关于总分数据体系的架构思考
战斗力经常会有关于数据架构的讨论：数据部门应该独立还是下放到业务中心？最近经过一段时间的架构调整，加上之前经历的一些业务测试，现在把总结的关于数据应该集中还是下放的基本情况分享下。
战斗力的数据架构经历过从分散到业务中心到数据集中在数据中心但业务对接业务中心，最后是形成数据中心总体把控，数据人员直接下放到业务中心的转变。
关于这三种模式，相信大家都有所了解，但到底哪种模式更适合企业？
第一种数据分散到业务中心
相信大多数公司都属于这一层，各个部门都有自己的分析人员或团队，但没有一个支持中心。通常数据都会在技术中心，由主数据组或DBA进行管理。 这种情况下，会出现以下几个问题:
各部门的数据是分散的，不完整的，甚至只是片面的，基于这种质量上的数据结论不言而喻；数据孤岛会导致不同部门间的数据无法交流和共享，同样一个转化率，可能有订单/UV，订单/访问，订单客户/UV甚至件数/PV，各种指标都有应用场景，没有统一无法度量。
当然，实际上你可能会说没有啊。那可能是你只有一点网站数据而没有其他数据源或太多应用场景，你可能不会相信:同样BO平台，同样ORACLE数据源，出来的报表都没有可参考性。原因是BO的构建逻辑因部门而已，我的百货可能需要有效支付的销售数据，而他的家电可能需要全部状态的订单。状态不同，取数逻辑不同，数据结果必然不同；这只是简单场景，同样的指标，不同的数据表，不同的同步时间和机制，甚至不同的数据库都会影响结果，而这些结果都是业务部门不可能知道的。在这样数据基础上出来的所谓的报告，价值能有多大？
当然，这种模式不是一无是处，他适合业务场景简单，数据源单一，公司较小的情形。
第二种数据集中到某中心
数据集中无非就是把数据等在某中心集中统筹。该中心大多是信息技术中心，少部分是数据中心。这种模式的问题在于集中管理的人员不够了解业务。不够了解业务意味着什么？意味着做的报表都是我们异想天开的，我们的报告都是不切实际的，我们的建议都是天马流星的。那结果是什么？我们的报表系统报告没人用，我们的价值展现不出来。
当然我们也会告诉分析师，要去了解业务，了解业务，但对于一个外人，我们能了解多少？一天能有多长时间跟业务打成一片？--太少 。甚至我们还把分析师直接派到业务中，工位直接搬到业务中心去做。事实证明，这种方式确实能让分析师很好的了解业务，出来的东西接地气，能落地。但这是有前提的:
1. 分析师有扎实的数据素质，能及时有效准确的解答数据问题。新人，没有扎实基础的分析师会带给业务和分析师本身造成负面影响。
2. 良好的个人时间把控能力，懂得如何安排零散需求。你肯定不会想象，当你做到业务中间，随时随地都会有业务过来问你各种问题，各种零散需求。
3. 良好的工作流程和工作机制，保证各种较大的需求规范性，有规律可依。
单纯的集中管理数据的模式是不可取的，数据将是累赘而非价值。而下放人员过去的模式将做良好的补充。这种模式适合业务群较多，同时分析师的能力和流程都较为成熟的场景。
战斗力收集各个中心的零散需求，同时汇总到数据中心，数据中心会将各中心共同性特殊进行提取，从而形成全公司的共同知识财富，应用点将会深入到数据从底层收集、数据ETL、数据建模、可视化、推荐等各个工作场景——这部分是分散到业务中心最大的价值所在；
战斗力整体来看，数据中心负责集中力量做各中心的支持工作，同时也会做一些智能化、自动化、可视化的支持；分中心负责深入业务收集需求并建立符合业务需求的数据应用体系，二者相互补充，缺一不可。个人认为，这种模式是适合大企业同时能最大化数据应用价值的模式。