1.1 数据流程

不管是时髦的大数据还是之前传统的数据仓库，不管是目前应用最为广泛的离线数据还是越来越得到重视的实时数据，其端到端流程都包含：数据产生、数据采集和传输、数据存储处理、数据应用四大过程，具体的数据流程图及其包含的关键环节如图1-1所示。

下面详述图1-1所示的各个关键关节。

1.1.1 数据产生

数据产生是数据平台的源头，没有数据，所谓的大数据也无从谈起。所以首先要保证有数据。

随着近年来互联网和移动互联网的蓬勃发展，数据已经无处不在，毫无疑问，这是一个数据和信息爆炸的时代。所以，即使一个企业和个人没有数据，通过爬虫工具和系统的帮助，也可以从互联网上爬取到各种各样的公开数据。但是更多的、高质量的数据是爬取不到的，这些数据存在于各个公司、企业、政府机关和机构的系统内部。

1．数据分类

根据源头系统的类型不同，我们可以把数据产生的来源分为以下几种。

（1）业务系统

业务系统指的是企业核心业务的或者企业内部人员使用的、保证企业正常运转的IT系统，比如超市的POS销售系统、订单/库存/供应链管理的ERP系统、客户关系管理的CRM系统、财务系统、各种行政系统等。不管何种系统，后台的数据一般都存在后台数据库内。早期的大部分数据主要来源于这些业务系统的数据库，管理人员和业务运营人员查看的数据报表等基本来源于此。即便是目前，企业的业务系统依然是大部分公司数据平台的主要数据来源，业务系统的数据通常是格式化和高质量的。

（2）Web系统

随着互联网的发展，很多系统都变成了Web系统，即互联网或者局域网范围内通过浏览器就可以访问，而不是必须安装客户端软件才能访问的系统（这种就是传统的业务系统）。Web系统也会有用于存储各种格式化数据的后台数据库，但除此之外，还有各种用户行为日志，比如用户通过何种途径访问了本网站（搜索引擎、直接输入Web网址、其他系统跳转等），在网站内都有何种行为（访问了哪些网页、点击了哪些按钮、停留了多长时间）。通过cookie以及各种前端埋点技术，用户的这些行为都可以被记录下来，并保存到相应的日志文件内。Web系统的日志文件通常是非格式化的文本文件。Web系统和业务系统不是互相对立的，比如现在的ERP系统通常也支持Web和浏览器访问。

（3）手机App

在当今的移动互联网时代，作为移动互联网的基础设施，手机App已经渗透到所有人的吃穿住行，毫不夸张地说，手机俨然称得上是一个身体的“新器官”；另一方面，通过手机的内置传感器可以知道你是谁（指纹识别、虹膜识别、人脸识别），你在哪里（GPS、WiFi和移动网络）和你在干什么（吃穿住行App），当然移动App也会记录你在该App上的各种行为，比如你打开了几次App、点击了哪些页面和使用了哪些功能。

（4）外部系统

很多企业除了自己内部的数据，还会通过爬虫工具与系统来爬取竞争对手的数据和其他各种公开的数据，此外企业有时也会购买外部的数据，以作为内部数据的有益补充。

（5）人工整理

尽管通过各种内部和外部系统可以获取到各种数据，但有些数据是无法直接由系统处理的，必须通过人工输入和整理才能得到，典型的例子是年代较久的各类凭证、记录等，通过OCR识别软件可以自动识别从而简化和加快这类工作。

以上从IT系统的类型介绍了数据产生的源头，从数据的本身特征，数据还可以分为以下几类。

（1）结构化数据

结构化数据的格式非常规范，典型的例子是数据库中的数据，这些数据有几个字段，每个字段的类型（数字、日期还是文本）和长度等都是非常明确的，这类数据通常比较容易管理维护，查询、分析和展示也最为容易和方便。

（2）半结构化数据

半结构化数据的格式较为规范，比如网站的日志文件。这类数据如果是固定格式的或者固定分隔符分隔的，解析会比较容易；如果字段数不固定、包含嵌套的数据、数据以XML/JSON等格式存储等，解析处理可能会相对比较麻烦和繁琐。

（3）非结构化数据

非结构化数据主要指非文本型的、没有标准格式的、无法直接处理的数据，典型代表为图片、语音、视频等，随着以深度学习为代表的图像处理技术和语音处理技术的进步，这类数据也越来越能得到处理，价值也越来越大（比如最近Facebook公布了他们基于深度学习技术的研究成果，目前已经可以初步识别图片中的内容并就图片内容标注标签）。通常进行数据存储时，数据平台仅存储这些图片、语音和视频的文件地址，实际文件则存放在文件系统上。

