1.Linux基础和分布式集群技术

学完此阶段可掌握的核心能力：

熟练使用Linux，熟练安装Linux上的软件，了解熟悉负载均衡、高可靠等集群相关概念，搭建互联网高并发、高可靠的服务架构；

学完此阶段可解决的现实问题：

搭建负载均衡、高可靠的服务器集群，可以增大网站的并发访问量，保证服务不间断地对外服务；

学完此阶段可拥有的市场价值：

具备初级程序员必要具备的Linux服务器运维能力。

1.内容介绍：关注作者：需要大数据学习视频资料可以加我QQ群，此文里面连起来的数字，你会找到我的

在大数据领域，使用最多的操作系统就是Linux系列，并且几乎都是分布式集群。该课程为大数据的基础课程，主要介绍Linux操作系统、Linux常用命令、Linux常用软件安装、Linux网络、防火墙、Shell编程等。

2.案例：搭建互联网高并发、高可靠的服务架构。

2.离线计算系统课程阶段

1. 离线计算系统课程阶段

Hadoop核心技术框架

学完此阶段可掌握的核心能力：欢迎加入722680258零基础到项目实战

1、通过对大数据技术产生的背景和行业应用案例了解hadoop的作用；2、掌握hadoop底层分布式文件系统HDFS的原理、操作和应用开发；3、掌握MAPREDUCE分布式运算系统的工作原理和分布式分析应用开发；4、掌握Hive数据仓库工具的工作原理及应用开发。

学完此阶段可解决的现实问题：

1、熟练搭建海量数据离线计算平台；2、根据具体业务场景设计、实现海量数据存储方案；3、根据具体数据分析需求实现基于mapreduce的分布式运算程序；

学完此阶段可拥有的市场价值：

具备企业数据部初级应用开发人员的能力

1.1 HADOOP快速入门

1.1.1 hadoop知识背景

什么是hadoop、hadoop产生背景、hadoop在大数据云计算中的位置和关系、国内hadoop的就业情况分析及课程大纲介绍

国内外hadoop应用案例介绍

分布式系统概述、hadoop生态圈及各组成部分的简介

1.1.2 HIVE快速入门

hive基本介绍、hive的使用、数据仓库基本知识

1.1.3 数据分析流程案例

web点击流日志数据挖掘的需求分析、数据来源、处理流程、数据分析结果导出、数据展现

1.1.4 hadoop数据分析系统集群搭建

集群简介、服务器介绍、网络环境设置、服务器系统环境设置、JDK环境安装、hadoop集群安装部署、集群启动、集群状态测试

HIVE的配置安装、HIVE启动、HIVE使用测试

1.2 HDFS详解

1.2.1 HDFS的概念和特性

什么是分布式文件系统、HDFS的设计目标、HDFS与其他分布式存储系统的优劣势比较、HDFS的适用场景

1.2.2 HDFS的shell操作

HDFS命令行客户端启动、HDFS命令行客户端的基本操作、命令行客户端支持的常用命令、常用参数介绍

1.2.3 HDFS的工作机制

HDFS系统的模块架构、HDFS写数据流程、HDFS读数据流程

NAMENODE工作机制、元数据存储机制、元数据手动查看、元数据checkpoint机制、NAMENODE故障恢复、DATANODE工作机制、DATANODE动态增减、全局数据负载均衡

1.2.4 HDFS的java应用开发

搭建开发环境、获取api中的客户端对象、HDFS的java客户端所具备的常用功能、HDFS客户端对文件的常用操作实现、利用HDFS的JAVA客户端开发数据采集和存储系统

1.3 MAPREDUCE详解

1.3.1 MAPREDUCE快速上手

为什么需要MAPREDUCE、MAPREDUCE程序运行演示、MAPREDUCE编程示例及编程规范、MAPREDUCE程序运行模式、MAPREDUCE程序调试debug的几种方式

1.3.2 MAPREDUCE程序的运行机制

MAPREDUCE程序运行流程解析、MAPTASK并发数的决定机制、MAPREDUCE中的combiner组件应用、MAPREDUCE中的序列化框架及应用、MAPREDUCE中的排序、MAPREDUCE中的自定义分区实现、MAPREDUCE的shuffle机制、MAPREDUCE利用数据压缩进行优化、MAPREDUCE程序与YARN之间的关系、MAPREDUCE参数优化

通过以上各组件的详解，深刻理解MAPREDUCE的核心运行机制，从而具备灵活应对各种复杂应用场景的能力

MAPREDUCE实战编程案例：通过一个实战案例来熟悉复杂MAPREDUCE程序的开发。该程序是从nginx服务器产生的访问服务器中计算出每个访客的访问次数及每次访问的时长。原始数据样例如下：

通过一系列的MAPREDUCE程序——清洗、过滤、访问次数及时间分析，最终计算出需求所要的结果，用于支撑页面展现：

1.4 HIVE增强

1.4.1 HIVE基本概念

HIVE应用场景、HIVE内部架构、HIVE与hadoop的关系、HIVE与传统数据库对比、HIVE的数据存储机制、HIVE的运算执行机制

1.4.2 HIVE基本操作

HIVE中的DDL操作、HIVE中的DML操作、在HIVE中如何实现高效的JOIN查询、HIVE的内置函数应用、HIVE shell的高级使用方式、HIVE常用参数配置、HIVE自定义函数和TRANSFORM的使用技巧、HIVE UDF开发实例

1.4.3 HIVE高级应用

HIVE执行过程分析及优化策略、HIVE在实战中的最佳实践案例、HIVE优化分类详解、HIVE实战案例--数据ETL、HIVE实战案例--用户访问时长统计

HIVE实战案例--级联求和报表实例：

离线数据挖掘系统

学完此阶段可掌握的核心能力：

1、通过对数据仓库知识的加强初步掌握数据仓库的核心概念和设计流程;2、通过对HADOOP生态圈关键辅助工具的学习掌握hadoop分析系统的整合能力;3、通过电商系统点击流日志数据挖掘系统实战项目，掌握hadoop离线数据挖掘系统从数据采集、入库、分析及报表展现的整套流程

学完此阶段可解决的现实问题：

1、可根据企业具体场景设计海量数据分析系统的通用架构2、根据具体场景的特点有针对性地调整数据分析各环节的技术选型;3、根据具体需求搭建起整套离线数据分析系统;4、简单数据仓库模型的设计和架构5、各环节具体功能模块的开发实现

学完此阶段可拥有的市场价值：

具备企业数据部中高级应用开发和初级架构师能力

2.1 数据仓库增强

2.1.1 数据仓库及数据模型入门

什么是数据仓库、数据仓库的意义、数据仓库核心概念、数据仓库的体系结构

2.1.2 数据仓库设计

建立数据仓库的步骤、数据的抽取、数据的转换、数据的加载、什么是数据模型、数据模型的常见类型、如何设计数据模型、如何选择数据建模的架构

典型数据模型——星型建模实例

2.1.3 数据仓库建模样例

业务建模、领域建模、逻辑建模、物理建模

web点击流日志分析系统数据仓库设计实战：

通过对数据特点和业务需求的分析，关系梳理，设计出一个主题明确、层次合理的数据模型

2.2 离线辅助系统

2.2.1 数据采集系统

数据采集概念介绍

FLUME日志采集框架介绍、FLUME工作机制、FLUME核心组件、FLUME参数配置说明、FLUME采集nginx日志实战案例

2.2.2 任务调度系统

任务调度系统概念介绍、常用任务调度工具比较、OOZIE介绍、OOZIE核心概念、OOZIE的配置说明、OOIZE实现mapreduce/hive等任务调度实战案例

2.2.3 数据导出

数据导出概念介绍、SQOOP基础知识、SQOOP原理及配置说明、SQOOP数据导入实战、SQOOP数据导出实战、SQOOP批量作业操作

2.3 web点击流日志分析系统实战项目

2.3.1 项目介绍

1. 在PC时代，营销的核心是购买，在移动互联网时代，其核心是如何实现用户个性化互动，对用户传播更为精准化的内容，而实现这一核心的基础就是对数据的管理和分析——数据驱动型商业模型。

2. 各类互联网服务产品(如网站、APP)都可以通过前端技术获取用户的详细行为数据(如访问的页面，点击的区域、登陆的频次、注册行为、购买的行为等)，将这些点击流日志数据与后台商业数据综合起来，就可以挖掘对公司运营决策意义非凡的商业价值。

3. 本项目则是一个用大数据技术平台实现的点击流日志分析数据挖掘系统，项目内容涵盖一个典型数据挖掘系统中，包括需求分析、数据采集、数据存储管理、数据清洗、数据仓库设计、ETL、业务模型统计分析、数据可视化的全部流程。

2.3.2 需求分析

什么是点击流日志、点击流日志的商业价值、点击流日志分析需求

业务模型指标体系设计——流量分析、来源分析、受访分析、访客分析、转化率分析

2.3.3 系统设计及开发

1. 系统架构设计

2. 数据采集设计及开发——数据格式、数据内容分析、数据生成规律、采集系统技术选型解析、FLUME采集系统实现

3. 数据存储设计及开发——存储技术选型、存储业务流程解析、存储目录规划及文件命名规则、小文件合并实现

4. 数据统计设计及开发——数据预处理、数据加载、原始数据表的创建、数据入库、数据ETL

5. 报表统计设计——数据模型设计、事实表设计、维度表梳理

6. 业务指标设计及开发——PV统计(时间维度、终端维度、地域维度)、来访次数统计(时间维度、地域维度、终端维度)、独立访客统计(时间维度、终端维度、地域维度)、受访页面统计(时间维度、栏目维度)、页面热点图、转化率分析、来源关键词分析、来源搜索引擎分析、来源广告推广分析

2.3.4 任务调度系统设计实现

任务调度单元实现、各环节任务运行频次及依赖关系梳理、工作流设计及实现、工作流定义配置上传部署、工作流启动即状态监控

2.3.5 数据可视化——结果报表展现

1. hive分析结果使用sqoop导出到msyql数据库

2. 报表展现系统技术选型：

后台使用spingmvc + spring + mybatis

前端页面使用全静态异步刷新技术jQuery + Echarts

3. web展现程序架构搭建，使用maven构建项目工程

4. web展现程序页面设计开发：原型页面设计、js代码开发

5. 最终实现以下数据可视化效果：

(1)流量概况可视化效果：

(2)来源地域分析可视化效果：

(3)来源类型分析可视化效果：

