漫谈数据治理之一:计算与存储压力

背景概要

做数据的同学都能够有体会,当我们做业务时间长了以后,数据表的数量就会变得庞大无比,很多过去的逻辑,如果负责的同学离职了,那么能再看懂它的人就很少了。久而久之,就造成了表一大堆,没人敢动的问题。等到计算或者存储遇到瓶颈了,回过头来再改,会让人痛不欲生。

主要痛点

  • 只建表,不删表:绝大多数做数据工作的同学,都没有及时清理无用表的习惯。

  • 交接过程产生漏洞:由于业务的问题比较繁琐,理解起来有一定难度,因此在离职交接时通常不会交接的很好,埋下了坑。

  • 日常研发过程无规范:很多中小公司,数据作为支持部门存在,解决需求就可以,没有长远的规划,时间久了看不懂的东西越来越多。

  • 野蛮开发,无序增长:业务高速发展时,大家以需求为第一目标,开发过程没有考虑计算与存储问题,频繁发生数据倾斜、全表扫描等场景,或者是数据存储周期设置不合理。

谈一谈基本的治理思路

主要就是两点:粗治理和细治理。粗治理:普遍性治理项目,通过自动的扫描可以获得的信息,通常包括如下几种:

  1. 创建的临时表:以tmp/test开头的表;

  2. 无访问信息表:例如最近一个月没有访问信息;

  3. 无下游依赖表:下游没有使用方的表;

  4. 无更新时间表:表结构长期没有更新信息。

将以上四类表抓出来,基本上能处理掉一大批没人管的包。

细治理:专项性质的治理方案,主要针对有人负责的项目,通常包括如下几种:

  1. 运行时间过长的节点;

  2. 存储空间过大的表。这一类的治理行为通常花费时间很长,但产生的效果会非常明显。

能够沉淀下来的方法论

数据治理是一个十分消耗时间的过程,也是一次自我革新的历程。除了制定一些可跟踪、可管控、可负责、可施行的方案外,最好能够制定一定的标准,即使这些标准很简单,也能够产生非常好的效果。对数据研发同学,就更要强化自我对于数据的治理意识,如果有可能,在招聘过程、晋升答辩、KPI制定中都加入数据治理相关的要求,对于推广更有帮助。

热门文章

直戳泪点!数据从业者权威嘲讽指南!

数据分析师做成了提数工程师,该如何破局?

全栈型VS专精型,团队到底需要什么样的人?

数据驱动业务,比技术更重要的是思维的转变

最近面了十多个数据分析师,聊一聊我发现的一些问题

漫谈数据治理之计算与存储压力

你也「在看」吗?????

相关文章:

  • 2022-01-13
  • 2021-12-19
  • 2022-12-23
  • 2021-09-17
  • 2021-12-06
  • 2021-12-23
  • 2021-04-27
  • 2022-01-14
猜你喜欢
  • 2021-12-26
  • 2022-12-23
  • 2022-12-23
  • 2022-12-23
  • 2021-06-05
  • 2021-04-24
  • 2021-05-25
相关资源
相似解决方案