从事互联网数据仓库工作好多年了，其中最大的感触就是数据仓库开发人员每天做的最多的工作就是为业务方取数。简单重复的取数工作，一方面很难让大家在技能上有提高，另一方面也慢慢的消磨了大家的积极性和意志，也让大家极没有存在感。
另外，在公司的整体架构中，取数这种工种很容易被替代，所以，也极不被重视。
那做为一名数据仓库的开发人员，该怎么反省提高自己？下面是我的一些想法：
1、首先审视一下自己的取数水平
1）保证自己写SQL的技能一定是没问题的，看自己是否能非常灵活的用SQL完成业务方提出的各种各样的关联的，分组的，随机抽样等等需求。如果这点做不到，那就要考虑一下是不是自己学艺不精，先从SQL练起，提高自己。
2）看看自己能否做到，自己负责的业务线，只要业务方一开口，基本就知道怎么取了。如果在取数的过程经常跟业务方扯皮，返工，就得想想是不是自己对业务理解程度还不够，而不是人家跟你过不去。
3）看看是否做到，自己负责业务线所涉及到的仓库的基础模型表的来龙去脉都了解清楚了。要知其然，知其所以然。
总之就是要形成自己的取数套路，形成自己的取数权威，让业务人员信任你。熟练的SQL技能、对自己所处仓库模型表的深刻理解，可以让你快速提数，节省出时间来思考，提高自己。
2、让自己在技术上更进一步
熟练使用SQL只是数仓开发人员的基本功，假设目前你的仓库开发是基于hive的，那么我们不仅仅要只会使用工具，更要能够驾驭它。
可以试着去看看hive的各个实现模块，可以从最常用UDF,UDTF源码看起；然后，了解一下hive的启动过程，内存分配；了解hive的编译过程，以方便我们对hive sql做优化；了解hive的序列化、反序列化机制。。。搭建起环境，调试一下各个环节，积极关注hive jira，及时发现hive的bug并解决。当然，我们也可以基于我们当前的业务，对hive做二次开发，让更高效的满足现在的业务。
如果用的是mapreduce计算框架的话，也需要去深刻理解mapreduce的计算模型还有hdfs。
在这个基础，审视一下当前的仓库平台，看是不是能发现一些可以优化的点，可以改进的地方。
3、让自己在业务上更进一步
主动参与一些分析，主动跟业务方沟通取数的目的。
有大量的取数是有一定难度的，业务部门往往事先没想清楚，比如，在取数过程中，我们会遇到这样场景：
业务部门小哥说：“我要一个过去3个月有活跃用户人数”
给了数，又说：“我要一个过去4个月内有活跃用户人数”
给了数，又说：“我要一个过去5个月内有活跃用户人数”...
如果我们不假思索的就给他们取数，那真的会累死。接到一个需求后，要多问几个为什么？比如：要解决的业务问题是什么？准备拿哪几个数来说明这个问题？我给你这几个数以后你又准备怎么判断？总之，要抓住机会主动提供一些建议，与业务人员互动也是理解业务需求和分析思路的好机会，要善于换位思考，最好将取数的主动权抓在自己手里，引导业务人员按你的想法去做，不仅让人家觉得你这人靠谱，而且可以降低大量无效的取数，要知道，业务人员越想不清楚的需求，就越容易乱提，然后双方就在口径上纠缠不清，取数人员经常埋怨业务部门新人乱提需求，不懂基本的规则，就是这个原因。
4、让自己在数据建模上更进一步
数据仓库模型本来的目的是降低取数的成本，但随着业务发展、系统变更及取数复杂性的增大，可用性会越来越差。我们在使用过程可以尝试做一些模型优化，最直接的好处就是提高提数效率，解放时间。另外，优化模型的过程，会养成我们深度思考的习惯，在这个过程中不仅仅要考虑到业务，也要精心的考虑这张模型表该属于哪个主题？该放在哪个分层？该放哪些指标最合理？
当模型设计出来了之后，还要评估该模型表建立以后可能的使用频率，所占的硬盘资源，文件数，数据量大小，生成这张表的运行时长，看它是不是最优的一种方案，是不是真正节省了运算资源，是不是更方便了以后的取数，是不是能保证以后出数据口径统一...
可以以此为切入点，做一些更长远的事，比如试着梳理仓库的整体业务架构，从整体上来审视仓库的模型，从自己的出发点，整理合理的地方和不合理的地方，提升自己整体的模型架构能力。
总的来说，数据仓库涉及到的技术、业务和架构是方方面面的，我们可以从自己能够触及的地方，一步一步脚踏实地的来提高自己，要时刻保持独立思考的习惯，当团队遇到问题的时候，不能只是抱怨和指责，要多想想，如果这件事让自己去处理，又有哪些办法能做的更好一些？
