下载掌阅APP，畅读海量书库
立即打开
小白： 老姜，听了以上的分享，使我对数据仓库有了更深入的认识。那么，作为数据分析师，我们的日常工作中会有哪些涉及数据仓库的内容，以及需要掌握多少数据仓库的知识？
老姜： 这个问题问得很好，直接涉及我们的日常工作。下面，回答一下这两个问题。
数据分析师日常工作中，有一部分内容会涉及数据仓库方面，也常常需要与数据工程师打交道。下面，谈谈涉及数据仓库的几个主要工作方向。
数据分析师在日常工作中，无论是做分析还是做挖掘，都需要对数据的定义及逻辑有一个清晰的认知。很多时候，下游指标的计算逻辑是我们为数据研发人员配置的，这就要求我们对数据底表的字段含义、计算逻辑、数据血缘非常清晰，不能出现模棱两可的情况。
因此，这里建议将核心数据的链路绘制成数据地图，主要涵盖表命名、表含义、流转关系、核心处理内容等，便于在日常工作中应用查看。
日常工作中，往往会有一些新数据的引入，比如前端增加了某些模块、公参，需要在现有日志字段基础上扩充；再比如，业务开展了某些活动，增加了活动数据，需引入数据仓库进行下游分析。此类情况下，数据分析师需作为数据研发与产品经理的中间人，从数据应用的角度出发，设计新数据的引入格式及需求字段，推动数据建设。
在这样的背景下，需要数据分析师充分了解数据逻辑，从源头开始设计所需内容。成为相比产品人员更懂数据、相比研发人员更懂业务的角色。
3.2节介绍过，数据仓库主要分为三个层级：数据接入层、数据仓库层、数据应用层。数据分析师的日常工作中，会涉及很多业务需求，对于偏应用层的数据表，如果给数据研发提需求处理，往往还需要等待排期。因此，很多数据分析人员承接了ADS层的数据建设并维护日常的任务调度。
日常数据指标发生波动时，数据分析师需要负责排查问题产生的原因。指标波动一般主要由两大类因素所导致。
其一，业务因素。此类因素导致的指标波动无须排查数据底层。
其二，数据底层Bug。其中包括很多种原因，例如ETL过程部分数据传输失败、集群出现问题导致部分数据丢失、字段出现异常格式导致解析出错等。
在遇到第二类因素导致的问题时，往往需要数据分析师主导，推动数据研发人员一同排查问题本质，这就要求数据分析师对于底层的数据逻辑非常清晰。 这里建议在问题排查完成后，对问题进行系统记录，并搭建监控看板，以提升未来同类问题的排查效率。
在这样的工作背景下，就需要数据分析师对数据仓库有一个全面的认识，虽然无须像数据研发人员一样精专，但对于整体的架构及数据流转仍需要掌握。具体有以下要求。
首先，需要对当前企业的数据仓库架构有一个宽泛了解，采用的是哪种技术选型、离线内容和实时内容如何做到融合、开发技术用的是什么。对于数据分析师，具体的技术细节无须精通，但至少需要了解数据仓库整体是如何搭建的。
在日常工作中，有时我们需要站在业务侧给数据研发人员提需求，为了保障提出的需求合情合理，就必须对上面的内容有所了解。
上面提及过，数据分析师的工作需要涉及数据应用及问题排查，因此这就需要对核心数据的流转过程烂熟于心，而不是浅尝辄止。需要花一些时间，梳理核心流程每个环节的代码，掌握各个字段的生成逻辑。
这一点，需要在入职初期抽出一部分时间来完成，这样可以大大缩减后续在数据应用上的成本，将更多时间花在更有价值的分析上。
要做好一个事情，先要深入了解该内容的规范，数据仓库也是一样，因为工作中会涉及很多这方面的事情，掌握数据仓库的搭建规范可以降低后续的应用及沟通成本。
数据分析师日常会处理诸多数据分析需求，涉及ADS层表及临时数据表的建设，因此，需要对表的增、删、查、改应用自如，并且，对于调度平台配置以及数据异常报警配置要“充分了解+熟练应用”。在入职初期，数据分析师往往需要和数据研发人员多沟通请教。
数据分析师的工作涉及很多方面，对于上下游内容均有渗透，因此需要努力提升自身能力。