2．数据埋点

后台数据库和日志文件一般只能够满足常规的统计分析，对于具体的产品和项目来说，一般还要根据项目的目标和分析需求进行针对性地“数据埋点”工作。所谓埋点，就是在额外的正常功能逻辑上添加针对性的统计逻辑，即期望的事件是否发生，发生后应该记录哪些信息，比如用户在当前页面是否用鼠标滚动页面、有关的页面区域是否曝光了、当前用户操作的时间是多少、停留时长多少，这些都需要前端工程师进行针对性地埋点才能满足有关的分析需求。

数据埋点工作一般由产品经理和分析师预先确定分析需求，然后由数据开发团队对接前端开发和后端开发来完成具体的埋点工作。

随着数据驱动产品理念和数据化运营等理念的日益深入，数据埋点已经深入产品的各个方面，变成产品开发中不可或缺的一环。数据埋点的技术也在飞速发展，也出现了一批专业的数据分析服务提供商（如国外的Mixpanle和国内的神策分析等），尽管这些公司提供专门的SDK可以通用化和简化数据埋点工作，但是很多时候在具体的产品和项目实践中，还是必须进行专门的前端埋点和后端埋点才可以满足数据分析与使用需求。

1.1.2 数据采集和传输

业务系统、Web系统、手机App等产生的数据文件、日志文件和埋点日志等分散于各个系统与服务器上，必须通过数据采集传输工具和系统的帮助，才能汇总到一个集中的区域进行关联和分析。

在大数据时代，数据量的大当然重要，但更重要的是数据的关联，不同来源数据的结合往往能产生1+1＞2甚至1+1＞10的效果。另一个非常关键的点是数据的时效性，随着时间的流失，数据的价值会大打折扣，只有在最恰当的时间捕捉到用户的需求，才会是商机，否则只能是错失时机。试想一下，如果中午用户在搜索“西餐厅”，只有在这一刻对用户推送西餐厅推荐才是有效的，数分钟、数十分钟、数小时后的推送效果和价值将逐步递减。而实现这些必须借助于专业的数据采集传输工具和系统的帮助。

过去传统的数据采集和传输工具一般都是离线的，随着移动互联网的发展以及各种个性化推荐系统的兴起，实时的数据采集和传输工具越来越得到重视，可以毫不夸张地说，数据采集传输工具和系统已是大数据时代的关键基础设施。

数据产生的来源有很多，但是其物理存在表现形式主要为文本文件和数据库两种。理论上来说，数据采集和传输无非就是把一个地方的数据从源头复制到目的地，文本文件可直接复制，数据库也可以通过创建数据库连接直接拖数据，但是数据采集传输的挑战在于：数据可能分布在不同的数据中心，数据库也可能是分库分表的，而数据采集也不能对生产系统库有任何性能上的影响，最好也不需要产品开发、DBA或系统管理员的过多介入，有时候还必须能够做到毫秒级的实时采集，而这些都必须借助专业的数据采集传输工具和系统才能完成，比如专业的数据采集传输工具不会通过建立数据库连接来采集数据，而会通过解析数据库日志来进行。在无须数据库DBA、系统管理员和产品开发介入的情况下（只需要开通权限即可）高效地完成数据采集和同步的任务。

1.1.3 数据存储处理

数据采集同步后的数据是原始的和杂乱的，必须经过专门的清洗、关联、规范化和精心的组织建模，而且要通过数据质量检测后才能进行后续的数据分析或用于提供数据服务，而这就是数据平台构建的第三个关键关节——数据存储处理。大数据项目和数据平台构建的实践表明，数据存储处理通常占用整个项目至少1/3以上的时间，这一环节的设计是否合理、最终的数据是否稳定可靠、建模是否灵活可扩展直接决定后续数据应用的成败，也决定了整个数据平台项目的成败。

数据存储处理也是数据领域最为激动人心和百花齐放的领域，各种开源技术框架和创新层出不穷，但是万变不离其宗，根据下游数据使用方的时效性，我们可以把数据存储处理工具和技术分为离线处理、近线处理和实时处理，处理后的数据也相应地存储于离线数据仓库、近线数据存储区和实时数据存储区。