3.Storm实时计算部分阶段

实时课程分为两个部分：流式计算核心技术和流式计算计算案例实战。

1.流式计算核心技术

流式计算核心技术主要分为两个核心技术点：Storm和Kafka，学完此阶段能够掌握Storm开发及底层原理、Kafka的开发及底层原理、Kafka与Storm集成使用。具备开发基于storm实时计算程序的技术能力。

学完此阶段可掌握的核心能力：

(1)、理解实时计算及应用场景

(2)、掌握Storm程序的开发及底层原理、掌握Kafka消息队列的开发及底层原理

(3)、具备Kafka与Storm集成使用的能力

学完此阶段可解决的现实问题：

具备开发基于storm的实时计算程序的能力

学完此阶段可拥有的市场价值：

具备实时计算开发的技术能力、但理解企业业务的能力不足

1.1、流式计算一般结构

2011年在海量数据处理领域，Hadoop是人们津津乐道的技术，Hadoop不仅可以用来存储海量数据，还以用来计算海量数据。因为其高吞吐、高可靠等特点，很多互联网公司都已经使用Hadoop来构建数据仓库，高频使用并促进了Hadoop生态圈的各项技术的发展。一般来讲，根据业务需求，数据的处理可以分为离线处理和实时处理，在离线处理方面Hadoop提供了很好的解决方案，但是针对海量数据的实时处理却一直没有比较好的解决方案。就在人们翘首以待的时间节点，storm横空出世，与生俱来的分布式、高可靠、高吞吐的特性，横扫市面上的一些流式计算框架，渐渐的成为了流式计算的首选框架。如果庞麦郎在的话，他一定会说，这就是我要的滑板鞋!

上图是流式分析的一般架构图，抽象出四个步骤就是数据采集、数据缓冲、数据处理、数据输出。一般情况下，我们采用Flume+kafka+Storm+Redis的结构来进行流式数据分析。实时部分的课程主要是针对Kafka、Storm进行学习

1.2、流式计算可以用来干什么

一淘-实时分析系统：实时分析用户的属性，并反馈给搜索引擎。最初，用户属性分析是通过每天在云梯上定时运行的MR job来完成的。为了满足实时性的要求，希望能够实时分析用户的行为日志，将最新的用户属性反馈给搜索引擎，能够为用户展现最贴近其当前需求的结果。

携程-网站性能监控：实时分析系统监控携程网的网站性能。利用HTML5提供的performance标准获得可用的指标，并记录日志。Storm集群实时分析日志和入库。使用DRPC聚合成报表，通过历史数据对比等判断规则，触发预警事件。

一个游戏新版本上线，有一个实时分析系统，收集游戏中的数据，运营或者开发者可以在上线后几秒钟得到持续不断更新的游戏监控报告和分析结果，然后马上针对游戏的参数和平衡性进行调整。这样就能够大大缩短游戏迭代周期，加强游戏的生命力。

实时计算在腾讯的运用：精准推荐(广点通广告推荐、新闻推荐、视频推荐、游戏道具推荐);实时分析(微信运营数据门户、效果统计、订单画像分析);实时监控(实时监控平台、游戏内接口调用)

为了更加精准投放广告，阿里妈妈后台计算引擎需要维护每个用户的兴趣点(理想状态是，你对什么感兴趣，就向你投放哪类广告)。用户兴趣主要基于用户的历史行为、用户的实时查�...

前沿技术普及系列·写在前面

不知道大家有没有和象牙妹儿一样的感觉，便是最近1年很多AI产品铺天盖地的来到了我们的生活，比如某些家的智能陪伴音响、翻译棒、智能机器人、AR拍照手机等等。

这里面背后的前沿技术大数据、云计算、区块链、物联网、 5G、数字化…前几年甚至到现在听着还很遥远，但却已有不少在冲击着商业的世界，渗透进我们的生活！

如何拨开层层浓雾，抵达未来的彼岸？如何把握技术的钥匙，启开未来商业世界的大门!

大象互联网圈发起主办的第二届中国【郑州】开发者大会不但关注技术·商业的融合，也关注着前沿技术的分享。

因此，从今天起，大象互联网圈公众号将目光聚焦在大数据、云计算、物联网IOT、人工智能AI、区块链、VR/AR等板块，一一从概念层、目前行业发展状况、企业实际应用层、技术层、岗位前景等为大家带来干货的普及，快来和象牙儿妹一块围观吧！

上一篇：人人都在说的大数据到底是什么？（概念层）

本文由“壹伴编辑器”提供技术支持

提到大数据技术，最基础和核心的仍是大数据的分析和计算。在2017年，大数据分析和计算技术仍旧在飞速的发展，无论老势力Hadoop还是当红小生Spark，亦或是人工智能，都在继续自己的发展和迭代。

目前绝大部分传统数据计算和数据分析服务均是基于批量数据处理模型：使用ETL系统或OLTP系统进行构造数据存储，在线的数据服务通过构造SQL语言访问上述数据存储并取得分析结果。这套数据处理的方法伴随着关系型数据库在工业界的演进而被广泛采用。

本文将分别讨论大数据技术涉及到的技术框架、平台以及未来的发展趋势。

本文由“壹伴编辑器”提供技术支持

1.批处理框架

传统的批量数据处理模型通常基于如下处理模型：

1.使用ETL系统或者OLTP系统构造原始的数据存储，以提供后续的数据服务进行数据分析和数据计算。用户装载数据，系统根据自己的存储和计算情况，对于装载的数据进行索引构建等一些列查询优化工作。

因此，对于批量计算，数据一定需要加载到计算机系统，后续计算系统才在数据加载完成后方能进行计算。

2.用户或系统主动发起一个计算作用并向上述数据系统进行请求。此时计算系统开始调度（启动）计算节点进行大量数据计算，该过程的计算量可能巨大，耗时长达数分钟乃至数小时。

同时，由于数据累计的不可及时性，上述计算过程的数据一定是历史数据，无法保证数据的实时性。

3.计算结果返回，计算作业完成后将数据以结果集形式返回用户，或者可能由于计算结果数量巨大保存着数据计算系统中，用户进行再次数据集成到其他系统。一旦数据结果巨大，整体的数据集成过程漫长，耗时可能长达数分钟乃至数小时。

典型代表：Hadoop

Hadoop是Apache的一个开源项目，是可以提供开源、可靠、可扩展的分布式计算工具。它主要包括HDFS和MapReduce两个组件，分别用于解决大数据的存储和计算。

HDFS是独立的分布式文件系统，为MapReduce计算框架提供存储服务，具有较高的容错性和高可用性，基于块存储以流数据模式进行访问，数据节点之间项目备份。默认存储块大小为64M，用户也可以自定义大小。

HDFS是基于主从结构的分布式文件系统，结构上包括NameNode目录管理、DataNode的数据存储和Client的访问客户端3部分。

NameNode主要负责系统的命名空间、集群的配置管理以及存储块的复制；DataNode是分布式文件系统存储的基本单元；Client为分布式文件系统的应用程序。

对于数据存储，HDFS采用的是多副本的方式来存储数据，即Client将数据首先通过NameNode获取数据将要存储在哪些DataNode上，之后这些存储到最新数据的DataNode将变更数据以同步或异步方式同步到其他DataNode上。

在Hadoop3.0之后，采用Erasure Coding可以大大的降低数据存储空间的占用。对于冷数据，可以采用EC来保存，这样才能降低存储数据的花销，而需要时，还可以通过CPU计算来读取这些数。

MapReduce是一种分布式计算框架，适用于离线大数据计算。采用函数式编程模式，利用Map和Reduce函数来实现复杂的并行计算，主要功能是对一个任务进行分解，以及对结果进行综合汇总。

具体来说，MapReduce是将那些没有经过处理的海量数据进行数据分片，即分解成多个小数据集；每个Map并行地处理每一个数据集中的数据，然后将结果存储为，并把key值相同的数据进行归并发送到Reduce处理。

本文由“壹伴编辑器”提供技术支持

2.流计算框架

不同于批量计算模型，流式计算更加强调计算数据流和低时延，流式计算数据处理模型如下：

1.使用实时集成工具，将数据实时变化传输到流式数据存储（即消息队列，如RabbitMQ）;此时数据的传输编程实时化，将长时间累积大量的数据平摊到每个时间点不停地小批量实时传输，因此数据集成的时延得以保证。

2.数据计算环节在流式和批量处理模型差距更大，由于数据集成从累计变成实时，不同于批量计算等待数据集成全部就绪后才启动计算作业，流式计算作业是一种常驻计算服务，一旦启动将一直处于等待事件触发的状态，一旦小批量数据进入流式数据存储，流计算立刻计算并迅速得到结果。

3.不同于批量计算结果数据需要等待数据计算结果完成后，批量将数据传输到在线系统；流式计算作业在每次小批量数据计算后可以立刻将数据写入在线系统，无需等待整个数据的计算结果，可以立刻将数据结果投递到在线系统，进一步做到实时计算结果的实时化展现。

典型代表：Spark

Spark是一个快速且通用的集群计算平台。它包含Spark Core、Spark SQL、Spark Streaming、MLlib以及Graphx组件。

Spark SQL是处理结构化数据的库，它支持通过SQL查询数据。Spark Streming是实时数据流处理组件。MLlib是一个包含通用机器学习的包。GraphX是处理图的库，并进行图的并行计算一样。

Spark提出了弹性分布式数据集的概念（Resilient Distributed Dataset），简称RDD，每个RDD都被分为多个分区，这些分区运行在集群的不同节点上。一般数据操作分为3个步骤：创建RDD、转换已有的RDD以及调用RDD操作进行求值。

在Spark中，计算建模为有向无环图（DAG），其中每个顶点表示弹性分布式数据集（RDD），每个边表示RDD的操作。

RDD是划分为各（内存中或者交换到磁盘上）分区的对象集合。在DAG上，从顶点A到顶点B的边缘E意味着RDD B是RDD A上执行操作E的结果。有两种操作：转换和动作。

转换（例如；映射、过滤器、连接）对RDD执行操作并产生新的RDD。

本文由“壹伴编辑器”提供技术支持

3.交互式分析框架

在解决了大数据的可靠存储和高效计算后，如何为数据分析人员提供便利日益受到关注，而最便利的分析方式莫过于交互式查询。

