作者：朱松岭
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
离线和实时大数据开发实战试读：
前言
为什么要写这本书
念念不忘，终有回响。
撰写一本数据开发相关书的念头始于笔者学习数据知识的早期，当时笔者遍寻市面上所有的数据书籍，却没有发现一本系统化且从项目实践角度突出重点的数据开发书籍。
笔者非常理解某领域初学者的苦衷，对于他们来说，最重要的不是具体的API、安装教程等，而是先找到该领域的知识图谱，有了它，就可按图索骥，有针对性地去学。
对于大数据技术来说，上述需求更甚。一方面，由于社区、商业甚至个人原因，大数据的技术可以说是五花八门、琳琅满目，初学者非常容易不知所措，不知从哪里下手。另一方面，从理论上来说，互联网上几乎可以查到所有的大数据技术，比如在百度上搜索、问知乎，但这些都是碎片化的知识，不成体系，初学者需要先建立自己的大数据知识架构，再进一步深入。
本书正是基于这样的初衷撰写的，旨在帮助和加快初学者建立大数据开发领域知识图谱的过程，带领初学者更快地了解这片领域，而无须花更长的时间自己去摸索。
当然，未来是DT（Data Technology）时代，随着人工智能、大数据、云计算的崛起，未来数据将起到关键的作用，数据将成为如同水、电、煤一样的基础设施。但是，实际上目前数据的价值还远远没有得到充分的挖掘，如医疗数据、生物基因数据、交通物流数据、零售数据等。所以笔者非常希望本书能够对各个业务领域的业务分析人员、分析师、算法工程师等有所帮助，让他们更快地熟悉和掌握数据的加工处理知识与技巧，从而能够更好、更快地分析、挖掘和应用数据，让数据产生更多、更大的价值。
通过阅读本书，读者能建立自己的大数据开发知识体系和图谱，掌握数据开发的各种技术（包括有关概念、原理、架构以及实际的开发和优化技巧等），并能对实际项目中的数据开发提供指导和参考。
大数据技术日新月异，由于篇幅和时间限制，书中仅讲述了当前主要和主流的数据相关技术，如果读者对大数据开发有兴趣，本书将是首选的入门读物。
本书特色
本书从实际项目实践出发，专注、完整、系统化地讲述数据开发技术，此处的数据开发技术包括离线数据处理技术、实时数据处理技术、数据开发优化、大数据建模、数据分层体系建设等。
我们处于一个信息过度的时代，互联网涵盖了人类有史以来的所有知识，浩如烟海。对大数据开发技术来说，更是如此。那么，大数据相关人员如何吸收、消化、应用和扩展自己的技术知识？如何把握相关的大数据技术深度和广度？深入到何种程度？涉猎到何种范围？
这是很有意思的问题。笔者认为最重要的是找到锚点，而本书的锚点就是数据开发技术。所以本书的另一个特点是以数据开发实战作为锚点，来组织、介绍各种数据开发技术，包括各种数据处理技术的深度和广度把握等。比如在离线数据处理中，目前事实的处理标准是Hive，实际项目中开发者已经很少自己写Hadoop MapReduce程序来进行大数据处理，那是不是说MapRedue和HDFS就不需要掌握了呢？如果不是，又需要掌握到何种程度呢？笔者的答案是，对于Hive要精深掌握，包括其开发技巧和优化技巧等。MapReduce要掌握执行原理和过程，而MapRedue和HDFS具体的读数据流程、写数据流程、错误处理、调度处理、I/O操作、各种API、管理运维等，站在数据开发的角度，这些都不是必须掌握的。
本书还有一个特点，就是专门讲述了实时数据处理的流计算SQL。笔者认为，未来的实时处理技术的事实标准将会是SQL，实际上这也是正在发生的现实。
读者对象
本书主要适合于以下读者，包含：
·大数据开发工程师
·大数据架构师
·数据科学家
·数据分析师
·算法工程师
·业务分析师
·其他对数据感兴趣的人员
如何阅读本书
本书内容分为三篇，共12章。
第一篇为数据大图和数据平台大图（第1章和第2章），主要站在全局的角度，基于数据、数据技术、数据相关从业者和角色、离线和实时数据平台架构等给出整体和大图形式的介绍。
第1章 站在数据的全局角度，对数据流程以及流程中涉及的主要数据技术进行介绍，还介绍了主要的数据从业者角色和他们的日常工作内容，使读者有个感性的认识。
第2章 是本书的纲领性章节，站在数据平台的角度，对离线和实时数据平台架构以及相关的各项技术进行介绍。同时给出数据技术的整体骨架，后续的各章将基于此骨架，具体详述各项技术。
第二篇为离线数据开发：大数据开发的主战场（第3～7章），离线数据是目前整个数据开发的根本和基础，也是目前数据开发的主战场。这一部分详细介绍离线数据处理的各种技术。
第3章 详细介绍离线数据处理的技术基础Hadoop MapReduce和HDFS。本章主要从执行原理和过程方面介绍此项技术，是第4章和第5章的基础。
第4章 详细介绍Hive。Hive是目前离线数据处理的主要工具和技术。本章主要介绍Hive的概念、原理、架构，并以执行图解的方式详细介绍其执行过程和机制。
第5章 详细介绍Hive的优化技术，包括数据倾斜的概念、join无关的优化技巧、join相关的优化技巧，尤其是大表及其join操作可能的优化方案等。
第6章 详细介绍数据的维度建模技术，包括维度建模的各种概念、维度表和事实表的设计以及大数据时代对维度建模的改良和优化等。
第7章 主要以虚构的某全国连锁零售超市FutureRetailer为例介绍逻辑数据仓库的构建，包括数据仓库的逻辑架构、分层、开发和命名规范等，还介绍了数据湖的新数据架构。
第三篇为实时数据开发：大数据开发的未来（第8～12章），主要介绍实时数据处理的各项技术，包括Storm、Spark Streaming、Flink、Beam以及流计算SQL等。
第8章 详细介绍分布式流计算最早流行的Storm技术，包括原生Storm以及衍生的Trident框架。
第9章 主要介绍Spark生态的流数据处理解决方案Spark Streaming，包括其基本原理介绍、基本API、可靠性、性能调优、数据倾斜和反压机制等。
第10章 主要介绍流计算技术新贵Flink技术。Flink兼顾数据处理的延迟与吞吐量，而且具有流计算框架应该具有的诸多数据特性，因此被广泛认可为下一代的流式处理引擎。
第11章 主要介绍Google力推的Beam技术。Beam的设计目标就是统一离线批处理和实时流处理的编程范式，Beam抽象出数据处理的通用处理范式Beam Model，是流计算技术的核心和精华。
第12章 主要结合Flink SQL和阿里云Stream SQL介绍流计算SQL，并以典型的几种实时开发场景为例进行实时数据开发实战。
勘误和支持
本书是笔者对大数据开发知识的“一孔之见”，囿于个人实践、经验以及时间关系，难免有偏颇和不足，书中也难免出现一些错误、不准确之处和个人的一些主观看法，恳请读者不吝赐教。你可以通过以下方式联系笔者。
·微信号：yeshubert
·微博：hubert_zhu
·邮箱：493736841@qq.com
希望与大家共同交流、学习，共同促进数据技术和数据行业的发展，让数据发挥更大的价值。
致谢
首先非常感谢Apache基金会，在笔者撰写各个开源技术框架相关内容的过程中，Apache官方文档提供了最全面、最深入、最准确的参考材料。
感谢互联网上无名的众多技术博客、文章撰写者，对于数据技术和生态的繁荣，我们所有人都是不可或缺的一分子。
感谢阿里巴巴公司智能服务事业部数据技术团队的全部同事，尤其薛奎、默岭、萧克、延春、钟雷、建帧、思民、宇轩、赛侠、紫豪、松坡、贾栩、丘少、茅客等，与他们的日常交流让我受益颇多。
感谢机械工业出版社华章策划编辑高婧雅，从选题到定稿再到本书的出版，她提供了非常专业的指导和帮助。
特别致谢
特别感谢我的妻子李灿萍和我们的女儿六一，你们永远是我的力量源泉。
同时感谢我的父母和岳父岳母，有了你们的诸多照顾和支持，我才有时间和精力去完成额外的写作。
谨以此书献给我的家人，以及直接或间接让数据发挥价值的所有朋友们！朱松岭（邦中）第一篇数据大图和数据平台大图“不谋万世者，不足谋一时；不谋全局者，不足谋一域。”作为本书的开篇，本篇正是基于此考虑撰写的。本篇分为两章，主要站在全局的角度对数据、数据技术、数据相关从业者和角色、离线和实时数据平台架构等给出整体和大图形式的介绍。
本篇不会详细深入具体的各项数据技术内部，这些内容将交由第二篇和第三篇的各个具体章节来完成。
第1章为数据大图，主要从数据整体角度，结合数据从采集到消费的四大流程，对相关的数据技术和人进行介绍和刻画。
第2章为数据平台大图，主要从数据平台的角度对离线和实时数据平台架构以及相关的各项技术进行介绍。就业界数据平台的现状来讲，离线数据平台仍然是众多公司和组织的数据主战场，但是实时数据越来越重要，也越来越得到重视并被放在战略地位，可以说实时数据平台是数据平台的未来，未来也许将会颠覆离线数据平台。
第2章是本书的纲领，同时给出了数据技术的整体骨架，后续的第二篇和第三篇将基于此骨架，具体介绍各个数据开发技术和框架。第1章数据大图
数据是原油，数据是生产资料，数据和技术驱动，人类正从IT时代走向DT时代，随着数据的战略性日渐得到认可，越来越多的公司、机构和组织，尤其是互联网公司，纷纷搭建了自己的数据平台。不管是基于开源技术自研、自建还是购买成熟的商业解决方案，不管是在私有的数据中心还是在公有云端，不管是自建团队还是服务外包，一个个数据平台纷纷被搭建，这些数据平台不但物理上承载了所有的数据资产，也成为数据开发工程师、数据分析师、算法工程师、业务分析人员和其他相关数据人员日常的工作平台和环境，可以说数据平台是一个公司、机构或组织内“看”数据和“用数据”的关键基础设施，已经像水电煤一样不可或缺，正是它们的存在才使得数据变现成为可能。
数据从产生到进入数据平台中被消费和使用，包含四大主要过程：数据产生、数据采集和传输、数据存储和管理以及数据应用，每个过程都需要很多相关数据技术支撑。了解这些关键环节和过程以及支撑它们的关键技术，对一个数据从业者来说，是基本的素养要求。因此本章首先对数据流程以及相应的主要数据技术进行介绍。
同时，本章也将介绍数据的主要从业者，包括平台开发运维工程师、数据开发工程师、数据分析师、算法工程师等，并对他们的基本工作职责和日常工作内容等进行介绍，使读者对数据相关的职位有基本的认识和了解。1.1 数据流程
不管是时髦的大数据还是之前传统的数据仓库，不管是目前应用最为广泛的离线数据还是越来越得到重视的实时数据，其端到端流程都包含：数据产生、数据采集和传输、数据存储处理、数据应用四大过程，具体的数据流程图及其包含的关键环节如图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今日头条都代表着数据和算法结合的成功，也彰显着数据+算法的威力。借助数据挖掘、机器学习算法和深度学习算法以及在线数据服务等技术，数据已经成为在线生产系统的一部分。1.2 数据技术
目前大数据相关的技术可以说是蓬勃发展、百花齐放，对于初入者来说，一个个响亮的名字，一个个眼花缭乱的框架，之前刚了解了一个，很快又跳出来一个，正如白居易的《钱塘湖春行》所言，真的是“乱花渐欲迷人眼”。
但是万变不离其宗，不管这些技术如何变化、名词如何新颖，它们都属于1.1节介绍的某个具体流程和环节，因此下面将结合前面所述的数据流程来介绍当前主要的数据技术和框架。
结合1.1节的数据流程图，当前大数据生态系统的主要开源技术和框架如图1-2所示。图1-2 当前大数据生态系统的主要开源技术和框架
出于篇幅和开源框架实际情况考虑，图1-2并没有列出所有数据相关的开源技术框架，比如SQL on Hadoop方面的技术还有很多（如Cloudera Impala、Presto、Shark、Dremel等），数据采集传输还有Chukwa、RabbitMQ等，数据存储还包含Redis缓存数据库以及MySQL等关系型数据库。此外，IBM、微软、Oracle、Informatica等大公司的商业软件和技术尚不在此列。
但正是这些所有的数据技术一起构成了目前大数据的生态系统，各种技术你中有我，我中有你，互相借鉴，互相启发。实际上很多技术甚至其基本原理都是类似的，只是由于商业的、社区的或者甚至私人的各种原因，它们才独立出来。也许正是这样，才促成了目前大数据整个生态圈的繁荣和欣欣向上，正如一句诗所言：“一花独放不是春，万紫千红春满园”。
下面逐一介绍图1-2中提到的各种技术。1.2.1 数据采集传输主要技术
数据采集传输工具和技术主要分为两大类：离线批处理和实时数据采集和传输。顾名思义，离线批处理主要是批量一次性采集和导出数据。离线批处理目前比较有名和常用的工具是Sqoop，下游的用户主要是离线数据处理平台（如Hive等）。实时数据采集和传输最为常用的则是Flume和Kafka，其下游用户一般是实时流处理平台，如Storm、Spark、Flink等。（1）Sqoop
Sqoop（发音：skup）作为一款开源的离线数据传输工具，主要用于Hadoop（Hive）与传统数据库（MySQL、PostgreSQL等）间的数据传递。它可以将一个关系型数据库（例如MySQL、Oracle、PostgreSQL等）中的数据导入Hadoop的HDFS中，也可以将HDFS的数据导入关系型数据库中。
Sqoop项目开始于2009年，最早作为Hadoop的一个第三方模块存在，后来为了让使用者能够快速部署，也为了让开发人员能够更快速地迭代开发，独立为一个Apache项目。（2）Flume
随着目前业务对实时数据需求的日益增长，实时数据的采集越来越受到重视，而目前这方面主流的开源框架就是Flume，国内很多互联网公司也都是基于Flume搭建自己的实时日志采集平台。
Flume是Cloudera提供的一个高可用、高可靠、分布式的海量日志采集、聚合和传输的系统，目前已经是Apache的顶级子项目。使用Flume可以收集诸如日志、时间等数据，并将这些数据资源集中存储起来供下游使用（尤其是流处理框架，例如Storm）。和Flume类似的另一个框架是Scribe（Facebook开源的日志收集系统，它为日志的分布式收集、统一处理提供一个可扩展的、高容错的简单方案）。（3）Kafka
通常来说Flume采集数据的速度和下游处理的速度通常不同步，因此实时平台架构都会用一个消息中间件来缓冲，而这方面最为流行和应用最为广泛的无疑是Kafka。
Kafka是由LinkedIn开发的一个分布式消息系统，以其可以水平扩展和高吞吐率而被广泛使用，目前主流的开源分布式处理系统（如Storm和Spark等）都支持与Kafka集成。
Kafka是一个基于分布式的消息发布–订阅系统，特点是快速、可扩展且持久。与其他消息发布–订阅系统类似，Kafka可在主题当中保存消息的信息。生产者向主题写入数据，消费者从主题读取数据。作为一个分布式的、分区的、低延迟的、冗余的日志提交服务，得益于其独特的设计，目前Kafka使用非常广泛。
和Kafka类似的消息中间件开源产品还包括RabbitMQ、ActiveMQ、ZeroMQ等。1.2.2 数据处理主要技术
数据处理是数据开源技术最为百花齐放的领域，离线和准实时的工具主要包括MapReduce、Hive和Spark，流处理的工具主要包含Storm，还有最近较为火爆的Flink、Beam等。（1）MapReduce
MapReduce是Google公司的核心计算模型，它将运行于大规模集群上的复杂并行计算过程高度抽象为两个函数：map和reduce。MapReduce最伟大之处在于其将处理大数据的能力赋予了普通开发人员，以至于开发人员即使不会任何的分布式编程知识，也能将自己的程序运行在分布式系统上处理海量数据。
MapReduce是第3章的重点介绍内容，在此不做过多阐述，第3章中将会重点介绍其架构和原理等。（2）Hive
MapReduce将处理大数据的能力赋予了普通开发人员，而Hive进一步将处理和分析大数据的能力赋予了实际的数据使用人员（数据开发工程师、数据分析师、算法工程师和业务分析人员等）。
Hive是由Facebook开发并贡献给Hadoop开源社区的，是一个建立在Hadoop体系结构上的一层SQL抽象。Hive提供了一些对Hadoop文件中的数据集进行数据处理、查询和分析的工具，它支持类似于传统RDBMS的SQL语言的查询语言，以帮助那些熟悉SQL的用户处理和查询Hadoop中的数据，该查询语言称为Hive QL（下文将用Hive SQL指代，因为其更为直观和便于理解）。Hive SQL实际上先被SQL解析器解析，然后被Hive框架解析成一个MapReduce可执行计划，并按照该计划生成MapReduce任务后交给Hadoop集群处理。
Hive目前仍然是包括国际大厂（如Facebook和国内BAT）在内的互联网公司所使用的主流离线数据处理工具，详细内容参见第4章和第5章。（3）Spark
尽管MapReduce和Hive能完成海量数据的大多数批处理工作，并且在大数据时代成为企业大数据处理的首选技术，但是其数据查询的延迟一直被诟病，而且也非常不适合迭代计算和DAG（有向无环图）计算。由于Spark具有可伸缩、基于内存计算等特点，且可以直接读写Hadoop上任何格式的数据，较好地满足了数据即时查询和迭代分析的需求，因此变得越来越流行。
Spark是UC Berkeley AMP Lab（加州大学伯克利分校的AMP实验室）所开源的类Hadoop MapReduce的通用并行框架，它拥有Hadoop MapReduce所具有的优点。但不同于MapReduce的是，Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce算法。
Spark也提供类Hive的SQL接口（早期叫Shark，现为Spark SQL），来方便数据人员处理和分析数据。
此外，Spark还有用于处理实时数据的流计算框架Spark Streaming，其基本原理是将实时流数据分成小的时间片断（秒或者几百毫秒），以类似Spark离线批处理的方式来处理这小部分数据。
本书第9章将会专门介绍Spark和Spark Streaming技术。（4）Storm
MapReduce、Hive和Spark是离线和准实时数据处理的主要工具，而实时数据处理的开山鼻祖毫无疑问是Storm。
Storm是Twitter开源的一个类似于Hadoop的实时数据处理框架，它原来是由BackType开发，后BackType被Twitter收购后，Twitter将Storm作为Twitter的主要实时数据处理系统并贡献给了开源社区。
Storm对于实时计算的意义相当于Hadoop对于批处理的意义。Hadoop提供了Map和Reduce原语，使对数据进行批处理变得非常简单和优美。同样，Storm也对数据的实时计算提供了简单的Spout和Bolt原语。Storm集群表面上看和Hadoop集群非常像，但在Hadoop上面运行的是MapReduce的Job，而在Storm上面运行的是Topology（拓扑），Storm拓扑任务和Hadoop MapReduce任务一个非常关键的区别在于：1个MapReduce Job最终会结束，而1个Topology永远运行（除非显式地杀掉它），所以实际上Storm等实时任务的资源使用相比离线MapReduce任务等要大很多，因为离线任务运行完就释放掉所使用的计算、内存等资源，而Storm等实时任务必须一直占用直到被显式地杀掉。
Storm拥有低延迟、分布式、可扩展、高容错等特性，可以保证消息不丢失，目前Storm、类Storm或者基于Storm抽象的框架技术是实时处理、流处理领域主要采用的技术。（5）Flink
在数据处理领域，批处理任务与实时流计算任务一般被认为是两种不同的任务，一个数据项目一般会被设计为只能处理其中一种任务，例如Storm只支持流处理任务，而MapReduce、Hive只支持批处理任务。那么两者能够统一用一种技术框架来完成吗？批处理是流处理的特例吗？
Apache Flink是一个同时面向分布式实时流处理和批量数据处理的开源计算平台，它能够基于同一个Flink运行时（Flink Runtime），提供支持流处理和批处理两种类型应用的功能。Flink在实现流处理和批处理时，与传统的一些方案完全不同，它从另一个视角看待流处理和批处理，将二者统一起来。Flink完全支持流处理，批处理被作为一种特殊的流处理，只是它的输入数据流被定义为有界的而已。基于同一个Flink运行时，Flink分别提供了流处理和批处理API，而这两种API也是实现上层面向流处理、批处理类型应用框架的基础。（6）Beam
Google开源的Beam在Flink基础上更进了一步，不但希望统一批处理和流处理，而且希望统一大数据处理范式和标准。Apache Beam项目重点在于数据处理的编程范式和接口定义，并不涉及具体执行引擎的实现。Apache Beam希望基于Beam开发的数据处理程序可以执行在任意的分布式计算引擎上！
Apache Beam（原名Google Cloud DataFlow）是Google于2016年2月贡献给Apache基金会的Apache孵化项目，被认为是继MapReduce、GFS和Bigtable等之后，Google在大数据处理领域对开源社区的又一个非常大的贡献。
Apache Beam项目重点在于数据处理的编程范式和接口定义，并不涉及具体执行引擎（Runner）的实现。Apache Beam主要由Beam SDK和Beam Runner组成，Beam SDK定义了开发分布式数据处理任务业务逻辑的API接口，生成的分布式数据处理任务Pipeline交给具体的Beam Runner执行引擎。Apache Beam目前支持的API是由Java语言实现的，Python版本的API正在开发之中。Apache Beam支持的底层执行引擎包括Apache Flink、Apache Spark以及Google Cloud Platform，此外Apache Storm、Apache Hadoop、Apache Gearpump等执行引擎的支持也在讨论或开发当中。1.2.3 数据存储主要技术（1）HDFS
Hadoop Distributed File System，简称HDFS，是一个分布式文件系统。它是谷歌的Google File System（GFS）提出之后，Doug Cutting受Google启发而开发的一种类GFS文件系统。它有一定高度的容错性，而且提供了高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS提供了一个高容错性和高吞吐量的海量数据存储解决方案。
在Hadoop的整个架构中，HDFS在MapReduce任务处理过程中提供了对文件操作和存储等的支持，MapReduce在HDFS基础上实现了任务的分发、跟踪和执行等工作，并收集结果，两者相互作用，共同完成了Hadoop分布式集群的主要任务。（2）HBase
HBase是一种构建在HDFS之上的分布式、面向列族的存储系统。在需要实时读写并随机访问超大规模数据集等场景下，HBase目前是市场上主流的技术选择。
HBase技术来源于Google论文《Bigtable：一个结构化数据的分布式存储系统》。如同Bigtable利用了Google File System提供的分布式数据存储方式一样，HBase在HDFS之上提供了类似于Bigtable的能力。HBase解决了传统数据库的单点性能极限。实际上，传统的数据库解决方案，尤其是关系型数据库也可以通过复制和分区的方法来提高单点性能极限，但这些都是后知后觉的，安装和维护都非常复杂。而HBase从另一个角度处理伸缩性问题，即通过线性方式从下到上增加节点来进行扩展。
HBase不是关系型数据库，也不支持SQL，其中的表一般有这样的特点。
·大：一个表可以有上亿行、上百万列。
·面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。
·稀疏：为空（NULL）的列并不占用存储空间，因此表可以设计得非常稀疏。
·无模式：每一行都有一个可以排序的主键和任意多的列。列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。
·数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，它是单元格插入时的时间戳。
·数据类型单一：HBase中的数据都是字符串，没有类型。1.2.4 数据应用主要技术
数据有很多种应用方式，如固定报表、即时分析、数据服务、数据分析、数据挖掘和机器学习等。下面挑选典型的即时分析Drill框架、数据分析R语言、机器学习TensorFlow框架进行介绍。（1）Drill
Apache Drill是一个开源实时大数据分布式查询引擎，目前已经成为Apache的顶级项目。
Drill是开源版本的Google Dremel。Dremel是Google的“交互式”数据分析系统，可以组建成规模上千的集群，处理PB级别的数据。MapReduce处理数据一般在分钟甚至小时级别，而Dremel将处理时间缩短到秒级，即Drill是对MapReduce的有力补充。Dremel作为Google BigQuery的报表引擎，获得了很大的成功。
Drill兼容ANSI SQL语法作为接口，支持对本地文件、HDFS、Hive、HBase、MongeDB作为存储的数据查询，文件格式支持Parquet、CSV、TSV以及JSON这种无模式（schema-free）的数据。所有这些数据都可以像使用传统数据库的表查询一样进行快速实时查询。
Drill于2014年年底成为Apache的顶级项目，旨在为基于Hadoop应用的开发者和BI分析人员的工作效率带来巨大提升。（2）R语言
R是一种开源的数据分析解决方案，其实市面上也有很多优秀的统计和制图软件，如Excel、SAS、SPSS和Stata等。那么为什么R变得这么流行，成了很多数据分析师的主要工具呢？原因如下。
·R是自由软件。这意味着它是完全免费的、开放源代码的。可以在官方网站及其镜像中下载任何有关的安装程序、源代码、程序包及其源代码、文档资料，标准的安装文件自身就带有许多模块和内嵌统计函数，安装好后可以直接实现许多常用的统计功能。
·R是一种可编程的语言。作为一个开放的统计编程环境，R语言的语法通俗易懂，而且目前大多数最新的统计方法和技术都可以在R中直接得到。
·R具有很强的互动性。除了图形输出是在另外的窗口，它的输入/输出都是在同一个窗口进行的，输入语法中如果出现错误会马上在窗口中给出提示，对以前输入过的命令有记忆功能，可以随时再现、编辑、修改以满足用户的需要，输出的图形可以直接保存为JPG、BMP、PNG等图片格式，还可以直接保存为PDF文件。此外，R与其他编程语言和数据库之间有很好的接口。（3）TensorFlow
随着大数据时代和人工智能热潮的到来，数据已经不仅仅局限在“看”，数据和算法已经是生产系统的一部分，众多的开源机器学习平台和深度学习平台纷纷出现，而TensorFlow无疑是目前最为流行的一个。
TensorFlow是一个非常灵活的框架，它能够运行在个人电脑或者服务器的单个/多个CPU和GPU上，甚至是移动设备上。TensorFlow最早是Google大脑团队为了研究机器学习和深度神经网络而开发的，但后来发现这个系统足够通用，能够支持更加广泛的应用，于是将其开源。
TensorFlow是基于数据流图的处理框架，TensorFlow节点表示数学运算（mathematical operations），边表示运算节点之间的数据交互。TensorFlow从字面意义上来讲有两层含义：第一层含义，Tensor代表的是节点之间传递的数据，通常这个数据是一个多维度矩阵（multidimensional data arrays）或者一维向量；第二层含义，Flow指的是数据流，形象理解就是数据按照流的形式进入数据运算图的各个节点。1.3 数据相关从业者和角色
大数据时代，数据已经变为生产资料，但是数据真正从生产资料变成生产力变现必须借助专业数据人员的帮助。
下面结合数据流程图介绍数据相关的主要从业者和角色。1.3.1 数据平台开发、运维工程师
数据的埋点、采集传输、存储处理，乃至后续的分析、挖掘、数据服务等都离不开专业平台和工具的支持。而这些正是数据平台开发工程师和数据平台运维工程师的职责。
数据平台开发工程师以及数据平台运维工程师负责开发并运维专门的埋点工具、专门的数据同步工具、离线计算平台（如Hadoop、Hive等）、流计算平台（如Storm、Spark、Flink等）、数据存储工具和平台（如HBase、MySQL、Redis等），乃至分析师使用的数据分析平台和算法工程师使用的机器学习平台等。这些专业性的支撑平台是构建数据平台的基础设施，也直接关系着最终公司数据平台的成败、成本、效率和稳定性。
Hadoop、Hive、Spark、HBase、Kafka以及近一两年的Flink、Beam等，诸多开源数据框架的出现让人眼花缭乱，但本书主要面对的是数据开发工程师。数据开发工程师应该了解这些技术，知道其后台原理和适用场合，然后合理利用这些技术，达到构建数据平台的目的。
大数据和云计算是相辅相成和自然的一体选择，随着企业越来越多的系统运行在云上，企业的各种数据也都存储于云上，基于云计算的大数据平台工具也自然而然地快速得到发展。主流的国内外云计算公司（如阿里云、亚马逊、微软、Google等）都提供了云端的数据处理平台和工具。随着企业IT系统的上云，笔者认为未来云端的数据平台和工具将成为主流。1.3.2 数据开发、运维工程师
数据开发、运维工程师是本书主要面对的对象，也是一般企业里构建数据平台的中坚力量。
·数据开发工程师需要和产品经理、数据分析师沟通确定埋点需求，并具体对接前端开发工程师和后端开发工程师确定数据接口，从而将数据分析需求落地。
·数据开发工程师需要根据离线数据、实时数据、近线数据的时效性要求，选择恰当的离线和实时数据同步工具来采集与同步数据。
·数据开发工程师需要对采集和同步来的原始数据进行加工处理、合理数据建模并写入数据仓库中。
·数据开发工程师需要设计开发实时流处理任务，提供实时数据指标并提供在线数据服务。
·数据开发工程师必须严格保证数据加工的质量和数据的口径，确保下游看到的数据是高质量和一致的。
·数据开发工程师也通常是数据咨询的集中点，数据是否能够拿得到？数据在哪里？数据口径如何？数据质量如何？
·数据开发工程师向下对接数据平台工程师，向上对接数据分析工程师、算法工程师和业务人员，是使用数据的窗口和中枢。
·数据开发工程师也是公司数据资产的管理者，保证数据被合理分级、组织、使用、安全保存和稳定可靠。1.3.3 数据分析工程师
数据分析工程师是企业和公司“看”数据的主要窗口。随着数据化运营思想以及数据驱动产品开发的日益深入，数据分析工程师在一个公司或项目中的地位越来越重要。
数据分析工程师需要将公司的业务运营报表化，并抽取出关键运营指标给公司和部门管理人员做决策参考，以监控日常公司和部门的运营情况。
数据分析工程师也需要给产品的优化提供数据支持，并用数据验证产品经理的产品改进效果。
数据分析工程师是业务和数据的桥梁，数据分析工程师不但要了解数据，而且必须非常熟悉业务。此外，数据分析工程师还必须具有很强的表达能力和总结能力，能将关于业务的洞察以恰当的方式清晰明了地传递给决策人员、业务人员和产品人员，供决策和运营分析使用。
数据分析工程师也是数据开发工程师最为紧密的合作伙伴之一。1.3.4 算法工程师
算法工程师使一个公司和企业应用数据的能力不局限在“看”和分析上，而是能够直接变现应用在生产系统和产品上。
比如Google的PageRank算法，正是有了PageRank算法的发明，才使得网页重要性排名变成可以工程化的现实，也才奠定了Google搜索引擎和Google公司的成功基础。
这样的例子还有很多，比如淘宝的“千人千面”个性化推荐系统，其中的推荐算法大大提高了用户的转化率，直接提高了整个网站的GMV，也直接带来了经济效益，目前推荐系统已经成为绝大多数电子商务网站的标配，而这都离不开后台算法工程师的直接贡献。
并不是每个算法工程师都要发明算法，但他们需要熟悉常见的各种算法并了解其适用场合，需要查阅文献和论文，时刻关注业界进展，并将它们应用在业务实践中。
算法工程师必须具有一定的编程和工程能力，能够将构建的算法用代码实现，并在数据集上测试验证，然后根据效果进行相应的算法调整、参数调优等，如此反复，这就构成了算法工程师日常的主要工作。1.3.5 业务人员
一个公司和部门的分析师人数是有限的，固定每日运行的报表也是有局限性的，业务人员经常发现自己的数据分析需求处于分析师排期甚至无法支持的境地，这个问题的最终解决方法是业务人员自己具备数据分析的能力。
随着自助式数据分析工具的日益成熟，人人都可以成为数据分析师！
从数据平台的角度来讲，数据平台团队应该提供自助式数据分析工具，赋能给每个业务接口人或者业务分析人员，因为业务团队才是最了解自己业务的，如果有了自助式分析工具的帮助并具备了一定的数据分析能力，对于业务人员来说，无疑是如虎添翼的。1.4 本章小结
本章主要从整体上对数据进行了概述，包括数据从产生到消费的四大过程：数据产生、数据采集和传输、数据存储处理以及数据应用，每一个过程都涉及很多的技术、开源框架、工具和平台，比如离线的主要数据处理技术是基于Hadoop MapReduce的Hive，而Hive是一种SQL on Hadoop的技术，但类似的SQL on Hadoop技术和框架还有很多，比如Cloudera的Impala、Apache的Drill以及Presto和Shark等，初学者应该以一种技术为主，辅助了解其他相关的技术，否则容易失去重点，从而不知所措。
本章还对数据从业者的各种角色进行了介绍，包括他们的主要职责以及日常工作内容等。
通过学习本章，读者应该对数据的概貌有了纲要性的认识，下一章将把这些流程、技术和角色整合起来，也就是构建数据平台！第2章数据平台大图
什么是数据平台呢？或者更时髦点，什么是大数据平台呢？目前业界并没有对数据平台的精确定义，但通常所说的数据平台主要包含三部分。
·数据相关的工具、产品和技术：比如批量数据采集传输的Sqoop、离线数据处理的Hadoop和Hive、实时流处理的Storm和Spark以及数据分析的R等。
·数据资产：不仅包含公司业务本身产生和沉淀的数据，还包括公司运作产生的数据（如财务、行政），以及从外界购买、交换或者爬虫等而来的数据等。
·数据管理：有了数据工具，也有了数据资产，但是还必须对它们进行管理才能让数据产生最大价值并最小化风险，因此数据平台通常还包括数据管理的相关概念和技术，如数据仓库、数据建模、数据质量、数据规范、数据安全和元数据管理等。
上面是对数据平台逻辑范畴上的一个划分，实际上数据平台从数据处理的时效性角度通常还是分为离线数据平台和实时数据平台。
离线数据平台通常以天为典型的数据处理周期，数据延迟也是以天为单位。离线数据平台的数据应用主要以“看”为主，就目前业界的数据现状来看，离线数据平台还是数据平台的主战场。
但是随着大数据应用的日益深入以及人工智能浪潮的兴起，产品的智能化趋势越来越明显，数据的实时化、在线化也对数据平台的实时性提出了越来越高的要求，从刚开始的分钟级别延迟到目前的秒级甚至毫秒级延迟，实时数据平台越来越得到重视，挑战也越来越大，当然也变得越来越主流，随着Spark、Flink、Beam技术的发展，未来有一天也许将会颠覆离线数据平台的技术和架构。
本章将主要介绍数据平台，出于逻辑清晰以及技术相关性考虑，将主要从离线数据平台、实时数据平台以及数据管理三个方面来对数据平台相关的概念和技术进行介绍。
本章是后续各章技术的一个总览，因此请读者务必仔细阅读本章，确保对数据平台的整体架构和大图做到心中有数。后续各章将会聚焦在各个具体的技术上。
试读结束[说明：试读内容隐藏了图片]