分析之前 你的数据准备好了么？

大家好，我是司马懿。

我在上一期文章《数据准备：让ETL敏捷起来》从用户角度介绍了产品的设计和流程，接下来我将依次介绍数据准备的产品架构、设计思路、迭代过程以及最佳实践，希望通过一个全景式的产品介绍，帮助大家快速熟悉产品。

还是先从上一期的超市案例说起（忘记案例内容的建议重温下），这个案例了描述业务人员分析数据的工作思路以及敏捷分析实践。在快速变化的业务场景中，赋能业务人员快速处理数据的能力，让业务人员快速完成数据的接入、整理、输出，提高了整个组织的工作效率。

为了方便理解，我将数据准备划分成以下几个模块：

• 数据任务：一个完整数据处理工作流，由一系列输入、转置、输出节点构成，是数据操作的最终产出；
• 数据接入：建立产品跟数据库之间的联系，获取权限，读取数据，查询计算，获取数据是分析的起点，但本文聚焦于数据准备流程，假设这一步已经完成，不做具体介绍；
• 算法节点：数据的具体转置操作在产品上的实现，某一类节点对应特定的数据算法，如行转列节点可以将长表转换为宽表；
• 执行计划：数据任务的执行策略，如时机，重试，预警等，合理设计的执行计划才能保证数据的准确、可靠、稳定。

接下来我将会依次介绍不同模块的产品概念。

在介绍数据任务之前，我们先看一下数据开发平台的工作流程。下图是一个典型的数据开发任务，它由一系列任务节点构成，各个任务节点相互独立，节点与节点之间单向连接。

我们以数据开发平台作为参照，通过对比两个产品之间的差距，介绍概念，阐述定义，帮助大家理解数据准备的产品设计和相关概念。

• 任务节点：既可以表示逻辑上的数据操作，也可以表示物理上的任务执行。对数据开发平台来说，用户在任务节点上定义数据操作逻辑，设定数据更新策略，每一个节点同时完成逻辑定义和物理定义。而数据准备区分了逻辑节点和物理节点，产品实现上仅输出节点是任务节点，其他节点仅完成数据逻辑定义。
• 工作方法：既可以基于代码进行自由开发，也可以通过可视化编辑。数据开发平台对节点的适用场景定义比较宽泛，核心数据操作是由开发人员用代码实现，灵活性高，但门槛也高。而数据准备面向业务人员，核心数据操作由业务人员在界面上拖拽，结合部分伪代码实现，门槛低，操作便捷，但是牺牲了灵活性。
• 节点与节点之间的关系：整个任务流是一个有向无环图。从节点的关系这个角度来看，两个节点之间用一个有向的线条表达节点之间的前后关系。数据开发平台中的前后节点表达的是执行的先后顺序，节点之间不必然存在数据逻辑，而数据准备中前后节点表达是数据上的逻辑关系，执行由产品根据最优策略执行。

打个比方，我们可以将数据准备任务理解为一个复杂的数学公式，比方说“Z = [ (a+b)*2 - (b-c)*4 ]  /  [(a-d)*3 - 5]” ，加减乘除这些运算符号对应数据准备的不同算法，中括号、小括号对应数据准备中的计算过程和运算逻辑，最终计算的结果以“Z”输出。当然，如果我想把中间结果保存起来可以增加一个“Z1 = (a+b)*2”，相对于数据开发平台来说，整个数学公式也许就是一个节点。

算法节点

那数据准备中的算法节点该怎么理解呢？我们以产品上的行转列节点作为例子。

上图的例子中，地区字段做了转置，最终将一张比较长的表转换为一个比较宽的表，用户可以非常方便的分析两个地区之间的的数据关系（比方说做一个桑吉图）。基于转置后的数据用户也可以继续做二次加工。在数据准备这个产品上，如果需要实现行转列操作，用户仅需要将指定字段拖拽到转置区域、聚合区域，一步到位。

从产品设计上来说，数据准备可以分为输入、转置（计算、清洗）、输出三种节点类型，用户通过这些节点的灵活组合实现复杂任务的编辑。

• 输入节点：获取产品的表、字段以及注释信息，仅做数据连接，不支持清洗操作。当前产品支持原表和自定义视图作为输入，其中，自定义视图赋予用户以SQL方式编辑数据的能力。
• 计算节点：定义数据表的粒度或者多表之间的关系，用户使用计算节点实现聚合，转置，合并，关联操作。简单来说，表关联在列上定义两个表的关系，表合并在行上定义表的关系；而转置、聚合节点通过增加或者减少数据维度，为后续分析做好准备。
• 清洗节点：清洗操作在不改变数据粒度基础上，对列或者行进行操作操作。典型场景如：数据类型转换，增加、隐藏列，异常数据排除，空数据替换等单元格粒度的数据整理。用户可以在计算节点上完成清洗操作，也可以使用单独的清洗节点实现清洗操作。
• 输出节点：数据任务中唯一的执行节点，负责数据的落库操作，输出节点定义数据更新策略（增量更新，全量更新），存储方式（行存储、列存储），数据的分区方式等物理表现，也可以定义表名、字段、注释等释义信息。
• 数据视图：视图是操作的结果呈现，产品上分为字段视图和数据视图，用户在视图中可以实时获取操作反馈，快速了解数据分布。

总结来说，数据准备将分析中常用的关联、合并、聚合、转置等数据算法抽象为算法节点。用户通过拖拉拽即可实现数据的加工和处理，清洗，再辅以数据视图，每一步操作可以实时得到反馈，加快了整个工作的节奏，提高了效率。

执行计划简介

不同节点组合成一个数据任务，负责执行数据的接入、计算、输出操作，但是实际工作中数据往往是动态更新，实时变化的，我们仍然需要将数据任务按照某一个策略定时执行，实现数据更新操作。这个具体的执行策略就是数据任务的执行计划。

• 定时调度：按照某一个频率定时执行数据任务，完成数据的新增和更新；
• 依赖调度：基于事件触发的调度机制，典型场景如上游数据产出后，下游任务自动开启；
• 其他策略如：重试策略、失败预警、任务禁用等也是比较常规的调度策略。

合理设计的执行计划才能保证数据的准确、可靠、稳定，典型场景如用上一个数据准备当前节点的输入时，如果上游任务没有完成，当前节点的数据加工可能是错误的，或者至少是不完整的。

写在最后

数据准备通过一个个数据任务将数据处理化繁为简，让ETL工作也可以敏捷起来，赋能业务人员处理数据的能力，让业务人员通过简单配置即可完成数据处理，从根本上降低了使用数据的门槛。我们最终目标是建立一套处理数据的可视化操作系统，提高用户进行数据分析的效率，普及数据决策文化。

产品目标决定了我们的工作路径，在实现产品目标的路径上有很多设计思考，比如节点为什么采用拖拽式交互？计算节点上可以实现清洗操作，为什么还要有单独的清洗节点？输出表可以直接使用，为什么还要有内置连接等等。后续我将介绍这款产品在设计过程中遵循的一些设计原则，供大家品鉴。