这几年交互式分析技术发展迅速，目前这一领域知名的平台有十余个，包括Google开发的Dremel和PowerDrill，Facebook开发的Presto，Hadoop服务商Cloudera和HortonWorks分别开发的Impala和Stinger，以及Apache项目Hive、Drill、Tajo、Kylin、MRQL等。

一些批处理和流计算平台如Spark和Flink也分别内置了交互式分析框架。由于SQL已被业界广泛接受，目前的交互式分析框架都支持用类似SQL的语言进行查询。早期的交互式分析平台建立在Hadoop的基础上，被称作SQL-on-Hadoop。

后来的分析平台改用Spark、Storm等引擎，不过SQL-on-Hadoop的称呼还是沿用了下来。SQL-on-Hadoop也指为分布式数据存储提供SQL查询功能。

典型代表：Hive

ApacheHive是最早出现的架构在Hadoop基础之上的大规模数据仓库，由Facebook设计并开源。Hive的基本思想是，通过定义模式信息，把HDFS中的文件组织成类似传统数据库的存储系统。

Hive保持着Hadoop所提供的可扩展性和灵活性。Hive支持熟悉的关系数据库概念，比如表、列和分区，包含对非结构化数据一定程度的SQL支持。它支持所有主要的原语类型（如整数、浮点数、字符串）和复杂类型（如字典、列表、结构）。

它还支持使用类似SQL的声明性语言HiveQueryLanguage(HiveQL)表达的查询，任何熟悉SQL的人都很容易理解它。HiveQL被编译为MapReduce过程执行。下图说明如何通过MapReduce实现JOIN和GROUPBY。

部分HiveQL操作的实现方式

Hive与传统关系数据库对比如下：

Hive的主要弱点是由于建立在MapReduce的基础上，性能受到限制。很多交互式分析平台基于对Hive的改进和扩展，包括Stinger、Presto、Kylin等。其中Kylin是中国团队提交到Apache上的项目，其与众不同的地方是提供多维分析（OLAP）能力。

Kylin对多维分析可能用到的度量进行预计算，供查询时直接访问，由此提供快速查询和高并发能力。Kylin在eBay、百度、京东、网易、美团均有应用。

本文由“壹伴编辑器”提供技术支持

5.其他类型的框架

除了上面介绍的几种类型的框架外，还有一些目前还不太热门但具有重要潜力的框架类型。图计算是DAG之外的另一种迭代式计算模型，它以图论为基础对现实世界建模和计算，擅长表达数据之间的关联性，适用于PageRank计算、社交网络分析、推荐系统及机器学习。这一类框架有GooglePregel、ApacheGiraph、ApacheHama、PowerGraph、，其中PowerGraph是这一领域目前最杰出的代表。很多图数据库也内置图计算框架。

另一类是增量计算框架，探讨如何只对部分新增数据进行计算来极大提升计算过程的效率，可应用到数据增量或周期性更新的场合。这一类框架包括GooglePercolator、MicrosoftKineograph、阿里Galaxy等。

另外还有像

ApacheIgnite、ApacheGeode（GemFire的开源版本）这样的高性能事务处理框架。

本文由“壹伴编辑器”提供技术支持

6.总结与展望

从Hadoop横空出世到现在10余年的时间中，大数据分布式计算技术得到了迅猛发展。不过由于历史尚短，这方面的技术远未成熟。各种框架都还在不断改进，并相互竞争。

性能优化毫无疑问是大数据计算框架改进的重点方向之一。而性能的提高很大程度上取决于内存的有效利用。这包括前面提到的内存计算，现已在各种类型的框架中广泛采用。

拥抱机器学习和人工智能也是大数据计算的潮流之一。Spark和Flink分别推出机器学习库SparkML和FlinkML。更多的平台在第三方大数据计算框架上提供机器学习，如Mahout、Oryx及一干Apache孵化项目SystemML、HiveMall、PredictionIO、SAMOA、MADLib。

在同一平台上支持多种框架也是发展趋势之一，尤其对于那些开发实力较为雄厚的社区。

Spark以批处理模型为核心，实现了交互式分析框架SparkSQL、流计算框架SparkStreaming（及正在实现的StructuredStreaming）、图计算框架GraphX、机器学习库SparkML。

本文由“壹伴编辑器”提供技术支持

7.学习资料

最后介绍一下大数据计算方面的学习资料。

论坛

首推知乎、Quora、StackOverflow，运气好的话开发者亲自给你解答。其他值得关注的网站或论坛包括炼数成金、人大经济论坛、CSDN、博客园、云栖社区、360大数据、推酷、伯乐在线、小象学院等。

微信订阅号

InfoQ是最权威的，其他还有THU数据派、大数据杂谈、CSDN大数据、数据猿、Hadoop技术博文等，各人根据偏好取舍。

官方网站文档

若要进行系统的学习，则首先应参考官方网站文档。不少大数据平台的官方文档内容都比较详实，胜过多数教材。

书籍

国外O\'Reilly、Manning两家出版社在大数据领域出版了不少优秀书籍，特别是Manning的InAction系列和O\'Reilly的DefinitiveGuide系列。

本篇关于大数据的技术层面分析就介绍到这，下一篇我们将对大数据的最终价值体现——大数据实践进行分析介绍。

END

第二届中国【郑州】开发者大会

线上报名通道全面开放

本次大会将开设从数字化到大数据落地专场，现已开放报名通道，门票分为49.9普通票和VIP票两种，其中VIP票权益非常丰富，票价为199元且仅限200张，下面是两种票的权益对比：

[来自IT168]　　【IT168 专稿】本文根据伍翀老师在2018年5月12日【第九届中国数据库技术大会】现场演讲内容整理而成。　　讲师简介：

伍翀，阿里巴巴高级研发工程师，花名“云邪”，阿里巴巴计算平台事业部高级研发工程师，Apache Flink Committer。北京理工大学硕士毕业，2015 年加入阿里巴巴，参与阿里巴巴实时计算引擎 JStorm 的开发与设计。从 2016 年开始从事阿里新一代实时计算引擎 Blink SQL 的开发与优化。现在专注的方向主要是分布式处理和实时计算，热爱开源，热爱分享。　　摘要：　　SQL是数据处理中使用最广泛的语言。它允许用户简明扼要地声明他们的业务逻辑。大数据批计算使用SQL很常见，但是支持SQL的实时计算并不多。Apache Flink是一款同时支持批和流计算的引擎，Flink SQL的实现完全遵循ANSI SQL标准，这是它和其他流处理框架(例如Kafka和Spark)在DSL上的一个重要的不同。阿里巴巴是Flink SQL最大的贡献者，Flink开源社区的一半以上的SQL功能都是阿里工程师开发的。阿里内部绝大部分的流计算业务也都在使用Flink SQL编写。本次演讲我们将介绍Flink SQL的设计原理以及分享在阿里大规模使用中收获的经验。　　分享大纲：　　1、Background　　2、Flink SQL基本概念　　3、Flink SQL核心功能　　4、Flink SQL优化　　5、阿里云流计算产品　　正文：　　阿里巴巴自2015年开始调研开源流计算引擎，最终决定基于Flink打造新一代计算引擎，针对Flink存在的不足进行优化和改进，并将最终代码贡献给开源社区。目前为止，我们已经向社区贡献了数百个Commiter。阿里巴巴将该项目命名为Blink，主要由Blink Runtime与Flink SQL组成。Blink Runtime是阿里巴巴内部高度定制化的计算内核，Flink SQL则是面向用户的API层，我们完善了部分功能，比如Agg、Join、Windows处理等。今年，我们已经全部跑通TPCH 及TPC-DS的Query，熟悉数据库的人都知道，这代表着整个数据库或引擎是一个基本功能完备的产品。　　接下来主要介绍Flink SQL的基本概念及使用。传统的流式计算引擎，比如Storm、Spark Streaming都会提供一些function或者datastream API，用户通过Java或Scala写业务逻辑，这种方式虽然灵活，但有一些不足，比如具备一定门槛且调优较难，随着版本的不断更新，API也出现了很多不兼容的地方。　　我们一直在思考最适合流计算处理的API，毫无疑问，SQL已经成为大数据领域通用且成熟的语言，因此我们的Flink和Blink均基于此，之所以选择将SQL作为核心API，是因为其具有几个非常重要的特点，一是SQL属于设定式语言，用户只要表达清楚需求即可，不需要了解具体做法;二是SQL可优化，内置多种查询优化器，这些查询优化器可为SQL翻译出最优执行计划;三是SQL易于理解，不同行业和领域的人都懂;四是SQL非常稳定，在数据库30多年的历史中，SQL本身变化较少，非常稳定。当我们升级或替换引擎时，用户是无感知的且完全兼容;最后，SQL经过优化可以统一流和批。　　过去，我们既需要批模式跑全量数据，也需要流模式实时跑增量数据，因此需要同时维护两个引擎，并且保持两份代码之间的同步。如果使用SQL，我们便可以一份代码同时跑在两个模式下，但SQL是为传统批处理设计的，并不能为流处理所用。SQL定义在表上，而不是流上。传统SQL处理的数据集比较有限，查询一次只返回一个结果。但是，流处理需要不断接收数据，不断对结果进行更新，并且查询也不会结束，这导致其需要对历史数据不断修正。所以，SQL的很多概念无法直接映射到流计算，这就是在流计算上定义SQL的难点。　　

为了在流计算上定义SQL，我们需要引入几个概念。既然批处理需要定义SQL表的概念，那在流计算上也需要表的概念，我们需要将传统静态表扩展成动态表，所谓动态表就是数据会随时间而不断变化的表。此时，我们发现流和动态表之间有一种对偶性，也就是说流和动态表可以相互转换。将流的每条数据插入到数据库中，就得到了一张表;同时我们可以抽取动态表的changelog还原原始流。

从流计算到SQL，我们可以把它看成是连续查询。连续查询区别于传统的批处理查询，需要源源不断地接收数据，每收到一条新数据就会更新结果且结果也是一张动态表，那结果的动态表又可以作为下一个查询的输入，从而串起整个流计算。　　基于上述两个概念，我们可以在SQL上定义流计算。但是，流计算中的数据需要不断修正和更新，因此这些数据下发后可能导致最终结果的错误，我们需要把这些错误数据进行修正，这就涉及到流计算中一个非常重要的概念——Retraction。

为了解释此概念，我们举一个简单的例子，上图所示有一个点击输入流，它具备两个字段：user和url，经过第一个查询根据用户进行分组，统计每个用户的点击次数;进入第二个查询，根据点击次数进行分组，统计每个次数的具体点击人数。最终，我们会收到两条记录，点击次数所对应的人数。从结果明显可以看出计算有误，Mary的数据并没有合并计数，这就需要引入修正的概念。

