互联网产品 + 大数据产品 = 大数据平台
大数据计算通过将可执行的代码分发到大规模的服务器集群上进行分布式计算，以处理大规模的数据，即所谓的移动计算比移动数据更划算。但是在分布式系统中分发执行代码并启动执行，这样的计算方式必然不会很快，即使在一个规模不太大的数据集上进行一次简单计算，MapReduce 也可能需要几分钟，Spark 快一点，也至少需要数秒的时间。
而互联网产品处理用户请求，需要毫秒级的响应，也就是说，要在 1 秒内完成计算，因此大数据计算必然不能实现这样的响应要求。但是互联网应用又需要使用大数据，实现统计分析、数据挖掘、关联推荐、用户画像等一系列功能。
那么如何才能弥补这互联网和大数据系统之间的差异呢？解决方案就是将面向用户的互联网产品和后台的大数据系统整合起来，也就是今天我要讲的构建一个大数据平台
大数据平台，顾名思义就是整合网站应用和大数据系统之间的差异，将应用程序产生的数据导入到大数据系统，经过处理计算后再导出给应用程序使用。
下图是一个典型的互联网大数据平台的架构。
在这张架构图中，大数据平台里面向用户的在线业务处理组件用褐色标示出来，这部分是属于互联网在线应用的部分，其他蓝色的部分属于大数据相关组件，使用开源大数据产品或者自己开发相关大数据组件。
你可以看到，大数据平台由上到下，可分为三个部分：数据采集、数据处理、数据输出与展示。
将应用程序产生的数据和日志等同步到大数据系统中，由于数据源不同，这里的数据同步系统实际上是多个相关系统的组合。数据库同步通常用 Sqoop，日志同步可以选择 Flume，打点采集的数据经过格式化转换后通过 Kafka 等消息队列进行传递。
不同的数据源产生的数据质量可能差别很大，数据库中的数据也许可以直接导入大数据系统就可以使用了，而日志和爬虫产生的数据就需要进行大量的清洗、转化处理才能有效使用。
这部分是大数据存储与计算的核心，数据同步系统导入的数据存储在 HDFS。MapReduce、Hive、Spark 等计算任务读取 HDFS 上的数据进行计算，再将计算结果写入 HDFS。
MapReduce、Hive、Spark 等进行的计算处理被称作是离线计算，HDFS 存储的数据被称为离线数据。在大数据系统上进行的离线计算通常针对（某一方面的）全体数据，比如针对历史上所有订单进行商品的关联性挖掘，这时候数据规模非常大，需要较长的运行时间，这类计算就是离线计算。
除了离线计算，还有一些场景，数据规模也比较大，但是要求处理的时间却比较短。比如淘宝要统计每秒产生的订单数，以便进行监控和宣传。这种场景被称为大数据流式计算，通常用 Storm、Spark Steaming 等流式大数据引擎来完成，可以在秒级甚至毫秒级时间内完成计算。
前面我说过，大数据计算产生的数据还是写入到 HDFS 中，但应用程序不可能到 HDFS 中读取数据，所以必须要将 HDFS 中的数据导出到数据库中。数据同步导出相对比较容易，计算产生的数据都比较规范，稍作处理就可以用 Sqoop 之类的系统导出到数据库。
这时，应用程序就可以直接访问数据库中的数据，实时展示给用户，比如展示给用户关联推荐的商品。淘宝卖家的量子魔方之类的产品，其数据都来自大数据计算产生。
除了给用户访问提供数据，大数据还需要给运营和决策层提供各种统计报告，这些数据也写入数据库，被相应的后台系统访问。很多运营和管理人员，每天一上班，就是登录后台数据系统，查看前一天的数据报表，看业务是否正常。如果数据正常甚至上升，就可以稍微轻松一点；如果数据下跌，焦躁而忙碌的一天马上就要开始了。
将上面三个部分整合起来的是任务调度管理系统，不同的数据何时开始同步，各种 MapReduce、Spark 任务如何合理调度才能使资源利用最合理、等待的时间又不至于太久，同时临时的重要任务还能够尽快执行，这些都需要任务调度管理系统来完成。
有时候，对分析师和工程师开放的作业提交、进度跟踪、数据查看等功能也集成在这个任务调度管理系统中。
简单的大数据平台任务调度管理系统其实就是一个类似 Crontab 的定时任务系统，按预设时间启动不同的大数据作业脚本。复杂的大数据平台任务调度还要考虑不同作业之间的依赖关系，根据依赖关系的 DAG 图进行作业调度，形成一种类似工作流的调度方式。
对于每个公司的大数据团队，最核心开发、维护的也就是这个系统，大数据平台上的其他系统一般都有成熟的开源软件可以选择，但是作业调度管理会涉及很多个性化的需求，通常需要团队自己开发。开源的大数据调度系统有 Oozie，也可以在此基础进行扩展。
上面我讲的这种大数据平台架构也叫 Lambda 架构，是构建大数据平台的一种常规架构原型方案。Lambda 架构原型请看下面的图。
- 批处理大数据层是数据主要存储与计算的地方，所有的数据最终都会存储到批处理大数据层，并在这里被定期计算处理。
- 批处理大数据层的计算结果输出到服务层（serving layer），供应用使用者查询访问。
- 由于批处理的计算速度比较慢，数据只能被定期处理计算（比如每天），因此延迟也比较长（只能查询到截止前一天的数据，即数据输出需要 T+1）。所以对于实时性要求比较高的查询，会交给流处理大数据层（speed layer），在这里进行即时计算，快速得到结果。
我们看下一个典型的互联网企业的数据流转。用户通过 App
等互联网产品使用企业提供的服务，这些请求实时不停地产生数据，由系统进行实时在线计算，并把结果数据实时返回用户，这个过程被称作在线业务处理，涉及的数据主要是用户自己一次请求产生和计算得到的数据。单个用户产生的数据规模非常小，通常内存中一个线程上下文就可以处理。但是大量用户并发同时请求系统，对系统而言产生的数据量就非常可观了，比如天猫“双十一”，开始的时候一分钟就有数千万用户同时访问天猫的系统。
在线数据完成和用户的交互后，会以数据库或日志的方式存储在系统的后端存储设备中，大量的用户日积月累产生的数据量非常庞大，同时这些数据中蕴藏着大量有价值的信息需要计算。但是我们没有办法直接在数据库以及磁盘日志中对这些数据进行计算，前面我们也一再讨论过大规模数据计算的挑战，所以需要将这些数据同步到大数据存储和计算系统中进行处理。
但是这些数据并不会立即被数据同步系统导入到大数据系统，而是需要隔一段时间再同步，通常是隔天，比如每天零点后开始同步昨天 24 小时在线产生的数据到大数据平台。因为数据已经距其产生间隔了一段时间，所以这些数据被称作离线数据。
离线数据被存储到 HDFS，进一步由 Spark、Hive 这些离线大数据处理系统计算后，再写入到 HDFS 中，由数据同步系统同步到在线业务的数据库中，这样用户请求就可以实时使用这些由大数据平台计算得到的数据了。
离线计算可以处理的数据规模非常庞大，可以对全量历史数据进行计算，但是对于一些重要的数据，需要实时就能够进行查看和计算，而不是等一天，所以又会用到大数据流式计算，对于当天的数据实时进行计算，这样全量历史数据和实时数据就都被处理了。
但是在绝大多数情况下，我们都不需要自己开发大数据产品，我们仅仅需要用好这些大数据产品，也就是如何将大数据产品应用到自己的企业中，将大数据产品和企业当前的系统集成起来。
大数据平台听起来高大上，事实上它充当的是一个粘合剂的作用，将互联网线上产生的数据和大数据产品打通，它的主要组成就是数据导入、作业调度、数据导出三个部分，因此开发一个大数据平台的技术难度并不高。
大数据就是存储、计算、应用大数据的技术，如果没有数据，所谓大数据就是无源之水、无本之木，所有技术和应用也都无从谈起。可以说，数据在大数据的整个生态体系里面拥有核心的、最无可代替的地位。很多从事机器学习和人工智能的高校学者选择加入互联网企业，并不是贪图企业给的高薪，而是因为只有互联网企业才有他们做研究需要用到的大量数据。
技术是通用的，算法是公开的，只有数据需要自己去采集。因此数据采集是大数据平台的核心功能之一，也是大数据的来源。数据可能来自企业内部，也可能是来自企业外部，
大数据平台的数据来源主要有数据库、日志、前端程序埋点、爬虫系统
在大数据技术风靡之前，关系数据库（RDMS）是数据分析与处理的主要工具，我们已经在关系数据库上积累了大量处理数据的技巧、知识与经验。所以当大数据技术出现的时候，人们自然而然就会思考，能不能将关系数据库数据处理的技巧和方法转移到大数据技术上，于是 Hive、Spark SQL、Impala 这样的大数据 SQL 产品就出现了。
虽然 Hive 这样的大数据产品可以提供和关系数据库一样的 SQL 操作，但是互联网应用产生的数据却还是只能记录在类似 MySQL 这样的关系数据库上。这是因为互联网应用需要实时响应用户操作，基本上都是在毫级完成用户的数据读写操作，通过前面的学习我们知道，大数据不是为这种毫秒级的访问设计的。
所以要用大数据对关系数据库上的数据进行分析处理，必须要将数据从关系数据库导入到大数据平台上。目前比较常用的数据库导入工具有 Sqoop 和 Canal。
Sqoop 是一个数据库批量导入导出工具，可以将关系数据库的数据批量导入到 Hadoop，也可以将 Hadoop 的数据导出到关系数据库。
Sqoop 数据导入命令示例如下。
你需要指定数据库 URL、用户名、密码、表名，就可以将数据表的数据导入到 Hadoop。
Sqoop 适合关系数据库数据的批量导入，如果想实时导入关系数据库的数据，可以选择 Canal。
而我们只要开发一个 Canal 客户端程序就可以解析出来 MySQL 的写操作数据，将这些数据交给大数据流计算处理引擎，就可以实现对 MySQL 数据的实时处理了。
日志也是大数据处理与分析的重要数据来源之一，应用程序日志一方面记录了系统运行期的各种程序执行状况，一方面也记录了用户的业务处理轨迹。依据这些日志数据，可以分析程序执行状况，比如应用程序抛出的异常；也可以统计关键业务指标，比如每天的 PV、UV、浏览数 Top N 的商品等。
Flume 是大数据日志收集常用的工具。Flume 最早由 Cloudera 开发，后来捐赠给 Apache 基金会作为开源项目运营。Flume 架构如下。
从图上看，Flume 收集日志的核心组件是 Flume Agent，负责将日志从数据源收集起来并保存到大数据存储设备。
Agent Source 负责收集日志数据，支持从 Kafka、本地日志文件、Socket 通信端口、Unix 标准输出、Thrift 等各种数据源获取日志数据。
Source 收集到数据后，将数据封装成 event 事件，发送给 Channel。Channel 是一个队列，有内存、磁盘、数据库等几种实现方式，主要用来对 event 事件消息排队，然后发送给 Sink。
Sink 收到数据后，将数据输出保存到大数据存储设备，比如 HDFS、HBase 等。Sink 的输出可以作为 Source 的输入，这样 Agent 就可以级联起来，依据具体需求，组成各种处理结构，比如下图的结构。
这是一个日志顺序处理的多级 Agent 结构，也可以将多个 Agent 输出汇聚到一个 Agent，还可以将一个 Agent 输出路由分发到多个 Agent，根据实际需求灵活组合。
前端埋点数据采集也是互联网应用大数据的重要来源之一，用户的某些前端行为并不会产生后端请求，比如用户在一个页面的停留时间、用户拖动页面的速度、用户选中一个复选框然后又取消了。这些信息对于大数据处理，对于分析用户行为，进行智能推荐都很有价值。但是这些数据必须通过前端埋点获得，所谓前端埋点，就是应用前端为了进行数据统计和分析而采集数据。
事实上，互联网应用的数据基本都是由用户通过前端操作产生的，有些互联网公司会将前端埋点数据当作最主要的大数据来源，用户所有前端行为，都会埋点采集，再辅助结合其他的数据源，构建自己的大数据仓库，进而进行数据分析和挖掘。
对于一个互联网应用，当我们提到前端的时候，可能指的是一个 App 程序，比如一个 iOS 应用或者 Android 应用，安装在用户的手机或者 pad 上；也可能指的是一个 PC Web 前端，使用 PC 浏览器打开；也可能指一个 H5
前端，由移动设备浏览器打开；还可能指的是一个微信小程序，在微信内打开。这些不同的前端使用不同的开发语言开发，运行在不同的设备上，每一类前端都需要解决自己的埋点问题。
埋点的方式主要有手工埋点和自动化埋点。
手工埋点就是前端开发者手动编程将需要采集的前端数据发送到后端的数据采集系统。通常公司会开发一些前端数据上报的 SDK，前端工程师在需要埋点的地方，调用 SDK，按照接口规范传入相关参数，比如 ID、名称、页面、控件等通用参数，还有业务逻辑数据等，SDK 将这些数据通过 HTTP 的方式发送到后端服务器。
自动化埋点则是通过一个前端程序
SDK，自动收集全部用户操作事件，然后全量上传到后端服器。自动化埋点有时候也被称作无埋点，意思是无需埋点，实际上是全埋点，即全部用户操作都埋点采集。自动化埋点的好处是开发工作量小，数据规范统一。缺点是采集的数据量大，很多数据采集来也不知道有什么用，白白浪费了计算资源，特别是对于流量敏感的移动端用户而言，因为自动化埋点采集上传花费了大量的流量，可能因此成为卸载应用的理由，这样就得不偿失了。在实践中，有时候只是针对部分用户做自动埋点，抽样一部分数据做统计分析。
介于手工埋点和自动化埋点之间的，还有一种方案是可视化埋点。通过可视化的方式配置哪些前端操作需要埋点，根据配置采集数据。可视化埋点实际上是可以人工干预的自动化埋点。
在很多公司前端埋点都是一笔糊涂账。很多公司对于数据的需求没有整体规划和统一管理，数据分析师、商业智能 BI 工程师、产品经理、运营人员、技术人员都会在数据采集这里插一脚，却没有专门的数据产品经理来统一负责数据采集的规划和需求工作。很多需要的数据没有采集，更多没用的数据却被源源不断地被采集存储起来。
不同于业务需求，功能和价值大多数时候都是实实在在的。数据埋点需求的价值很多时候不能直观看到，所以在开发排期上往往被当作低优先级的需求。而很多埋点也确实最后没起到任何作用，加剧了大家这种印象。老板觉得数据重要，却又看不到足够的回报，也渐渐心灰意冷。
所以专业的事情需要专业对待，从安排专业的人专门负责开始。
通过网络爬虫获取外部数据也是公司大数据的重要来源之一。有些数据分析需要行业数据支撑，有些管理和决策需要竞争对手的数据做对比，这些数据都可以通过爬虫获取。
对于百度这样的公开搜索引擎，如果遇到网页声明是禁止爬虫爬取的，通常就会放弃。但是对于企业大数据平台的爬虫，常常被禁止爬取的数据才是真正需要的数据，比如竞争对手的数据。被禁止爬取的应用通常也会采用一些反爬虫技术，比如检查请求的 HTTP 头信息是不是爬虫，以及对参数进行加密等。遇到这种情况，需要多花一点技术手段才能爬到想要的数据。
各种形式的数据从各种数据源导入到大数据平台，进行数据处理计算后，又将数据导出到数据库，完成数据的价值实现。输入的数据格式繁杂、数据量大、冗余信息多，而输出的数据则结构性更好，用更少的数据包含了更多的信息，这在热力学上，被称作熵[shāng]减。
熵是表征系统无序状态的一个物理学参量，系统越无序、越混乱，熵越大。我们这个宇宙的熵一刻不停地在增加，当宇宙的熵达到最大值的时候，就是宇宙寂灭之时。虽然宇宙的熵在不停增加，但是在局部，或者某些部分、某些子系统的熵却可以减少。
比如地球，似乎反而变得更加有序，熵正在减少，主要原因在于这些熵在减少的系统在吸收外部能量，地球在吸收太阳的能量，实现自己熵的减少。大数据平台想要实现数据的熵的减少，也必须要吸收外部的能量，这个能量来自于工程师和分析师的算法和计算程序。
如果算法和程序设计不合理，那么熵可能就不会下降多少，甚至可能增加。所以大数据技术人员在审视自己工作的时候，可以从熵的视角看看，是不是输出了更有价值、更结构化的数据，是不是用更少量的数据包含了更多的信息。
人作为一个系统，从青壮到垂老，熵也在不停增加。要想减缓熵增的速度，必须从外部吸收能量。物质上，合理饮食，锻炼身体；精神上，不断学习，参与有价值的工作。那些热爱生活、好好学习、积极工作的人是不是看起来更年轻，而整日浑浑噩噩的人则老的更快。
知名大厂如何搭建大数据平台？
上面介绍了一个常规的大数据平台架构方案，这种架构方案是基于大数据平台 Lamda 架构进行设计的。事实上，业界也基本是按照这种架构模型搭建自己的大数据平台。
今天我们来看一下淘宝、美团和滴滴的大数据平台，一方面进一步学习大厂大数据平台的架构，另一方面也学习大厂的工程师如何画架构图。通过大厂的这些架构图，你就会发现，不但这些知名大厂的大数据平台设计方案大同小异，架构图的画法也有套路可以寻觅。
淘宝可能是中国互联网业界较早搭建了自己大数据平台的公司，下图是淘宝早期的 Hadoop 大数据平台，比较典型。
淘宝的大数据平台基本也是分成三个部分，上面是数据源与数据同步；中间是云梯 1，也就是淘宝的 Hadoop 大数据集群；下面是大数据的应用，使用大数据集群的计算结果。
数据源主要来自 Oracle 和 MySQL 的备库，以及日志系统和爬虫系统，这些数据通过数据同步网关服务器导入到 Hadoop 集群中。其中 DataExchange 非实时全量同步数据库数据，DBSync 实时同步数据库增量数据，TimeTunnel 实时同步日志和爬虫数据。数据全部写入到 HDFS 中。
在 Hadoop 中的计算任务会通过天网调度系统，根据集群资源和作业优先级，调度作业的提交和执行。计算结果写入到 HDFS，再经过 DataExchange 同步到 MySQL 和 Oracle 数据库。处于平台下方的数据魔方、推荐系统等从数据库中读取数据，就可以实时响应用户的操作请求。
淘宝大数据平台的核心是位于架构图左侧的天网调度系统，提交到 Hadoop 集群上的任务需要按序按优先级调度执行，Hadoop 集群上已经定义好的任务也需要调度执行，何时从数据库、日志、爬虫系统导入数据也需要调度执行，何时将 Hadoop 执行结果导出到应用系统的数据库，也需要调度执行。可以说，整个大数据平台都是在天网调度系统的统一规划和安排下进行运作的。
DBSync、TimeTunnel、DataExchange 这些数据同步组件也是淘宝内部开发的，可以针对不同的数据源和同步需求进行数据导入导出。这些组件淘宝大都已经开源，我们可以参考使用。
Kafka 的数据会被流式计算和批处理计算两个引擎分别消费。流处理使用 Storm 进行计算，结果输出到 HBase 或者数据库。批处理计算使用 Hive 进行分析计算，结果输出到查询系统和 BI（商业智能）平台。
数据分析师可以通过 BI 产品平台进行交互式的数据查询访问，也可以通过可视化的报表工具查看已经处理好的常用分析指标。公司高管也是通过这个平台上的天机系统查看公司主要业务指标和报表。
美团大数据平台的整个过程管理通过调度平台进行管理。公司内部开发者使用数据开发平台访问大数据平台，进行 ETL（数据提取、转换、装载）开发，提交任务作业并进行数据管理。
滴滴大数据平台分为实时计算平台（流式计算平台）和离线计算平台（批处理计算平台）两个部分。
实时计算平台架构如下。数据采集以后输出到 Kafka 消息队列，消费通道有两个，一个是数据 ETL，使用 Spark Streaming 或者 Flink 将数据进行清洗、转换、处理后记录到 HDFS 中，供后续批处理计算。另一个通道是 Druid，计算实时监控指标，将结果输出到报警系统和实时图表系统 DashBoard。
离线计算平台架构如下。滴滴的离线大数据平台是基于 Hadoo 2（HDFS、Yarn、MapReduce）和 Spark 以及 Hive 构建，在此基础上开发了自己的调度系统和开发系统。调度系统和前面其他系统一样，调度大数据作业的优先级和执行顺序。开发平台是一个可视化的 SQL 编辑器，可以方便地查询表结构、开发 SQL，并发布到大数据集群上。
此外，滴滴还对 HBase 重度使用，并对相关产品（HBase、Phoenix）做了一些自定义的开发，维护着一个和实时、离线两个大数据平台同级别的 HBase 平台，它的架构图如下。
来自于实时计算平台和离线计算平台的计算结果被保存到 HBase 中，然后应用程序通过 Phoenix 访问 HBase。而 Phoenix 是一个构建在 HBase 上的 SQL 引擎，可以通过 SQL 方式访问 HBase 上的数据。
你可以看到，这些知名大厂的大数据平台真的是大同小异，他们根据各自场景和技术栈的不同，虽然在大数据产品选型和架构细节上略有调整，但整体思路基本上都是一样的。
不过也正是这种大同小异，让我们从各个角度更加了解大数据平台架构，对大数据平台架构有了更加深刻的认知。
同一类问题的解决方案通常也是相似的。一个解决方案可以解决重复出现的同类问题，这种解决方案就叫作模式。模式几乎是无处不在的，一旦一个解决方案被证明是行之有效的，就会被重复尝试解决同类的问题。
所以我们看到，很多大数据产品的架构也都是差不多的，比如 Hadoop 1、Yarn、Spark、Flink、Storm，这些产品的部署架构真的是太像了。
某位互联网大佬说过，未来 20 年最有发展潜力的三项技术分别是：区块链、人工智能、物联网。关于区块链，现在可能是最有争议也是最迷茫的时候；关于人工智能的价值，我们已经达成共识并稳步发展；而真正完成早期探索、处于突破临界点的可能就是物联网了。
物联网确实也能给我们足够的想象空间：万物互联，所有的一切设备都是智能的，它们通过互相通信，彼此联系；而人们也可以通过云端的应用掌控一切，就像科幻电影描述的那样。
最关键的是，相比人工智能和区块链还在进行技术探索，物联网的技术已经成熟，只待“临门一脚”了。
现在说“万物互联”也许为时尚早，但是很多细分的垂直领域场景已经实现了物联网。
智能家居可能是和我们最接近，也是目前最普及的物联网。目前市面上销售的各种大家电，很多都有上网和远程控制功能。小米旗下的几乎所有家电都可以通过网络控制，这些设备和智能音箱联通，我们可以通过语音控制台灯、电饭煲、自动窗帘等。
下班回家，说一句“我回来了”，家里的灯立即打开，空调开启、窗帘关闭。要睡觉了，说声“晚安”，大灯关闭、夜灯开启、空气净化器进入夜间模式。是不是很酷？最重要的，这些技术和产品都已经成熟，而且价格低廉。
车联网曾经被人们寄予厚望，车联网的美好场景被描述如下：
道路上的车辆互相通信连接，前面车辆刹车，立即通知后面车辆，后面车辆也减速；路上发生车祸，警告其他车辆小心驾驶，车辆通过自己的摄像头将车祸现场照片视频自动上传给交警和保险公司；进入停车场，车辆和泊位系统通信，自动引导到空车位。车辆和车辆之间、车辆和其他交通设施之间彼此通信，互相协作，构成一个网络。
除此之外，物联网还应用在农业领域，土壤传感器探测土壤湿度，数据上传云端，云端系统根据农作物特性远程控制农田现场的喷淋装置。在能源利用领域，摄像头和红外传感器捕捉人们的活动，自动控制照明和空调系统，保证舒适和节能的平衡。
物联网主要是将各种传感器和智能设备连接起来，将数据上传云端，根据规则和机器学习模型进行远程控制，并通过物联网应用程序进行监控管理。一个典型的物联网平台架构如下图所示。
终端传感器实时采集数据，利用移动数据网络将数据上传给智能网关，智能网关进行初步的数据处理，根据规则和机器学习模型进行计算，再将计算结果通过移动数据网络下发给可控制的终端智能设备。
由于传感器可能部署在很多相距较远的地方，而且数量庞大，所以不可能将传感器数据直接接入云端服务器，而且也不是所有的传感器数据都需要实时上传云端。所以，需要有一个在传感器现场的前置服务器进行现场管理。智能网关就是距离现场传感器最近的一个计算机。
由于智能网关布置在物联网的作业现场，和传感器距离很近，处于整个云计算的边缘，所以在智能网关上的计算也叫边缘计算
智能网关进行现场数据处理后，也就是进行边缘计算后，还要把数据上传到云端，即物联网大数据平台，将数据永久存储，进行机器学习。还要将各个异地的传感器数据统一汇总，进行全局性的计算并进行全局性的控制。
此外云端还负责将各种数据推送给应用程序设备，工作人员可以实时监控整个物联网的运行情况，并通过应用程序进行远程控制。
大数据技术在物联网中的应用
如果说互联网连接的是人，那么物联网连接的就是物，是各种智能设备和传感器。相对人的数量来说，智能设备的数量要多得多，人不会时刻都在上网，而智能设备则时刻都在联网传输数据，所以物联网更需要大数据技术。
物联网里大数据技术的应用，一方面是大数据的存储和计算，另一方面就是边缘计算管理。我们先看下物联网大数据平台的架构。
- 智能网关通过消息队列将数据上传到物联网大数据平台，Storm 等流式计算引擎从消息队列获取数据，对数据的处理分三个方面。
- Spark 等离线计算引擎定时对写入存储系统的数据进行批量计算处理，进行全量统计分析和机器学习，并更新机器学习模型。
- 应用程序也可以通过设备管理服务器直接发送控制指令给智能网关，控制终端智能设备。
这样就构成一个典型的物联网“端 - 云 - 端”架构，其中两个端分别是传感器与智能设备端，以及应用程序设备端，而云则是大数据云计算平台。
此外，边缘计算也要执行大量的逻辑运算，主要是对传感器数据进行处理和计算。运算逻辑代码和处理规则可能会经常变化，特别是规则配置，随时可能更新。
比较好的做法就是参考大数据计算框架的做法，即移动计算，将执行代码和规则配置分发到智能网关服务器。
开发者将代码和配置通过设备管理服务器分发给各个智能网关，智能网关热加载这些代码开始执行。这样人们不但可以可以远程控制智能设备，还可以控制智能设备的运行逻辑。
现在一些商业化的物联网云计算平台提出函数即服务 FaaS，在应用程序或者云控制台上编写函数，分发到智能网关执行就可以，这也是目前比较火的 Serverless 的一种实现。
物联网的很多应用场景都会加上“智能”二字，比如智能家居、智能交通等。万物互联本身不是目的，让万物更智能，让生活更美好才是目的，而这些智能正是靠大数据技术实现的。不管是大规模传感器数据的采集、传输、处理，还是关于这些数据的分析与机器学习，以及最后对现场智能设备控制的边缘计算，背后都用到了大数据技术。
物联网的概念从提出到现在也过去很多年了，最近两年又重新开始火起来，我想应该跟大数据技术的普及有很大关系。
为什么大数据平台至关重要？
我前面说过，软件大体可以分为两种：
- 一种是为最终用户开发的，实现用户需要的业务功能；
- 另一种是为软件工程师开发的，供软件工程师使用。
讲到的各种大数据产品，都属于后一种，最终用户不可能自己提交一个 Hadoop 程序去执行大数据计算，这是软件工程师的工作，因此大数据产品也是为软件工程师开发的。而如何让软件工程师能够便捷地提交各类大数据计算程序给大数据计算引擎去执行，如何将用户实时数据转化为大数据产品的数据源，如何利用好大数据的计算结果，这些都是大数据平台的职责范围。
大数据平台将互联网应用和大数据产品整合起来，构建成一个完整的系统，将实时数据和离线数据打通，使数据可以实现更大规模的关联计算，挖掘出数据更大的价值，从而实现数据驱动业务，通过数据统计发现业务规律（也就是机器学习模型）。而利用这个规律对未来的数据进行分类和预测，使系统呈现出智能的特性，也为互联网未来发展和人类的生产生活创造了无限可能。
大数据平台将互联网应用和大数据产品整合起来，一方面使互联网应用变得更加智能、强大；一方面也使得大数据产品实现技术落地。技术不同于科学，科学拓展人类的认知边界，而技术是人们改造世界的工具，科学的成果可以转化为技术；而技术真正能够改造世界，需要技术落地，真正应用到生产过程中。用我们熟知的 Hadoop
为例，即使它的技术再厉害，如果没有具体应用，没有被广泛使用，同样也很难说明它有多大的价值。所以技术落地使技术产品实现真正价值，也正是大数据平台使得大数据技术产品可以落地应用，实现了自身价值。
所以，大数据平台不但对应用至关重要，对各种大数据技术产品也至关重要。
数据分析是大数据应用的一个主要场景，通过数据分析指标监控企业运营状态，及时调整运营和产品策略，是大数据技术的关键价值之一。互联网企业大数据平台上运行的绝大多数大数据计算都是关于数据分析的，各种统计、关联分析、汇总报告，都需要大数据平台来完成。
老板跟技术部说，我们要加强监控。技术部以为老板对程序运行监控不满意，这也是情理之中，当对技术人员说监控的时候，他们通常理解的监控就是程序运行期监控，包括操作系统监控和应用程序监控。所以技术部专门挖了做监控的专家，成立了监控运维开发团队，花了半年时间做了一个漂亮的技术运维监控系统。
老板其实想要的是运营监控，就是我下面要列举的那些运营数据指标，他需要全面快速了解这些指标，以发现公司运营中出现的问题。而技术部却给了他一个监控系统响应时间、执行超时、CPU 利用率的监控系统。
从公司角度看，运营数据是公司运行发展的管理基础，既可以通过运营数据了解公司目前发展的状况，又可以通过调节这些指标对公司进行管理，即数据驱动运营。
而运营数据的获得，需要在应用程序中大量埋点采集数据，从数据库、日志和其他第三方采集数据，对数据清洗、转换、存储，利用 SQL 进行数据统计、汇总、分析，才能最后得到需要的运营数据报告。而这一切，都需要大数据平台的支持。
互联网运营常用数据指标
不同的互联网行业关注不同的运营数据，细化来看，复杂的互联网产品关注的运营指标成百上千。但是有一些指标是我们最常用的，这些指标基本反映了运营的核心状态。
新增用户数是网站增长性的关键指标，指新增加的访问网站的用户数（或者新下载 App 的用户数），对于一个处于爆发期的网站，新增用户数会在短期内出现倍增的走势，是网站的战略机遇期，很多大型网站都经历过一个甚至多个短期内用户暴增的阶段。新增用户数有日新增用户数、周新增用户数、月新增用户数等几种统计口径。
新增的用户并不一定总是对网站（App）满意，在使用网站（App）后感到不满意，可能会注销账户（卸载 App），这些辛苦获取来的用户就流失掉了。网站把经过一段时间依然没有流失的用户称作留存用户，留存用户数比当期新增用户数就是用户留存率。
计算留存有时间窗口，即和当期数据比，3 天前新增用户留存的，称作 3 日留存；相应的，还有 5 日留存、7 日留存等。新增用户可以通过广告、促销、病毒营销等手段获取，但是要让用户留下来，就必须要使产品有实打实的价值。用户留存率是反映用户体验和产品价值的一个重要指标，一般说来，3 日留存率能做到 40% 以上就算不错了。和用户留存率对应的是用户流失率。
用户下载注册，但是很少打开产品，表示产品缺乏黏性和吸引力。活跃用户数表示打开使用产品的用户数，根据统计口径不同，有日活跃用户数、月活跃用户数等。提升活跃是网站运营的重要目标，各类 App 常用推送优惠促销消息给用户的手段促使用户打开产品。
打开产品就算活跃，打开以后是否频繁操作，就用 PV 这个指标衡量，用户每次点击，每个页面跳转，被称为一个 PV（Page View）。PV 是网页访问统计的重要指标，在移动 App 上，需要进行一些变通来进行统计。
GMV 即成交总金额（Gross Merchandise Volume），是电商网站统计营业额（流水）、反映网站营收能力的重要指标。和 GMV 配合使用的还有订单量（用户下单总量）、客单价（单个订单的平均价格）等。
转化率是指在电商网站产生购买行为的用户与访问用户之比。
用户从进入网站（App）到最后购买成功，可能需要经过复杂的访问路径，每个环节都有可能会离开：进入首页想了想没什么要买的，然后离开；搜索结果看了看不想买，然后离开；进入商品详情页面，看看评价、看看图片、看看价格，然后离开；放入购物车后又想了想自己的钱包，然后离开；支付的时候发现不支持自己喜欢的支付方式，然后离开…一个用户从进入网站到支付，完成一笔真正的消费，中间会有很大概率流失，网站必须要想尽各种办法：个性化推荐、打折促销、免运费、送红包、分期支付，以留住用户，提高转化率。
以上是一些具有普适性的网站运营数据指标，具体到不同的网站根据自身特点，会有自己的指标。比如百度可能会关注“广告点击率”这样的指标，游戏公司可能会关注“付费玩家数”这样的指标。每个产品都应该根据自身特点寻找能够反映自身运营状况的数据指标。
数据可视化图表与数据监控
为了便于分析决策，这些指标通常会以图表的方式展示，即数据可视化。数据以图表方式展示，可以更直观展示和发现数据的规律，互联网运营常用可视化图表有如下几种。
折线图是用的最多的可视化图表之一，通常横轴为时间，用于展示在时间维度上的数据变化规律，正向指标（比如日活跃用户数）斜率向上，负向指标（比如用户流失率）斜率向下，都表示网站运营日趋良好，公司发展欣欣向荣。
数据分析的时候，散点图可以有效帮助分析师快速发现数据分布上的规律与趋势，可谓肉眼聚类算法。
热力图用以分析网站页面被用户访问的热点区域，以更好进行页面布局和视觉展示。
在地图上展示的热力图则表示了该地区的拥堵和聚集状态，方便用户进行出行规划。
漏斗图可谓是网站数据分析中最重要的图表，表示在用户的整个访问路径中每一步的转化率。当重要的营收指标（GMV、利润、订单量）发生异常的时候，就必须要对整个的漏斗图进行分析，判断是网站的入口流量发生了问题，还是中间某一步的转化发生了问题；是内容的问题还是系统的问题，需要逐个进行分析排查。除了发现提升网站运营效率的关键点与方法，分析找出异常问题的根源也是数据分析最重要的工作之一。
此外还有柱状图、饼图等，也经常用于数据分析和展示。可视化图形在数据分析时可以帮助分析师更准确、更快速做出趋势预判并发现问题，在汇报工作时使用图表更有说服力，决策时也更有依据和信心。俗话说得好，“一图胜千言”，多掌握一些图表技巧可以使工作中很多事情事半功倍。
以上示例用的图表都来自于 百度开源的一个前端可视化图表组件，使用这个组件，只需要几行代码，就可以将运营数据以炫酷的方式可视化展示出来。
大数据技术最终落地必须要为企业带来实际价值，数据分析是其中最主要的应用场景之一。分析结果是最终的成果展示，在此之前，数据的采集、清洗、转换、存储、计算、分析，需要大量的工作。既然已经做了这么多工作，如何将最终的工作成果包装得更加直观、有科技感，技术人员需要换位思考，从用户角度、非技术角度去思考，争取让自己的工作更得到认可，实现更大价值。
很多互联网公司都有监控大屏，一个目的是做展示用，在公司显眼的位置放一个大屏幕，显示主要的运营指标和实时的业务发生情况，给公众和参观者展示直观的公司商业运营情况。比如天猫每年双十一的时候，都会通过大屏幕直播实时购物数据。
监控大屏的另一个目标就是实时展示业务运营状况，让我们对自己的工作成绩一目了然。如果数据突然出现波动，相关人员也可以快速响应，排查是技术问题还是运营市场问题，实现快速分析、快速解决。
企业运营的数据可以让管理者、运营人员、技术人员全面、快速了解企业的各项业务运行的状况，并发现公司可能出现的经营问题，进而能通过这些指标进行详细分析，最后定位问题的原因，并找到解决的办法。
X 网站是一家主营母婴用品的电商网站，网站运营多年，是该领域的领头者之一，各项数据指标相对比较稳定。运营人员发现从 8 月 15 日开始，网站的订单量连续四天明显下跌。由于受节假日、促销、竞争对手活动等影响，日订单量有所起伏是正常现象，所以前两天（8.15、8.16）运营人员并没有太在意。
但是，8 月 18 号早晨发现 8 月 17 号的订单量并没有恢复到正常水平，运营人员开始尝试寻找原因：是否有负面报道被扩散，是否竞争对手在做活动，是否某类商品缺货、价格异常，但是并没有找到原因。并且第二天发现订单量依然没有恢复正常，于是将问题提交给数据分析团队，作为最高优先级成立数据分析专项小组进行分析。
你从上图可以看到，8 月 15 日开始订单量明显下滑。
数据分析师第一反应是网站新增用户出现问题，因为历史上出现过类似比例的订单量下跌，当时查找到的原因是，网站的主要广告推广渠道没有及时续费，广告被下架，新增用户量明显下滑导致订单量下降。数据分析师拉取了同期的新增用户量数据，发现新增用户并没有明显下降，如下图所示。
拉出同期的日活数据查看，发现日活数据也没有明显下降，便做出基本判断：用户在访问网站的过程中，转化出了问题。
和一般的电商网站类似，X 网站的常规转化过程也是：用户打开 App，搜索关键词查找想要的商品，浏览商品搜索结果列表，点击某个商品，查看该商品的详细信息，如果有购买意向，可能会进一步咨询客服人员，然后放入购物车，最后对购物车所有商品进行支付，产生有效订单。X 网站的转化漏斗如下。
如果定义打开 App 为活跃，那么网站的整体转化就是活跃到订单的转化，公式为：
显然从 15 号开始，这个转化率开始下降，但转化过程有多个环节，那么具体是哪个环节出了问题呢？数据分析师对转化过程每个环节计算转化率。例如：
以此类推，每个环节都可以计算其转化率，将这些转化率的近期历史数据绘制在一张折线图上，就可以看到各个环节转化率的同期对比视图。
由于比例关系，图中可能不太明显，但是还是可以看出，有明显降幅的是咨询详情转化率（最下方折线），降幅接近 10%。调查客服也没有发现异常情况，进一步对咨询信息分类统计后发现，新用户的咨询量几乎为 0，明显不合常理。
数据分析师自己注册了一个新用户然后发起咨询，没有得到回复。查询后台，发现咨询信息没有到达客服。于是将问题提交给技术部门调查，工程师查看 8 月 15 日当天发布记录，发现有消息队列 SDK 更新，而咨询信息是通过消息队列发给客服的。进一步调查发现是程序 bug，新用户信息构建不完整，导致消息发送异常。
最后紧急修复 bug 发布上线，第二天订单量恢复正常。
辩证唯物主义告诉我们，这个世界是普遍联系的，任何事物都不是孤立存在的。所以当出现运营数据异常的时候，引起异常的原因可能有很多，越是根本性的问题，越是有更多引起问题的可能，如何进行数据分析，其实并不是一件简单的事。
数据分析中，有一种金字塔分析方法。它是说，任何一个问题，都可能有三到五个引起的原因，而每个原因，又可能有三到五个引起的子原因，由此延伸，组成一个金字塔状的结构。我们可以根据这个金字塔结构对数据进行分析，寻找引起问题的真正原因。
上面案例中一开始运营人员自己寻找订单量下降原因的时候，其实就用了金字塔分析方法。
金字塔分析方法可以全面评估引起问题的各种原因，但是也可能会陷入到太过全面，无从下手或者分析代价太大的境况。所以要根据经验和分析，寻找主要原因链路。绝大多数互联网产品的主要原因链路就在转化漏斗图上，上面案例中，数据分析师的分析过程，基本就集中在转化漏斗上。
我曾经看过某独角兽互联网公司的数据运营指导文件，对于几个关键业务指标的异常必须要及时通知高管层，并在限定时间内分析异常原因。而指导分析的链路点，基本都在转化漏斗图上，只不过因为入口渠道众多，这样的分析链路也有很多条。
这种金字塔方法不仅可以用于数据分析过程，在很多地方都适用，任何事情都可以归纳出一个中心点，然后几个分支点，每个分支点又有几个子分支。构建起这样一个金字塔，对于你要表达的核心观点，或者要学习知识，都可以有一个清晰的脉络，不管是和别人交流，还是自己思考学习，都很有帮助。
上面画的金字塔分析图其实就是思维导图，我的大数据专栏的知识点也可以用金字塔方法描述。
数据分析是大数据最主要的应用场景，很多企业所谓的大数据其实就是大数据分析，而大数据分析也确实能够对企业管理和运营起到积极的推进作用。而企业的管理、产品、技术过程中的各种决策、外部市场环境的变化，也都会在数据上反映出来。关注数据分析，抓住数据，就能抓住企业运行的关键。而企业在运营过程中出现的问题，也可以通过数据分析定位，发现引起问题的原因，并从根本上解决问题。
在网站和 App 的产品设计中，经常会遇到关于哪种产品设计方案更优的思考和讨论：按钮大一点好还是小一点好；页面复杂一点好还是简单一点好；这种蓝色好还是另一种蓝色好；新的推荐算法是不是真的效果好…这种讨论会出现在运营人员和产品经理之间，也会出现在产品经理和工程师之间，有时候甚至会出现在公司最高层，成为公司生死存亡的战略决策。
在 Facebook 的发展历史上，曾经多次试图对首页进行重大改版，甚至有时候是扎克伯格亲自发起的改版方案，但是最终所有的重大改版方案都被放弃了，多年来 Facebook 基本保持了一贯的首页布局和风格。
相对应的是，一直被认为抄袭 Facebook 的人人网在 Facebook 多次改版举棋不定的时候，毅然进行了重大的首页改版，摆脱了长期被诟病的抄袭指责。但是讽刺的是，事后回头再看，伴随着人人网改版的是用户的快速流失，并最后导致了人人网的没落，而 Facebook 的守旧却保证了 Facebook 的持续发展。
让 Facebook 放弃改版决定的，正是 Facebook 的 A/B 测试。Facebook 开发出新的首页布局版本后，并没有立即向所有用户发布，而是随机选择了向大约 1% 的用户发布，即这 1% 的用户看到的首页是新版首页，而其他用户看到的还是原来的首页。过一段时间后观察两部分用户的数据指标，看新版本的数据指标是否好于旧版本。
事实上 Facebook 观察到的结果可不乐观，新版本的用户数据指标呈下跌状态。扎克伯格不甘心，要求继续放大新版测试用户的比例，运营团队一度将新版测试用户的比例放大到 16%，但是数据显示新版并不受用户欢迎，数据指标很糟糕。最后扎克伯格决定放弃新版，首页维持原来布局。
A/B 测试是大型互联网应用的常用手段。如果说设计是主观的，那么数据是客观的，与其争执哪种设计更好、哪种方案更受用户欢迎，不如通过 A/B 测试让数据说话。如果人人网当初认真做 A/B 测试，也许不会贸然改版；据说今日头条为了论证两条新闻之间的分割究竟应该用多宽的距离，同样是做了数百组 A/B 测试。
所以 A/B 测试是更精细化的数据运营手段，通过 A/B 测试实现数据驱动运营，驱动产品设计，是大数据从幕后走到台前的重要一步。
A/B 测试将每一次测试当作一个实验。通过 A/B 测试系统的配置，将用户随机分成两组（或者多组），每组用户访问不同版本的页面或者执行不同的处理逻辑，即运行实验。通常将原来产品特性当作一组，即原始组；新开发的产品特性当作另一组，即测试组。
经过一段时间（几天甚至几周）以后，对 A/B 测试实验进行分析，观察两组用户的数据指标，使用新特性的测试组是否好于作为对比的原始组，如果效果比较好，那么这个新开发的特性就会在下次产品发布的时候正式发布出去，供所有用户使用；如果效果不好，这个特性就会被放弃，实验结束。
对于一个大型网站，通常都会开发很多新产品特性，其中很多特性需要进行 A/B 测试，所以在进行流量分配的时候，每个特性只会分配到比较小的一个流量进行测试，比如 1%。但是由于大型网站总用户量比较大，即使是 1% 的用户，实验得到的数据也具有代表性了。Facebook 拥有几十亿用户，如果 A/B 测试的新特性对用户不友好，那么即使只测试 1% 的用户，也有几千万用户受到影响。所以，在进行
A/B 测试时对实验流量和特性的选择也要谨慎对待。
A/B 测试的系统架构
A/B 测试系统最重要的是能够根据用户 ID（或者设备 ID）将实验配置参数分发给应用程序，应用程序根据配置参数决定给用户展示的界面和执行的业务逻辑，如下图。
在实验管理模块里进行用户分组，比如测试组、原始组，并指定每个分组用户占总用户的百分比；流量分配模块根据某种 Hash 算法将用户（设备）分配到某个实验组中；一个实验可以有多个参数，每个组有不同的参数值。
移动 App 在启动后，定时和 A/B 测试系统通信，根据自身用户 ID 或者设备 ID 获取自己参与的 A/B 测试实验的配置项，根据配置项执行不同的代码，体验不同的应用特性。应用服务器和 A/B 测试系统在同一个数据中心，获取实验配置的方式可以更灵活。
移动 App 和应用服务器上报实验数据其实就是传统的数据采集，但是在有 A/B 测试的情况下，数据采集上报的时候需要将 A/B 测试实验 ID 和分组 ID 也上报，然后在数据分析的时候，才能够将同一个实验的不同分组数据分别统计，得到 A/B 测试的实验数据报告。
经过 A/B 测试验证过的功能特性，就可以发布到正式的产品版本中，向所有用户开放。但是有时候在 A/B 测试中表现不错的特性，正式版本发布后效果却不好。此外，A/B 测试的时候，每个功能都应该是独立（正交）的，正式发布的时候，所有的特性都会在同一个版本中一起发布，这些特性之间可能会有某种冲突，导致发布后的数据不理想。
解决这些问题的手段是灰度发布，即不是一次将新版本发布给全部用户，而是一批一批逐渐发布给用户。在这个过程中，监控产品的各项数据指标，看是否符合预期，如果数据表现不理想，就停止灰度发布，甚至进行灰度回滚，让所有用户都恢复到以前的版本，进一步观察分析数据指标。
灰度发布系统可以用 A/B 测试系统来承担，创建一个名叫灰度发布的实验即可，这个实验包含这次要发布的所有特性的参数，然后逐步增加测试组的用户数量，直到占比达到总用户量的 100%，即为灰度发布完成。
灰度发布的过程也叫作灰度放量，灰度放量是一种谨慎的产品运营手段。对于 Android 移动 App 产品而言，因为国内存在很多个应用下载市场，所以即使没有 A/B 测试系统，也可以利用应用市场实现灰度发布。即在发布产品新版本的时候，不是一次在所有应用市场同时发布，而是有选择地逐个市场发布。每发布一批市场，观察几天数据指标，如果没有问题，继续发布下一批市场。
A/B 测试的目的依然是为了数据分析，因此通常被当作大数据平台的一个部分，由大数据平台团队主导，联合业务开发团队和大数据分析团队合作开发 A/B 测试系统。A/B 测试系统囊括了前端业务埋点、后端数据采集与存储、大数据计算与分析、后台运营管理、运维发布管理等一个互联网企业几乎全部的技术业务体系，因此开发 A/B 测试系统有一定难度。但是一个良好运行的 A/B
测试系统对企业的价值也是极大的，甚至可以支撑起整个公司的运营管理。
利用大数据成为“增长黑客”
增长黑客是近几年颇为流行的一个词汇，它是指利用数据、技术、产品等一系列手段为互联网产品获得快速用户增长的人。互联网的访问没有边界，用户量的增加对应成本的增加也几乎可以忽略不计，所以如何快速、大规模获取用户是互联网产品的成功之道，我们所熟知的成功的互联网公司，例如国内的 BAT、国外的 FLAG，都拥有数亿甚至数十亿的用户。
你有没有曾经幻想过“如果全国人民每人给我一块钱，我就成了亿万富翁”？事实上，这种想法并不天真，在互联网时代，你只要让全国人民都知道你，你肯定就能成为亿万富翁。因为我们处在一个注意力和流量可以变现的时代，支付宝在微博上随机抽取一个“锦鲤”，这个人瞬间就能得到全国人民的关注，然后就能财富自由周游世界了。还有那些拥有数百万粉丝的网红，年收入一般都能上百万。所以我们看到，在微博、在快手、在抖音，很多人费尽心机求关注、求点赞，因为这些关注和点赞最后都能变现为财富。
互联网产品也一样，如果你能拥有大量的用户，你就成功了。所以我们看到互联网公司，特别是初创互联网公司，为了获得用户，为了用户数量增长可以说是费尽心机。淘宝在成立的时候，马云给淘宝管理团队的指示是“不要赚钱”。那么不要赚钱要什么？答案是要用户，要增长。所以淘宝 2003 年成立，到 2009 年一直在亏损，但是用户量在飞速增长，后面开始盈利以后，就仿佛开启了印钞机，赚得盆满钵满。
那么如何才能获得用户呢？传统的做法是打广告，在各种媒体进行曝光，向用户推销自己的产品。但是这种方法投入大、见效慢，不能满足互联网产品的增长要求，互联网产品必须利用自己的特点寻求不一样的增长之道，这就是增长黑客这一互联网特有的角色出现的背景。下面我给你讲一个“增长黑客”的传奇故事。
Hotmail 是两个工程师的创业项目，他们用网页方式提供电子邮箱服务，而当时其他的电子邮箱都需要安装客户端才能使用，因此他们的产品很创新，技术也很先进，对用户也很有价值。但是问题是如何才能把这么好的产品推广给使用电子邮件的目标人群呢？传统推广渠道不合适，一来是两人没那么多钱，二来是传统媒体的用户也不是电子邮件的用户。关于如何寻找目标用户，如何向他们推广 Hotmail
邮箱，两人想来想去，最后想出一个绝妙的主意：他们在用户使用 Hotmail 发送的每一封邮件的结尾处，附了一行字：“我爱你，快来 Hotmail 申请你的免费邮箱”。
这一很小的改动产生了戏剧性的效果，Hotmail 像病毒一样开始传播，仅仅几个小时后，Hotmail 用户数就开始快速增长。六个月的时间，Hotmail 获得了 100 万的用户，然后只用了五周的时间，又获得了 100 万用户。就这样，Hotmail 用了一年多的时间，让当时全球 20% 的网民成为自己的用户，数量大约是 1500 万。后面的故事我们就很熟悉了，Hotmail
现在，距离 Hotmail 创业已经过去 20 多年了，互联网产业也进入了“下半场”，简单复制 Hotmail 的做法很难再现奇效，但是综合利用大数据、智能推荐、病毒营销等一系列手段，依然能够创造奇迹，典型的案例就是拼多多。拼多多于 2015
年成立，那时人们普遍认为电商的互联网格局已经形成，后来者的机会已经不多了。但是就是在这样的情况下，拼多多只用了两年时间订单量就超过了京东，成立三年完成上市，让京东、淘宝等电商巨头寝食难安。
关于用户增长有一个著名的 AARRR 模型，它描述了用户增长的 5 个关键环节，分别是：获取用户（Acquisition）、提高活跃度（Activation）、提高留存率（Retention）、获取收入（Revenue）和自传播（Refer）。
- 获取用户：通过各种推广手段，使产品触达用户并吸引用户，让用户访问我们的产品。
- 提高活跃度：用户访问我们的产品后，如果发现没意思、体验差，就很难再次打开，产品的价值也就无法实现。因此需要结合产品内容、运营活动各种手段吸引用户，提升产品的活跃度。
- 提高留存率：留住一个老用户的成本远低于获取一个新用户，而真正为产品带来营收利润的通常是老用户，因此需要提高留存率。提高留存率的常用手段有：针对老用户推出各种优惠和活动；建立会员等级体系，注册时间越长等级越高；对于一段时间没有访问的疑似流失用户进行消息短信推送以实现用户挽回等。
- 获取收入：做企业不是做慈善，开发、运营互联网产品的最终目的还是为了赚钱，即获取收入。互联网产品收入主要有用户付费和广告收入，有些互联网产品看起来是用户付费，但其实主要营收是广告收入，比如淘宝。
- 自传播：让用户利用利用自己的社交网络进行产品推广就是自传播，几乎所有的互联网产品都有“分享到”这样一个功能按钮，促进用户社交传播。有些产品还会利用“帮我砍价”“帮我抢票”等产品功能推动用户进行分享，实现产品的裂变式传播、病毒式营销。
我还以拼多多为例，一起看看拼多多如何利用 AARRR 模型实现用户快速增长。
- 拼多多是近几年互联网产品中将自传播发挥到极致的一个产品。拼多多用户群体主要为三四线以下城市人群，社交成本比较低，愿意为了砍几块钱发动自己的各种社交资源，因此拼多多就利用“帮好友砍价”这一功能实现产品的快速裂变传播。事实上，拼多多非常准确地抓住了这一群体的社交痛点：交往不多的朋友，与其尬聊维持友谊，不如帮我砍价来的更实惠更亲密。
- 自传播也是拼多多主要获取用户的手段。比如帮好友砍价时，拼多多会提示“下载 App 可以帮好友砍更多价”，于是用户量呈指数级增长。
- 拼多多为了让新来的用户快速上手、增加活跃度，用户第一次使用拼多多的时候，并不需要注册登录，直接就可以挑选商品和购买，在后面订单环节再让用户注册，这时用户已经产生购买冲动，进行注册也更容易被接受。
- 拼多多通过各种消息推送促使用户打开 App（或者微信小程序），并在开屏页面的优惠信息给用户制造惊喜，达到留存用户的目的。
- 拼多多的主要交易模式为拼团，拼团属于冲动型购买，拼多多为了减少用户的思考时间、维持购买冲动，将购买路径设计得尽可能短，使用户可以尽快完成付费，企业获取收入
利用大数据增长用户数量
AARRR 增长模型的各个环节其实都离不开大数据的支持，具体是利用大数据分析和计算，增长用户的手段主要有：
- 利用用户画像进行精准广告获客。比如微信朋友圈的广告，通过对用户微信数据的分析进行用户画像。投放广告的时候，可以精确使用用户标签进行广告投放，获取到有效的客户，即所谓的广告选人。
- 通过用户分析挽回用户。我在前面说过，互联网产品的用户留存很难超过 40%，对于流失用户，可以通过短信、推送等手段进行挽回，比如根据用户注册信息，推送用户感兴趣的商品、折扣券、红包等信息，重新激活用户。留存用户由于某些原因也会再次流失或者沉默，通过用户价值分析和流失原因分析，也可以进一步采用各种运营策略挽回用户。
- A/B 测试决定产品功能。新功能通过 A/B 测试进行数据分析，分析是否对用户留存、购买转化等关键指标有正向作用，以此决定是否上新功能。
- 大数据反欺诈、反羊毛。互联网产品在拉新或提高留存的过程中，会有很多促销手段，但是这些促销手段会吸引来专业的“羊毛党”，他们会注册大量虚假账号，然后领取红包，使企业的促销资源无法投放到真正的用户手中。此时可以通过历史数据、用户点击行为分析等大数据技术，有效识别出“羊毛党”。
- 用户生命周期管理。一个互联网产品的用户会经历获取、提升、成熟、衰退、离网几个阶段，用户在不同的生命周期阶段会有不同的诉求，通过数据分析对用户进行分类，可以有针对性的运营，进一步提升用户的留存和转化。
上面提到的推荐、用户画像等都属于大数据算法的技术范围。
今天我给你讲了增长黑客以及他们所关注的增长模型，对于应用大数据技术帮助产品提高增长，主要就是利用大数据分析发现产品运营中的各种规律，然后用大数据算法针对特定的用户提供各种个性化的服务，以实现产品的用户增长、营收增长，最终将企业做大做强。
互联网进入下半场，以前那种产品 OK、团队给力，就可以野蛮、快速增长的时代已经过去了。现在用户增长的各个环节都需要进行精细化运营，才能在竞争中获得优势，而精细化运营则必须依赖海量的用户、商品、行为数据才能完成，这都是大数据技术的用武之地。
为什么说数据驱动运营？
当我们谈论大数据的时候，我们究竟在谈什么？是谈 Hadoop、Spark 这样的大数据技术产品？还是谈大数据分析、大数据算法与推荐系统这样的大数据应用？其实这些都是大数据的工具和手段，大数据的核心就是数据本身。数据就是一座矿山，大数据技术产品、大数据分析与算法是挖掘机、采矿车，你学了大数据，每天开着矿车忙忙碌碌，那你只是一个矿工，可能每天面对一座金山却视而不见。
数据比代码的地位要高得多，用途也大得多，做大数据的同学要意识到数据的重要性。数据的作用是无处不在的，不但能做统计分析、精准营销、智能推荐，还能做量化交易帮你自动赚钱，甚至能驱动公司运营，管理整个公司。今天这篇答疑就是想把数据的地位认识拔高一些，让你知道自己学大数据究竟能做什么。
关于中国互联网三巨头 BAT（百度、阿里巴巴、腾讯）的企业组织与管理，江湖上有一种常见的说法是：百度是技术驱动的，阿里巴巴是运营驱动的，腾讯是产品驱动的。
也就是说，百度的公司增长与进步主要是通过工程师的技术创新实现的，工程师在技术上有所突破和创新后，调动公司产品、运营，甚至公关、法务方面的资源进一步扩大占领市场。工程师在公司拥有优势地位，在公司内能整合各方资源，驱动公司发展与进步。
相对应的，在阿里巴巴，运营人员拥有核心地位，马云的战略决策和运营指标下达给运营人员，运营人员千方百计通过各种手段，主要是产品和技术手段，完成运营指标，实现公司战略。在淘宝，所有员工都自称“小二”，站在运营角度开展工作，通过运营整合公司资源，驱动公司进步。
而在腾讯，公司的发展壮大则主要靠产品取胜，产品经理思考用户体验和产品特性，耐心打磨自己的产品，让用户在使用过程中被产品吸引，扩大产品的市场占有。腾讯的核心人物马化腾和张小龙都称自己为产品经理，公司资源也围绕产品展开。
作为业界翘楚，在成长过程中逐渐摸索出适合自身的组织管理和内部驱动方式，但是更多的互联网企业，包括一些知名的互联网企业，还没有找到科学的管理方式。这其中发展好一点的企业通常采用一种叫作“老板驱动型”的管理方式，老板事无巨细亲自关心业务，员工一旦没有老板的指示，就茫然失措，不知道自己该干什么。而差一点的企业则会进入到一种“老板也不知道怎么驱动型”的管理状态，大家忙忙碌碌，却像是在做布朗运动，不但不能进步，甚至连个像样的失败都没有。
一般的互联网企业的组织方式是下面这样的。
通常的工作模式是：首先，老板有个想法，或者运营有个点子，又或者市场有个反馈；然后运营人员把这个想法、点子、反馈变成一个业务需求提交给产品团队；接着产品经理和设计师进行需求分析、产品设计，将产品需求提给技术团队；最后工程师将这些功能开发完成，发布上线供用户使用。
一个点子从提出到开发上线，通常需要数周乃至数月的工作量；而开发资源一般总是紧缺的，产品需求需要进行开发排期，短则数天、长则数月。因此一个业务需求从提出到上线，要经过较长一段时间。往往工程师加班加点开发了一个新功能，上线以后这个功能的提出者已经失去了提出时激情，甚至已经忘了这个功能。没有后续的推广运营，没有进一步的迭代增强，这个新功能就变成产品的一个鸡肋，直至无人问津。
大多数互联网企业，保守估计的话至少 80% 的业务需求没有实现最初期望的价值，相当一部分功能甚至完全没有起任何作用。5 个工程师开发 3 周的红包功能最后只有两个用户领取，3 个工程师开发一个月的活动小游戏只有区区几百个点击…这样的事例在现实中不胜枚举。
导致这个现象的一个原因是整个工作流程缺乏反馈，运营不断提需求，产品不断做设计，工程师忙着搬砖，自己做的工作对公司业务有多大价值却缺乏思考，为了工作而工作。除非有个头脑敏捷又精力旺盛的老板在其中不断干预，各个环节全方位参与，否则公司就会进入一种忙忙碌碌却没有进步的境地。而且即使有这样的老板，这样的公司也很难做大。
说了那么多问题，我们的目标还是要解决它。一个解决办法是引入业务数据监控，在提出一个新需求时，就需要对价值进行预估：这个新功能可以有多少点击，可以提高多少留存、多少转化，对预期价值进行量化。产品和开发需要知道预期价值，如果对价值有疑惑，可以提出质疑，多方一起讨论，对需求进行完善。新功能上线后，对新功能的业务指标进行持续监控，检验是否达到当初的预期；如果没有，提出后续改进的措施。
从上面的图中你可以看到，通过业务数据的反馈从而使公司的工作流程变成一个闭环，用户数据会成为运营团队想法策略的重要输入，工作目标和团队协作围绕数据展开。老板只需要对数据提出合理的目标和期望，就可以驱动团队有效运作，使团队之间的合作或竞争都集中在实现公司商业价值这个根本目的上来。
从上面的图中你可以看到，通过业务数据的反馈从而使公司的工作流程变成一个闭环，用户数据会成为运营团队想法策略的重要输入，工作目标和团队协作围绕数据展开。老板只需要对数据提出合理的目标和期望，就可以驱动团队有效运作，使团队之间的合作或竞争都集中在实现公司商业价值这个根本目的上来。
事实上，公司到了一定规模，产品功能越来越复杂，人员越来越多，不管用什么驱动，最后一定都是数据驱动。没有量化的数据，不足以凝聚团队的目标，甚至无法降低团队间的内耗。这个时候哪个部门能有效利用数据，能用数据说话，能用数据打动老板，哪个部门就能成为公司的驱动核心，在公司拥有更多话语权。我们学大数据，手里用的是技术，眼里要看到数据，要让数据为你所用。数据才是核心才是不可代替的，技术并不是。
数据，不管你用还是不用，它就在那里。但是它的规律与价值，你不去分析、挖掘、思考，它不会自己跳出来告诉你答案。顶尖的高手，总是能从看似不相干的事物之间找到其联系与规律，并加以利用，产生出化腐朽为神奇的功效。我们应该对数据保持敏感与好奇，不断将现实发生的事情与数据关联起来，去思考、去分析，用数据推断出来的结论指导现实的工作，再根据现实的反馈修正自己的方法与思维，顶尖高手就是在这样的训练中不断修炼出来的。
现实纷繁复杂，其呈现出来的表象距其本质通常相去甚远，甚至南辕北辙。根据表象见招拆招，只会让你陷入现实纷乱的漩涡，疲惫且无效，就像热锅上的那只蚂蚁。数据作为对事物的一次抽象，能够强迫你去思考事物背后的规律与本质，并在思考过程中逐渐把握事物发展的脉络与走向，抢占先机，掌控局面。“君子生非异也，善假于物也”，用好数据，方能洞悉真相。
