1.2 什么是数据应用

在上文中，笔者提到了数据产品与数据应用。在本节中，笔者继续深入探讨各种数据应用的形式与其自身的特点。

笔者将从三个不同的角度分析数据应用，三个角度分别为数据处理的角度、数据展现形式的角度和应用目的的角度。

1.2.1 数据处理的角度

数据处理的过程，指的是数据从原始状态，经过各种数据加工和计算过程，最终成为有意义的、便于获得和理解的结果数据的过程。在这个过程中，有几个关键的环节，如下所示。

采集。

存储。

计算。

可视化。

消息触达。

1.数据采集

数据采集是数据处理过程的第一步，它的关键性在于，为后续的所有流程提供“原材料”。而这一环节的困难在于，只有通过充分地了解业务和分析逻辑，才能保证为后续的流程准备充分的“原材料”。

随着对用户和业务本身的研究逐渐深入，我们对“原材料”的要求也在逐步提高。我们不仅要了解新增用户的数量，还要将其拆解到不同的渠道。我们不仅要了解用户的交易额是多少，还要了解用户在真正下单之前的整个选品过程的行为特征等。

与此同时，我们也能够发现，在业务形态相似的前提下，实际需要采集的数据内容也是类似的。这就使那些专门从事数据采集工作的团队和企业可以针对现有的各种业务形态，逐渐抽象出相对通用的数据采集方法，从而形成通用的方法论和平台化的采集产品。同时进一步提升自动化程度，减少人力参与，甚至直接做到“无埋点”。比如，GrowingIO、友盟、百度统计，以及Google公司提供的系列分析产品等。

2.数据存储与计算

存储与计算通常是密不可分的，在计算的过程中也经常会用到存储。存储与计算是数据处理过程中的第二个关键环节，它决定了我们是否能够得到想要的数据处理结果。从事技术研发的朋友可能会更加关注这个环节，其次就是需要同数据查询打交道的数据分析师，而做交互式OLAP（On-Line Analytic Processing，联机分析处理）的朋友则几乎感知不到这部分的存在，其最明显的感受大概就是“今天的查询速度变慢了”。

在目前的大数据技术框架中，The Apache Software Foundation（Apache软件基金会）提供的一系列技术框架最为常见，比如Apache Hadoop、Apache HBase、Apache Hive、Apache Flink、Apache Storm、Apache Spark、Apache Kafka等。而其他知名的互联网公司和软件公司也在提供着自己的技术框架，比如来自Facebook公司的Presto。

以上是技术研发人员的关注点，而分析师对存储与计算框架的关注点，通常是不同框架的性能特点，以及在执行数据查询和计算之前，能否提前进行相应的优化工作。比如，依据数据集的特性，针对Hive或Presto引擎，进行Hive SQL或Presto SQL的数据查询逻辑优化。

3.可视化

可视化环节是贴近“非专业型”用户的过程之一，它呈现出来的就是美观的统计图表或其他更加复杂的信息图。在一个页面中将多个相互关联的图表有机地组织起来，再搭配一些可以对数据进行简单筛选、切换、钻取、聚合等操作的功能面板，这就是普通的数据产品的样子。

这个环节的输入内容，主要是在存储与计算过程中得到的计算结果。而可视化的方式，又与实际的业务分析需要紧密关联——需要根据分析的目标和得到的计算结果，选择可高效传达分析结论的图表类型。如果解释一个分析结论需要结合多个图表，就需要考虑这些图表在页面上的排布方式，同时应适当添加必要的说明文字，帮助查看页面的人能够更快速地接收图表要传达的信息。

由此可见，在可视化环节，应重点考虑三个方面的问题。首先，是图表类型的丰富；其次，是与数据分析方法论的深度结合；最后，是用户直接接触的交互部分需要进行良好的设计。

4.消息触达

消息触达是一种“主动沟通”的方式。上文提到的数据查询和数据可视化过程，都是那些实际需要获得数据支持的人主动来索取数据。而消息触达，则是根据事先约定的应用场景、触发规则和内容格式，在恰当的时候将关键信息主动发送给“订阅”过的用户。

这个发送的过程，可以通过企业内的邮件服务向指定用户发送邮件，或者通过企业内的即时通信工具发送即时消息，也可以采用企业外部第三方的服务，如短信、语音电话、企业微信、企业QQ等方式。当然，要实现这个过程，还需要前面几个环节的支撑，特别是可能会频繁地用到存储与计算。