如上图所示，经过修正之后，经过第二个查询时，Mary的总查询次数会被合并计算，Mary 1的结果会被告知撤回，从而输出正确的结果，这就是引入Retraction的作用。在整个过程中，是否触发Retraction以及发送方式均由优化器决定，用户对整个过程是无感知的。　　在此基础上，我们发现世界不需要所谓的Stream SQL语法，标准的ANSI SQL就可用来定义流计算，Flink SQL就是标准的ANSI SQL语法。其部分核心功能如下：DDL用来定义数据源表、数据结构表;UDF、UDTF、UDAF用户自定义函数，可以定制化用户复杂的业务需求;JOIN是一个比较复杂的功能，包括流与流之间的Join，流与表之间的Join以及Windows Join等;聚合功能包括类似Group AGG，Windoes Agg以及Over Agg等。

接下来我会结合实例对核心功能进行介绍。首先是装载数据，需要create table语法。如上图所示，我们先定义一张clicks表，然后定义表的schema、user、cTime以及url，with里是表的一系列属性，它是一个来自kafka的日志表，我们可以用SELECT * FROM clicks查询转载表里面的数据。

如果要将上述查询数据写到某个表中，我们需要用create table定义结果表，语法同上，创建一张 last_clicks 结果表，主键是user，通过INSERT INTO 语法将上述查询数据插入Mysql表中。

如果想把中间处理结果同时写入多个存储，比如把数据处理结果同时写到Mysql和HBase，如上使用CREATE VIEW 定义一个来自淘宝的点击记录，同时连续写多个INSERT INTO到Mysql和HBase。

接下来是Group Aggregate，也就是无限流量聚合。所谓无限流量聚合指从历史开始到现在的所有用户点击数据，如上查询展示的是根据用户分组，然后统计点击次数。如果来了一条Mary1的数据，我们就先插入该数据，后续如果Mary再次进行点击，我们就在原数据基础上进行修改更新，以此类推。

Window Aggregate是定义在窗口上的聚合，有别于上述无限流聚合，它的原理是是每个窗口对应输出一个结果，比如每小时每个用户的点击次数，需要在group by的结果上加上endT数据，也就是窗口标识。　　

接下来介绍双流join，目前我们支持INNER, LEFT, RIGHT, FULL, SEMI, ANTI等Join类型，举例说明双流Join的主要使用场景，比如把主流打成宽表，并补上额外字段等。如上图所示，我们需要将订单和物流表信息进行Join操作，在Join的物理实现上会有两份状态，用来存储两条流到目前为止收到的所有历史数据,淘汰机制时间设定为一天半一次。两者中任何一方信息延迟都会先在表中等待，直到同一个订单的信息与物流关联之后才会通过Join输出。

维表Join与双流Join类似，目前支持INNER, LEFT两种交易类型。维表Join的使用同样为补全主流，但想补全的字段在另一维表中。如上图所示，使用时首先需要通过CREATE TABLE 语法定义一张维表，此处定义的是 Products 表，存储与产品相关信息，查询同样使用Join语法。Order与Products表通过Products ID实现Join。关键字PERIOD FOR SYSTEM_TIME 是 SQL 2.11标准里的语法，意思是当前关联的Products是当前时刻的信息，关联之后不再更新信息。上图右侧展示的是维表Join物理执行的概念。我们可以根据Order去Products数据库里查询信息，最终Products维表返回关联信息。　　核心功能如上所述，接下来主要聊优化。维表中，订单O1查询时是堵塞等待IO的状态，此时无论如何调优性能，吞吐量和CPU使用率都上不去，因此我们引入异步IO功能。

如上左半部分为未引入异步IO时的状态，如上右半部分为引入后，此时若发起A请求，不需等待IO就可立刻发起BCD查询请求，然后异步等待返回结果。返回ABCD以后再管理输出，极大地提高了整体性能。

如上，异步IO使用时与维表Join只有一行配置改动，对于用户来说，这个使用是非常简便的。

第二个优化是大数据中的常见场景——数据倾斜。如上为改进之前，红色聚合节点出现数据积压现象，而紫色节点相对较空。

如果持续一段时间，红色聚合节点就会被打满，从而变为热点，所有上游map节点就会反压，停止处理数据进入等待状态，而下游的紫色节点基本处于空闲状态。

我们引入Local-Global 聚合优化。左图是未优化拓扑图，右边是引入Local-Global优化后的图，我们在Map后引入Local Agg节点，Map与Local Agg是链在一起的一个线程，之间的数据传输没有任何网络开销。Local Agg可以将收到的数据按照 key进行预聚合，然后将结果按照 key分发给下游Global Agg进行汇总。　　假如每个Map的 TPS 是每秒1万的数据量，全局就2个 key：红色和紫色。如果 Local Agg聚合的间隔是每秒钟一次，那么每个Local Agg能将1万条数据预聚合成最多2条(全局共2个 key)。那么Global Agg每秒钟最多收到只会三条消息，能有效降低Global Agg 的热点。优化后，我们对此进行性能测试，发现Local-Global 可以带来超过20倍的性能提升。因此，整个方案是十分有效的。

0.Hadoop

Hadoop是一个开源框架，它允许在整个集群使用简单编程模型计算机的分布式环境存储并处理大数据。它的目的是从单一的服务器到上千台机器的扩展，每一个台机都可以提供本地计算和存储。

1.Druid

Druid是实时数据分析存储系统，Java语言中最好的数据库连接池。Druid能够提供强大的监控和扩展功能。

2.Ambari

大数据平台搭建、监控利器；类似的还有CDH

提供Hadoop集群

Ambari为在任意数量的主机上安装Hadoop服务提供了一个逐步向导。Ambari处理集群Hadoop服务的配置。

管理Hadoop集群

Ambari为整个集群提供启动、停止和重新配置Hadoop服务的中央管理。

监视Hadoop集群

Ambari为监视Hadoop集群的健康状况和状态提供了一个仪表板。

3.Spark

大规模数据处理框架（可以应付企业中常见的三种数据处理场景：复杂的批量数据处理（batch data processing）；基于历史数据的交互式查询；基于实时数据流的数据处理，Ceph:Linux分布式文件系统。

4.Storm

Storm是一个免费开源、分布式、高容错的实时计算系统。Storm令持续不断的流计算变得容易，弥补了Hadoop批处理所不能满足的实时要求。Storm经常用于在实时分析、在线机器学习、持续计算、分布式远程调用和ETL等领域。Storm的部署管理非常简单，而且，在同类的流式计算工具，Storm的性能也是非常出众的。

以上5个大数据处理/数据分析/分布式工具，有任何IT问题都欢迎问我~这里有一些我收集的资料想要的评.论！回复【资料】即可

阿里云流计算(Alibaba Cloud StreamCompute)是运行在阿里云平台上的流式大数据分析平台，提供给用户在云上进行流式数据实时化分析工具。

1 引言

大数据技术的广泛应用使其成为引领众多行业技术进步、促进效益增长的关键支撑技术。根据数据处理的时效性，大数据处理系统可分为批式(batch)大数据和流式(streaming)大数据两类。其中，批式大数据又被称为历史大数据，流式大数据又被称为实时大数据。

目前主流的大数据处理技术体系主要包括Hadoop[1]及其衍生系统。Hadoop技术体系实现并优化了MapReduce[2]框架。Hadoop技术体系主要由谷歌、推特、脸书等公司支持。自2006年首次发布以来， Hadoop技术体系已经从传统的“三驾马车”(HDFS[1]、MapReduce和HBase[3])发展成为包括60多个相关组件的庞大生态系统。在这一生态系统中，发展出了Tez、Spark Streaming[4]等用于处理流式数据的组件。其中，Spark Streaming是构建在Spark基础之上的流式大数据处理框架。与Tez相比，其具有吞吐量高、容错能力强等特点，同时支持多种数据输入源和输出格式。除了Spark开源流处理框架，目前应用较为广泛的流式大数据处理系统还有Storm[5]、Flink[6]等。这些开源的流处理框架已经被应用于部分时效性要求较高的领域，然而在面对各行各业实际而又差异化的需求时，这些开源技术存在着各自的瓶颈。

在互联网/移动互联网、物联网等应用场景中，个性化服务、用户体验提升、智能分析、事中决策等复杂的业务需求对大数据处理技术提出了更高的要求。为了满足这些需求，大数据处理系统必须在毫秒级甚至微秒级的时间内返回处理结果。以国内最大的银行卡收单机构银联商务为例，其日交易量近亿笔，需对旗下540多万个商户进行实时风险监控，在确保这些商户合规开展收单业务的同时，最大限度地保障个人用户的合法权益。这样的高并发、大数据、高实时应用需求给大数据处理系统提出了严峻的挑战。银联商务以前使用的T+1事后风控系统存在风险侦测迟滞高(次日才能发现风险，损害已经造成)、处理时间长(十几个小时之后才能完成风险识别)、无法处理长周期历史数据(只能分析最近几日的流水数据)以及无法支持复杂规则(仅能支持累积求和等简单规则)等重大缺陷。为此，亟须研发全新的事中风控系统，以重点实现低迟滞(在1 min内甄别突发风险)、高实时(100 ms内返回处理结果)、长周期(可处理长达10年以上的历史周期数据)以及支持高复杂度规则(如方差、标准差、K阶中心矩、最大连续统计等)等目标。这一目标可以抽象为一个大数据处理科学问题：如何在一个完整的大数据集上，实现低迟滞、高实时的即席(Ad-Hoc)查询分析处理。

2 技术解析

现有的大数据处理系统可以分为两类：批处理大数据系统与流处理大数据系统。以Hadoop为代表的批处理大数据系统需先将数据汇聚成批，经批量预处理后加载至分析型数据仓库中，以进行高性能实时查询。这类系统虽然可对完整大数据集实现高效的即席查询，但无法查询到最新的实时数据，存在数据迟滞高等问题。相较于批处理大数据系统，以Spark Streaming、Storm、Flink为代表的流处理大数据系统将实时数据通过流处理，逐条加载至高性能内存数据库中进行查询。此类系统可以对最新实时数据实现高效预设分析处理模型的查询，数据迟滞低。然而受限于内存容量，系统需丢弃原始历史数据，无法在完整大数据集上支持Ad-Hoc查询分析处理。因此，研发具有快速、高效、智能且自主可控特点的流式大数据实时处理技术与平台是当务之急。

