| 报表开发流程 | 您所在的位置：网站首页 › 工作统计报表怎么做 › 报表开发流程 |
报表开发流程
|
报表开发是数据分析师的常见工作之一。报表是业务监控必备工具之一(用数据说话)，另一方面，报表监控的指标通常都是业务相关的重要指标，做报表的过程也是深入了解业务的过程。 把数据分析分为“描述、解释、预测、控制”4个层级。那么报表开发就对应“描述”这一层级，也就是要做到准确、及时地监控业务数据。 描述、解释是最常见的工作内容 本文梳理报表开发的主要流程及注意事项，在不同的实际操作场景下涉及到的环节可能不一样，本流程仅供参考。 报表开发的主要流程 报表开发的主要流程1. 需求提交 报表需求发起人就是业务方(通常也称为“需求方”)，一般需求方是产品或者运营的同事。 提交需求时，要提供的信息如下： 业务背景；报表字段及统计口径(中文描述)；关注数据周期，e.g. 当前年、当前月、近7天、近30天等；报表发送频率，e.g. 月报、周报、日报、时报、实时等。建议制作一个需求模板让需求方填写各项信息，主要用途有两个： 帮助需求方想清楚报表的背景和目的，同时过滤掉一部分不靠谱的需求；规范填写的信息，以减少沟通成本。2. 可行性评估 该环节主要解决3个问题： Q1：有没有必要做？ 是否其他系统或报表上可以获得需求方要的数据？报表的价值或者重要性大不大？报表的使用频率是不是够高？如果只是偶尔一次，手动取数应该就可以了。Q2：能不能做？ 一方面要考虑技术上是否可以实现，e.g.实时报表通常由技术人员实现(分析师通常只提供统计口径)；另一方面要考虑权限、合规、安全上的问题，e.g. 报表中是否涉及敏感字段，需求方是否有足够的权限获得这些数据。Q3：是不是其他人做更合适？ 数据分析师会做一部分报表，但不是所有的报表都是由数据分析师来做。做报表的目的一方面是便于及时监控业务数据，另一方面，报表相当于“自动化”的数据处理任务，所以报表也能减轻分析师的工作量。 如果是直接拉取明细数据，或者只是很简单的计数或者求和，那么是否生产库的技术人员应该可以直接做(一般生产库会对接到一个数据后台，不过功能一般比较粗糙)。 3.需求排期
在考虑报表需求的重要性、紧急程度的同时，还需要对需求方进行预期管理，留够充足的时间。 进入“需求排期”阶段就意味着需要登记相应的信息(比如登记在wiki上)，e.g. 报表的编号，业务线归属，报表中文名称，报表类型，需求方，需求提交日期，预计上线日期，开发负责人，当前进度等。 4.数据抽取
可以简单的把企业数据按用途分为3类库：生产库、分析库、报表库。 生产库，是生产数据直接存储的地方，非开发人员一般是不能直接访问的，生产库的数据通常称为“源数据”(也就是数据源头)；分析库，就是将生产库的数据ETL处理后，放到一个地方集中供数据部门直接使用，数据分析师的日常工作通常依赖于这类库；报表库，则是存放各业务线报表数据的数据库，通常报表库会对接到各数据产品(e.g. 报表系统、数据展板、自助分析平台等)。数据抽取，也就是将数据从生产库抽取到分析库。 一般业务发展成熟时，报表开发所需要的大部分源数据表都已经抽取过，所以该步骤不一定需要执行。如果是某个业务刚上线或者报表需要用到的表没有被抽取，那么就可能需要执行该步骤： 联系业务线的产品经理以确认生产库的技术接口人；然后，技术接口人提供库名、表名(英文及中文)、建表代码等源表信息；接下来，将源表信息传递给数据ETL的同事进行数据抽取。5. 代码编写 这里的代码主要指SQL代码，也就是选择合适的数据表，统计出业务方需要的报表字段数据。 除了统计口径要准确外，代码编写的时候还要注意3点： ①代码规范，代码要有必要的注释、版本信息，注意对齐和命名规范； ②文档管理，主要是便于后期的报表维护以及统计口径整合，建议： 代码放到企业网盘备份或者托管到企业内部的git平台；用wiki登记报表的相关信息，e.g. 报表名称、负责人、代码、数据字典等③建中间表，如果有需要，那就建立中间表，将常用字段整合到一张表，以便于统计分析和口径维护。 常见的中间表有3类：用户宽表、订单宽表、维表。 用户宽表就是记录用户属性的一张表，比如用户画像的大多数属性都可以放到这张表里，e.g. 基本属性(年龄、性别等)、产品属性(是否开通某服务、产品标签等)、统计属性(首次、常用、最近等)订单宽表整合订单的各种信息(这里的订单泛指交易订单)，e.g.电商订单中的订单来源信息(硬件设备、操作系统、网络类型等)、优惠信息、物流信息、售后信息(退换货等)维表则是记录字段枚举值的含义的表，因为业务会发生变化，相应的业务类型也会增加调整。e.g. 记录地区编号对应的省市信息表，记录产品各页面名称信息的表，记录不同商品信息(品类、品牌等)的表。注：用户宽表和订单宽表之所以称为“宽表”，因为用户或者订单的属性(列)通常比较多(从各个业务线的数据整合过来)，且这两类表通常会有增加列的操作(属性扩展)；而维表的列(属性)通常比较稳定，一般情况下不会有增加列的操作。 设计中间表时，除了要求口径的准确性外，最需要关注的是可扩展性，也可以理解为通用性，扩展性要考虑表的维度和计量两个方面： i.维度 一般为分类变量，包括日期、二值属性、多值离散属性等，维度就意味着数据表的颗粒度，常见的颗粒度有用户、订单、商品、日期等；维度上的扩展性体现为，可以进行行压缩或者行列转置等pivot table的操作，一般而言颗粒度越细化(在业务需要的范围内)，扩展性越高；ii.计量 通常是连续变量，包括数量、金额、时间等绝对量；计量上的扩展性在于，可以用多个计量的组合计算得到另一个变量，e.g. 计算百分比；6. 数据验证 数据验证主要是核对数据是否准确、完整。 一般的方式如下： 自检代码逻辑，字段相互验证；和其他系统的数据比对验证，比如生产库的数据；由测试人员进行验证；数据验证阶段，发现的问题通常在3个地方： 统计逻辑，e.g. 隐藏前提，交叉标签等；数据抽取，e.g. 数据增量抽取时依赖update_time字段，而该字段在生产库没有同步更新，这种情况下要么改抽取方式为“全量抽取”，要么生产库的字段更新逻辑要进行调整；生产库改动，e.g. 生产库的业务逻辑改动(业务分流)，或者先前的表的字段已被弃用(不再更新)；如果数据核对不上，则建议按上述的顺序一一排查。 7. 前端展示 这个步骤就涉及最终报表的交付形式了，报表的交付形式是在“可行性评估”这个环节确定的。 按报表展示的载体可以大致分为3类： 自动定时邮件；网页展示(PC端或者移动端)；独立应用(e.g. 移动端app)；该环节需要使用到呈现数据的工具(不一定可视化工具，大多数情况还是会用表格展示)，这些工具可以是企业内部开发的数据工具(平台)，也可以是购买的FineBI, Tableau等方便易用的商业软件。但工具不是最重要的，更重要的是呈现的数据能突出重点、准确反映问题。 注：理想的数据展示应该是选用了恰当的展示方式，按业务逻辑、有层级地组织了数据，并讲述了一个完整的故事。关于图表可视化建议阅读《用图表说话：麦肯锡商务沟通完全工具箱》这本书。
8. 报表验收 在正式上线之前要先对报表进行“自测”，比如： 邮件是否能正常定时发送；图表是否能正常显示，是否有添加必要的说明提示(e.g. 统计口径等)；显示的数据格式是否OK，e.g. 小数点后位数，单位，坐标轴范围等)；需求方需要用到的功能是否正常，e.g.筛选、交互等；完成上述工作后，就可以交由需求方验收了，后续可能需要根据需求方提出的建议做适当的调整，当需求方确认OK时就准备上线。 9. 报表上线 报表验收通过，接下来就是正式上线。 如果是自动邮件，则要确认发送的频率、收件人等信息； 注：邮件中最好有相应的计算口径说明 如果是网页或者在独立应用中展示，通常需要申请权限，那么报表上线后需要告知业务费报表申请路径(走OA或者发邮件)、报表名称等信息。 以上，就是报表开发的主要步骤，涉及到的技术的东西比较少，主要是流程以及信息的沟通，希望对大家有用，欢迎留言交流。 需要补充的信息： i. 本文所述流程是以需求导向的“被动”的报表开发流程，实际上，我们平时也会根据业务需要来“主动”做报表，例如高频的“临时需求”就可以转化成报表需求(自动化的报表可以解放劳动力)，另一方面，如果分析师是以项目导向的工作方式，则需要主动和业务方沟通需要有哪些数据需要监控(e.g. KPI、转化率、交易情况等)； ii. 如果是新业务上线时，报表开发者可能对统计口径一无所知，那么在第一步“需求提出”环节，可以： 让业务方先和产品经理沟通确定报表字段及口径；然后产品经理再和生产库技术接口人确定技术口径；产品经理将相应的字段统计口径发送给报表开发者(分析师)，并抄送业务方及技术接口人；这样业务上线初期，通过报表开发就能积累后续会常用到的统计口径，对报表开发过程中使用到的统计口径进行分类和整理，不管是将相应信息记录到wiki还是建立中间表(这也是数据部分知识管理的一部分)，对后续的业务分析都能极大地提高效率。 iii. 报表也是数据产品之一，凡产品都有其生命周期，报表也不例外，报表后续的维护不仅包括报表字段的增删改，还要进行下线和清理工作，以节省计算资源，同时减少对需求方的打扰。此外，沟通的环节尽量走邮件，一方面是确保信息送达相关人员，另一方面，信息的存档真的很重要。 |
【本文地址】