离线处理一般按天进行数据处理，每天凌晨等数据采集和同步的数据到位后，相关的数据处理任务会被按照预先设计的ETL（抽取、转换、加载，一般用来泛指数据清洗、关联、规范化等数据处理过程）逻辑以及ETL任务之间的拓扑关系依次调用，最终的数据会被写入离线数据仓库中。离线数据仓库中的数据通常是按照某种建模思想（最常用的是维度建模思想）精心组织的，这样既可以使下游用户非常直观和方便地使用，又可以使数据处理过程很方便地扩展和修改。

从各个源头系统采集同步过来的离线数据，通常放在一个Staging Area（暂存区，也叫登台区），进行便于后续的离线ETL处理。离线数据的存储处理技术发展已经比较成熟，也有很多成熟的ETL工具、商业/开源数据仓库和解决方案。这些商业或者开源的数据仓库工具和解决方案在数据量不是很大和解决结构化数据方面还是比较成功的，但是随着Google关于分布式计算三篇论文的发表内容主体分别是分布式文件系统Google File System，分布式计算框架MapReduce，分布式数据库Bigtable）和基于Google三篇论文开源实现的Hadoop生态系统（分别对应Google三篇论文——HDFS, MapReduce, HBase）兴起，大数据时代真正到来，这些传统的商业和开源数据仓库工具与解决方案在成本及可扩展性方面的劣势日益显现，不仅仅是互联网公司，越来越多的传统公司也日渐转向基于Hadoop生态系统的数据仓库工具和解决方案。

大数据时代对于数据的使用已经不限于离线数据的分析，实时数据正变得越来越重要，而这必须借助专业的流计算工具和框架才能实现。目前最为流行和使用广泛的流计算框架是Storm/类Storm的流处理框架和Spark生态的Spark Streaming等。国内外大厂在使用这些开源框架的同时，还结合自身的使用实践对这些流计算框架从不同层面进行改进和创新，如稳定性、可扩展性、性能等，但是笔者认为这其中最具革命性的是SQL抽象层的出现。SQL抽象层使得实时开发用户不必写Java或者其他编程语言来开发实时处理逻辑，不但大大加快了实时开发的效率，而且大大降低了实时开发的门槛。通常，实时处理的结果会写入实时存储区（比如HBase），以提供高可靠和高并发的实时数据服务，比如用户的实时画像和实时搜索请求，后续的个性化推荐系统或者智能处理程序直接访问此实时存储区就可以实现实时数据服务。

近线数据的时效性于离线（以“天”为单位）和实时（以毫秒/秒为单位）之间，比如最近1小时的数据或者最近15分钟的数据。近线数据兼有离线批次处理的便捷性和实时数据的时效性优势，通常是业务需求和技术可实现性折中的结果。近线数据可以通过提高离线任务调度频次来实现，但是必须有相关的数据采集同步工具提供近线数据源头的支持。

离线和在线以及近线的划分，是目前数据工业界的技术现状，但这样是合理的吗？为什么同样的业务逻辑必须用离线和在线两种技术分别实现？离线的批处理难道不是实时流处理的一种特例吗？离线的批处理和实时的流处理为什么不能实现融合（用一种技术来实现），同样的逻辑为什么要存在于离线和实时两个地方？2015年和2016年以来涌现出来的Apache Flink和Apache Beam等就是同时针对流数据和批数据两者的分布式数据处理引擎，这些技术已经逐渐成熟并大量进入生产环境中使用，这些技术代表了未来大数据处理的方向。

1.1.4 数据应用

数据的精心埋点、海量离线数据同步和毫秒级的实时数据采集、繁琐的数据处理和精心的数据建模，这些都为数据使用奠定了坚实的基础，但是数据最终发挥价值依赖于数据应用环节。

数据应用最广泛的方式是“看”，比如决策层和管理人员定时查看的公司/部门业务日报、业务周报和业务月报，一线运营人员查看的运营指标和报表，分析师给业务决策和业务运营参考的数据分析报告，还有分析人员和业务人员不定时的即席分析等。这些数据报表帮助企业管理人员、产品和项目管理人员及一线运营人员定位企业、产品和项目中的问题、隐患和发力方向，并及早采取措施修正方向或者看到正确趋势后加大投入。可以毫不夸张地说，一个企业“看”数据的能力代表了这个企业的数据应用能力水平，也是其核心竞争力之一。

随着大数据时代和人工智能热潮的到来，数据已经不仅局限于“看”。Google的超级搜索框、淘宝的“千人千面”个性化推荐系统、新闻聚合推荐App今日头条都代表着数据和算法结合的成功，也彰显着数据+算法的威力。借助数据挖掘、机器学习算法和深度学习算法以及在线数据服务等技术，数据已经成为在线生产系统的一部分。