实现一个融合批处理和流处理两类系统且对应用透明的系统级方案，需要攻克以下几个技术难点。

(1)复杂指标的增量计算

尽管计数、求和、平均等指标能够依靠查询结果合并实现，然而方差、标准差、熵等大部分复杂指标无法依靠简单合并完成查询结果的融合。再者，当查询涉及热点数据维度及长周期时间窗口的复杂指标时，多次重新计算会带来巨大的计算开销。

(2)基于分布式内存的并行计算

采用粗放的调度策略(例如约定在每天的固定时间将流数据导入批处理系统)会造成内存资源的极大浪费，亟须研究实现一种细粒度的基于进度实时感知的融合存储策略，以极大地优化和提升融合系统的内存使用效率。

(3)多尺度时间窗口漂移的动态数据处理

来自业务系统的数据查询请求会涉及多种尺度的时间窗口，如“最近5笔刷卡交易的金额”“最近10 min内密码重试次数”“过去10年的月均交易额”等。每次查询请求都重新计算结果会对系统性能造成极大的影响，亟须研究实现一种支持多种时间窗口尺度(数秒到数十年)、多种窗口漂移方式(数据驱动、系统时钟驱动)的动态数据实时处理方法，以快速响应来自业务系统的即席查询请求。

(4)高可用、高可扩展的内存计算

基于内存介质能够大大提升数据分析及处理能力，然而由于其易挥发的特性，一般需要采用多副本的方式来实现基于内存的高可用方案，这使得“如何确保不同副本的一致性”成为一个待解决的问题。此外，在集群内存不足或者部分节点失效时，“如何让集群在不间断提供服务的同时重新平衡”同样是一个待解决的技术难题。亟须研究分布式多副本一致性协议以及自平衡的智能分区算法，以进一步提升流处理集群的可用性以及可扩展性。

“流立方”流式大数据实时处理技术在上述领域取得了一系列突破，该技术提供基于时间窗口漂移的动态数据快速处理，支持计数、求和、平均、最大、最小、方差、标准差、K阶中心矩、递增/递减、最大连续递增/递减、唯一性判别、采集、过滤等多种分布式统计计算模型，并且实现了复杂事件、上下文处理等实时分析处理模型集的高效管理技术。

3 平台纵览

基于“流立方”流式大数据实时处理技术，研发了“流立方”流式大数据实时处理平台。其应用框架如图1所示，具有良好的灵活性和适应性。平台的数据装载模块负责从具体业务系统中接入实时流数据，数据抽取模块负责批量抽取历史数据，模型装载模块负责将分析处理模型集中的计算模型和脚本加载到平台中。当收到业务系统发出的实时查询请求时，“流立方”平台能够根据分析处理模型在完整大数据集上实时计算出相应的指标，并进行判断，将结果反馈给业务系统。

图1 “流立方”平台应用框架

在测试环境为8台服务器(每台服务器配置24核 CPU、256 GB内存)，同时计算16个统计指标(涉及4个维度，包含计数、求和、平衡、最大、最小、标准差、过滤、去重、排序、复杂事件处理等多种算法)的性能测试中，“流立方”平台达到了单节点写入大于43 000 TPS、8节点读取大于100万TPS、平均时延为1～2 ms的优异性能，如图2所示。

图2 “流立方”平台性能指标

“流立方”平台在解决批式大数据和流式大数据融合实时处理技术难题，实现优异性能的同时，还解决了流式大数据处理平台面临的两大工程化难题。一是作业的编排效率问题。大部分开源流处理平台在完成一个流处理编排时，都需要经过拓扑设计、代码编写、功能测试、打包部署等环节，一般需要一周的时间才能完成。“流立方”平台通过基于“所见即所得”的在线作业编排管理，将上线任务耗时降低到分钟级，大大提升了流处理作业的编排效率。二是流处理作业的灵活变更问题。流处理平台擅长进行逻辑预先定义的增量计算，尽管其计算效率极高，但计算灵活度受到限制。例如，某业务需要统计过去3个月的数据，现有的流处理平台在该业务上线3个月后才能完全生效，这样的工作方式使流处理技术在实际应用中受到很大的局限。“流立方”平台创新性地引入流媒体播放器的录制与重放思路，在原始数据进入流处理平台时，通过顺序写的方式持久化一份原始数据，在需要上线新的计算作业时，即刻重发指定时间窗口内的原始数据，从而实现快速(分钟级甚至秒级)计算作业上线。

“流立方”平台引入了一系列创新技术，在性能、可用性、可扩展性等多个层面提升了流处理平台的处理能力，满足金融领域在内的众多领域的业务及运维需求。引入数据冲突智能规避技术，解决了流式处理中的热点数据处理问题，从而解决了大颗粒数据维度的处理效率问题;引入Paxos一致性协议，解决内存存储计算时多副本一致性问题，提供了面向运维人员透明的一致性解决方案;引入智能分区技术，基于一致性散列技术，进一步将散列值拆解为散列块，通过散列块的平滑迁移解决存储集群的可伸缩性设计问题，确保对于运维人员的集群变更透明性;引入计算作业的动态运行时加载技术，规避了作业手工打包部署的问题，进一步提升了开发人员的工作效率。

在国内某大型银行卡收单机构组织的招标测试中，测试环节为两台低配置虚拟机，测试数据为该机构的数千万笔交易流水，计算逻辑包括50多条规则，涉及30多个统计指标。在该测试环节下，两家国外著名厂商中，一家厂商的计算时间长达24 h，另一家老牌数据库软件提供商则未能在一天内完成计算。相较于这些国外著名厂商的大数据处理平台，“流立方”平台能够在3 h内完成所有计算，且正确率为100%。

4 应用场景

“流立方”流式大数据实时处理系统在金融、交通、电信、公安等行业具有广泛的应用场景。以金融风控反欺诈为例，部署“流立方”风控系统仅需在交易前端增加风控探头，将实时交易数据旁路接入系统。“流立方”风控系统根据融合了专家知识和机器学习结果的数百条规则对每笔交易进行风险评估，判断是否允许进行该笔交易，流程如图3所示。该系统平均响应时间在6 ms以下，并发数超过50 000笔/s。同时，实现这一性能仅需要4台服务器。

图3 基于“流立方”的金融风控反欺诈流程

基于“流立方”的金融风控反欺诈技术体系包含技术(如设备指纹、代理侦测、生物识别、关联分析、机器学习等技术)、知识(如盗卡反欺诈、伪卡反欺诈、信用卡套现、营销反欺诈等规则与模型)、数据(如虚假手机数据、代理IP数据、P2P失信数据等标识数据)三大板块。技术部分中的设备指纹技术通过主被动混合的形式采集设备中软硬相关要素，结合概率论等算法为每一个设备颁发一个全球唯一的指纹编码，这些指纹编码在反欺诈的整个过程中起到非常积极的作用;代理侦测技术通过短时间内扫描IP相关端口来识别那些开启代理的IP，并在这些IP访问金融服务时进行识别;生物识别技术通过采集设备上用户的鼠标点击、触摸、键盘敲击等行为识别操作者是人还是机器以及是否操作者本人的问题;关联分析技术在底层通过图数据库存储不同节点以及关系信息，最终在界面上通过图的形式进行欺诈者关联分析及复杂网络分析;机器学习技术通过有监督、无监督的机器学习算法提升欺诈识别的准确率及覆盖率，并结合流立方技术提供模型的事中预测能力。

基于上述技术体系，研发了银行业务风险实时监控系统、互联网支付业务风险实时监控系统、电商业务风险实时监控系统等金融风控反欺诈系列解决方案。这些方案已应用到银行、第三方支付机构、互联网金融等领域的上百家企业。目前50%以上的线下交易都在“流立方”的保护下进行，基于“流立方”的金融风控反欺诈解决方案每天为我国的金融机构抵御上亿次的攻击。该技术已经成为我国金融安全领域基础设施必不可少的组成部分。

此外，在互联网机器防御系统中，“流立方”同样能发挥巨大作用。如今网络机器人遍布票务、电商、招聘、银行、政府、社交等各类网站，消耗了40%～60%的网络流量。网络机器人不仅消耗网络资源、影响正常客户访问、增加网站运营成本，还会爬取产品、价格信息，形成不正当竞争，甚至混淆网站用户生态，影响营销分析。传统的控制策略通过采取屏蔽频繁访问、设置验证码等方式防御网络机器人，无法应对日益智能化的新型网络机器人。基于“流立方”的互联网机器防御系统通过在Web服务器上嵌入插件或者独立的嗅探器(sniffer)程序，将全流量的Web访问请求旁路到独立的机器防御集群，进行实时的流量分析及防御决策，并将决策后的结果实时回馈到Web服务器插件中。Web服务器插件在判定当前访问的设备或者IP地址等是机器人时，能够自动改写响应内容，根据不同的风险级别自动拒绝交易或将访问者引导到第三方图形验证码服务商进行机器人验证。访问者在通过验证后可以继续正常访问Web服务。该系统还创新地将设备指纹以及人机识别服务运用到机器防御系统中，不仅增加了可分析维度，提升了控制颗粒度，同时能够对基于浏览器内核的高级爬虫进行防护。此外，将机器防御规则、数据服务、设备指纹、人机识别以及图形验证码以软件即服务(software as a service，SaaS)的形式提供服务，进一步降低了互联网网站客户的运维门槛，提升了产品竞争力。该机器防御系统工作过程如图4所示。

基于“流立方”的实时机器防御系统通过多服务器访问流水关联决策、长周期数据决策、复杂规则爬虫识别、设备维度爬虫识别、人机识别等技术，实现了微秒级(400～800μs)的识别时延，同时具有机器人识别管控一体化、轻量级接入等优点。根据已经接入机器防御服务的几十家客户的反馈，基于“流立方�...

在过去几年，对于 Apache Kafka 的使用范畴已经远不仅是分布式的消息系统：我们可以将每一次用户点击，每一个数据库更改，每一条日志的生成，都转化成实时的结构化数据流，更早的存储和分析它们，并从中获得价值。同时，越来越多的企业应用也开始从批处理数据平台向实时的流数据数据平台转移。本演讲将介绍最近 Apache Kafka 添加的一些系统架构，包括 Kafka Connect 和 Kafka Streams，并且描述一些如何使用它们的实际应用体验。

流处理

