什么是大数据？大数据就是指在一定时间范围内无法使用传统数据库工具对其进行捕捉、管理、计算、分析和处理的数据集合，大数据有以下四个特性：海量的数据规模（Volumn），数据类型繁多（Variety），数据流转速度极快（Velocity）以及价值密度较低（Value），我们就说说这四大特性。

海量的数据规模

我们接触最多最敏感的数据那就是我们手机所购买的流量，最常见的数据计量单位为K、M和G，他们的关系为1G=1024M，1M=1024KB。也许你也听过TB，1TB=1024G，这个数据单位对我们来世已经相当庞大了，我们的笔记本最大的容量也就在1TB这个级别，但是在大数据眼里最小的数据也得10TB起，比TB级还大的数据计量单位还有吗？有，而且还很多，1PB=1024TB，1EB=1024PB，1ZB=1024EB，1YB=1024ZB......我们已经无法感知这么大的数据量了。截止到2011 年，互联网用户数已达到20 亿； RFID 标签在2005 年的保有量仅有13亿个，但是到2010 年这个数字超过了300 亿；2006 年资本市场的数据比2003 年增长了17.5倍；日前新浪微博上每天上传的微博数超过1 亿条；Facebook 每天处理10TB 的数据；世界气象中心积累了220TB 的Web 数据，9PB 其他类型数据……

极快的数据流转

数据具有一定的时效性，是不停的变化的，可以随时间数据量逐渐增大，也可在空间上不断移动变化的数据。如果我们采集到的数据不经过流转，最终会过期作废。客户的体验在分秒级别，海量的数据，带来的第一个问题就是大大延长了各类报表生成时间，我们能否在极端的时间内提取最有价值的信心呢？数据在1秒内得不到流转处理，就会给客户带来较差的使用体验，若我们的数据处理软件达不到“秒”处理，所带来的商业价值就会大打折扣。

价值密度低

尽管大数据的数据量巨大，但是有价值的信息极少，我们要通过分析才能将大数据从数据到价值的转变，这些工作量极其庞大，所以云计算是一个很好的解决途径。以监控视频为例，一小时的视频，在不间断的监控过程中，可能有用的数据仅仅只有一两秒。

数据种类繁多

数据的格式是多样化的，如文字、图片、视频、音频、地理位置信息等，也可以是不同的数据类别，也可以有不容的来源，如传感器、互联网。首先用户是一个复杂的个体，单一的行为数据是不足以描述用户的各种行为，多元化的信息采集处理就像拼图一样，逐渐勾勒出我们身体的骨架，增添上我们的血肉。我们在淘宝、京东购物时，总会在下面的推荐区推荐我们想要的东西，比如我们去频繁的搜索浏览某件商品，这是他们就会采集我们浏览的数据，从中挖去有价值的信息，推送给我们。所以说这样的模式给一种体验，那就是这些app越来越懂我们的爱好和需求。

大数据未来会渗透在很多领域，大数据与云计算，机器学习与人工智能，物联网，区块链等。

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)的识别时延，同时具有机器人识别管控一体化、轻量级接入等优点。根据已经接入机器防御服务的几十家客户的反馈，基于“流立方�...

文 | 吕鹏 DataPipeline架构师

进入大数据时代，实时作业有着越来越重要的地位。本文将从以下几个部分进行讲解DataPipeline在大数据平台的实时数据流实践。

一、企业级数据面临的主要问题和挑战

1. 数据量不断攀升

随着互联网+的蓬勃发展和用户规模的急剧扩张，企业数据量也在飞速增长，数据的量以GB为单位，逐渐的开始以TB/GB/PB/EB，甚至ZB/YB等。同时大数据也在不断深入到金融、零售、制造等行业，发挥着越来越大的作用。

2. 数据质量的要求不断地提升

当前比较流行的AI、数据建模，对数据质量要求高。尤其在金融领域，对于数据质量的要求是非常高的。

3. 数据平台架构的复杂化

企业级应用架构的变化随着企业规模而变。规模小的企业，用户少、数据量也小，可能只需一个MySQL就搞能搞；中型企业，随着业务量的上升，这时候可能需要让主库做OLTP，备库做OLAP；当企业进入规模化，数据量非常大，原有的OLTP可能已经不能满足了，这时候我们会做一些策略，来保证OLTP和OLAP隔离，业务系统和BI系统分开互不影响，但做了隔离后同时带来了一个新的困难，数据流的实时同步的需求，这时企业就需要一个可扩展、可靠的流式传输工具。

二、大数据平台上的实践案例

下图是一个典型的BI平台设计场景，以MySQL为例，DataPipeline是如何实现MySQL的SourceConnector。MySQL作为Source端时：

全量+ 增量；全量：通过select 方式，将数据加载到kafka中；增量：实时读取 binlog的方式；使用binlog时需要注意开启row 模式并且image设置为 full。

1. MySQL SourceConnector 全量+增量实时同步的实现

下面是具体的实现流程图，首先开启repeatable read事务，保证在执行读锁之前的数据可以确实的读到。然后进行flush table with read lock 操作，添加一个读锁,防止这个时候有新的数据进入影响数据的读取，这时开始一个truncation with snapshot，我们可以记录当前binlog的offset 并标记一个snapshot start，这时的offset 为增量读取时开始的offset。当事务开始后可以进行全量数据的读取。record marker这时会将生成record 写到 kafka 中，然后commit 这个事务。当全量数据push完毕后我们解除读锁并且标记snapshot stop，此时全量数据已经都进入kafka了，之后从之前记录的offset开始增量数据的同步。

2. DataPipeline做了哪些优化工作

