下载掌阅APP，畅读海量书库
立即打开
具备一定规模的互联网公司一般会设立数据分析师岗位，由其负责与业务方（运营人员、产品经理和管理层等）对接，进行数据提取、业务分析、业务预测等工作。但在实际工作中，经常会出现需求管理混乱、对接沟通反复、成果交付形式单一、工作成果无法沉淀与传承等问题。本章就来介绍作为数据产品经理，我们如何利用工具化思维分析上述问题的成因，并建设一个自动化数据分析平台来优化数据分析流程，以提高工作效率和交付能力。
使用该平台，数据分析师可以 在线提取数据、分析数据、实现可视化并自动将数据发送给业务方 。数据分析需求的管理也是本平台的一大亮点，它将数据分析的工作流程串联起来，整合企业OA，加入自动化任务功能，把需求的输入和输出紧密联系起来，从而降低人力成本，提升人力资源效率。
下面将先对数据分析业务的现状进行梳理和分析，找出问题，接着按数据应用链条中的各个岗位角色进行需求分析，最后进行自动化数据分析平台的设计。
数据分析和数据的业务实践是一项跨团队、跨职能的协同工作，需要流程和制度来保障其有序进行。现实中，需求产生和调整的过程中缺少记录会导致目标失控，业务接手人需要从头探索，造成资源浪费，并导致数据分析师与业务方沟通需求费时、交付的数据无法满足场景需要、运营日报的交付费时费力等问题。
数据分析是一项工程，是一个漫长的过程，从问题的提出到方案的确定，再到分析工作的实施、得出结论，其间还可能有无数次反复的数据探索、方案重新讨论。 在没有项目管理及系统支撑的情况下，这个工作可能会失控，也有可能偏离目标。
业务的发展是一个演进的过程，中间会进行无数次策略调整，如果没有系统作为工具，每次调整的分析过程和数据依据很难沉淀下来，更难以形成方法论。
案例： A公司为一家处于快速上升期的互联网公司，数据需求量大，但数据分析师流动频繁。新到岗的数据分析师接手分析业务时，希望了解业务的历史数据分析文档、数据分析思路及常用SQL模板，但由于之前没有完善的文档管理，只能从零开始学习和理解业务，自己探索分析思路，重新编写代码。分析过程和数据依据没有沉淀下来，造成了很大的资源浪费。
运营数据日报、周报是运营人员的周期性工作，旨在向参与者特别是企业管理层通知和汇报项目的运行情况。运营人员或数据分析师一般会先对每日产出的数据进行格式处理、指标计算、排版美化等，之后再发出。这些重复性的工作重要但烦琐，经常会消耗他们大量的时间。
还有一些监控类的数据需求，如新业务上线，需要运营人员每天甚至每小时关注某项指标的变化，以及时调整运营策略。如果没有主动消息推送的功能，运营人员就需要不停地刷新来查看数据。
此外，一些简单的数据分析工作其实不需要人工参与，使用简单的逻辑判断就可以得出结论，这也是数据分析师的一个重要需求。
以上这些问题都会让数据分析师和运营人员花费大量时间去做简单的重复性工作，而没有更多的时间思考业务，致使业务无法创新，个人发展受到影响。
案例： 小A是公司某项目的运营人员，需要每天发送项目的运营数据日报。数据日报的基本内容是一些项目指标的客观数据及一些简单的分析，小A将这些内容进行数据可视化后通过邮件发送给团队成员及管理层。由于没有实现自动化，他每天需要花费约两个小时整理日报，而他还需要整理项目周报、月报等。数据整理工作占用了他大量的时间，他也因此被同事们戏称为“表哥”。
为了保证数据挖掘和分析工作的有效推进，企业对数据分析岗位采取了不同的整合方式，一般来说有以下几种。
1）有独立的数据分析部门的，采用 接单模式 。有业务数据需求时，数据分析部门会分派数据分析师进行对接，从项目的前期到整个数据分析生命周期结束全程参与。这种模式的优点是可以灵活配置人力资源，但缺点也很明显：数据分析师有点像独立第三方，由于服务对象不固定，无法深入理解业务。
2）数据分析师岗位设立在运营部门的，采用 贴身服务模式 。数据分析师和运营人员共同负责一条业务线，能够实现优势互补，数据分析师也会全身心地投入到项目中，从而全面理解项目。但这样也有缺点，如果公司存在多条互相交织的业务线，那么会有多个属于这种模式的数据分析师，他们都只了解自己所负责的业务线，无法从公司整体出发进行全局思考。
3）数据分析师接受双线管理，即采用 双线模式 ：数据分析师岗位设立在数据分析部门，但同时受业务负责人的绩效考核。双线模式可以利用制度创新的优势，既能实现数据分析师的有效流动和与业务的高度匹配，又能让数据分析师为业务提供长期、稳定、全面的支持。
一般流程是：运营人员提出需求，数据分析师与运营人员讨论需求并确定分析方案，数据分析师实施方案并输出数据与结论，运营人员进行验证。运营人员如果有疑问，会和数据分析师查找问题，重新讨论分析方案并确定新方案，直至解决疑问。
在这个过程中，以上的不同组织架构可能会带来不同的业务流程。例如：如果数据分析工作由数据分析部门承担，则数据分析会以类似外包的形式进行，业务方发起需求时会受数据分析部门的内部管理制度、资源排期等因素影响；如果数据分析师同在业务部门，则数据分析师可能会经常遇到同质需求，无法更好地从平台全局出发分析业务。
案例： A公司为每个业务设有专职的数据分析师岗位，但由于各业务的复杂度、运营节奏不同，数据分析师的工作量时多时少，加之公司没有整体的数据分析流程，无法进行数据分析资源的统一调度。
无论采用以上何种组织架构和工作流程，若没有相应的系统作为支撑，就很难实现从过程到结果的有效管理。如何保证资源调度的有效性，同时保持数据分析师的独立性，在讨论系统工具时还需要从人员组织架构和制度流程层面进行重新思考。
数据交付包含数据分析师按照分析方案得到的数据表格、可视化图表、分析结论等，有时还包含分析业务背景和分析过程的数据分析报告。总的来说，交付物往往存在交付不完整、交付形式不能满足需求、不能周期性交付等问题。
1）交付不完整 。数据分析师与业务方反复确认的过程会涉及多次数据发送，最终确定一个交付稿。实践中，很多数据分析师会使用企业内部的即时通信工具交付过程稿，而以邮件形式发送最终的交付稿。这样，其他分析思路和结果并没有体现，不容易探究最终方案的形成原因，也无法将这些分析思路沉淀下来。
案例： 数据分析师小A负责对某业务的用户留存率下降原因进行分析。在向运营人员了解了近期的运营动作后，他制定了一个数据分析方案。在分析过程中，他又与运营人员讨论了其他几个分析方案并实施，最终选择了一个大家比较认可的方案作为最终交付。但业务方按交付结论对业务采用运营手段进行干预后发现效果不佳。此时运营人员想到之前在做数据分析时得出过更符合当前结果的结论，但由于没有规范的过程文档管理，此方案的文档未保留，无据可查。
2）交付形式不能满足需求。 业务方对于交付形式也有一定的需求，比如需要进行一定的可视化，需要定期收取，需要存在变量的数据（如每天收到前一天的数据），数据可分发给其他同事，等等。多样的交付形式可以大大提升数据的使用效率，但并不是总能得到很好的支持。
案例： A公司新上线了一项业务，在上线前确定了此业务的几个核心指标，并要求了解这些指标每小时的变化。数据分析师已经完成了SQL脚本的编写，但由于公司没有对自动化数据交付功能的系统支持，他只能每小时运行SQL脚本并将数据发送给业务方。
3）不能周期性交付。 对于一些非高频数据，用户希望仅在需要的时候主动获取；对于一些周期数据，希望可以订阅、取消收取等。但很多系统并不能很好地支持这些功能。
案例： A公司开发了一个社交App，每次发版后都需要了解Android和iOS系统的更新比例。运营人员无法自主获取此数据，需要找数据分析师通过数据查询获取。
以上总结了运营人员和数据分析师在协同使用数据的过程中产生的一些流程问题和诉求。上述案例中，数据在经历了一系列庞大的系统工程后最终被交付到用户手中，如同在经过千万道工序后生产出一件优质的商品，采购、物流、仓储环节都很完美，但最终交付到用户的过程却不尽如人意。我们要解决的就是最终数据的使用体验问题，这也是我们建设自动化数据分析平台的初衷。
接下来，我们分析一下在数据应用链条上的各方的诉求。
通过上文的问题和现状分析，我们确定了通过一个在线系统来解决这些问题。这个系统用来承载数据分析工作流程，包括 数据分析需求的发起、数据需求的承接、代码的编写、数据的调度、数据的处理、数据的验收交付 等各个环节。本节从数据分析工作流程出发，结合数据工作中的各个角色做一下需求分析。
对数据分析的工作流程进行梳理后得到图1-1。
图1-1 数据分析工作流程
具体流程是：需求方（一般为业务运营人员）编写需求文档，发起数据分析需求，与数据分析师讨论和确定需求；数据分析师接收需求并进行排期，按排期处理需求，完成后交付给需求方一版数据集，由需求方验证。如有疑问，需求方会再与数据分析师讨论并调整；如无疑问，需求方对数据集进行分析和总结，形成报表（如有需要可向其他相关人员分享）。
在企业里，数据的需求方一般可以分为两类：业务运营人员和公司决策人员。业务运营人员是数据需求的主要发起方，他们的主要需求如下。
在数据流程上，能够随时发起需求，将需求清楚地传达给数据分析师并得到及时响应，且后续环节流程明确、操作简单、可视化，方便自己调整工作节奏。
在交付阶段，能够验证数据，加工数据集，进行更多的数据探索操作。有数据分析能力、掌握数据相关技能的运营人员可以进行与数据分析师相同的操作。
在交付形式上，交付物不需要自己再进行大量的本地操作（如使用Excel整理数据和进行可视化），运营日报、周报能够自动化交付，还可以将数据快速分享给相关同事。
公司决策人员一般为运营负责人（如运营总监）和公司管理人员，他们希望定期收到业务的核心数据，自己在讨论业务时能够方便地读取数据，对数据进行探索分析。
数据分析师是本平台的核心用户，他们在处理需求时需要一个流程化的单据来帮助自己整理工作内容，管理优先级，使业务流程清晰化。他们希望：在取数阶段，有丰富的源数据可用，能够创建临时数据表来存储分析数据，能够将自己编写的SQL脚本和数据处理脚本放在线上；在代码编写过程中，能够进行版本管理和测试；在交付数据时，能够线上化，无须导出线下文件，需求方可以自主使用、下载和订阅数据。
这里提到的产品经理一般指数据产品经理。作为数据仓库建设的负责人，他们希望发挥数据的最大价值，让用户能够顺畅地使用数据，为业务提供支撑。产品经理也有非常多的数据使用场景，如调研数据仓库信息、监控数据指标、巡查数据质量问题等。 产品经理以数据分析师身份来使用本平台。
打造数据价值工具也是产品经理的主要工作，建设一个高效的数据分析平台能够更好地体现产品经理在企业数据体系中的价值。
一些企业的 开发人员以数据分析师身份来使用本平台 ，他们会配合数据分析师做一些数据提取、数据源建立、关系型数据库管理的工作。如果将这些工作系统化，开发资源将会得到释放。利用开发资源开发一个有业务价值的平台，更能体现技术价值的放大作用。
本节分析了企业中各个岗位对于数据分析工作的基本诉求，这些分析可以帮助我们创建功能更完善、可用性更强的业务系统。接下来，我们开始自动化数据分析平台的设计工作。
做足了需求分析，本节正式设计和搭建平台。平台的设计遵循顶格规划、必要设计、分期实施的原则。对于一个新业务平台的分析，不能只着眼于解决当前问题，还需要 考虑较长期的业务发展，实现较全面的场景覆盖，为平台的发展留下想象空间 。在设计时要分清枝叶，着重满足当前迫切的需求，在实施过程中，分拆出一个MVP（最小可行产品）快速上线，快速迭代。
本平台的功能分为底层功能和应用功能两部分，底层功能提供数据源管理、数据集管理、账号权限等系统最底层的功能，应用功能提供数据需求单、数据分析单、自动任务调度、数据探索工具等实用功能。平台的功能模块见表1-1，后文将一一详述这些功能模块的用途和设计。
表1-1 自动化数据分析平台的功能模块
数据需求单是本平台的核心业务单据，所有数据需求的发起都会生成数据需求单，后续的工作进展也会引起数据需求单状态的变化。数据需求单的主要内容见表1-2。
表1-2 数据需求单的主要内容
数据需求单是本系统的业务流程管理系统，是数据分析工作的主流程，不仅解决了前文分析的需求管理方面的诸多问题，让需求方和数据分析师之间的协同更高效，而且作为公司数据资产的一部分，将在知识积淀、项目复盘、业务传承、绩效管理方面发挥重要作用。
下面根据业务流程，结合需求单的状态，说明一下需求单的业务流转情况。
1）待接单。 这是需求单创建后的默认状态，此时等待数据分析师领取需求单。需求单可以由数据分析部门负责人根据各个数据分析师的专长和工作排期来分配。
2）待排期。 此时需求已经分配给了指定的数据分析师，数据分析师与需求方就需求进行讨论，确定需求、期望交付时间等内容，最终将确认结果写到需求单中。
3）待处理。 此时排期已经完成，确定了交付时间，数据分析师还没有开始处理需求。
4）分析中。 数据分析师正在进行数据分析工作，在平台上编写代码，撰写分析报告。在此阶段，需求方可以参与进来配合数据分析师的工作。
5）已交付。 数据分析师交付了一个版本的数据后，需求方对交付数据、分析结果进行核对和验证，过程中可能需要开会，让数据分析师做数据分析报告。如调整了分析策略，数据分析师会再次进入分析中状态，如此往复，直至完成整个数据分析工作。
6）已完结。 整个工作已经完成，由需求方或数据分析师操作完结需求单。
不难发现，状态的命名基于的是下一步的操作，而不是当前已经做了什么，这样做的好处是能让各方都清楚下一步工作是什么。
在权限方面，可以对所有人开放需求发起功能。发起需求时可以指定接单人，也可以允许自己接自己的单、多人接同一个单等，以让整个业务体系更加灵活开放，为所有人特别是非数据分析师赋能，不会因系统化而让业务受到掣肘。
案例： 业务运营人员小A之前发起数据需求时，需要给数据分析负责人发邮件，并在邮件中写明需求背景、诉求及期望时间；有了自动化数据分析平台后，他可以在平台上创建数据需求单，只需要写明需要的数据及分析内容，并附上之前类似需求的数据分析单链接。数据分析师B对需求单中的项目比较熟悉，于是接单开始工作，按照数据分析单流转，最终在平台上完成了任务交付。整个过程对运营部门负责人和数据分析负责人可见。
数据分析单是在数据需求单的基础上创建的数据分析单据，在其上可以完成数据提取、数据分析、数据可视化、数据交付等工作。数据分析师接单后，创建一个数据分析单，开始数据分析工作。数据分析单中的部分内容见表1-3。
表1-3 数据分析单中的部分内容
（续）
一个数据需求单支持多个数据分析单，便于多个数据分析师同时分析同一个需求，对一个需求实施多个分析方案。如图1-2所示，在数据需求单中可以创建多个数据分析单对数据需求进行分析。
图1-2 数据分析单界面
接单人在数据需求单下创建数据分析单，进入数据分析工作阶段，数据分析师的所有数据分析过程均在数据分析单上完成。对数据源粗加工得到的数据称为“数据集”，数据集是我们做数据分析的“食材”。通过处理得到结果数据、可视化内容、分析结论后，就可以进入交付阶段了。在下文的数据分析过程中，我们将详细介绍数据分析单的功能。图1-3给出了数据分析单的内容构成。
图1-3 数据分析单的内容构成
案例： 运营人员小A发起了一个数据分析单。由于需求量较大，数据分析师B和C同时接单，并各自创建了数据分析单开始工作。他们在数据分析单上编写SQL脚本，得到数据集后，使用Python脚本对数据进行了处理，还增加了数据可视化，最后通过邮件交付数据。
数据分析单的操作为本系统的核心功能，所有的数据分析工作都在数据分析单上进行。产品经理在做产品设计时应该与开发人员、数据分析师深入交流，将从数据源中查询出数据、对数据进行探查处理、编写数据分析代码、输出可视化图形、撰写分析报告、指定数据交付方式等分散的功能集成在一起，这些功能对应的环节形成完整的工作流程。如果缺少其中某个功能，产品的可用性会大打折扣，因为对数据分析工作流程中各个环节需要的功能的有效整合关系到系统的成败。
数据分析单操作的功能组成和流程如图1-4所示。接下来我们结合业务场景对上述数据分析单操作中的一些功能进行详细介绍。
图1-4 数据分析单操作的功能组成和流程
数据分析过程分为以下几个步骤。
1）获取数据集。 通过SQL脚本、Python脚本从数据源获取数据后，可以利用界面化操作或者Python脚本将其处理为数据集（见图1-5），这时需求方就可以自主在数据集上进行数据探索了。如果还需要进一步处理，可针对数据集编写SQL或Python脚本。
2）数据集处理。 可以开发界面化的数据工具来对数据集进行处理，但务必让该工具支持Python脚本。Python是数据处理的利器，可以实现数据清洗、数据筛选、数据形状变换、数据可视化。
图1-5 获取数据集功能示意图
3）数据分析。 对处理好的数据进行数据分析和可视化，从而得出结论（还可以利用Python的库包进行数据建模、机器学习等操作），这是数据分析师的必备技能。本平台对Python脚本的支持可以让数据分析师尽情发挥。图1-6所示为对数据进行可视化分析。如果需要其他语言（如R），可以集成。
4）数据交付。 产生最终的数据结果并得到数据分析结论后，进入数据交付阶段。根据前期的需求沟通结果，通过在线配置设定交付形式，完成数据交付。
案例一： 运营人员小A会编写一些简单的数据处理脚本。他首先在自己创建的数据需求单上创建了一个数据分析单，接着使用数据分析师编写的SQL脚本查出数据集，最后编写了数据处理脚本。后续需要此数据时，他只需执行此数据分析单便可得到想要的数据。
图1-6 数据分析功能示意图
案例二： 数据分析师小C以往的工作流程是，接到需求后，首先在公司大数据查询平台上使用SQL脚本导出数据集，然后使用Excel做些数据透视和数据可视化工作，最后通过邮件将数据发送给需求方。使用自动化数据分析平台后，她通过创建数据分析单对接需求，在分析单中在线编写SQL脚本，产出数据后，用几行Python代码就完成了数据处理和可视化，最后设定通过邮件将数据发送给需求方。需求方下次需要此数据时可以自主执行此数据分析单，并接收数据。
在数据分析单中首先需要有一个数据源。数据源丰富多样，一般包含以下几种。
本地数据文件 。本地数据文件主要是由用户自己上传的数据文件，可以是CSV、Excel文件，也可以是SQLite数据库文件等，通常为业务沉淀数据、配置数据等。例如过去一年每天的订单量，由于需要做数据同比，为了缩短查询时间、提高效率，可以将数据沉淀到数据源里。也可以将从数据仓库中查询取到的数据集保存为本地数据文件。
关系型数据库 。将从数据仓库查询取到的数据存入关系型数据库，用作数据探索，允许用户在此库中创建表来承接查询结果。可以将数据集纳入关系型数据库，还可以每天定时将业务数据同步到关系型数据库中，作为数据源来解决数据需求。
大数据数据仓库 。对接企业级的数据仓库，由Spark、Hive、Impala、HBase、GBase等引擎提供SQL语句查询。
外部数据 。利用外部数据，由第三方公司提供接口，传入一定的参数，查询后返回结果数据，流转到数据处理流程中。
爬虫采集数据 。编写爬虫脚本，利用HTTP访问获取指定页、接口的数据，然后流转到数据处理流程中。此功能解决前端业务监听等需求。
丰富的数据源给了平台处理能力想象空间。试想一下，在公司的所有数据都接入这个平台后，所有数据分析相关工作也都会迁移到此平台上，成为推动平台持续建设的强大动力。
在权限方面，可以对数据源设定精细的权限，以保护公司数据资产。例如：关系型数据库、大数据数据仓库可以细化到表级别，必要时可以到字段级别，视公司的数据规模和安全策略而定。
企业一般会建立一个大数据仓库，并由专门的数据产品经理负责建设。在建设数据仓库时，按照大数据分层理论逐层聚合，形成不同层级的数据库，每个数据库中包含不同主题的数据表。这些数据都需要接入自动化数据分析平台，数据分析师会利用SQL对这些库表进行查询来获得数据集。数据仓库建设的内容可以查阅相关图书，这里简单介绍一下典型的分层方法。
操作数据层（Operational Data Store，ODS）。这一层原封不动地承接从业务流转过来的原始数据，包括从业务库同步过来的业务数据、从外部采集的数据，如前后端埋点、第三方接入数据等。当然，并不会同步业务库中的所有字段，而会根据实际业务需求进行选择。此外，还会对数据进行脱敏处理。
数据明细层（Data Warehouse Detail，DWD）。这一层解决数据质量问题，以一定的主题对ODS中不同的表进行加工清洗，建立一个稳定的、业务最小粒度的明细数据。这是数据分析师用得最多的数据层。
数据服务层（Data Warehouse Service，DWS）。这一层对DWD做了聚合，如按时间（按日、按月）、按用户等维度，与其他表联合加工出更多的同维度信息，使得一个主题的数据量大大减少。
数据集市层（Data Mart，DM）。这一层面向应用，表与表之间不存在依赖，基本与最终可用于数据分析的数据集差不多，可以存储在关系型数据库中。
企业一般会用Hadoop生态套件处理数据仓库分层工作，并利用Spark、Hive、Impala等查询引擎对外提供服务。套件也有专门提供的SQL管理工具，图1-7所示为Hue提供的SQL查询功能，可以参考集成。如需要SQL审计、库表权限等功能，可以自主开发SQL查询平台。
可设计为数据仓库支持多个SQL查询数据，提供一个输出接口，如{分析单号}-sql-01、{分析单号}-sql-02，然后利用Python脚本读取这些结果数据，再进行汇集处理，最终形成数据集。可以自动生成一个SQLite数据库文件存储这个数据集，也可以将它存入内存，等待下一步处理。如果需要长期自动更新，可以存储在关系型数据库（如MySQL）中的一个数据表里，每次自动更新时追加新的数据。完成数据集的创建后，进入数据探索阶段。
图1-7 Hue数据查询界面
这里的底表是指承接数据集的数据表。在本平台中，关系型数据库是数据集存储的主要方式之一。关系型数据库还可以作为数据源应用到下次的数据分析中。对于周期性需求，需要考虑数据的追加机制。我们可以提供在线创建和管理数据表的功能，同时在创建表时增加相关的配置。一般按承接数据的维度设置索引，如果遇到同索引的数据，可以设置为覆盖原数据还是忽略。当然，对于不同索引的数据一般会执行insert操作。
可以提供一个执行建表SQL语句的界面化操作工具，也可以提供一个界面来完成这项工作。图1-8所示为phpMyAdmin提供的MySQL在线创建数据表工具界面。
为了挖掘数据集所代表的业务趋势信息，我们需要进行一些数据探索，如通过分组、排序了解数据的分布情况。在进行数据探索时可以借助工具，市面上有许多数据探索工具，如Tableau、Power BI、DataHunter、Quick BI等。为了通过数据找到规律，对数据集进行随心所欲的筛选、聚合、分组、计算、可视化，这是一项非常重要的工作。在获取到数据集后就可以进行这项工作了。
可以集成第三方智能BI多维分析工具，供运营人员分析使用。通过接入成熟的开源数据探索工具，可以减少重复开发，加快产品化进程。这里推荐3个常用的开源工具，分别是Superset、Metabase和Davinci（达芬奇）。前两个是用Python开发的，最后一个是用Java开发的。图1-9和图1-10分别为Superset数据探索示例、Superset官方数据看板示例。
图1-8 phpMyAdmin MySQL在线创建数据表工具界面
图1-9 Superset数据探索示例
图1-10 Superset官方数据看板示例
可以将数据探索的结果数据配置成一个BI报表，分享给其他人查看。
案例： 运营人员小A想从多个维度（性别、地域、使用手机型号等）了解自己所负责业务的人群分布情况。在数据分析师通过SQL查询取到明细数据集后，小A利用在线数据探索功能自行按不同维度进行了多次分析，最终完成用户画像分析，并将分析结果分享给其他同事。
很多需求为周期性的，需要每天、每周查询数据，如果系统能够自动执行数据查询并汇集为数据集，再对数据集进行聚合计算，形成可视化，最后对数据按建立好的模型输出分析结果，那么将会大大节省数据分析和数据使用环节的人力资源。还有一些项目的日报、周报、月报，如果能交由系统自动完成，将会把运营人员从“表哥”“表姐”的身份中解放出来。
Linux系统有一个crontab服务，该服务可以利用crontab命令让系统按规定的周期自动执行脚本，从而实现自动化重复执行操作。Cron表达式有着丰富的表达能力，能够适应各种时间表达需求。图1-11所示为Cron表达式语法格式。
图1-11 Cron表达式语法格式
以下为部分示例，表达了实现自动调度的周期。
我们设计一个自动任务调度单来完成这项工作，该调度单中的部分内容见表1-4。
表1-4 自动任务调度单中的部分内容
调度单在需求单下创建，一个需求单下可以创建多个调度单。在调度单中填入Cron表达式以确定调用周期。可以填写多个表达式，让周期设定更加灵活。需要为调度单设定执行的数据分析单。在我们的设计中数据分析单已经非常灵活，数据分析师可以发挥想象，实现非常多的功能。
由于要实现自动化数据分析，我们需要考虑在数据分析过程中数据交换的依赖关系。例如：从源数据中查询的多个SQL语句要有一定的顺序，不能同时执行，否则会让处理脚本报错。数据集生成后才能进入数据分析过程，数据分析过程完成后才能进行数据交付。考虑到测试工作的需求，在调度单上有必要增加一个手工执行的功能。
此外，还有一些变量问题，比如各个SQL语句中的日期。在编写SQL语句时，如果要查询截至前一天的数据，我们会加where条件，如where day＜ 20220801，其中20220801为当天的日期。如果写死，每天会得到一样的结果，而不是我们需要的每天截至前一天的数据。因此就要在SQL语句中设计一个变量的表达方式，来表达这个例子中当天的变量。比如where day＜{{today|YYYYMMDD}}，其中双花括号代表了一个日期及格式，today就是任务执行的当天。如果想表达前3天，可以用{{today-3|YYYYMMDD}}。还有一些文本类型的变量，在填写SQL语句时增加一个变量输入框进行赋值，用SQL语句来进行调用。这方面的设计可以与开发人员共同商定。
案例： 数据分析师小C需要每周一、周二、周三发送某项目的数据。她在数据分析单中编写的SQL语句将数据查询日期设置为变量{{today-1|YYYYMMDD}}，即执行截至前一天的数据，并创建了自动任务调度单，Cron表达式为008？*MON-WEN。系统会自动在每周一、周二、周三的早上8点发出数据邮件。
数据交付会涉及数据的交付形式。自动化平台的优势体现在可以满足实际工作中的众多交付场景，在交付设计上一定要结合公司的现行制度按照优先级提供支持。根据之前的设计，我们的自动化数据分析平台有以下交付方式。
在线报表 。需求方可直接在数据分析单上查看数据，也可重新对数据集进行探索，生成自己的个性化报表。
数据文件 。将数据集或数据探索结果下载到本地，一般用于线下的本地二次加工。不过有了自动化在线平台，这个需求会大大减少。
邮件 。邮件是非常典型的数据交付方式，邮件中可以包含正文数据表格、正文可视化图片、Excel附件、交互式的可视化HTML页面附件等。
短信 。短信适合接收一些核心数据、监控数据、预警数据，需要利用账号体系中的用户手机号码，需要考虑要不要设置勿扰时段。
App通知 。如果有内部办公App，可以考虑通过该App的推送体系对一些预警数据进行推送。
IM通知 。企业内部办公用的IM工具，如钉钉、企业微信等，都开放了聊天消息、群消息通知的推送功能，可以将数据和可视化图片推送到IM工具上。
另外，以上交付方式的接收人可以由需求发起人管理。比如新同事需要通过邮件接收某个数据通知，需求发起人可以将其加入交付的邮件接收人列表中。其他人可以订阅周期性调度数据。如果企业对数据权限管理严格，可以增加一个交付接收的在线流程。
需求方可以将数据分析结果分享给指定的人在线查看，也可以将数据分析单的交付报表整合为BI报表，形成一个完整的BI，从而放大数据分析工作的成果。
案例： A公司使用钉钉作为工作IM工具。某个业务上线后，为便于监控业务的运行情况，该公司在自动化数据分析平台上设置了定时数据发送功能，可每小时将该业务的PV、UV、交易额发送到钉钉中的公司运营群里。
一个完整的账号体系由以下两方面组成。
账号信息 ：包含用户名、用户密码及用户辅助信息（如手机号、职级信息等），用在系统的业务流程中。
权限系统 ：对有必要做权限管理的功能点设立权限，无权限者无法访问和操作；多个权限组成一个角色，每个账号可以分配几个角色。
在账号信息方面，由于涉及的是内部系统，因此建议与企业内部的员工账号打通，这样可以方便地获取员工邮件、手机号等信息，将登录验证交由公共模块完成，从而保障安全性。
在权限系统方面，对有必要做权限管理的功能点设立权限。例如：对部分数据源设置使用权限；设置只有需求发起人才能查看数据分析单，其他人想要查看，只能通过需求发起人的分享。数据分析操作的相关功能可以开设给运营人员、产品经理，这样我们抽象的是系统角色，而不是实际的工作岗位。
对于账号的管理，设立一个系统管理员角色，开统一管理权限，后期可完善权限申请审批流程。
本节全面介绍了系统的架构及各项功能的细节，解决了之前提出的业务难题。当然，系统不能解决所有问题，但系统化是解决问题的一个重要思路。将线下业务系统化的目的是提高企业效能，系统也需要跟随业务不断进化。
相对于一般产品来说，本系统的设计是一个专业化程度较高的过程，需要产品经理既对数据的整个链路相当了解，又善于观察业务中出现的各种问题，研究形成原因，提出优化方案。
本节就自动化数据分析平台建设中的常见问题做一下解答。
大多数业务需求会有一个主要的需求方。比如运营活动，运营人员承担着相应的业务增长压力，而业务的增长将在运营活动中实现，因此运营人员自然而然地成为运营活动的需求方。回到本项目，对于一个流程及工具项目，似乎数据使用方（如运营人员）和数据提供方（数据分析师）都可以作为需求方，不过我们不妨换个思路， 数据分析流程和数据交付是公司数据体系建设的一个重要工作节点，补足这部分才能让数据发挥更大的价值 。因此，笔者更希望由数据产品经理承担起需求方这个角色，通过收集各方需求，构建一个用户体验流畅的平台。
首先，本系统涉及的人员较多，要了解这些人员的工作内容和工作流程，需要做大量的调研工作。
接着，需要对调研到的需求进行分析，特别是 重新对工作流程进行规划设计，并与各业务方达成一致 ，其中需要做大量的沟通工作。
最后，在产品设计阶段，需要全面认识数据的流向，并理解相关技术在平台中的应用。
这三方面都需要花费数据产品经理大量的时间。
本项目的产品经理需要掌握的技能分为两方面：一是对数据分析过程的理解，二是对相关技术的了解。在数据分析工程方面，需要掌握常见的数据分析方法、思路和流程；在技术方面，需要了解数据治理、Hadoop大数据套件、数据处理技术、数据可视化等。
本项目的最大难点是，提出一个让业务干系人认可的全局性解决方案，并在执行过程中及时发现新问题，修正与迭代解决方案。另外，还 需要权衡成本收益问题 ，本项目完成后确实能大幅提升效率，也能打通公司数据分析业务的各个节点，但同时存在需求点和功能点多、开发成本高的问题。我们可对本项目按优先级进行分期实施，比如先进行底层功能建设，接着做数据需求管理方面的功能（对应数据需求单功能），然后做数据分析操作功能，最后做自动调度、数据探索等功能。同时留出时间来深度思考业务、分析需求。
本章总结
本章指出了大数据环境下数据分析流程中存在的问题，提出了建设一个自动化数据分析平台的设想，并完成系统设计，对实施细节进行了分析。 作为数据产品经理，我们除了在数据治理层面投入大量精力外，还需要关注数据的使用层面 ，毕竟数据能够带来价值是我们的最终目标。
在本平台的设计过程中，数据产品经理需要及时发现公司在数据工作中暴露出的主要问题，凭借良好的沟通能力了解各个工作角色的诉求，特别是要对运营人员、数据分析师的工作进行深入观察。同时，还要对Hadoop、Hive、SQL、Python、可视化等数据处理相关技术有所了解，需要有能力协同开发，对一些开源的数据处理项目进行调研。
最后，希望这个平台设计案例能给各位数据产品经理、准数据产品经理带来思考和启发。