在流处理刚被提出来的时候，很多人认为流处理只能进行做近似的结果或者增量的计算，倘若你想保证其安全性，以 Lamda 架构为基础，利用流处理得到最现在的结果。但同时你需要采用 batch processing 等其他方式来保证其全局的安全性以正确性。

在如此多年的研究结果下，在我看来，流处理并不一定是近似的，或者是仅仅以无法保证真确性为代价而提高速度的一种数据处理方式。相反，流处理应该是一个与全局计算、batch processing 稍微有点不同的计算模型。跟批量处理不同之处在于，批量处理将数据引向计算，而流处理将计算引向数据。这句话大概有点模糊，接下来，我举几个大家熟悉的计算模型例子。

第一个计算模型例子—请求应答模型。

请求应答模型是业务生活中最常用的模型例子。首先提交一个请求到服务方，而服务方可能是一个数据库、也可能是别的存储工具；然后进行等待…等待；最后得到一个回答。这便是一次请求、一次计算、一次回答。该模型非常简单、也极易操作，当你需要延展到多个机器上时，只要简单地增加客户端以及处理器即可成功。但是缺点在于，不能达到大的吞吐量，每提交一次请求，都需要等待时间来获得最终应答的结果。

第二种常见的模型就是批量处理如上图所示。如果请求应答模型在谱系的一端，那么 typo 的另一端则认为是批量处理。当我积累数据数量足够多的时候，一次性提交任务到数据仓库，再进行等待，等待时间短则几秒钟、几分钟，长则几小时，最后才得到最终的结果—所有输入对应的所有输出。该批处理模型的好处在于能够提高其吞吐率，一次的请求和应答可以得出较多结果。但它的缺点是具有高延时性，比如某数据产生时间为上午 6 点钟，用户点击某网页，由于批处理模型，每 12 小时才会运行一次，那么它必须等到上午 6 点到下午 6 点的所有数据完整以后才会进行工作，那么运行结果可能是用户点击的 12 个小时之后。高延迟性是批处理自身带有的特性。

那么什么是流处理呢? 在我看来，流处理就是介于请求应答和批处理之间的一种新型计算模型或者编程模型。流处理并不等待数据的完整性，或者说数据本没有完整性这一讲法，数据本身就是一个数据流，当每个数据流每产生一个新数据的时候立刻被计算出、进行返回，因此数据是源源不断地通向计算，并且源源不断有结果被输出。你可以设想，与等待数据完全完成之后发布到计算上相比，流处理就是将计算移到你数据发生地进行实时计算的方式。

为什么很多人之前有这样一种错觉，他们认为流处理可能存在有丢包的情况、或者说只可以得到近似的结果，其实这是早期的一些数据流处理系统所自带的一些限制。因此以 Lamda 架构为基础，在流处理上需要讨论不同维度的取舍。接下里我将举三个例子，延迟、、成本和正确性。正如很多人之前提及的，在进行流处理时候，其大多数情况需要用时间来换取正确性，或者用更多的成本换取时间等等。

第一个例子，说如果你需要做一个实时的 ETL 处理。而关于 ETL 处理不需要太小的延迟，为达到低成本的一种保证，我们可以忍受几分钟或者 1 分钟的延迟；但是，如果你正在进行一个实时的在线监测，存在着几毫秒的延迟，那么这时候可能更愿意选择花大量的金钱，或者采取一些可能不必要的 possibility 来达到一种低延迟的效果；第二个例子，假设你在做一个在线付费协议，它也是一个流处理平台。由于在线付费协议可能关乎到其机构，或者其公司的利益所在，因此你会说，我需要保证百分之百的正确性，我不希望有任何丢包情况；

第三个例子，如果你是做一个实时的日志处理，实时收集所有日志，并将其导入 root，在这种情况下，你可能会说，为了降低成本，我愿意付出一小部分正确性的代价，即使不能达到 100%、达到 99.99%、达到 99.9%，这样的结果都可以接受。这本是用户在定义不同流处理应用或者业务的时候应该可以自己做出的选择。但比较遗憾的是，多数早期的流处理平台其实并没有给予用户该种选择，他们自身的设计理念，那就是为了低延迟直接放弃掉正确性，或者说为了更高的吞吐量直接放弃低延迟。

以上是我想分享的关于流处理的一些误会认知，如果我的分享能够让大家带走两个答案的话，我希望这就是一个。我认为流处理仅仅是一种不一样的计算模型或者编程模型，它将计算带到数据上，而不是将数据引用到计算上，并且在流处理的时候，用户往往需要在正确性、延迟性、成本等不同的维度上做出选择。

Kafka 的角色

为什么当我们说到流处理的时候，很多人都在说 Kafka。大多数人在最早接触 Kafka 时会说，Kafka 就是一个分布式发布订阅的消息系统，但是如果我们去观察 Kafka 的最初一些设计特性可发现以下几点内容。第一点，它可以作为一个写在磁盘上的缓存来使用，或者说，并不是仅基于内存来存储流数据，它可以保证数据包不被及时消费时，依然可用且不被丢失；第二点，由于位移的存在提供了逻辑上的顺序，在同一个话题上，第一个数据比第二个数据最先被发布的时候，也可保证在消费时也是永远第一个数据比第二个数据先被消费；第三点，因为 Kafka 是一个公有的大数据中转站，就是说，所有的数据只要在 Kafka 上，永远可以在 Kafka 周围进行业务的开发或者认知事物的开发。接下来我将花费一些时间详细介绍这三点之间的关系。

Kafka 不仅仅是一个订阅消息系统，同时也是一个大规模的流数据平台，那么它提供了什么呢？第一，提供订阅和发布消息；第二，提供一个缓存的流数据存储平台；第三，提供流数据的处理平台。今天，我将着重讨论流式计算在 Kafka 上面的应用。

流式计算在 Kafka 上的应用主要有哪些选项呢？第一个选项就是 DIY，Kafka 提供了两个客户端 —— 一个简单的发布者和一个简单的消费者，我们可以使用这两个客户端进行简单的流处理操作。举个简单的例子，利用消息消费者来实时消费数据，每当得到新的消费数据时，可做一些计算的结果，再通过数据发布者发布到 Kafka 上，或者将它存储到第三方存储系统中。DIY 的流处理需要成本。打个比方，考虑数据的延迟性，考虑不同时间上的管理分配，正如很多人提到的 processing time，这将是我后文会重点提及的概念。以上这些都说明，利用 DIY 做流处理任务、或者做流处理业务的应用都不是非常简单的一件事情。

第二个选项是进行开源、闭源的流处理平台。比如，spark。关于流处理平台的一个公有认知的表示是，如果你想进行流处理操作，首先拿出一个集群，且该集群包含所有必需内容，比如，如果你要用 spark，那么必须用 spark 的 runtime。因为他们划定了你作为一个流处理平台使用者需要用到的所有行为，比如，资源管理系统、参数调配系统、容器配置、代码封装、分发等，以上行为都已被该平台所限定。一旦你选择使用甲就必须用甲套餐装备，如果选择使用乙就必须使用乙套餐装备。有人不禁提出疑问，我能不能既选择流处理平台，又使用自己选择的，我能不能这样做呢？

这个应用场景其实很普遍，举个例子，可异步式微服务处理。什么叫异步式微服务处理？假设 Kafka 作为一个缓存数据，在该缓存区含有很多不同的业务。打个比方，一个网店的机构可以有不同的组、不同的员工，有人负责销售、有人负责商品分发，有人负责价格管理、有人负责在线实时的限流监控，不同的组、不同的员工可能会以不同的时间，或者以不同的代码来更新他们的产品，只要拥有一个异步式缓存机制，即 Kafka，便可扩大该微服务，而不需要他们的任何一个组之间进行同步请求应答机制。

在该微服务情况下，每个小组的喜好、特性并不一致，有的组表示我需要做流处理平台，从 Kafka 读数据，处理完再写回 Kafka，并且想要使用 EWS 把我的应用部署在云端大规模集群上；而另外小组表示我不需要那么复杂，我只是小规模数据，不希望起一个集群，只需起三个机器，并且每个机器有 1GB 内存足以，可进行手动控制操作，不需要资源管理器。那么我们能不能同时满足他们不同的需求呢? 答案就是我接下来要说的第三种选项。

第三种选项是使用一个轻量级流处理的库，而不需要使用一个广泛、复杂的框架或者平台来满足他们不同的需求。在 Kafka 0.10 当中已发布轻量级流处理内容平台，我们可以设想，跟其他客户端发布者和消费者一样，它也是一个客户端，不同之处在于它是一个计算者客户端，一个好用的、功能强大的客户端，并且支持 state processing、Windows 延时的、异步的、甚至不同数据的调控。 最重要的是 Kafka 作为一个库，可以采用多种方法来发布流处理平台的使用。比如，你可以构建一个集群；你可以把它作为一个手提电脑来使用；甚至还可以在黑莓上运行 Kafka。以上都是尤其简单的运行库的概念。

因此我们要做的事情与使用 Kafka 其他的客户端类似，比如发布者、消费者，只要在代码里边加入就可以使用各种各样的 API。当你要调配控制 Kafka Stream 应用的时候，选择最基础的 War File 来运行或者采用 Java、C，甚至资源管理器来运行都是可行的。因为 Kafka Stream 是一个轻量级流处理的库，可支持各种各样的运维方式。

在我们看来，简单的就是美的，只有给用户提供最大的兼容性与最大的延展性，用户才能得到最好的用户体验。

Kafka Stream 的编程语言

如果接触过 Storm、Spark 等流处理平台的同学可以发现，它们与 Kafka Stream 高阶位 DSL 语言其实有相似之处。如上图所示，首先定义一个 Streams 流， Streams 是从 topic1 中的 topic 获取得到，即定义 Streams、处理 Streams、得到新的 Streams。比如，从 topic1 里面得到两个原始数据流，然后数据流进行 countByKey 得到新的数据流叫做 Counts。那么 counts.to(“topic2”) 是什么意思呢？在获取到新的数据流之后写回 Kafka topic2 内，启动 KafkaStreams 进程，与 Kafka producer、Kafka consumer 类似，让它来运行已定义计算。