与相对“被动”的可视化环节相比，这种“主动”将数据和信息触达个人的方式，为用户提供了更好的体验，同时也能满足一些特殊场景的需要。比如，当业务出现严重问题，或者遇到紧急情况时，通过短信直接通知相关的负责人并在第一时间采取行动，比通过邮件这种相对“低效”的方式更适合。而邮件这种形式，则更适合需要传递包含图片、富文本、文件附件等多样内容的场景。

1.2.2 数据展现形式的角度

良好的展现形式，能帮助阅读数据的人高效地获取数据中隐含的信息。在上文数据处理的内容中，笔者提到了两种数据的展现形式，分别是可视化的统计图表或其他信息图，以及分析报告。这也是大多数用户经常接触到的两种数据的展现形式。

除此之外，还有两种比较常见的数据展现形式。

1.数据文件

数据文件是数据内容实际存储在计算机中的形式，我们可以使用一些工具软件编辑这些数据文件，从而调整数据内容。比如，Microsoft公司的Excel就是这样一款软件，其生成的扩展名为“.xlsx”的文件就可以算作一种数据文件（2007版本之前的Excel生成的文件扩展名为“.xls”）。当然，这些Excel文件中还可能包含统计图等可视化的信息。

另一类比较常见的数据文件就是通过公开的数据网站下载的数据文件，通常是扩展名为“.CSV”的文件。扩展名为“.CSV”的文件存储的仍是普通的文本数据，其每行代表一条记录，记录中各个字段的值通常使用“，”（英文逗号）分割。上文中提到的Excel软件也可以用来创建和编辑扩展名为“.CSV”的文件。

与上文中提到的可视化平台相比，这种数据文件的形式更适合在个体用户之间传递，同时借助计算机的文件系统，也更方便进行归档、备份等操作。当然，如果要进行多个用户之间的共享，或者需要多个用户协作进行数据修改，那么在线平台的形式无疑就是更好的选择。

2.API

API （Application Programming Interface，应用程序编程接口）一般被简称为“接口”，在通过程序语言获取数据时经常被用到。在系统划分模块之后，设计良好的API保证了模块之间交换数据过程的简捷、安全、高效。

在需要将数据进行输出时，特别是在需要自动化接收数据的场景中，基于API的方案是一个不错的选择。在通过API对外提供数据的场景中，通过API读取的数据也是一种数据的展现形式，并且数据的格式也是预先约定好的。在获取数据之后，通常还要继续通过计算机程序的其他模块对数据进行进一步的处理。

笔者在上文中提到一个词——“设计良好”，API是要经过设计的，需要根据具体应用场景的需要，在通用性与性能之间寻找平衡。设计API，不仅要考虑其自身的性能问题，还要考虑对方得到数据之后的易用性问题。同时，出于对安全性和稳定性的考虑，通常对获取数据的频率、数量等都应有相关的限制，通常将其简称为“频控”和“量控”。比如，设定查询次数（调用量）上限为1000次/小时。

1.2.3 应用目的的角度

应用目的是数据应用的初衷和结果，也是投入时间、人力和物力的最终意义。我们可以将应用目的笼统定义为“业务分析”或“辅助业务发展”。但在细分之后，笔者发现存在以下几种常见的数据应用目的。

统计。

监控。

分析。

洞察。

决策。

1.统计

这种简单的数据应用目的，是对某个指标进行加和、计数、去重计数等计算，并直接提供结果。在业务层面，通常根据这些指标的计算结果，对当前的业务情况进行初步的评估，决定业务是否存在严重问题，以及是否需要继续进行更深入的数据分析。

除了对特定指标的计算，还有一类是对数据集本身的特性进行描述的统计，被称作“描述性统计”。比如，每天新增用户数的平均数、中位数、众数、集中趋势、离散程度、极值等。进行这些计算的目的主要是了解数据集本身的特征，同时为具体情况的评估提供一个初步的评价标准。比如，通过每天新增用户数的平均数，找到低于平均数的日期并进行重点分析。

进行数据统计，关键在于数据计算的“口径”问题，也就是对指标的定义。在这方面，既有行业通用的定义，又有根据具体业务形态、发展阶段、企业背景等因素的不同，而专门总结的定义。

