数据部门起步阶段需要建立数仓么?

之前我写了一篇关于数据中台和数仓的关系 的文章,里面理清了数仓和中台的关系。后面我了解到更通用的技术词汇去表达数据管理的两种方式: 数据联邦和数据仓储。

显然传统的数仓采用的是数据仓储的概念,而中台则更合适的是数据联邦,同时,在中台看来,实际的数据存储应该是联邦以及仓储混合的模式。

但是我发现很多公司在组建数据部门的时候,第一步都是通过hive建立数仓,但是实际情况是,数仓极其复杂,管理成本也颇高。从开始建立到真正能很好的对外输出价值会是一件非常漫长的事情,同时还有一个致命的缺陷,就是数据延迟性。通常的数仓都是T+1标准设计的。这就意味着数据是延后一天的。这个对产品和运营,还有商务而言,其实影响很大,尤其是需要快速响应的今天。

所以,在公司组建数据部门的时候,最好的方式是采用数据联邦,通过中台,先获得全局数据的访问权,同时对重要的数据建立Meta信息存储。在数据部门初期,大部分业务部门可能还没有很好的数据思维,他们初期的诉求应该是“提数”,也就是“提取数据”,做简单的分析,而这个数据往往是在自己部门内部的数据。通过中台,他们可以很好的访问自己部门内部的数据,完成数据获取,极大的满足了运营,产品对当前自己产品的数据状况。而且,因为跨部门的数据获取需求不多,数据部门去协调跨部门数据交流成本会降低,可以专心修炼内功。

但是联邦的问题其实也明显,比如我司经常遇到的问题就是业务的从库扛不住分析和查询。导致这个问题不好解决的原因有两个:

  1. 第一种是思维模式上的。运维并不认为提供的从库应该有非常高的运维优先等级。甚至资源占用量比主库高是可能比较难以让人理解。
  2. 第二种是业务技术没有跟上时代,经过这么多年,数据库依然停留在单机时代,进行传统的分库分表。当然,现在随着云以及数据库自身技术(比如分布式关系型数据库TiDB)的崛起,其实这个问题已经得到了极大的解决。但是我们无法让业务去替换采用这种技术。

所以要解决这两个问题也方法上比较简单(执行上依然存在困难),第一是让业务的新增从库采用最新的数据库技术,比如TiDB,这种数据库本身比较适合OLOAP分析,也就是能支持大数据量的存取。第二是中台采用透明的缓存技术(比如我们使用时可以按用户将数据缓存到HDFS再进行计算,或者引入类似JuiceFS这种专门解决解决数据存储和计算分离问题的存储系统),减轻业务从库的压力。

从我的思考上看,数仓和中台应该同步建设,但是在数据部门的起步阶段,为了最快的进行输出,解决业务的“提数”难题,应该优先建立中台,并且直连业务数据从库,从而实现业务自主操作。同时让分析师团队帮助业务团队进行使用,并且提供更高级的报表分析业务。

你可能感兴趣的:(数据部门起步阶段需要建立数仓么?)