1）以往在数据同步环节都分为全量同步和增量同步，全量同步为一个批处理。在批处理时我们都是进行all or nothing的处理，但当大数据情况下一个批量会占用相当长的时间，时间越长可靠性就越难保障，所以往往会出现断掉的情况，这时一个重新处理会让很多人崩溃。DataPipeline 解决了这一痛点，通过管理数据传输时的position 来做到断点续传，这时当一个大规模的数据任务即使发生了意外，也可以重断掉的点来继续之前的任务，大大缩短了同步的时间，提高了同步的效率。

2）在同步多个任务的时候，很难平衡数据传输对源端的压力和目的端的实时性，在大数据量下的传输尤其能够体现，这时DataPipeline 在此做了大量相关测试来优化不同的连接池，开放数据传输效率的自定义化，供客户针对自己的业务系统定制合适的传输任务，对于不同种类的数据库的传输进行优化和调整，保证数据传输的高效性。

3）自定义异构数据类型的转化，往往开源类大数据传输工具如 sqoop 等，对异构数据类型的支持不够灵活，种类也不够齐全。像金融领域中对数据精度要求较高的场景，在传统数据库向大数据平台传输时造成的精度丢失是很大的一个问题。DataPipeline 对此做了更多数据类型的支持，比如hive 支持的复杂类型以及 decimal 和 timestamp 等。

3. Sink端之Hive

1）Hive的特性

Hive 内部表和外部表；依赖HDFS；支持事务和非事务；多种压缩格式；分区分桶。2）Hive同步的问题

如何保证实时的写入？schema change了怎么办？怎么扩展我想保存的格式？怎么实现多种分区方式？同步中断了怎么办？如何保证我的数据不丢？3）KafkaConnect HDFS 的 Hive 同步实践

使用外表：Hive外部表，能够提高写入效率，直接写HDFS，减少IO消耗，而内表会比外表多一次IO；Schema change：目前的做法是目的端根据源端的变化而变化，当有增加列删除列的情况，目标端会跟随源端改动；目前支持的存储格式：parquet，avro ，csv插件化的partitioner，提供多种分区方式，如 Wallclock RecordRecordField：wallclock是使用写入到hive端时的系统时间，Record 使用是读取时生成record的时间，RecordField是使用用户自定义的时间戳来定义分区，未来会实现可自定义化的partitioner 来满足不同的需求；Recover 机制保障中断后不会丢失数据；使用WAL （Write-AheadLogging）机制，保证数据目的端数据一致性。4）Recover的机制

recover 是一种恢复的机制，在数据传输的阶段往往可能出现各种不同的问题，如网络问题等等。当出现问题后我们需要恢复数据同步，那么recover是怎么保证数据正常传输不丢失呢？当recover开始的时候，获取目标文件在hdfs 上的租约，如果这时候需要读写的HDFS当前文件是被占用的，那我们需要等待它直到可以获取到租约。当我们获取到租约后就可以开始读之前写入时候的log，如果第一次会创建一个新的log，并标记一个begin，然后记录了当时的kafka offset。这时候需要清理之前遗留下来的临时数据，清理掉之后再重新开始同步直到同步结束会标记一个end。如果没有结束的话就相当于正在进行中，正在进行中每次都会提交当前同步的offset，来保证出现意外后会回滚到之前offset。

5）WAL （Write-Ahead Logging）机制

Write-Ahead Logging机制其实就是核心思想在数据写入到数据库之前，它先写临时文件，当一个批次结束后，在将这个临时文件改名为正式文件，确保每次提交后的正式文件一致性，如果中途出现写入错误将临时文件删除重新写入，相当于一个回滚。hive 的同步主要利用这种实现方式来保证一致性。首先它同步数据写入到HDFS临时文件上，确保一个批次的数据正常后再重命名到正式文件当中。正式的文件名会包含kafka offset，例如一个avro 文件的文件名为 xxxx+001+0020.avro ，这表示当前文件中有offset 1 到 20 的20条数据。

4. Sink端之GreenPlum

GreenPlum，是一个MPP架构的数据仓库，底层由多个postgres数据库作为计算节点，擅长OLAP，作为BI数据仓库有着良好的性能。

1）DataPipeline对GreenPlum 同步实践以及优化策略

greenplum 支持多种数据加载方式，目前我们使用copy的加载方式。批量处理提高sink端写入效率，不进行insert 和 update 的操作，一律使用 delete + copy 的方式批量加载；多线程加预加载机制： 每个需要同步的表单独记录一个offset，当整个任务失败时可以分开进行恢复；

使用一个线程池管理加载数据的线程，每个同步的表单独一个线程来进行加载数据，多表同时同步；

在加载数据的时间里，提前对kafka进行消费，缓存处理好的一个数据集，当一个线程加载数据结束后马上开始新的线程加载数据，减少处理加载数据的时间；

delete + copy的方式可以保证数据最终一致性；source 端有主键的表可以通过主键来合并一个批次需要同步的数据，如一个需要同步的批量数据中包含一条 insert 的数据，后面跟着 update 该条数据，那就无需同步两遍，将该数据更新到 update 之后的状态 copy 到 gp 当中即可。同步GreenPlum需要注意：因为是通过copy 写入文件的，需要文件是结构化数据，典型的是使用CSV，CSV 写入时需注意spiltquote，escapequote，避免出现数据错位的现象。update主键的问题 , 当源端是update一个主键时，同时需要记录update前的主键，并在目标端进行删除。还有 \0 特殊字符的问题，因为核心是用C语言，所以在同步的时候\0需要特殊处理掉。

三、DataPipeline未来的工作