正如大家所了解的，API 的使用其实很简单。提供一个简单的 API，用户简单地写入运行逻辑即可运行。但是编程应用总是容易的，而它的复杂程度在于，一旦你开始运维该应用，当你想要把业务拓展到更大规模，或者业务出现变化，或者集群不稳定，需要强大的运维时，运维的程度便显得异常重要，最上面的编程可能只是冰山一角。Kafka Stream 的设计理念是最简单的就是最美的，包括 API、运维、debugging，以及各种各样的方式，都是希望给用户带来最简单的体验。它的核心思想就是把难问题直接给 Kafka 集群本身。

Kafka 的介绍

Kafka 的核心思想是什么？就是把这些消息全部存成一个有序日志，所有的消息发布者把消息发布到底端，从某一个逻辑上的位移开始顺序读取所有的消息。它的一个好处在于所有的读和写，尽管都是刷到磁盘上，但都是按照顺序进行，该方式对磁盘的使用比较有效，倘若消费者和发布者隔得比较近，将利用 page cash 直接读数据。

延展性。如上图，提供 topic 以及 topic partitions，即话题与话题分区的机制。每个用户有不同的 topic，每个 topic 可以有多个分区，每个分区可被装载在不同的机器上，当用户提高规模之后，Kafka 只需要简单地增加机器和 topic partitions 数量，或者采用 ROM balance 的方式到不同机器上，即可达到线性延展方式。

以上是 Kafka 最简单的核心思想，接下来我将介绍 Kafka Streams 作为 Kafka 客户端如何利用以上核心思想来设计流处理的平台。数据流其实就是有序的记录或消息，每个消息是一个 Key 加一个 Value，并且 record 与 Kafka 自身 massage 具有一一对应关系。

用户所提供的业务上的计算模型，其实可用拓补结构进行表达。如上图，图的左边。用户首先进行定义数据流，然后对数据流进行计算，得到新的数据流，最终将数据流写回到 Kafka 内。每当用户进行定义的时候，每一步都会变成拓扑结构里面的一个点，每个点通过流进行计算，变成新的流来进行新的连接，最终在 Kafka 内部形成拓扑结构。用户并不需要在意该拓补结构，只需明白定义流、计算流、得到新的流，写回 Kafka。

连接每一个不同的运算单元就是一个 Stream，即 record stream，每一个 Stream 都在源源不断地实时产生 record，每一个 record 是一个 key 加一个 value。利用 Stream Processor 连接 Stream，每个用户定义的流的一个计算单位对应着一个 Stream Processor。

当用户定义每一步计算的时候，就是定义每个拓扑结构里面的每个点，最终把整个拓补结构定义完整到 Kafka Stream 来运行。计算单�...

更多深度文章，请关注云计算频道：https://yq.aliyun/cloud

阿里云数据事业部强琦为大家带来题为“流式计算的系统设计与实现”的演讲，本文主要从增量计算和流式计算开始谈起，然后讲解了与批量计算的区别，重点对典型系统技术概要进行了分析，包括Storm、Kinesis、MillWheel，接着介绍了核心技术、消息机制以及StreamSQL等，一起来了解下吧。

增量计算和流式计算

流式计算

流计算对于时效性要求比较严格，实时计算就是对计算的时效性要求比较强。流计算是利用分布式的思想和方法，对海量“流”式数据进行实时处理的系统，它源自对海量数据“时效”价值上的挖掘诉求。

那么，通常说的实时系统或者实时计算，严格意义上来说分成三大类：

ad-hoc computing（数据的实时计算）：计算不可枚举，计算在query时发生。

stream computing（实时数据的计算）：计算可枚举，计算在数据发生变化时发生。

continuous computing(实时数据的实时计算)：大数据集的在线复杂实时计算。

增量计算

增量计算是分批，也就是batch，每个batch会计算出一个function的delta值，数据的一个delta最终会变成对function的一个delta值，最终通过增量计算达到效果。

batch => delta: f(x + delta) = g( f(x), delta )

实际上是在数据的delta值上计算的一个结果，这个f（x）我们称之为oldValue，整个function的一个oldValue从公式就可以看到，整个增量计算与全量计算和批量计算有很大的不一样的地方，就在于它是有状态的计算，而批量计算系统和全量计算系统是无状态的计算，所以这就会导致整个系统的设计思路理念和整个的容错机制会有很大的不同，相对于oldValue本批次的数据，delta作为一个输入，整体上是一个有状态的计算，它会在系统的时效性、系统的复杂性和系统性能之间去做tradeoff，如果batch里的数据量是非常少的，那这个系统表现出来的时效性是最实时的，当然，整个系统的容错吞吐就会受到影响，就是说一批次的数据量是比较少的情况下，整个的系统吞吐会比较低，整个系统的容错复杂度也会比较高，那么在增量计算情况下，它有哪些优势呢？

1.相比以前的全量计算，中间的计算结果是实时产出的，也就是说它的时效性是很强的；

2.我们把一个计算平摊在每一个时间段，可以做到平摊计算。整个集群的规模是受峰值的影响，双十一的峰值流量是非常大的，如果按照最峰值的流量去计算，整个服务器资源是相对较高的，如果能够把传统的计算平摊在每一分钟每一秒，实际可以起到降低成本的作用；

3.整个数据处理链路如果放在一次Query中进行处理，也即是全部的数据在进行一个function的计算时，会大量膨胀中间结果，也就是说像Group By Count会到达200G，而增量计算可以做到中间结果不膨胀；

4.增量计算是一个有状态的计算，在分布式领域，有状态的failover策略会跟无状态的计算系统截然不同，但是它的优势是恢复快，任务可以切成很多碎片去运行，一旦任务因为任何几台服务器的抖动而宕机，整个的恢复是从前一次有效的batch开始计算，而不是像全量计算和离线计算一样，全部要重新进行计算，当在离线计算和在线计算混合部署的情况下，这显得尤为重要；

5.增量计算把一大块数据分批去计算，因此在批量计算里面经常遇到会一些数据倾斜问题在增量计算并不会遇到。在真实场景下，数据倾斜会对整个计算系统产生非常致命的影响，所以假设不同的节点之间数据倾斜比是1000，这个实际是很平常的，双十一的时候，光小米一家店铺就做到了很高的销售额，小米店铺和其他店铺的成交是上万倍甚至几十万倍的scale，传统的分布式计算的整个计算延时是受最慢的那个节点影响，如果把全部的数据分批次，实际上对于每一批来说，数据的倾斜度就会缓解，而且每个批次是可以并行去运行的，所以这可以大大地去降低整个计算任务在数据倾斜情况下的运行效率问题。

增量计算和流式计算应用场景

日志采集和在线分析：如基于访问日志、交易数据的BI算法分析。比较有名的像Google的统计、百度的统计,一些网站根据访问日志，会分析出各种的UV、 PV、 IPV等运营指标，有了流式计算，就可以对这些访问的时效性做到秒级、分钟级的监控，比如双十一当天，不同的店铺会通过店铺的实时访问情况来决定后面的运营策略；

大数据的预处理：数据清洗、字段补全等；

风险监测与告警：如交易业务的虚假交易实时监测与分析；

网站与移动应用分析统计：如双11运营、淘宝量子统计、CNZZ、友盟等各类统计业务；

网络安全监测：如CDN的恶意攻击分析与检测；

在线服务计量与计费管理系统 搜索引擎的关键词点击计费；

此外，流式计算和增量计算也应用在工业4.0和物联网上。

流式计算的数据特点

流（stream）是由业务产生的有向无界的数据流。

不可控性：你不知道数据的到达时机以及相关数据的顺序，对于数据质量和规模也是不可控的；

时效性要求：在容错方案、体系架构和结构输出方面都与传统的计算是截然不同的；

体系缺失：传统学术领域已经对批量计算和离线计算的体系研究的非常成熟，而在实时领域如数据仓库中间层等领域都是缺失的，包括数据源管理、数据质量管理等等。

另外，数据处理粒度最小，可以小到几条数据，对架构产生决定性影响；

处理算子对全局状态影响不同，有状态、无状态、顺序不同等；

输出要求，比如一致性和连贯性等。

整个流计算会对系统有非常多的不一样的要求，这就会导致整个系统有非常大的复杂性，跟离线非常的不同，我们的计算仍然要求时效性、要求快，质量上要求它的计算一定是精准的，对容错的要求，不论你的机器、集群、网络硬件有任何的宕机，计算应该是持续稳定，对整个计算的要求也是非常多样性的。关于多样性，不同的业务场景，对计算的结果要求也是不一样的，有些要求精确，一点数据都不能丢、精度损失，还有的业务场景要求可以多但是不能少，还有丢数据有一个sla在保证等，所以种种特点导致我们做流式计算和增量计算系统会面临与传统的离线计算和增量计算完全不同的要求。

与批量计算的区别

从架构角度，增量计算、流式计算和离线处理、批处理有什么本质的区别?

与批量计算的区别如上图所示，比如全量计算设计理念是面向吞吐，而流式计算是实时计算的一部分，面向延时；随之而来的整个全量DAG是一个串型的DAG，是一个StageByStage的DAG，而流式计算的DAG是一个并行DAG，也就是说Batch跟Batch之间是完全可以并行的，离线的批量系统它的串型化和Streaming场景下的并行化，它们在整个数据的时效性上

有非常大的区别，特别是在Latency的体现。

典型系统计算概要分析

下面将向大家介绍业界比较经典的几个流计算产品：

Twitter Storm

Storm是Twitter内部使用开源被广泛使用的一套流计算系统，那么它的一个核心概念是说，一个任务要创建一个Topology，它表示了一个完整的流计算作业，它的最开始的源头名字叫做Spout，做收集数据的任务，它的前面可以挂任何的数据源、任何一个队列系统甚至可以对接文件，那么Bolt是它的具体计算任务所在的载体，而Bolt里有诸多的Task，它是在Spout和Bolt里负责具体一个数据分片的实体，它也是Storm里调度的最小单位。Acker负责跟踪消息是否被处理的节点。Storm的整个容错是采用源头重发的消息机制

源头重发在网络流量激增的情况下，会造成系统的雪崩风险大大提升。上图是两个Storm的作业，它先从源头读出数据，然后进行filter过滤，最终进行join，join后进行一些逻辑处理。

Nimbus–Zookeeper–Supervisor

Storm采用了Nimbus Supervisor之间的方式进行任务调度和跟踪，它们之间是利用Zookeeper来进行通讯，Nimbus相当于一个全局的任务Master，负责接收Topology，然后进行二重的资源调度，并且将调度的信息记录到Zookeeper中，定期检查Zookeeper中的各种Supervisor的心跳信息，根据心跳状态决定任务是否进行重新调度，而Supervsor充当着每台物理机的一个watchdog，它在轮询Zookeeper中的调度任务信息，然后接收到发现有启动任务的信息，就会拉启进程，启动Task，同时定期要把心跳信息写入Zookeeper，以便Supervisor来做出重新调度或者系统的重发操作。

