数据分析通常是这样组织的：这里我们有存储库的开发人员，而这里有分析师。 在DWH（数据仓库，存储）中，他们可以使用SQL，而我们的分析师可以使用Excel。 如果我们需要分析某些内容，请去分析员那里，他们去找数据，然后去DWH那里去找数据。 这似乎是合乎逻辑的。 许多人认为这是正常的分工。 在本文中，我想传达一种想法，即这种分工是错误的，并且会大大降低整个数据分析过程的效率和生产率。
关于分析问题的典型工作周期如下所示：
- 企业提出了一个问题，并要求答案。
- 分析师正在与企业讨论需要做什么。
- 分析师意识到，他们希望从他们那里获得业务，并了解他们在数据中的大致需求。
- 分析师在DWH中编写查询以获取数据。
- DWH接收请求，读取，询问，澄清，检索数据并给出。
- 分析人员了解到，他们并没有采取一切行动或误解了他们，而是再次将请求写在DWH中以获取数据。
- DWH接收请求，读取，询问，澄清，检索数据并给出。
- 分析人员了解到，他们并没有采取一切行动或误解了他们，而是再次将请求写在DWH中以获取数据。
- 重复步骤7和8
曾经，DWH的家伙说他们无法提供数据或不准备处理分析师的如此多的请求。 作为回应，分析人员开始以某种出色的方式将数据从DWH收集起来。 在那里，他们根据从DWH可以“不战而胜”的结果，开始尽可能地收集ETL流程。
结果是：
- DWH不能充分满足消费者的需求（就DWH而言，用户似乎不知道他们想要什么）。
- 分析师开始编写不良的ETL流程，并根据其数据量创建伪DWH，但没有保留，访问控制，性能低下等问题。
- DWH与分析师的互动受到影响，因为 一个人不该死的事，第二个人不懂通俗的“鸟语”。
- 获得业务问题答案的过程被延迟了，因为现在数据处理过程是DWH之外的一堆手工工作。 为什么我们要构建DWH（除了单个存储库之外）？
- 业务问题陈述中的微小变化从几乎为零开始了数据分析周期，因为 DWH不会再显示出灵活性，分析人员也不会在新的环境中获得数据。
有什么解决方案？ 如果要摆脱DWH和分析师之间的互动问题，那么必须使DWH和分析师的能力更紧密。 结合了这些能力的人可以称为数据分析师。
这样的全栈数据分析员应该做什么？
- 使用原始数据源，了解数据存储的工作方式。
- 要根据数据内容，要添加的数据以及如何进行方法上的处理来制定需要在存储库中进行哪些更改，以便铁杆DWH开发人员可以实施它。
- 了解业务需求，讨论需求，并帮助您的客户（内部或外部）提出问题和解决方案。
- 能够设计分析解决方案，即 了解如何解决问题，需要什么数据，需要“发明”什么，需要做出什么假设
- 能够可视化结果并向客户报告（内部或外部）
- 为了能够进行“可重复的”研究，该分析可以始终对相同的数据进行重复并获得相同的结果。 为此，您需要能够使用R / python或允许您正式化分析过程的系统。
如果您将一项技术和分析能力结合在一个分析中，那么您将获得一个真正完整的员工，可以解决端到端问题。 这对于分析任务非常重要，因为 只有这位分析师才知道他在做什么以及为什么。 将人员分为“分析”人员和“处理数据”人员，导致以下事实：每个员工都被禁用：分析人员没有双手，因为 无法大规模获得和处理任何东西，数据工程师一如既往地“毫无头脑”。 他不认为它将如何使用以及存在什么假设。
分工非常重要，但必须在稍微不同的平面上进行。 分析人员必须能够获得他进行分析所需的一切，数据工程师的任务是建立可以有效地在分析人员感兴趣的任何方面提供数据的系统。 对于数据工程师来说，这意味着数据应该以一种相当灵活的形式存储，但同时又以一种方便使用的形式存储：部分进行非规范化，部分通过多维数据集访问，部分进行预聚合和计算。
而且，如果您找不到自己的完整堆栈分析师，那么至少在分析团队中加入Data Engeneer，这样就不会将处理数据的能力从分析转移到外部服务。
支持从google adwords API检索数据不是数据分析师的职责，而是Data Engeneer的职责是编写一个选择来获取上个月的收入数据。