之前我写了一篇关于数据中台和数仓的关系 的文章，里面理清了数仓和中台的关系。后面我了解到更通用的技术词汇去表达数据管理的两种方式： 数据联邦和数据仓储。
显然传统的数仓采用的是数据仓储的概念，而中台则更合适的是数据联邦，同时，在中台看来，实际的数据存储应该是联邦以及仓储混合的模式。
但是我发现很多公司在组建数据部门的时候，第一步都是通过hive建立数仓，但是实际情况是，数仓极其复杂，管理成本也颇高。从开始建立到真正能很好的对外输出价值会是一件非常漫长的事情，同时还有一个致命的缺陷，就是数据延迟性。通常的数仓都是T+1标准设计的。这就意味着数据是延后一天的。这个对产品和运营，还有商务而言，其实影响很大，尤其是需要快速响应的今天。
所以，在公司组建数据部门的时候，最好的方式是采用数据联邦，通过中台，先获得全局数据的访问权，同时对重要的数据建立Meta信息存储。在数据部门初期，大部分业务部门可能还没有很好的数据思维，他们初期的诉求应该是“提数”，也就是“提取数据”，做简单的分析，而这个数据往往是在自己部门内部的数据。通过中台，他们可以很好的访问自己部门内部的数据，完成数据获取，极大的满足了运营，产品对当前自己产品的数据状况。而且，因为跨部门的数据获取需求不多，数据部门去协调跨部门数据交流成本会降低，可以专心修炼内功。
但是联邦的问题其实也明显，比如我司经常遇到的问题就是业务的从库扛不住分析和查询。导致这个问题不好解决的原因有两个：
- 第一种是思维模式上的。运维并不认为提供的从库应该有非常高的运维优先等级。甚至资源占用量比主库高是可能比较难以让人理解。
- 第二种是业务技术没有跟上时代，经过这么多年，数据库依然停留在单机时代，进行传统的分库分表。当然，现在随着云以及数据库自身技术（比如分布式关系型数据库TiDB）的崛起，其实这个问题已经得到了极大的解决。但是我们无法让业务去替换采用这种技术。
所以要解决这两个问题也方法上比较简单（执行上依然存在困难），第一是让业务的新增从库采用最新的数据库技术，比如TiDB,这种数据库本身比较适合OLOAP分析，也就是能支持大数据量的存取。第二是中台采用透明的缓存技术（比如我们使用时可以按用户将数据缓存到HDFS再进行计算，或者引入类似JuiceFS这种专门解决解决数据存储和计算分离问题的存储系统），减轻业务从库的压力。
从我的思考上看，数仓和中台应该同步建设，但是在数据部门的起步阶段，为了最快的进行输出，解决业务的“提数”难题，应该优先建立中台，并且直连业务数据从库，从而实现业务自主操作。同时让分析师团队帮助业务团队进行使用，并且提供更高级的报表分析业务。
