如何避免数据仓库开发者成为取数机器
新闻来源：优漫教育
日期：2021-06-21
在因特网数据仓库领域工作多年的人中，最大的疑问就是数据仓库开发人员每天所做的最多的工作就是计算业务方数值。单纯重复性的取数工作，一方面难以让每个人都有进步，另一方面也慢慢打消了每个人的积极性和意志，也让每个人都极无存在感。
此外，在公司的整体架构中，这种工作模式很容易被替代，因此，也极不受重视。那么作为一个数据仓库的开发人员，应该如何反思和提升自己呢？这里有一些我的想法：
一、首先，检查一下自己的取数水平。
1、保证自己写SQL的技能一定是没问题的，看自己是否能够非常灵活地完成业务方提出的各种关联、分组、随机抽样等要求。假如这个方法做不到，那么就要考虑自己是否学艺不精，先从SQL练习开始，提高自己。
2、看自己能不能做到，自己负责的业务线，只要业务方一开口，基本知道如何去做。假如在取数的过程中经常和业务方扯皮、返工，就要考虑是不是自己对业务了解不够，而不是别人对你不够了解。
3、看一看是否做到，对自己负责的业务线所涉及的仓库的基本模型表有详细的了解。想知道就知道，想要知道就知道。
简而言之，就是制定自己的取数规则，建立自己的取数权威，让业务人员信任你。精通SQL语言，对自己所在的仓库模型表有深入的了解，能让您快速提数，节省思考的时间，提升自己。
二、让你自己的技术走得更远。
熟悉SQL的人都会用到SQL，但是如果假设您当前的仓库开发是基于hive，那么我们就不会仅仅使用工具，而是能够驾驭它。
您可以尝试查看hive的各个实现模块，可以查看最常用的UDF、UDTF源代码；然后查看hive的启动过程、内存分配；可以查看hive的编译过程，以帮助我们优化hivesql；可以查看hive的序列化、反序列化机制…构建一个环境，对各个环节进行调试，积极关注hivejira，及时发现并解决hive的bug。当然，我们也可以对hive进行二次开发，使之更有效地满足当前的业务需求。
在使用mapreduce计算框架的情况下，还需要深入了解mapreduce的计算模型以及hdfs。
以此为基础，检查一下当前的仓库平台，看看是否能找到一些可优化、可改进之处。
三、、让自己在事业上更上一层楼。
积极参与一些分析工作，主动与业务部门沟通，达到取舍的目的。
存在着大量的计数是有一定难度的，业务部门往往事先就没有考虑清楚，例如，在计数的过程中，我们会遇到以下场景：
“我想要一个在过去3个月中有活跃用户数量的用户”，业务部门妹妹说。
给出数字，然后说：“我想要一个在过去4个月中有大量活动的用户”
给出数字，然后又说：“我想要一个在过去5个月中的活跃用户数量...
假如我们不假思索地计算它们，它们将会被消耗殆尽。接了一个要求，还要问几个为什么？例如：什么是需要解决的业务问题？哪些数字是可以用来说明这个问题的呢？在我告诉你这些数字之后，你准备如何判断呢？总而言之，要抓住机会主动提出建议，与业务人员交流也是了解业务需求、分析思路的好机会，要善于换位思考，最好把取数的主动权掌握在自己手中，引导业务人员按照你的想法去做，不仅让别人觉得你是个靠谱的人，而且还能减少很多无效的取数，要知道，业务人员越是想不清楚需求，就越容易乱提，然后双方就在口径上纠缠不清，取数人员常常埋怨业务部门新人乱提需求，不懂基本规则，就是这个原因。
四、让你自己更深入地进行数据建模。
该模型原本是为了降低取数的成本，但是随着业务的发展，系统的变化，以及取数复杂度的增加，其可用性会越来越差。使用过程中可以尝试对模型进行一些优化，最直接的好处是提高提数效率和节省时间。此外，优化模型的过程，会养成我们深思熟虑的习惯，在这个过程中，不能只考虑业务，还要仔细考虑模型表应该属于哪个主题？放哪一层？选择哪种指标最合理？
在模型设计完成后，还需要对模型表建立以后可能的使用频率、所占的硬盘资源、文件数量、数据量大小进行评估，并生成该表的运行时间，以确定它是一种最佳方案，是真正节省了运算资源，是一种更方便日后计算的数据格式...
可将此作为切入点，做一些更长远的事情，如尝试对仓库的整体业务架构进行梳理，从整体上对仓库模型进行审视，从自身出发，对合理的地方进行梳理，对不合理的地方进行梳理，提升自己的模型架构能力。
五、结论。
总而言之，数据仓库涉及到的技术、业务和体系结构都是多方面的，我们可以从自己能够接触到的地方，逐步地提升自己，时刻保持独立思考的习惯，当团队遇到问题时，不要仅仅抱怨和责怪，多想想，如果事情是由自己来处理的，还有什么方法可以做得更好？
