还差半个月，我就入职满1年了。回想这一年，从一开始的生疏，到现在对各种需求的游刃有余，自己也算成长了很多吧。我很庆幸自己进入了一个很好的团队，同时也有一个很好的导师带我。
我上周在写转正总结的时候，总结了一下自己这快一年来做的事情，无非是：提数需求、报表开发、数提开发、日报推送、数据异常排查和原因定位、宽表建设等。其中，来自业务方的提数需求，应该占据了我日常需求的半壁江山吧。
我的工作内容和业务息息相关，工作中我所用到的技术栈不是很多，但是却经常需要和开发、前端和产品等各方人员对逻辑。老实说，和他们的沟通过程，不仅很好地锻炼了如何快速get到对方逻辑和判断他们逻辑能否行得通的能力，也让我的耐心有了很大的提高。我曾经有半个月很苦恼，因为那段时间，各种业务方同时来找你，明明事情也很小，问得我焦头烂额。不过现在我好像适应了，也没有觉得这种状况会让我苦恼。
我曾经也和组里的其他人沟通过，知道有的人很喜欢涉及业务，有的人却很讨厌去了解业务，只想做纯粹的开发；有的人也觉得自己作为数据挖掘工程师，却只是一个“SQL程序员”，只是天天在给需求方提数。这些疑惑，我也曾有过。可能因为我是文科生的原因，我还是挺喜欢了解业务的，而纯粹的开发可能对我来说有些无聊。至于第二个“提数工具”，这个问题，其实困惑了我很久。我很怕自己陷入这样一个死循环：因为天天做这种临时且没有技术含量的需求，自己实力并没有跟着工作时间的增加而提高，然后丧失了自己的竞争力。虽然现在这个问题我还没有完全解决，但是我也有了一点自己的思考吧！
作为数据从业人员，如果想“跳出纯粹的提数工具”这个怪圈，我觉得可以从两方面着手：一是工作上；二是自己下班后的学习。
工作中多进行数据沉淀
其实我现在因为对业务很熟悉，所以我现在每周的需求基本上都能提前一两天完成。后来我导师就和我说，我们现在不仅仅是完成每周的排期就可以了，完成这些需求之后，我们更应该进行思考，包括如何把这些临时性的需求固化下来，或者如果将这些临时性的需求加入到现有的宽表体系建设中，又或者我们现在做了这么多的报表和数提，需求方真的有在用这些吗？我们是不是在重复开发？
不仅如此，在很多的例会上，自己从大家的讨论中，我也慢慢明白：数据挖掘工程师进行数据沉淀、业务梳理、数据规整、数据质量建设等系统建设的重要性。因为公司的数据平台和系统早就搭建好了，后期的维护和完善是一个长期且必需的过程。而且，这些数据沉淀工作不是无缘无故发生地，它是根据实际的业务需求来推到。我们是不可避免要做这些临时需求，但我们也不能被这些临时需求牵着鼻子走。
数据沉淀的内容包括但不限于以下内容：
- 数据仓库的建设和完善：数仓和宽表建设是随着公司业务的发展而发展的，而它的建设是极其重要。以我司为例，宽表建设从全平台的订单和用户宽表，细分到各个业务领域的订单和用户宽表；各个业务的宽表，从订单和用户主题，逐渐扩展到获客、成本、券属性、财务、授信、开户、上报、商户等各个主题。而每一个宽表的开发和完善，都需要经过业务的梳理、逻辑的思考和数据的验证。
- 现有数据工具的监控和优化：这类工作的话，存在的主要原因是随着需求方内容的不断增加，一开始我们只是纯粹地在原有的代码逻辑上新增逻辑，导致运行时间过长，数据输出的时间越来越晚，或者代码根本跑不动。这个时候，就需要对整个需求进行重构和优化。
- 更高效的数据工具的探索：这一部分应该是最难的了吧，需要很有经验的数据分析师牵头启动。最近我们这边在做的包括：tableau数据推送、数据地图规划、调度治理等。
工作后有针对性地学习和复盘
这一块，我做的也不好吧。其实我知道自己应该要学的东西蛮多的，但是下了班我也没有咋看书了。希望以后自己能坚持学习吧！