笔者仍用上文中的“新增用户”来举例。对初创团队来讲，通常的做法是在初期阶段将“积累用户”定义为重点工作，关于“提高单个用户的贡献度”的问题则暂时会被放到低优先级。依据这样的思维方式，新增用户的定义就会变成“完成了基本注册流程的用户”。而当团队将“单个用户的贡献度”问题提上日程的时候，新增用户的概念就会变成“完成了首次转化的用户”。当然，其中还隐含着一个“转化用户”的定义，也会遇到与“新增用户”类似的情况。可见，对指标定义的总体方向是，随着团队和产品的发展，这个定义会变得越来越适合团队和产品，但在具体条件上也会变得越来越严苛。

2.监控

监控是在统计的基础之上发展而来的。通过初步的数据统计已经得到了数据集自身的一些特性（如上文中提到的平均值），或者经过以往的深入分析得到了关于指标阈值的分析结论。此时，可以通过对特定指标的变化情况设置监控，使其在出现异常情况时主动通知相关人员进行处理。

相对于“被动”进行的数据统计，监控是根据事先约定的判定逻辑，由系统“主动”向相关人员通知异常情况的场景。因此，监控中的难点，一方面在于如何设置合适的触发条件。上文中提到了两种比较常见的设置思路：第一种是基于数据集自身的特性（如平均值）来设置的；第二种是根据以往的数据分析提供的具体阈值来设置的。当然，如果类似这种简单的模式不能满足业务的需要，我们还可以设计针对特定场景的模型，以提供更动态、更精准、更智能的触发条件。比如，风险控制的场景。

另一方面，从业务实际需要的角度出发，不同的具体情况也需要不同的提醒方式。以“简单粗暴”的方式反复提醒，也会对相关人员造成不必要的打扰。为了避免这种打扰，可以对可能产生的异常情况进行分级，使不同级别的异常情况通知不同的相关人员。

3.分析

这是提到数据应用目的时最容易想到的场景。这里的分析过程，主要指的是从现有的数据中发现业务规律的过程。在实际工作中，分析过程主要包括上文中提到的数据处理过程，如存储、计算和可视化。在这些具体的“硬性工作”之外，则是对计算结果和可视化内容的思考过程，这就涉及分析思路的“软实力”问题了。

选择合适的分析思路，应从分析的目的出发开始寻找线索，而分析目标又是由研究业务的视角决定的。常见的分析视角包括利润视角、时机选择视角、行业和市场研究视角等。在这些视角下，我们可能会以利润最大化为目标，开始研究投入和产出的结构；以风险最小为目标，开始研究业务随时间变化的规律；以占领新兴市场为目标，开始研究现有市场的结构和进入途径等。

因此，分析的第一个关键点在于分析目标，其决定了后续分析工作的方向；分析的第二个关键点在于分析方法，我们需要时刻考虑分析方法是否严谨、是否在业务意义上具有说服力。

4.洞察

在日常用语中，“数据分析”的范畴非常宽泛，覆盖一部分“数据洞察”的工作。只有将分析和洞察放到一起时，才更容易将二者区分开：分析过程更专注于从数据中寻找规律，如集中的趋势、随时间变化的波动规律等；而洞察过程则是将这些规律“反哺”到业务当中，如支持对未来业务发展方向的预测、支撑关键决策的制定等。

如果将洞察过程作为一项相对独立而完整的工作看待，其输入的内容是在数据分析阶段发现的规律，而输出的内容则是更贴近业务的决策、计划、方案等。同时，洞察要求提出的方案应符合业务的需要，并且能实际落地。对洞察效果的评价，也应以实际业务发展的情况为依据。

因此，数据洞察过程的第一个关键点是制定可执行、可落地的业务方案；第二个关键点是收集在方案实施之后的业务层面的反馈数据，使方案接受实践的检验。

5.决策

决策也是一个比较概念化的过程，通常意味着在几种备选方案中进行取舍，这需要平衡多方的利益、需要考虑眼前和未来的多种影响因素，从而最终做出综合评价。同时，为了决策足够客观，还需要尽量避免决策者的主观好恶对决策结果的影响。

为了满足上文中提到的各项要求，需要在实际决策之前，先对决策问题建立衡量和评价的体系。建立衡量和评价的体系，可能要通过几个客观数据指标的组合，可能要通过建立专门的委员会，也可能要通过更具开放性的投票方式。在确定了衡量和评价的方式之后，只要依据衡量评价体系完成计算和评价的过程，就可以得到适合的决策结果。只有经过这一步的设计，才能使数据在决策中真正发挥作用。