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

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

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

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

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

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

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

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

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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值