目前我们碰到kafka connect rebalance的一些问题，所以我们对其进行了改造。以往的rebalance机制是假如我们增加或者删除一个task，会导致整个集群rebalance，这样造成很多无谓的开销而且频繁的rebalance 不利于数据同步的任务的稳定。于是我们将rebalance机制改造成一个黏性的机制：当我们增加一个新的任务的时候，我们会检查所有的worker使用率比较低的，当worker的task比较少，我们只把它加进比较少的worker就可以了，也不需要做全量的平衡，当然这时候可能还是有一些不平衡的资源浪费，这是我们可以容忍的，至少比我们做一次全量的rebalance开销要小；假如删除一个task，以往的机制是删除一个task的时候也会做全量的Rebalance，新的机制不会触发rebalance。这时候如果时间长也会造成一个资源不平衡，这是我们可以自动化rebalance一下所有的集群；假如说集群的某个节点宕掉了，该节点的task怎么办呢？我们不会马上就把这个节点上的 task分配出去，会先等待10分钟，因为有的时候它可能只是短暂的连接超时，过一段时间后就会恢复，如果根据这个来做一次rebalance，可能这是不太值的。当等待10分钟后节点还是没有恢复，我们再做rebalance，将宕掉的节点任务分配到其他节点上；2. 源端的数据一致性，目前通过WAL的机制可以保证目的端的一致性；

3. 大数据量下的同步优化以及提高同步的稳定性。

四、总结

1. 大数据时代企业数据集成主要面临各种复杂的架构，应对这些复杂的系统对ETL的要求也越来越高。我们能做的就是需要权衡利弊选取一个符合业务需求的框架；

2. Kafka Connect 比较适合对数据量大，且有实时性需求的业务；

3. 基于Kafka Connect 优良特性可以依据不同的数据仓库特性来提高数据时效性和同步效率；

4. DataPipeline针对目前企业在大规模实时数据流的痛点，进行了相关的改造和优化，首先数据端到端一致性的保证是几乎所有企业在数据同步过程中碰到的，目前已经做到基于kafka connect 的框架中 rebalance 中的优化和改造。

—end—