消息跟踪机制是Storm的核心，保证消息至少被处理一次，它追踪源头信息的所有子孙信息。

基本思路如下：

Acker节点是进行消息跟踪的节点，以源头消息的ID为hash key，来确定跟踪的Acker，源头信息对应的所有的子孙消息都有该Acker负责跟踪，而消息树上每产生一个新的子孙消息，则通知对应的Acker，子孙消息被处理，然后再去通知对应的Acker，当Acker里所有的子孙消息都被处理的时候，那么整个数据处理就完成了。

子孙的产生是由父节点，而处理是被子节点。所以Storm用了一个非常巧妙的异或方法，当父节点产生这个消息时，产生一个随机数，把这个随机数异或到Acker里，Acker把这个随机数传递到下一步的节点，当这个节点正确被处理以后，再把这节点发送给Acker去做异或，所以Storm利用了这个Acker机制来压缩整个数据的跟踪机制，最终保证任意节点出现宕机而值不会变成0。

Transactional Topology

光有以上的机制，还远远不够。被系统重发的消息没有任何附加信息，用户无法判断消息是否是被重发的等一些问题还有待解决，为解决消息被重复处理的问题，Storm 0.7.0以后版本推出了Transactional Topology进行改进，

原理如下：

在Spout上将源头消息串行划分成 Batch，为每个Batch赋以递增的id，记录在Zookeeper中，利用Acker跟踪Batch是否被完全处理完成，超时或者节点异常，Spout重发Batch内的所有消息，不影响中间状态的操作可以并发的执行，例如 Batch内的聚合操作，用户代码利用唯一的Batch ID进行去重。

整个Topology同一时刻只能有一个Batch正在提交，以保证在每个节点上Batch串行递增，简化用户去重的逻辑。

Storm优缺点

优点：消息在框架内不落地，处理非常高效，保证了消息至少被处理，Transactional Topology为消息去重提供了可能，调度模式简单，扩展能力强（关闭重发模式下），社区资源丰富，拥有各种常见消息源的Spout实现。

当然Storm也有自己的劣势：Transactional Topology对Batch串行执行方式，性能下降严重；Batch太大太小都有问题，大小需要用户根据具体业务分情况设置等。

Amazon Kinesis

Kinesis系统是一种完全托管的实时处理大规模数据流的开放服务。

所有节点运行于EC2中：相对Storm来说，它采用了消息节点内部重放的系统，而不是像Storm那样子源头重发，它的所有的节点都已经在EC2中，无需单独的调度策略、复用安全、资源隔离机制，且扩展性好、弹性可伸缩。

只支持单级Task，可以利用多个Stream组成复杂的DAG-Task，用户代码需要实现DAG-Task内部的消息去重逻辑。

数据收集与计算独立：数据收集模块（Shard）对消息进行持久化，最长保留24小时；可以Get方式从其它系统中读取Shard数据，计算模块（Kinesis App）处理被推送的数据，Instance个数与Shard个数相同；用户代码可以自主控制Checkpoint节奏。

用户可以自主调用相应的SplitShard\MergeShard接口，Stream上所有App的并发度随之调整。具体实现方法如下：

每个Shard串行将接收到的消息写入S3文件中，SplitShard后，原有Shard不再接收新数据，原有Shard对应的所有App的Instance处理完消息后关闭，启动新的Shards(两个)和对应新的Instances。

使计算可以更加的弹性，服务的可用性也更高。

Google MillWheel

MillWheel系统是利用内部支持Snapshot功能的Bigtable来进行持续化中间结果，将每个节点的计算输出消息进行持久化，实现消息的“不丢不重”。

区别于Storm的是，它没有复杂的跟踪树。因为每一级都把它的输出消息进行持久化，用户可以通过SetTimer\ProcessTimer接口解决用户代码在消息到来时才能取得控制流的弊端，然后在源头节点（Injector）上将数据打上系统时间戳，每个内部节点（Computation）计算出所有输入Pipe上的最小时间戳，向所有输出Pipe上广播当前完成的最小时间戳，用户可以利用Low Watermark这一机制解决消息乱序或一致性问题。

核心技术

那么，流式计算和增量计算中最核心的一些技术和难点有哪些呢？

从这张图可以看到，整个流计算是由一个复杂的Topology所构成。那么，从输入到输出，其中比较重要的两个角色一是Jobmaster，一是Coordinator。Jobmaster是每个Job负责运行时的一个master；而Coordinator是刚才所说的消息跟踪的一个角色，所以Coordinator最好是完全可以做到无状态的线性扩展。

Batch数据从源头进入后，进入Source节点，Source节点会从消息源读取数据，蓝色的部分代表着Worker节点，蓝色节点再向橙色节点进行数据传输的时候，遵循着Shuffle的方法，可以是哈希的方法，可以是广播的方法，也可以是任何用户自定义的方法，output节点会将输出结果向在线系统输出，或者向下一级MQ节点输出，输出的结果也是按照Batch去对齐。

系统�...

随着这些年全世界数据的几何式增长，数据的存储和运算都将成为世界级的难题。之前小鸟给大家介绍过一些分布式文件系统，解决的是大数据存储的问题，今天小鸟给大家介绍一些分布式计算框架：

Hadoop框架

提起大数据，第一个想起的肯定是Hadoop，因为Hadoop是目前世界上应用最广泛的大数据工具，他凭借极高的容错率和极低的硬件价格，在大数据市场上风生水起。Hadoop还是第一个在开源社区上引发高度关注的批处理框架，他提出的Map和Reduce的计算模式简洁而优雅。迄今为止，Hadoop已经成为了一个广阔的生态圈，实现了大量算法和组件。由于Hadoop的计算任务需要在集群的多个节点上多次读写，因此在速度上会稍显劣势，但是其吞吐量也同样是其他框架所不能匹敌的。

Storm框架

与Hadoop的批处理模式不同，Storm采用的是流计算框架，由Twitter开源并且托管在GitHub上。与Hadoop类似的是，Storm也提出了两个计算角色，分别为Spout和Bolt。

如果说Hadoop是水桶，只能一桶一桶的去井里扛，那么Storm就是水龙头，只要打开就可以源源不断的出水。Storm支持的语言也比较多，Java、Ruby、Python等语言都能很好的支持。由于Storm是流计算框架，因此使用的是内存，延迟上有极大的优势，但是Storm不会持久化数据。

Samza框架

Smaza也是一种流计算框架，但他目前只支持JVM语言，灵活度上略显不足，并且Samza必须和Kafka共同使用。但是响应的，其也继承了Kafka的低延时、分区、避免回压等优势。对于已经有Hadoop+Kafka工作环境的团队来说，Samza是一个不错的选择，并且Samza在多个团队使用的时候能体现良好的性能。

Spark框架

Spark属于前两种框架形式的集合体，是一种混合式的计算框架。它既有自带的实时流处理工具，也可以和Hadoop集成，代替其中的MapReduce，甚至Spark还可以单独拿出来部署集群，但是还得借助HDFS等分布式存储系统。Spark的强大之处在于其运算速度，与Storm类似，Spark也是基于内存的，并且在内存满负载的时候，硬盘也能运算，运算结果表示，Spark的速度大约为Hadoop的一百倍，并且其成本可能比Hadoop更低。但是Spark目前还没有像Hadoop哪有拥有上万级别的集群，因此现阶段的Spark和Hadoop搭配起来使用更加合适。

Flink框架

Flink也是一种混合式的计算框架，但是在设计初始，Fink的侧重点在于处理流式数据，这与Spark的设计初衷恰恰相反，而在市场需求的驱使下，两者都在朝着更多的兼容性发展。Flink目前不是很成熟，更多情况下Flink还是起到一个借鉴的作用。

以上就是现在比较主流的大数据运算框架的介绍了，欢迎大家收藏转发。关注小鸟，获取更多大数据级相关技术的资讯与教程。

5个月的好程序员大数据培训学习，只是冰山一角，对于大数据职业生涯，我们要走的路还很长。苦是真的，但是活着，身上的责任和梦想就应该去承担、去实现，要微笑的去面对磨砺。

马上就要上战场了，今年毕业生820万，想想都可怕。付出不一定有结果，但是，不付出一定什么都没有!大数据学习内容杂而多，要系统的掌握整体，需要很多的时间。包括Apache官网的各个框架的熟悉，更是需要时间的沉淀。好在遇到了好程序员的负责讲师，整体课程安排也十分科学，以下是我对大数据Flink部分学习的一些总结：

Flink是一个分布式流处理的开源框架，提供准确的结果，即使在无序或迟到数据的情况下也是如此，具有状态和容错能力，可以在保持一次性应用程序状态的同时无缝地从故障中恢复，大规模执行，在数千个节点上运行，具有非常好的吞吐量和延迟特性。

此前，我们讨论了将数据集的类型(有界还是无界)与执行模型的类型(批量与流媒体)进行对齐。下面列出的许多Flink功能 - 状态管理，无序数据的处理，灵活的窗口 - 对于在无界数据集上计算精确的结果非常重要，并且由Flink的流式执行模型来实现。

Flink保证有状态计算的exactly-once。“有状态的”意味着应用程序可以维护一段时间内已经处理的数据的汇总或汇总，并且Flink的检查点设置机制确保在发生故障时应用程序的状态exactly-once。Flink支持流处理和窗口事件时间semantics。事件时间可以轻松计算事件到达顺序不正确，事件可能延迟到达的流的精确结果。

除了数据驱动的窗口，Flink还支持基于时间，计数或会话的灵活窗口。Windows可以通过灵活的触发条件进行定制，以支持复杂的流模式。Flink的窗口可以模拟数据创建环境的实际情况。

Flink的容错功能是轻量级的，可以让系统保持高吞吐率，同时提供一次性一致性保证。Flink从零数据丢失的故障恢复，而可靠性和延迟之间的折衷可以忽略不计。

Flink的保存点提供了一个状态版本管理机制，可以更新应用程序或重新处理历史数据，而且不会丢失状态，停机时间最短。

Flink设计用于在数千个节点的大型集群上运行，除了独立集群模式之外，Flink还提供对YARN和Mesos的支持。

希望我们能用大数据人工智能去改变这个世界!