[来自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倍的性能提升。因此，整个方案是十分有效的。

目前，大数据领域每年都会涌现出大量新的技术，成为大数据获取、存储、处理分析或可视化的有效手段。大数据技术能够将大规模数据中隐藏的信息和知识挖掘出来，为人类社会经济活动提供依据，提高各个领域的运行效率，甚至整个社会经济的集约化程度。

1大数据生命周期

图1展示了一个典型的大数据技术栈。底层是基础设施，涵盖计算资源、内存与存储和网络互联，具体表现为计算节点、集群、机柜和数据中心。在此之上是数据存储和管理，包括文件系统、数据库和类似YARN的资源管理系统。然后是计算处理层，如hadoop、MapReduce和Spark，以及在此之上的各种不同计算范式，如批处理、流处理和图计算等，包括衍生出编程模型的计算模型，如BSP、GAS 等。数据分析和可视化基于计算处理层。分析包括简单的查询分析、流分析以及更复杂的分析(如机器学习、图计算等)。查询分析多基于表结构和关系函数，流分析基于数据、事件流以及简单的统计分析，而复杂分析则基于更复杂的数据结构与方法，如图、矩阵、迭代计算和线性代数。一般意义的可视化是对分析结果的展示。但是通过交互式可视化，还可以探索性地提问，使分析获得新的线索，形成迭代的分析和可视化。基于大规模数据的实时交互可视化分析以及在这个过程中引入自动化的因素是目前研究的热点。

有2个领域垂直打通了上述的各层，需要整体、协同地看待。一是编程和管理工具，方向是机器通过学习实现自动最优化、尽量无需编程、无需复杂的配置。另一个领域是数据安全，也是贯穿整个技术栈。除了这两个领域垂直打通各层，还有一些技术方向是跨了多层的，例如“内存计算”事实上覆盖了整个技术栈。

2.大数据技术生态

大数据的基本处理流程与传统数据处理流程并无太大差异，主要区别在于：由于大数据要处理大量、非结构化的数据，所以在各处理环节中都可以采用并行处理。目前，Hadoop、MapReduce和Spark等分布式处理方式已经成为大数据bbsitedu处理各环节的通用处理方法。

Hadoop是一个能够让用户轻松架构和使用的分布式计算平台。用户可以轻松地在Hadoop上开发和运行处理海量数据的应用程序。Hadoop 是一个数据管理系统，作为数据分析的核心，汇集了结构化和非结构化的数据，这些数据分布在传统的企业数据栈的每一层。Hadoop也是一个大规模并行处理框架，拥有超级计算能力，定位于推动企业级应用的执行。Hadoop又是一个开源社区，主要为解决大数据的问题提供工具和软件。虽然Hadoop提供了很多功能，但仍然应该把它归类为多个组件组成的Hadoop生态圈，这些组件包括数据存储、数据集成、数据处理和其他进行数据分析的专门工具。图2 展示了Hadoop 的生态系统，主要由HDFS、MapReduce、Hbase、Zookeeper、Oozie、Pig、Hive等核心组件构成，另外还包括Sqoop、Flume等框架，用来与其他企业融合。同时，Hadoop 生态系统也在不断增长，新增Mahout、Ambari、Whirr、BigTop 等内容，以提供更新功能。

图2Hadoop生态系统

低成本、高可靠、高扩展、高有效、高容错等特性让Hadoop成为最流行的大数据分析系统，然而其赖以生存的HDFS 和MapReduce 组件却让其一度陷入困境——批处理的工作方式让其只适用于离线数据处理，在要求实时性的场景下毫无用武之地。因此，各种基于Hadoop的工具应运而生。为了减少管理成本，提升资源的利用率，有当下众多的资源统一管理调度系统，例如Twitter 的Apache Mesos、Apache 的YARN、Google 的Borg、腾讯搜搜的Torca、Facebook Corona(开源)等。Apache Mesos是Apache孵化器中的一个开源项目，使用ZooKeeper实现容错复制，使用Linux Containers 来隔离任务，支持多种资源计划分配(内存和CPU)。提供高效、跨分布式应用程序和框架的资源隔离和共享，支持Hadoop、MPI、Hypertable、Spark 等。YARN 又被称为MapReduce 2.0，借鉴Mesos，YARN 提出了资源隔离解决方案Container，提供Java 虚拟机内存的隔离。对比MapReduce 1.0，开发人员使用ResourceManager、ApplicationMaster与NodeManager代替了原框架中核心的JobTracker 和TaskTracker。在YARN平台上可以运行多个计算框架，如MR、Tez、Storm、Spark等。

基于业务对实时的需求，有支持在线处理的Storm、Cloudar Impala、支持迭代计算的Spark 及流处理框架S4。Storm是一个分布式的、容错的实时计算系统，由BackType开发，后被Twitter捕获。Storm属于流处理平台，多用于实时计算并更新数据库。Storm也可被用于“连续计算”(Continuous Computation)，对数据流做连续查询，在计算时就将结果以流的形式输出给用户。它还可被用于“分布式RPC”，以并行的方式运行昂贵的运算。Cloudera Impala是由Cloudera开发，一个开源的Massively Parallel Processing(MPP)查询引擎。与Hive 相同的元数据、SQL语法、ODBC 驱动程序和用户接口(HueBeeswax)，可以直接在HDFS 或HBase 上提供快速、交互式SQL 查询。Impala是在Dremel的启发下开发的，不再使用缓慢的Hive+MapReduce 批处理，而是通过与商用并行关系数据库中类似的分布式查询引擎(由Query Planner、Query Coordinator 和Query Exec Engine这3部分组成)，可以直接从HDFS 或者HBase 中用SELECT、JOIN 和统计函数查询数据，从而大大降低了延迟。

Hadoop社区正努力扩展现有的计算模式框架和平台，以便解决现有版本在计算性能、计算模式、系统构架和处理能力上的诸多不足，这正是Hadoop2.0 版本“ YARN”的努力目标。各种计算模式还可以与内存计算模式混合，实现高实时性的大数据查询和计算分析。混合计算模式之集大成者当属UC Berkeley AMP Lab 开发的Spark生态系统，如图3所示。Spark 是开源的类Hadoop MapReduce的通用的数据分析集群计算框架，用于构建大规模、低延时的数据分析应用，建立于HDFS之上。Spark提供强大的内存计算引擎，几乎涵盖了所有典型的大数据计算模式，包括迭代计算、批处理计算、内存计算、流式计算(Spark Streaming)、数据查询分析计算(Shark)以及图计算(GraphX)。Spark 使用Scala 作为应用框架，采用基于内存的分布式数据集，优化了迭代式的工作负载以及交互式查询。与Hadoop 不同的是，Spark 和Scala 紧密集成，Scala 像管理本地collective 对象那样管理分布式数据集。Spark支持分布式数据集上的迭代式任务，实际上可以在Hadoop文件系统上与Hadoop一起运行(通过YARN、Mesos等实现)。另外，基于性能、兼容性、数据类型的研究，还有Shark、Phoenix、Apache Accumulo、Apache Drill、Apache Giraph、Apache Hama、Apache Tez、Apache Ambari 等其他开源解决方案。预计未来相当长一段时间内，主流的Hadoop平台改进后将与各种新的计算模式和系统共存，并相互融合，形成新一代的大数据处理系统和平台。

图3Spark生态系统

3.大数据采集与预处理

在大数据的生命周期中，数据采集处于第一个环节。根据MapReduce产生数据的应用系统分类，大数据的采集主要有4种来源：管理信息系统、Web信息系统、物理信息系统、科学实验系统。对于不同的数据集，可能存在不同的结构和模式，如文件、XML 树、关系表等，表现为数据的异构性。对多个异构的数据集，需要做进一步集成处理或整合处理，将来自不同数据集的数据收集、整理、清洗、转换后，生成到一个新的数据集，为后续查询和分析处理提供统一的数据视图。针对管理信息系统中异构数据库集成技术、Web 信息系统中的实体识别技术和DeepWeb集成技术、传感器网络数据融合技术已经有很多研究工作，取得了较大的进展，已经推出了多种数据清洗和质量控制工具，例如，美国SAS公司的Data Flux、美国IBM 公司的Data Stage、美国Informatica 公司的Informatica Power Center。

4.大数据存储与管理

传统的数据存储和管理以结构化数据为主，因此关系数据库系统(RDBMS)可以一统天下满足各类应用需求。大数据往往是半结构化和非结构化数据为主，结构化数据为辅，而且各种大数据应用通常是对不同类型的数据内容检索、交叉比对、深度挖掘与综合分析。面对这类应用需求，传统数据库无论在技术上还是功能上都难以为继。因此，近几年出现了oldSQL、NoSQL 与NewSQL 并存的局面。总体上，按数据类型的不同，大数据的存储和管理采用不同的技术路线，大致可以分为3类。第1类主要面对的是大规模的结构化数据。针对这类大数据，通常采用新型数据库集群。它们通过列存储或行列混合存储以及粗粒度索引等技术，结合MPP(Massive Parallel Processing)架构高效的分布式计算模式，实现对PB 量级数据的存储和管理。这类集群具有高性能和高扩展性特点，在企业分析类应用领域已获得广泛应用;第2类主要面对的是半结构化和非结构化数据。应对这类应用场景，基于Hadoop开源体系的系统平台更为擅长。它们通过对Hadoop生态体系的技术扩展和封装，实现对半结构化和非结构化数据的存储和管理;第3类面对的是结构化和非结构化混合的大数据，因此采用MPP 并行数据库集群与Hadoop 集群的混合来实现对百PB 量级、EB量级数据的存储和管理。一方面，用MPP 来管理计算高质量的结构化数据，提供强大的SQL和OLTP型服务;另一方面，用Hadoop实现对半结构化和非结构化数据的处理，以支持诸如内容检索、深度挖掘与综合分析等新型应用。这类混合模式将是大数据存储和管理未来发展的趋势。

5.大数据计算模式与系统

计算模式的出现有力推动了大数据技术和应用的发展，使其成为目前大数据处理最为成功、最广为接受使用的主流大数据计算模式。然而，现实世界中的大数据处理问题复杂多样，难以有一种单一的计算模式能涵盖所有不同的大数据计算需求。研究和实际应用中发现，由于MapReduce主要适合于进行大数据线下批处理，在面向低延迟和具有复杂数据关系和复杂计算的大数据问题时有很大的不适应性。因此，近几年来学术界和业界在不断研究并推出多种不同的大数据计算模式。

所谓大数据计算模式，即根据大数据的不同数据特征和计算特征，从多样性的大数据计算问题和需求中提炼并建立的各种高层抽象(abstraction)或模型(model)。例如，MapReduce 是一个并行计算抽象，加州大学伯克利分校著名的Spark系统中的“分布内存抽象RDD”，CMU 著名的图计算系统GraphLab 中的“图并行抽象”(Graph Parallel Abstraction)等。传统的并行计算方法，主要从体系结构和编程语言的层面定义了一些较为底层的并行计算抽象和模型，但由于大数据处理问题具有很多高层的数据特征和计算特征，因此大数据处理需要更多地结合这些高层特征考虑更为高层的计算模式。

根据大数据处理多样性的需求和以上不同的特征维度，目前出现了多种典型和重要的大数据计算模式。与这些计算模式相适应，出现了很多对应的大数据计算系统和工具。由于单纯描述计算模式比较抽象和空洞，因此在描述不同计算模式时，将同时给出相应的典型计算系统和工具，如表1所示，这将有助于对计算模式的理解以及对技术发展现状的把握，并进一步有利于在实际大数据处理应用中对合适的计算技术和系统工具的选择使用。

表1典型大数据计算模式

6.大数据分析与可视化

在大数据时代，人们迫切希望在由普通机器组成的大规模集群上实现高性能的以机器学习算法为核心的数据分析，为实际业务提供服务和指导，进而实现数据的最终变现。与传统的在线联机分析处理OLAP不同，对大数据的深度分析主要基于大规模的机器学习技术，一般而言，机器学习模型的训练过程可以归结为最优化定义于大规模训练数据上的目标函数并且通过一个循环迭代的算法实现，如图4所示。因而与传统的OLAP相比较，基于机器学习的大数据分析具有自己独特的特点。

图4基于机器学习的大数据分析算法目标函数和迭代优化过程

(1)迭代性：由于用于优化问题通常没有闭式解，因而对模型参数确定并非一次能够完成，需要循环迭代多次逐步逼近最优值点。

(2)容错性：机器学习的算法设计和模型评价容忍非最优值点的存在，同时多次迭代的特性也允许在循环的过程中产生一些错误，模型的最终收敛不受影响。

(3)参数收敛的非均匀性：模型中一些参数经过少数几轮迭代后便不再改变，而有些参数则需要很长时间才能达到收敛。

这些特点决定了理想的大数据分析系统的设计和其他计算系统的设计有很大不同，直接应用传统的分布式计算系统应用于大数据分析，很大比例的资源都浪费在通信、等待、协调等非有效的计算上。

传统的分布式计算框架MPI(message passing interface，信息传递接口)虽然编程接口灵活功能强大，但由于编程接口复杂且对容错性支持不高，无法支撑在大规模数据上的复杂操作，研究人员转而开发了一系列接口简单容错性强的分布式计算框架服务于大数据分析算法，以MapReduce、Spark和参数服务器ParameterServer等为代表。

分布式计算框架MapReduce将对数据的处理归结为Map和Reduce两大类操作，从而简化了编程接口并且提高了系统的容错性。但是MapReduce受制于过于简化的数据操作抽象，而且不支持循环迭代，因而对复杂的机器学习算法支持较差，基于MapReduce的分布式机器学习库Mahout需要将迭代运算分解为多个连续的Map 和Reduce 操作，通过读写HDFS文�...

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

不知道大家有没有和象牙妹儿一样的感觉，便是最近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张，下面是两种票的权益对比：

1.前言

计算机的基本工作就是处理数据，包括磁盘文件中的数据，通过网络传输的数据流或数据包，数据库中的结构化数据等。随着互联网、物联网等技术得到越来越广泛的应用，数据规模不断增加，TB、PB量级成为常态，对数据的处理已无法由单台计算机完成，而只能由多台机器共同承担计算任务。而在分布式环境中进行大数据处理，除了与存储系统打交道外，还涉及计算任务的分工，计算负荷的分配，计算机之间的数据迁移等工作，并且要考虑计算机或网络发生故障时的数据安全，情况要复杂得多。

举一个简单的例子，假设我们要从销售记录中统计各种商品销售额。在单机环境中，我们只需把销售记录扫描一遍，对各商品的销售额进行累加即可。如果销售记录存放在关系数据库中，则更省事，执行一个SQL语句就可以了。现在假定销售记录实在太多，需要设计出由多台计算机来统计销售额的方案。为保证计算的正确、可靠、高效及方便，这个方案需要考虑下列问题：

如何为每台机器分配任务，是先按商品种类对销售记录分组，不同机器处理不同商品种类的销售记录，还是随机向各台机器分发一部分销售记录进行统计，最后把各台机器的统计结果按商品种类合并？上述两种方式都涉及数据的排序问题，应选择哪种排序算法？应该在哪台机器上执行排序过程？如何定义每台机器处理的数据从哪里来，处理结果到哪里去？数据是主动发送，还是接收方申请时才发送？如果是主动发送，接收方处理不过来怎么办？如果是申请时才发送，那发送方应该保存数据多久？会不会任务分配不均，有的机器很快就处理完了，有的机器一直忙着？甚至，闲着的机器需要等忙着的机器处理完后才能开始执行？如果增加一台机器，它能不能减轻其他机器的负荷，从而缩短任务执行时间？如果一台机器挂了，它没有完成的任务该交给谁？会不会遗漏统计或重复统计？统计过程中，机器之间如何协调，是否需要专门的一台机器指挥调度其他机器？如果这台机器挂了呢？（可选）如果销售记录在源源不断地增加，统计还没执行完新记录又来了，如何保证统计结果的准确性？能不能保证结果是实时更新的？再次统计时能不能避免大量重复计算？（可选）能不能让用户执行一句SQL就可以得到结果？

上述问题中，除了第1个外，其余的都与具体任务无关，在其他分布式计算的场合也会遇到，而且解决起来都相当棘手。即使第1个问题中的分组、统计，在很多数据处理场合也会涉及，只是具体方式不同。如果能把这些问题的解决方案封装到一个计算框架中，则可大大简化这类应用程序的开发。

2004年前后，Google先后发表三篇论文分别介绍分布式文件系统GFS、并行计算模型MapReduce、非关系数据存储系统BigTable，第一次提出了针对大数据分布式处理的可重用方案。在Google论文的启发下，Yahoo的工程师Doug Cutting和Mike Cafarella开发了Hadoop。在借鉴和改进Hadoop的基础上，又先后诞生了数十种应用于分布式环境的大数据计算框架。本文在参考业界惯例的基础上，对这些框架按下列标准分类：

如果不涉及上面提出的第8、9两个问题，则属于批处理框架。批处理框架重点关心数据处理的吞吐量，又可分为非迭代式和迭代式两类，迭代式包括DAG（有向无环图）、图计算等模型。若针对第8个问题提出来应对方案，则分两种情况：如果重点关心处理的实时性，则属于流计算框架；如果侧重于避免重复计算，则属于增量计算框架。如果重点关注的是第9个问题，则属于交互式分析框架。

本文下面分别讨论批处理、流计算、交互式分析三种类别的框架，然后简要介绍大数据计算框架的一些发展趋势。文章最后介绍这一领域的学习资料。

图1.大数据计算框架全景图2.批处理框架

2.1.Hadoop

Hadoop最初主要包含分布式文件系统HDFS和计算框架MapReduce两部分，是从Nutch中独立出来的项目。在2.0版本中，又把资源管理和任务调度功能从MapReduce中剥离形成YARN，使其他框架也可以像MapReduce那样运行在Hadoop之上。与之前的分布式计算框架相比，Hadoop隐藏了很多繁琐的细节，如容错、负载均衡等，更便于使用。

Hadoop也具有很强的横向扩展能力，可以很容易地把新计算机接入到集群中参与计算。在开源社区的支持下，Hadoop不断发展完善，并集成了众多优秀的产品如非关系数据库HBase、数据仓库Hive、数据处理工具Sqoop、机器学习算法库Mahout、一致性服务软件ZooKeeper、管理工具Ambari等，形成了相对完整的生态圈和分布式计算事实上的标准。

图2.Hadoop生态圈（删减版）

MapReduce可以理解为把一堆杂乱无章的数据按照某种特征归并起来，然后处理并得到最后的结果。基本处理步骤如下：

把输入文件按照一定的标准分片，每个分片对应一个map任务。一般情况下，MapReduce和HDFS运行在同一组计算机上，也就是说，每台计算机同时承担存储和计算任务，因此分片通常不涉及计算机之间的数据复制。按照一定的规则把分片中的内容解析成键值对。通常选择一种预定义的规则即可。

执行map任务，处理每个键值对，输出零个或多个键值对。

MapReduce获取应用程序定义的分组方式，并按分组对map任务输出的键值对排序。默认每个键名一组。

待所有节点都执行完上述步骤后，MapReduce启动Reduce任务。每个分组对应一个Reduce任务。

执行reduce任务的进程通过网络获取指定组的所有键值对。

把键名相同的值合并为列表。

执行reduce任务，处理每个键对应的列表，输出结果。

图3.MapReduce处理过程

在上面的步骤中，应用程序主要负责设计map和reduce任务，其他工作均由框架负责。在定义map任务输出数据的方式时，键的选择至关重要，除了影响结果的正确性外，也决定数据如何分组、排序、传输，以及执行reduce任务的计算机如何分工。前面提到的商品销售统计的例子，可选择商品种类为键。MapReduce执行商品销售统计的过程大致如下：

把销售记录分片，分配给多台机器。每条销售记录被解析成键值对，其中值为销售记录的内容，键可忽略。

执行map任务，每条销售记录被转换为新的键值对，其中键为商品种类，值为该条记录中商品的销售额。

MapReduce把map任务生成的数据按商品种类排序。

待所有节点都完成排序后，MapReduce启动reduce任务。每个商品种类对应一个reduce任务。

执行reduce任务的进程通过网络获取指定商品种类的各次销售额。

MapReduce把同一种商品下的各次销售额合并到列表中。

执行reduce任务，累加各次销售额，得到该种商品的总销售额。

上面的过程还有优化的空间。在传输各种商品每次的销售额数据前，可先在map端对各种商品的销售额进行小计，由此可大大减少网络传输的负荷。MapReduce通过一个可选的combine任务支持该类型的优化。

2.2.DAG模型

现在假设我们的目标更进一步，希望知道销售得最好的前10种商品。我们可以分两个环节来计算：

统计各种商品的销售额。通过MapReduce实现，这在前面已经讨论过。对商品种类按销售额排名。可以通过一个排序过程完成。假定商品种类非常多，需要通过多台计算机来加快计算速度的话，我们可以用另一个MapReduce过程来实现，其基本思路是把map和reduce分别当作小组赛和决赛，先计算各分片的前10名，汇总后再计算总排行榜的前10名。

从上面的例子可以看出，通过多个MapReduce的组合，可以表达复杂的计算问题。不过，组合过程需要人工设计，比较麻烦。另外，每个阶段都需要所有的计算机同步，影响了执行效率。

为克服上述问题，业界提出了DAG（有向无环图）计算模型，其核心思想是把任务在内部分解为若干存在先后顺序的子任务，由此可更灵活地表达各种复杂的依赖关系。Microsoft Dryad、Google FlumeJava、Apache Tez是最早出现的DAG模型。Dryad定义了串接、全连接、融合等若干简单的DAG模型，通过组合这些简单结构来描述复杂的任务，FlumeJava、Tez则通过组合若干MapReduce形成DAG任务。

图4.MapReduce（左）与Tez（右）执行复杂任务时对比

MapReduce的另一个不足之处是使用磁盘存储中间结果，严重影响了系统的性能，这在机器学习等需要迭代计算的场合更为明显。加州大学伯克利分校AMP实验室开发的Spark克服了上述问题。Spark对早期的DAG模型作了改进，提出了基于内存的分布式存储抽象模型RDD（Resilient Distributed Datasets，可恢复分布式数据集），把中间数据有选择地加载并驻留到内存中，减少磁盘IO开销。与Hadoop相比，Spark基于内存的运算要快100倍以上，基于磁盘的运算也要快10倍以上。

图5.MapReduce与Spark中间结果保存方式对比

Spark为RDD提供了丰富的操作方法，其中map、 filter、 flatMap、 sample、groupByKey、 reduceByKey、union、join、cogroup、mapValues、sort、partionBy用于执行数据转换，生成新的RDD，而count、collect、 reduce、lookup、save用于收集或输出计算结果。如前面统计商品销售额的例子，在Spark中只需要调用map和reduceByKey两个转换操作就可以实现，整个程序包括加载销售记录和保存统计结果在内也只需要寥寥几行代码，并且支持Java、Scala、Python、R等多种开发语言，比MapReduce编程要方便得多。下图说明reduceByKey的内部实现。

图6.RDD reduceByKey内部实现

RDD由于把数据存放在内存中而不是磁盘上，因此需要比Hadoop更多地考虑容错问题。分布式数据集的容错有两种方式：数据检查点和记录数据的更新。处理海量数据时，数据检查点操作成本很高，因此Spark默认选择记录更新的方式。不过如果更新粒度太细太多，记录更新成本也不低。因此，RDD只支持粗粒度转换，即只记录单个块上执行的单个操作，然后将创建RDD的一系列变换序列记录下来，类似于数据库中的日志。

当RDD的部分分区数据丢失时，Spark根据之前记录的演变过程重新运算，恢复丢失的数据分区。Spark生态圈的另一项目Alluxio（原名Tachyon）也采用类似的思路，使数据写入速度比HDFS有数量级的提升。

下面总结Spark对MapReduce的改进：

MapReduce抽象层次低，需要手工编写代码完成；Spark基于RDD抽象，使数据处理逻辑的代码非常简短。MapReduce只提供了map和reduce两个操作，表达力欠缺；Spark提供了很多转换和动作，很多关系数据库中常见的操作如JOIN、GROUP BY已经在RDD中实现。MapReduce中，只有map和reduce两个阶段，复杂的计算需要大量的组合，并且由开发者自己定义组合方式；Spark中，RDD可以连续执行多个转换操作，如果这些操作对应的RDD分区不变的话，还可以放在同一个任务中执行。MapReduce处理逻辑隐藏在代码中，不直观；Spark代码不包含操作细节，逻辑更清晰。MapReduce中间结果放在HDFS中；Spark中间结果放在内存中，内存放不下时才写入本地磁盘而不是HDFS，这显著提高了性能，特别是在迭代式数据处理的场合。MapReduce中，reduce任务需要等待所有map任务完成后才可以开始；在Spark中，分区相同的转换构成流水线放到同一个任务中运行。3.流计算框架

3.1.流计算概述

在大数据时代，数据通常都是持续不断动态产生的。在很多场合，数据需要在非常短的时间内得到处理，并且还要考虑容错、拥塞控制等问题，避免数据遗漏或重复计算。流计算框架则是针对这一类问题的解决方案。流计算框架一般采用DAG（有向无环图）模型。图中的节点分为两类：一类是数据的输入节点，负责与外界交互而向系统提供数据；另一类是数据的计算节点，负责完成某种处理功能如过滤、累加、合并等。从外部系统不断传入的实时数据则流经这些节点，把它们串接起来。如果把数据流比作水的话，输入节点好比是喷头，源源不断地出水，计算节点则相当于水管的转接口。如下图所示。

图7.流计算DAG模型示意图

为提高并发性，每一个计算节点对应的数据处理功能被分配到多个任务（相同或不同计算机上的线程）。在设计DAG时，需要考虑如何把待处理的数据分发到下游计算节点对应的各个任务，这在实时计算中称为分组（Grouping）。最简单的方案是为每个任务复制一份，不过这样效率很低，更好的方式是每个任务处理数据的不同部分。随机分组能达到负载均衡的效果，应优先考虑。不过在执行累加、数据关联等操作时，需要保证同一属性的数据被固定分发到对应的任务，这时应采用定向分组。在某些情况下，还需要自定义分组方案。

图8.流计算分组

由于应用场合的广泛性，目前市面上已经有不少流计算平台，包括Google MillWheel、Twitter Heron和Apache项目Storm、Samza、S4、Flink、Apex、Gearpump。

3.2.Storm及Trident

在流计算框架中，目前人气最高，应用最广泛的要数Storm。这是由于Storm具有简单的编程模型，且支持Java、Ruby、Python等多种开发语言。Storm也具有良好的性能，在多节点集群上每秒可以处理上百万条消息。Storm在容错方面也设计得很优雅。下面介绍Storm确保消息可靠性的思路。

在DAG模型中，确保消息可靠的难点在于，原始数据被当前的计算节点成功处理后，还不能被丢弃，因为它生成的数据仍然可能在后续的计算节点上处理失败，需要由该消�...

存储计算域能力构成

作者ID：分析世界讲方案

企业级大数据中心往往包括一个最为关键的能力域，这个域就是存储计算域。

众观历史：分久必合，合久必分。计算与存储这两大能力同样适用于此模式：例如：计算机组成原理中的五大部件，存储（硬盘）和计算（CPU）是整合在一个机箱内的。后来发展的NAS和SAN存储网络，使得两者分离以提高I/O访问。再后来随着企业业务飞速发展，磁盘寻址却没有明显改善，所以分布式架构又将计算与存储整合在一起（如Hadoop就近计算）。再发展到今天，基于容器技术和云化架构，存储和计算似乎仍然可以分离而提高效率……所以这个命题确实很大。

我们知道，作为一个标准的大数据分析系统，虽然目标是产生业务价值，但中间过程其实是数据分析和关联计算，所以存储计算域是大数据分析的第二步（第一步是数据获取），我们可以根据时间发展阶段论述这个域的能力变化，并将每个时间点的关键词贯穿在整个时间轴上，更近生动和易懂。八组词：海量数据存的下、数据容量可提升、系统规模高扩展、集成数据强整合、任务处理速实效、磁盘I/O高吞吐、多温数据自适配、混合负载能支撑。

海量信息存的下：大数据炒作时期（2006-2009）。大数据/移动互联网时代数据井喷，IT系统应该具备海量数据存储和归档，从而提供服务并为后续业务带来价值，所以这个时期主要考虑数据存储和扩容问题。继而出现了文件存储、分布式存储、GFS/HDFS等相应的能力域。

数据容量可提升：伴随着业务高速发展（2009-2010），平台数据容量不断增加，什么样的系统能支撑多结构化数据的高速膨胀？这就要求系统容量更够通过增加存储单元而得到提升，这体现了分布式系统的灵活性和数据扩展性，而且扩容成本还必须很低廉。

系统规模高扩展：大数据发展时期（2010-2012），系统规模逐年增加的同时系统负载也随之增大，所以单一集群难以支撑高强度任务负载，这就要对系统进行高效稳定的扩展。当然，系统规模扩展和管理是大数据系统的难点问题，因为集群规模和集群一旦膨胀，就会将系统问题无形的转化为网络问题，对人员水平也是一大挑战。

集成数据强整合：实现系统规模的扩展性（2012-今），能够结合主题域/业务功能，实现大数据的跨功能洞察，包括跨多个主题域的集成决策能力，因此统一平台建设有益于数据分析。这个时期，数据孤岛严重。所以我们看到很多客户都在构建全网统一的大数据平台，整合企业内部各系统的分散数据源。换言之，大数据平台应具备数据的整合能力和技术支撑。

任务处理速实效：业务的快速洞察时期（2013-今），需要引入实时技术以支撑实时分析，例如：实时类业务（实时营销、实时推荐、实时告警、实时展现）。这就考验平台是否具备实时计算、流计算的能力，从而满足高时效业务需求。

磁盘I/O高吞吐：系统优化提上日程（2014-今），大数据发展逐渐健壮的同时，高并发查询和苛刻的分析环境对磁盘I/O及提出了极大挑战，因为这将决定大并发处理效率。所以为了不使数据通道成为瓶颈，大数据系统必须尽可能保持高吞吐服务能力，尤其是面向于数据分析的业务非常吃I/O，这个时期不乏有光网、InfiniBand交换系统的出现。

多温数据自适配：寻求进一步降低TCO（2015-今），数据系统中频繁访问并使用的热数据、以及不常访问的冷数据并存在系统中充占着资源，而且所占磁盘类型大多相同（SATA/SAS/固态），这并不适用于磁盘资源的合理使用，同时也浪费了宝贵的存储成本。因此应该根据业务规则辨别数据访问和更新频率，从而判别这些数据应该如何使用磁盘资源，从而实现资源自服务、自管理。

混合负载能支撑：大数据平台监控和负载管理是一项长期工作，很多商用产品都是通过这个能力提高自身产品的门槛和竞争力（分布式系统的监控管理一直都是复杂问题），因此这个能力一方面是考量系统能同时支撑多少并发应用，并根据并发应用的实际负载，考虑SLA的动态管理。（例如：数据加载和并发查询负载、数据更新和导出负载等）

上述八组能力，仅仅只是大数据存储计算域的“九牛一毛”，粗略简谈并非成体系，更多分享交流随时留言啦。

作者ID：分析世界讲方案

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的支持。

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

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

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还是起到一个借鉴的作用。

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