架构大数据_系统构架 功能架构 技术架构 逻辑架构 物理架构 数据架构 - CSDN
  • 架构大数据分析应用

    2016-05-18 21:23:55
    这是《Scalable Big Data Architecture》一书的翻译笔记和读书札记,融入自己的部分观点 ….典型使用场景....大数据生态系统.....

    这是《Scalable Big Data Architecture》一书的翻译笔记和读书札记,使用了原书中的大量图片,融入了自己的部分观点 ….典型使用场景….大数据生态系统……..

    数据管理比以往更加复杂,到处都是大数据,包括每个人的想法以及不同的形式:广告 , 社交图谱,信息流 ,推荐 ,市场, 健康, 安全, 政府等等.过去的三年里,成千上万的技术必须处理汇合在一起的大数据获取,管理 和分析; 技术选型对IT部门来说是一件艰巨的任务,因为在大多数时间里没有一个综合的方法来用于选型.

    当自己面临选择的时候,通常会问如下的问题: 什么时候需要考虑在IT系统中使用大数据? 准备好使用了么? 从哪里开始? 感觉大数据只是一种市场趋势,我还是应该去做么?这些问题萦绕着CIO和CTO们,当决定部署一个全局化分布式大数据架构时,可能会把企业置于危险之中。

    本章目的时定义大数据的表征—换句话说,就是什么时候需要考虑将大数据放入架构。 但是,也指出了各种大数据技术的区别,能够理解在何种情况使用哪种技术。

    最后, 基于真实世界的例子,构建了典型分布式大数据架构的基础模型。

    定义大数据表征

    基于不同的需要,可能选择开始大数据项目s: 因为所需处理的数据容量, 因为系统中数据结构的多样性, 因为扩展性问题, 或者因为需要削减数据处理的成本。 本节中,将看到怎样的征兆意味着一个团队需要开始一个大数据项目了。

    数据大小哪些事

    使人们开始考虑大数据的两个主要领域是何时出现了与数据大小和容量有关的问题。尽管大多数时间这些问题是考虑大数据的合情合理的原因,但今天而已,这并不是唯一的原因。

    有其他的表征—例如数据的类型. 如何在传统数据存储中管理不断增加的各种各样的数据类型, 如SQL数据库, 还期望象建表那样的结构化么? 不增加灵活性是不可行的,当出现新的数据结构是需要技术层面的无缝处理。当讨论数据类型是,需要想象非结构化数据,图数据,图片,视频,语音等等。

    不但要很好的存储非结构化数据,而且最好是得到一些他们之外的东西。另一表征来自于这一承诺: 大数据也可以从大容量的各种数据中提取增值信息.若干年前,对于大量读多于写的操作,通用的缓存或数据库队友每周的ETL (extract, transform,load) 处理是足够的。如今不再是这样的趋势。现在,需要一个架构具备长时间处理和准实时数据处理的能力。这一架构是分布式的,而不是依赖于高性能且价格高昂的商用机,取而代之的是,高可用,性能驱动和廉价技术所赋予的灵活性。

    当下,如何充分利用增值数据以及如何能够原生地搜索到它们呢?为了回答这一问题,再次考虑传统存储中为了加速查询而创建的索引。如果为了复杂查询而索引上百列而且包含了主键的不确定性,会是什么样子?不希望在一个基础SQL 数据库中做这些;取而代之的是,需要考虑按照特殊需要而使用一个 NoSQL存储. 所以,简单回顾一下主要路径:数据获取,结构化,可视化这些真正数据管理的场景,显而易见,数据大小不再是主要的考量因素。

    典型的商务使用场景

    除了技术和架构考虑,需要面对典型大数据用例的使用场景。它们部分和特殊的工业领域相关; 另外的部分可能适应于各种领域。这些考虑一般都是基于分析应用的日志,例如web访问日志,应用服务器日志,和数据库日志,但是也可以基于各种其他的数据源例如社交网络数据。当面对这些使用场景的时候,如果希望随着商务的增长而弹性扩展,就需要考虑一个分布式的大数据架构。

    客户行为分析

    感知客户, 或者叫做 “360-度客户视角”可能是最流行的大数据使用场景。客户视角通常用于电子商务网站以及开始于一个非结构化的点击流—换而言之, 由一个访客执行的主动点击和被动的网站导航操作组成。通过计算和分析点击量和面向产品或广告的印象,可以依赖行为而适配访客的用户体验, 目标是得到优化漏斗转换的见解。

    情绪分析

    公司关注的是其在社交网络上所被感知的形象和声誉; 把可能使他们声名狼藉的负面事件最小化并充分利用正面事件. 通过准实时爬下大量的社交数据,可以提取出社交社区中关于品牌的感受和情绪,从而找到影响用户并练习他们,改变并强化与这些用户的交互。

    CRM Onboarding

    基于访客的社交行为,可以将客户的行为分析和数据的情感分析结合在一起。公司希望将这些在线数据源和已经存在的离线数据结合在一起,这叫做 CRM (customer relationship management) onboarding, 以便于得到更好和更准确的客户定位. 进而,公司能够充分利用这一定位,从而建立更好的目标系统使市场活动的效益最大化。

    预测

    从数据中学习在过去几年已经成为主要的大数据趋势。基于大数据的预测在许多业界是非常有效的, 例如电信界, 这里可以预测大众化的路由日志分析. 每一次在设备上发生了问题, 公司可以预测它并避免宕机时间或利润丢失。

    当结合以上的使用场景的时候,根据用户的整体行为,可以使用一个预测型架构来诱惑产品目录的选择和价格。

    理解大数据技术生态系统

    一旦确实要实施一个大数据项目, 最困难的事是架构中的技术选型。这不仅是选择最著名的Hadoop相关技术,而且需要理解如何给它们分类才能构建一个一致性的分布式架构。为了得到大数据星云中的项目数量,可以参见 https://github.com/zenkay/bigdata-ecosystem#projects-1 ,这里有100多个工程项目。这里,你可以考虑选择一个Hadoop的发布版,一个分布式文件系统 ,一个类SQL处理语音, 一个机器学习语言, 调度器,面向消息的中间件, NoSQL数据存储,数据可视化等等。

    既然本书的目的是描述构建一个分布式架构的可扩展方法,所以不深入到所有的项目中;取而代之,重点在典型大数据工程中最可能使用的东西。显然,架构的选择和项目的集成依赖于具体的需要,你可以看到在特定的领域可以使用这些项目的具体实例。为了使Hadoop 技术表现的更有相关性,这一分布式架构将适用于前面描述的典型场景,命名如下:

    • 客户行为分析
    • 情绪分析
    • CRM onboarding 和预测

    Hadoop 发布版

    在涵盖了Hadoop 生态系统的大数据项目中,有两个选择:

    • 在一个连贯,弹性和一致的架构中分别下载相关项目,然后尝试创建或组装它们
    • 使用一个广泛流行的 Hadoop分发版, 已经装配或创建好了这些技术.

    尽管选项一完全可行,你还是可能选择方案二,因为一个Hadoop 发型包保证了所有安装组件的兼容性,安装,配置部署,监控和支持都非常简单。

    Hortonworks 和Cloudera 是这样领域的主角。尽管它们之间有些区别,但是从大数据包的角度上看,它们是一样的,你不需要那些专属的插件。我们的目标不是描述每个发布版的所有组件,二是聚焦在每个提供者在标准生态系统中所增加的部分。同时,描述了在每种情况下,该架构所依赖的其他组件。

    Cloudera CDH

    Cloudier在Hadoop基础组件上增加了一个内部机构组件的集合; 这些组件被设计成给你更好的集群管理和搜素体验。部分组件列表如下:

    • Impala: 一个实时,并行化,基于SQL的引擎来搜索 HDFS
      (Hadoop Distributed File System)和 HBase中的数据. Impala被认为是Hadoop 发布版提供商市场中最快的查询引擎,是UC Bekeley Spark 的直接竞争者。

    • Cloudera Manager: 这是Cloudier的控制台,用来管理和部署Hadoop集群内的Hadoop组件.

    • Hue: 一个用于执行用户交互数据操作和执行脚本的控制台,可以操作集群内不同的Hadoop组件.

    Figure 1-1 解释了Cloudera’s Hadoop分发包有如下组件分类:

    • 橙色部分是Hadoop核心栈.

    • 粉色部分是 Hadoop 生态系统项目

    • 蓝色部分是 Cloudera的特使组件.

    F1-1 CDH

    Figure 1-1. Cloudera Hadoop发布版

    Hortonworks HDP

    Hortonworks 是一个百分之百的开源而且使用了稳定的组件包,而不是1Hadoop 项目中最新的分发版本。它增加了一个组件管理控制台来与Cloudera Manager对比。Figure 1-2 展示了Hortonworks 发布版与Figure 1-1 相应的分类:绿色部分是Hortonworks的特殊组件.

    F1-2 HDP

    Figure 1-2. Hortonworks Hadoop distribution

    如前所述,当我们构建架构的时候,这两个发布版(Hortonworks 和Cloudera) 是一样的。尽管如此, 如果考虑到每个发布版的成熟度,应当选择; Cloudera Manager比Ambari更完整和稳定 .进一步,考虑实时与大数据集交互,更应该因为它的性能卓越而使用Cloudera.

    Hadoop Distributed File System (HDFS)

    你可能疑虑摄取到Hadoop集群中的数据存储到哪里。一般都在一个专有的系统上,叫做HDFS。HDFS的核心特性:

    • 分布式
    • 高吞吐量访问
    • 高可用
    • 容错
    • 参数调整
    • 安全
    • 负载均衡

    HDFS 是Hadoop集群中数据存储的头等公民。数据在集群数据节点中自动复制。
    Figure 1-3 展示了HDFS中的数据如何在 一个集群的五个节点中复制的。

    F1-3 HDFS 文件复制

    Figure 1-3. HDFS data replication

    可以从 hadoop.apache.org获得更多的有关HDFS的信息。

    Data Acquisition

    数据的获取或者摄取开始于不同的数据源,可能是大的日志文件,流数据, ETL处理过的输出,在线的非结构化数据,或者离线的结构化数据。

    Apache Flume

    当查看生成的摄取日志的时候,强烈推荐使用Apache Flume; 它是稳定且高可用的,提供了一个简单,灵活和基友流数据的可感知编程模型。基本上,仅通过配置管理不需要写一行代码就可以陪着一个数据流水线。

    Flume 由sources, channels, 和sinks组成. Flume source 基本上从一个外部数据源来消费一个事件如 Apache Avro source,然后存到channel. channel是一个像文件系统那样的被动存储系统 ; 它在sink 消费事件前一直持有它. sink 消费事件,然后从channel中删除该事件,并分发给一个外部的目标。

    Figure 1-4 描述了一个web server和HDFS间的日志流如 Apache,使用了Flume 流水线.

    F1-4 Flume

    Figure 1-4. Flume architecture

    通过 Flume, 可以将web服务器产生的不同日志文件移动到HDFS. 牢记我们工作在一个分布式的架构,可能包含有负载均衡器,HTTP servers,应用服务器,访问日志等等 . 我们是一不同的方式充分利用这些资源,使之能够被Flume流水线处理 . 详情参见 flume.apache.org.

    Apache Sqoop

    Swoop是一个从结构化数据库传说大量数据到HDFS. 使用它,既可以从一个外部的关系型数据库将数据导入到HDFS, Hive, 或者 HBase, 也可以Hadoop 集群导出到一个关系型数据库或者数据仓库.

    Sqoop 支持主流的关系型数据库例如Oracle, MySQL, 和Postgres. 这个项目把你从写脚本传输数据中解脱出来;它提供了高性能数据传输的特性.因为关系型数据库中的数据增长迅速, 最好从开始就定义那些快速增长的表,然后使用Sqoop将数据周期性地传输到Hadoop,以便用于分析.

    然后,结合Hadoop与其他数据,可以使用Sqoop 导出数据注入到BI 分析工具中. 详情参见 sqoop.apache.org.

    处理语言

    一旦数据到了HDFS,可以使用不同的处理语言从原始数据得到最好的结果.

    Yarn: NextGen MapReduce

    MapReduce 是第一代Hadoop集群中的主要处理框架; 它基本上将滑动数据分组(Map) 在一起,然后依赖特殊的聚合操作(Reduce)来聚会数据。在Hadoop 1.0中, 用户们可以使用不同的语言来写 MapReduce jobs—Java, Python,
    Pig, Hive等等. 无论用户选择了什么语言, 都依赖于相同的处理模型:MapReduce.

    随着Hadoop 2.0的发布, 有了HDFS之上新的数据处理架构. 现在已经实现了YARN (Yet Another Resource Negotiator), MapReduce 已经成为了众多处理模型中的一个. 这意味着可以依赖特殊的使用场景来采用特殊的处理模型.
    Figure 1-5 展示了HDFS, YARN, 和处理模型是如何组织的.

    F1-5 YARN

    Figure 1-5. YARN structure

    我们无法审视所有的语言和处理模型; 专注于 Hive 和Spark, 它们覆盖了我们所用的用例,长时间数据处理和流处理。

    使用Hive的批处理

    当决定写第一个批处理job的时候, 使用所喜欢语言实现它,例如Java或 Python,但如果真的要做,最好舒服地使用mapping 和reducing 设计模式, 但这需要开发的时间和复杂的编码,有时候很难去维护。

    作为一个替代方式, 可以使用例如Hive这样的高级语言, 以类SQL方式简单而又强大地从HDFS中查询数据. 在用Java写了10行代码的MapReduce地方,在Hive中, 只需要一条 SQL 查询语句.

    当使用其他语言而不是原生MapReduce, 其主要的缺陷是性能.在 Hive 和 MapReduce之间有着天然的时延; 另外, SQL查询也与关系型数据库中的查询截然不同。详情参见 hive.apache.org.

    Hive 不是一个实时或准实时的处理语言,被用作批处理,例如一个低优先级的长时间处理任务. 处理流式数据,需要使用Spark Streaming.

    使用Spark Streaming的流处理

    Spark Streaming 可以通过Java, Scale, 或者Python来写批处理任务, 但是可以处理流数据. 这非常适合处理高吞吐量的数据源T例如社交网络(Twitter), 点击流日志, 或者 web 访问日志.

    Spark Streaming 是Spark的一个扩展, 它充分利用了分布式数据处理架构,把流式计算作为 一系列不确定的小时间间隔的微型批处理计算。详情参见 spark.apache.org.

    Spark Streaming 可以从各种源获得数据,通过与如Apache Kafka这样工具的结合, Spark Streaming 成为强容错和高性能系统的基础。

    面向消息的中间件Apache Kafka

    Apache Kafka 是一个由Linkedin开发的订阅-发布消息的分布式应用。Kafka经常与 Apache ActiveMQ 或者RabbitMQ对比, 但根本不同是Kafka 没有实现JMS (Java Message Service). 然而, Kafka是一个持久化消息的高吞吐量系统 , 支持队列和话题语意, 使用 ZooKeeper形成集群节点。
    Kafka 实现了订阅-发布的企业级集成,支持并行化,以及性能和容错的企业级特性。
    Figure 1-6 给出了订阅-发布架构的高层视角,消息在broker传输,服务于分区的话题。

    F1-6 Kafka

    Figure 1-6. Kafka partitioned topic example

    使用 Kafka在我们架构中的引导点 ,主要用于接受数据并推送到Spark
    Streaming. 详情参见 kafka.apache.org.

    机器学习

    当我们以无限收敛模型处理小数据采样时,在架构中讨论机器学习还为时尚早。我们是充分利用现有的分层或特殊语言来使用机器学习,例如
    Spark中的 Spark MLlib。

    Spark MLlib

    MLlib是Spark上的机器学习库, 充分利用了 Spark Direct Acyclic Graph (DAG) 执行引擎, 所提供的API 集合方便地集成到Spark中. 它由各种的算法组成 :基本统计, 逻辑回归, k-means 聚类, 从混合高斯到奇异值分解以及多维朴素贝叶斯。

    通过 Spark MLlib 这些开箱即用算法,可以用几行代码就能过简单地训练数据并构建预测模型a 详情参见 spark.apache.org/mllib.

    NoSQL 存储

    NoSQL 存储是数据架构的基础组件,因为它们可以摄取大量数据,提供弹性伸缩,高可用性以及开箱即用。Couchbase 和 ElasticSearch是两种我们聚焦的技术,先做简单讨论,稍后使用它们。

    Couchbase

    Couchbase是一个面向文档的NoSQL数据库,提供了一个灵活的模型轻松缩放,以及一致性的高性能。使用 Couchbase作为文档数据存储,基本上重定向从前端来的所有查询 到 Couchbase 防止了关系型数据库的高吞吐量读操作。详情参见 couchbase.com.

    ElasticSearch

    ElasticSearch 是一种非常流行的 NoSQL 技术,拥有可伸缩分布式索引引擎和搜索特性,相当于一般架构中Apache Lucene 加上实时数据分析和全文搜索.
    ElasticSearch是ELK平台的一部分( ElasticSearch + Logstash + Kibana,),是由Elastic公司发布的。三个产品结合在一起提供了数据采集,存储和可视化最好的端到端平台:

    • Logstash 从各种数据源采集数据,例如社交数据,日志,消息队列,或者传感器,支持数据的丰富性和转换,然后传输到一个索引系统例如ElasticSearch.

    • ElasticSearch 在一个弹性伸缩的分布式系统中索引数据,无缝提供了多语言库,很容易在应用中实现实时搜索和分析。

    • Kibana 是一个定制化的用户界面,可以构建从简单到复杂的仪表盘,来探索和可视化ElasticSearch 索引的数据。

    Figure 1-7 展示了Elastic产品的结构.

    F1-7 LEK

    Figure 1-7. ElasticSearch products

    如前图所示, Elastic 也提供了商用产品例如Marvel,基于Kibana的一个监控控制台; Shield, 一个安全框架, 例如提供授权和认证; Watcher, 一个告警和通知系统. 但本书中不使用这些商用产品。我们主要使用ElasticSearch作为搜索引擎来持有Spark产生的产品。在处理和聚合之后,数据在ElasticSearch中被索引,使第三方系统通过ElasticSearch引擎查询数据。另一方面,我们也使用 ELK来处理日志和虚拟化分析,而不只是平台操作视角。详情参见 elastic.co.

    创建有长远规划的大数据架构

    记住所有这些大数据技术,现在来构建我们的架构。

    架构概览

    从高层视角来看, 我们的架构看起来象另一个电子商务应用架构,需要如下:
    + 一个web应用,访客可以用它导航一个产品目录
    + 一个日志摄取应用:拉取日志并处理它们
    + 一个机器学习应用:为访客触发推荐
    + 一个处理引擎:作为该架构的中央处理集群
    + 一个搜索引擎:拉取处理数据的分析

    Figure 1-8 展示了这些不同应用如何在该架构组织起来的。

    F1-8 架构概览

    Figure 1-8. Architecture overview

    日志摄取

    日志摄取应用被用作消费应用日志例如web 访问日志. 为了简化使用场景,提供一个web访问日志,模拟访客浏览产品目录,这些日志代表了点击流日志,既用作长时处理也用作实时推荐。架构有两个选项:第一个是以Flume来传输日志;第二个是以LEK 来创建访问分析。

    Figure 1-9 展示了ELK 和Flume是如何处理日志的.

    F1-9 数据摄取

    Figure 1-9. Ingestion application

    我们在架构中使用ELK ,因为LEK的三个产品无缝集成,能够比使用Flume给我们更多的价值 。

    机器学习

    机器学习应用接收数据流,构建推荐引擎。这一应用使用一个基本的算法来基于Spark MLlib 介绍 机器学习的概念。

    Figure 1-10 展示了该机器学习应用如何使用Kafka 接收数据,然后发送给Spark 处理,最后在ElasticSearch 建立索引为将来使用做准备。

    F1-10

    Figure 1-10. Machine learning

    处理引擎

    处理引擎是该架构的心脏; 它接收各种源的数据,代理合适模型的处理。
    Figure 1-11 展示了由Hive组成的处理引擎如何接收数据,以及Spark的实时/准实时处理。

    F1-11 处理引擎

    Figure 1-11. Processing engine

    这里使用Kafka 与 Logstash结合把数据分发给ElasticSearch. Spark位于 Hadoop 集群的顶端, 但不说必须的。为了简化起见,本书不建立 Hadoop集群,而是以standalone模式运行Spark。显然,应用同样可以部署在所选择的Hadoop 发布版上。

    搜索引擎

    搜索引擎充分利用处理引擎所处理的数据,同时暴露出专有的RESTful API以便于分析使用。

    展开全文
  • 自从像AWS这样的公共云产品开辟了大数据分析功能以来,小企业通过挖掘大量的数据做到只有大企业才能做到的事情,至今大约有10年时间。这些事情其中包括网络日志、客户购买记录等,并... 以下将介绍用于大数据堆栈的...

     自从像AWS这样的公共云产品开辟了大数据分析功能以来,小企业通过挖掘大量的数据做到只有大企业才能做到的事情,至今大约有10年时间。这些事情其中包括网络日志、客户购买记录等,并通过按使需付费的方式提供低成本的商品集群。在这十年中,这些产品蓬勃发展,涵盖了从实时(亚秒级延迟)流媒体式分析到用于分析批量模式工作的企业数据仓库,而企业数据仓库则可能需要数天或数周才能完成。

    \
      以下将介绍用于大数据堆栈的五个最有用的架构,以及每个架构的优点,以便更好地理解和权衡。此外,还对成本(按$ - $$$$$的规模)、何时使用、热门产品,以及每种架构的提示和技巧进行了阐述。

      五个大数据架构

      在此并没有什么特别的顺序,用户在AWS公共云旅程中可能遇到的五个顶级大数据架构是:

      流媒体- 允许摄取(并可能分析)任务关键型实时数据,这些数据可能会以爆发的形式出现在用户面前。

      通用(或特定)的批处理集群—在可扩展、经济高效的集群中提供通用存储和计算功能,可以执行其他四种架构的任何和所有功能。

      NoSQL引擎 - 使架构师能够处理“3V” —高速度、高容量,以及底层数据的多样性/可变性。

      企业数据仓库(EDW) - 允许组织为多年的历史数据维护一个单独的数据库,并对该数据运行各种长期运行的分析。

      就地分析 - 允许用户将数据“就地”保存在低成本存储引擎中,并针对该数据运行高性能的即席查询,而无需创建单独的、昂贵的“集群”。

      1. 流媒体

      流媒体解决方案由以下多个因素定义:

      关键任务数据—即使丢失一笔交易也会给用户带来灾难性的后果。

      负载中的爆发尖峰——物联网的基础设施可能会从完全无声的状态转变为同时与其通话设备中的一个。

      实时响应 - 高延迟响应对用户来说可能是灾难性的。

      这里有很多现实世界的例子,从特斯拉公司的电动汽车(基本上是移动的4G设备)不断将汽车的位置发送到数据中心,通知司机下一个充电站在哪里。此外,人们喜欢的日本一家高度自动化的寿司专营店:Sushiro。Sushiro所做的是将RFID传感器放在每个寿司盘底,然后,寿司传送带上的传感器跟踪每个盘子的动态,将数据点发送到AWS Kinesis,其后端响应仪表板的更新,通知寿司厨师,例如“丢掉即将过期变质的食物,或者制作更多的鸡蛋寿司,或者解冻更多的金枪鱼”,通过使用流媒体技术,该连锁店不仅有上述的实时效率推荐,而且还可以获得每家餐厅的历史信息,并且可以了解顾客购买的趋势。

      Sushiro是一个很好的例子,因为它符合流媒体的所有三个要求。其仪表板现在对业务运营至关重要。

      成本:$$ - $$$$$(通常为RAM密集型)

      适用性:任务关键型数据,负载爆发尖峰,实时响应。用户需要构建KPI的实时仪表板。

      注意事项:独立的流媒体解决方案的构建和维护成本很高。扩展可能具有挑战性,特别是如果在EC2上构建。失败对企业来说可能是灾难性的,但大多数产品都提供故障保护,例如复制优化、备份和灾难恢复,以避免这种情况。

      受欢迎的产品:Kinesis(托管服务),Kafka(基于EC2),Spark Streaming(作为托管服务和基于EC2)和Storm。

      提示和技巧:使用Kinesis作为初学者(易于使用、体积小、成本低)。许多组织转向基于EC2的Kafka(如果他们只需要流媒体)或Spark Streaming,以获得更好的控制,并降低大批量成本。这是AWS中为数不多的几次托管任务,像Kinesis这样的托管服务最终会比基于EC2的Kafka解决方案花费更多的费用。

      2. 通用(或特定)的批处理集群

      使用Hadoop/Spark这些系统,用户可以获得高度可扩展、低成本(商用硬件和开源软件)存储和计算,这些存储和计算可能会遇到大量问题,从而以尽可能低的成本对数据进行批量分析。

      Hadoop技术非常成熟,提供了一个非常丰富的软件生态系统,可以利用这些通用计算和存储资源提供从数据仓库到流媒体,甚至NoSQL的所有内容。

      在Hadoop之上,现在可以运行Spark,它带有自己的可扩展框架,以低延迟(高内存)方式提供上述所有功能,甚至适用于流媒体和NoSQL。

      成本:$ - $$$$(高度依赖于内存需求)

      适用性:最低成本、最大灵活性。如果希望采用一个集群完成所有任务,并从Hadoop或Spark内部部署转移,那么这是一个不错的选择,非常适合机器学习。

      注意事项:一个全能的系统很少把每件事都做好,但这可以通过使用Spark和为每个工作量身定制的集群来大大减轻工作负荷。

      热门产品:EMR(托管服务,也将运行Spark),Cloudera(基于EC2),Hortonworks(通过EMR作为托管服务,基于EC2)。

      提示和技巧:在S3存储桶中长期存储源数据,构建集群,并根据需要将数据加载到集群中,然后在分析任务完成后立即关闭所有数据。这实际上正是默认情况下EMR的工作原理,但即使使用的是Cloudera或Hortonworks(现在功能几乎相同),也可以轻松编写上述所有内容。利用EC2现场实例可以节省80%-90%的成本,并检查自己的分析,以便可以向上或向下旋转集群。以利用成本最低的spot窗口。

      3. NoSQL引擎

      Velocity(并发事务)在这里特别重要,这些引擎被设计为处理任意数量的并发读写。虽然其他系统通常不能用于最终用户(需要低延迟响应)和员工分析团队(可能会使用长时间运行的查询锁定多个表),同时,NoSQL引擎可以扩展以适应一个系统的两个主服务器。一些开发允许以低延迟方式实时加入和查询该数据。

      成本:$$ - $$$(通常为内存密集型)

      适用性:“3V”问题。简单和/或快速变化的数据模型。需要构建KPI的实时仪表板。

      警告:必须放弃交易和丰富多样的SQL。由于它不使用SQL,因此无法使用Tableau和Microstrategy等可视化工具直接查询数据。扩展(尤其是添加新节点和重新平衡)可能很困难,并且会影响用户延迟和系统可用性。

      受欢迎的产品:DynamoDB(托管服务),Neptune(托管服务,目前仍处于测试阶段),Cassandra(基于EC2),CouchDB(基于EC2)和HBase(通过EMR作为托管服务,基于EC2)。

      提示和技巧:努力采用AWS管理的服务DynamoDB,而不是配置EC2并加载第三方系统。定期修剪最终用户DynamoDB表,并在这些历史表上创建每周或每月的表。使用Dynamic DynamoDB“自动调整”配置的容量,使其始终满足消耗。使用DynamoDB Streams可以对客户服务取消等关键事件进行实时响应,或者在第二个区域提供备份。

      4. 企业数据仓库(EDW)

      企业数据仓库(EDW)与此处提到的其他系统截然不同。它提供了人们称之为“OLAP”(在线分析处理,可以支持来自内部用户的一些长时间运行的查询)与“OLTP”(在线事务处理,可以支持来自最终用户的大量读取和写入)功能,如Oracle的RDBMS或MySQL。当然,可以使用OLTP系统作为企业数据仓库(EDW),但是大多数人都将OLTP数据库集中在最近用户的低延迟,最近事件(如“跟踪上周的订单”)需求和定期(通常是每天)窗口更旧数据输出到OLAP系统,业务用户可以在数月或数年的数据中运行长时间的查询。

      这些OLAP系统使用诸如列式存储、数据非规范化(创建具有几乎无限维度的“数据立方体”)等策略,并提供RDBMS级ANSI 92 SQL依从性,这意味着可以完全访问SQL功能,并且可以定制Tableau等可视化工具直接与他们合作。

      成本:$$ - $$$$$(通常需要大量节点来存储和处理大量数据)。

      适用性:如果希望专门针对业务价值分析数据或构建KPI的实时仪表板。

      警告:确保团队了解OLAP和OLTP之间的区别,并确保他们以正确的方式使用每个OLAP和OLTP。

      提示和技巧:与EMR/Hadoop一样,只在需要时启动集群,将源数据保存在S3存储桶中(这实际上是Redshift默认工作的方式)。标记集群,以便用能够以自动方式快速识别和关闭未使用的容量。考虑保留以控制成本。真正了解可用的不同节点类型(高存储、高吞吐量)以便利用每个节点类型。采用本机加密,因为它可以将性能降低多达20%-25%。通过O'Reilly课程深入了解Redshift,或考虑通过出色的“数据仓库”课程进行面对面培训,该课程几乎完全涵盖Redshift。

      5. 就地分析

      几年前,Presto通过提供高性能的数据分析改变了游戏规则,而无需将数据从原生的、低成本的长期存储中移出。其最终结果是,可以简单地运行查询,而不是必须为昂贵的EMR或Redshift集群支付全部费用。而是只按使用的内容收费。

      此外,人们需要很多时间来尝试选择(然后管理)EMR或Redshift集群的正确节点和节点数。采用Presto,人们不再知道也不关心这种差别,而这一切都在用户需要的时候起到作用。

      最后,Presto支持RDBMS级别的ANSI-92 SQL兼容性,这意味着所有可视化工具都可以直接使用它,具有的SQL背景可以在ad-hoc查询中全面使用。

      费用:$ - $$

      适用性:成本极低。没有任何管理。可以作为低成本、中等性能的企业数据仓库(EDW)。它不需要将数据复制到第二个系统。大型连接和复杂分析效果很好。

      警告:需要最低延迟。为了获得不错的性能,可能会使用序列化格式Parquet、压缩、重新分区等重新格式化存储的数据。可能需要多轮查询调整和/或重新格式化才能获得正确的结果。目前不支持UDF或事务。

      热门产品:AWS Athena(用于查询S3数据的托管服务),EMR(托管服务-可以自动安装Presto),自我管理的Presto(基于EC2–用户永远不想在AWS中执行此操作)。

      提示和技巧:只需使用Athena。利用AWS Glue构建ETL管道,以获取原始数据,并将其重新格式化为S3或Athena可以更有效地使用的内容。使用S3生命周期策略将原有的数据移动到低成本的归档存储(如Glacier)。

      把它们放在一起

      通过了解将在公共云中运行的五个顶级大数据架构,用户现在可以获得有关最佳应用位置的可操作信息,以及潜伏的位置。

      一旦用户开始在AWS公共云中构建大数据架构,将很快了解到更多的架构,并且在很多情况下,企业可能会最终同时使用上述所有内容,可能使用Kinesis将客户数据流媒体传输到DynamoDB和S3。用户可能偶尔会在该源数据上启动EMR(进行某些机器学习)或Redshift(分析KPI)集群,或者可以选择以可以通过AWS Athena就地访问的方式格式化数据,让它像企业数据仓库(EDW)一样发挥作用。

      具有执行TMTOWTDI的能力是一件好事,AWS公司努力提供最适合用户需求的服务。如果用户从头开始,在AWS认证的全球知识培训课程中花费三天时间将可以提供满足其需求的服务,并让用户尽快开始运营,并且顺利实施。

    展开全文
  • 五种大数据处理架构

    2017-12-14 14:12:21
    大数据是收集、整理、处理大容量数据集,并从中获得见解所需的非传统战略和技术的总称。虽然处理数据所需的计算能力或存储容量早已超过一台计算机的上限,但这种计算类型的普遍性、规模,以及价值在最近几年才经历了...
    大数据是收集、整理、处理大容量数据集,并从中获得见解所需的非传统战略和技术的总称。虽然处理数据所需的计算能力或存储容量早已超过一台计算机的上限,但这种计算类型的普遍性、规模,以及价值在最近几年才经历了大规模扩展。

    本文将介绍大数据系统一个最基本的组件:处理框架。处理框架负责对系统中的数据进行计算,例如处理从非易失存储中读取的数据,或处理刚刚摄入到系统中的数据。数据的计算则是指从大量单一数据点中提取信息和见解的过程。

    下文将介绍这些框架:

    · 仅批处理框架:

    Apache Hadoop

    · 仅流处理框架:

    Apache Storm

    Apache Samza

    · 混合框架:

    Apache Spark

    Apache Flink

    大数据处理框架是什么?

    处理框架处理引擎负责对数据系统中的数据进行计算。虽然“引擎”和“框架”之间的区别没有什么权威的定义,但大部分时候可以将前者定义为实际负责处理数据操作的组件,后者则可定义为承担类似作用的一系列组件。

    例如Apache Hadoop可以看作一种以MapReduce作为默认处理引擎的处理框架。引擎和框架通常可以相互替换或同时使用。例如另一个框架Apache Spark可以纳入Hadoop并取代MapReduce。组件之间的这种互操作性是大数据系统灵活性如此之高的原因之一。

    虽然负责处理生命周期内这一阶段数据的系统通常都很复杂,但从广义层面来看它们的目标是非常一致的:通过对数据执行操作提高理解能力,揭示出数据蕴含的模式,并针对复杂互动获得见解。

    为了简化这些组件的讨论,我们会通过不同处理框架的设计意图,按照所处理的数据状态对其进行分类。一些系统可以用批处理方式处理数据,一些系统可以用流方式处理连续不断流入系统的数据。此外还有一些系统可以同时处理这两类数据。

    在深入介绍不同实现的指标和结论之前,首先需要对不同处理类型的概念进行一个简单的介绍。

    批处理系统

    批处理在大数据世界有着悠久的历史。批处理主要操作大容量静态数据集,并在计算过程完成后返回结果。

    批处理模式中使用的数据集通常符合下列特征…

    · 有界:批处理数据集代表数据的有限集合

    · 持久:数据通常始终存储在某种类型的持久存储位置中

    · 大量:批处理操作通常是处理极为海量数据集的唯一方法

    批处理非常适合需要访问全套记录才能完成的计算工作。例如在计算总数和平均数时,必须将数据集作为一个整体加以处理,而不能将其视作多条记录的集合。这些操作要求在计算进行过程中数据维持自己的状态。

    需要处理大量数据的任务通常最适合用批处理操作进行处理。无论直接从持久存储设备处理数据集,或首先将数据集载入内存,批处理系统在设计过程中就充分考虑了数据的量,可提供充足的处理资源。由于批处理在应对大量持久数据方面的表现极为出色,因此经常被用于对历史数据进行分析。

    大量数据的处理需要付出大量时间,因此批处理不适合对处理时间要求较高的场合。

    Apache Hadoop

    Apache Hadoop是一种专用于批处理的处理框架。Hadoop是首个在开源社区获得极大关注的大数据框架。基于谷歌有关海量数据处理所发表的多篇论文与经验的Hadoop重新实现了相关算法和组件堆栈,让大规模批处理技术变得更易用。

    新版Hadoop包含多个组件,即多个层,通过配合使用可处理批数据:

    · HDFS:HDFS是一种分布式文件系统层,可对集群节点间的存储和复制进行协调。HDFS确保了无法避免的节点故障发生后数据依然可用,可将其用作数据来源,可用于存储中间态的处理结果,并可存储计算的最终结果。

    · YARN:YARN是Yet Another Resource Negotiator(另一个资源管理器)的缩写,可充当Hadoop堆栈的集群协调组件。该组件负责协调并管理底层资源和调度作业的运行。通过充当集群资源的接口,YARN使得用户能在Hadoop集群中使用比以往的迭代方式运行更多类型的工作负载。

    · MapReduce:MapReduce是Hadoop的原生批处理引擎。

    批处理模式

    Hadoop的处理功能来自MapReduce引擎。MapReduce的处理技术符合使用键值对的map、shuffle、reduce算法要求。基本处理过程包括:

    · 从HDFS文件系统读取数据集

    · 将数据集拆分成小块并分配给所有可用节点

    · 针对每个节点上的数据子集进行计算(计算的中间态结果会重新写入HDFS)

    · 重新分配中间态结果并按照键进行分组

    · 通过对每个节点计算的结果进行汇总和组合对每个键的值进行“Reducing”

    · 将计算而来的最终结果重新写入 HDFS

    优势和局限

    由于这种方法严重依赖持久存储,每个任务需要多次执行读取和写入操作,因此速度相对较慢。但另一方面由于磁盘空间通常是服务器上最丰富的资源,这意味着MapReduce可以处理非常海量的数据集。同时也意味着相比其他类似技术,Hadoop的MapReduce通常可以在廉价硬件上运行,因为该技术并不需要将一切都存储在内存中。MapReduce具备极高的缩放潜力,生产环境中曾经出现过包含数万个节点的应用。

    MapReduce的学习曲线较为陡峭,虽然Hadoop生态系统的其他周边技术可以大幅降低这一问题的影响,但通过Hadoop集群快速实现某些应用时依然需要注意这个问题。

    围绕Hadoop已经形成了辽阔的生态系统,Hadoop集群本身也经常被用作其他软件的组成部件。很多其他处理框架和引擎通过与Hadoop集成也可以使用HDFS和YARN资源管理器。

    总结

    Apache Hadoop及其MapReduce处理引擎提供了一套久经考验的批处理模型,最适合处理对时间要求不高的非常大规模数据集。通过非常低成本的组件即可搭建完整功能的Hadoop集群,使得这一廉价且高效的处理技术可以灵活应用在很多案例中。与其他框架和引擎的兼容与集成能力使得Hadoop可以成为使用不同技术的多种工作负载处理平台的底层基础。

    流处理系统

    流处理系统会对随时进入系统的数据进行计算。相比批处理模式,这是一种截然不同的处理方式。流处理方式无需针对整个数据集执行操作,而是对通过系统传输的每个数据项执行操作。

    · 流处理中的数据集是“无边界”的,这就产生了几个重要的影响:

    · 完整数据集只能代表截至目前已经进入到系统中的数据总量。

    · 工作数据集也许更相关,在特定时间只能代表某个单一数据项。

    处理工作是基于事件的,除非明确停止否则没有“尽头”。处理结果立刻可用,并会随着新数据的抵达继续更新。

    流处理系统可以处理几乎无限量的数据,但同一时间只能处理一条(真正的流处理)或很少量(微批处理,Micro-batch Processing)数据,不同记录间只维持最少量的状态。虽然大部分系统提供了用于维持某些状态的方法,但流处理主要针对副作用更少,更加功能性的处理(Functional processing)进行优化。

    功能性操作主要侧重于状态或副作用有限的离散步骤。针对同一个数据执行同一个操作会或略其他因素产生相同的结果,此类处理非常适合流处理,因为不同项的状态通常是某些困难、限制,以及某些情况下不需要的结果的结合体。因此虽然某些类型的状态管理通常是可行的,但这些框架通常在不具备状态管理机制时更简单也更高效。

    此类处理非常适合某些类型的工作负载。有近实时处理需求的任务很适合使用流处理模式。分析、服务器或应用程序错误日志,以及其他基于时间的衡量指标是最适合的类型,因为对这些领域的数据变化做出响应对于业务职能来说是极为关键的。流处理很适合用来处理必须对变动或峰值做出响应,并且关注一段时间内变化趋势的数据。

    Apache Storm

    Apache Storm是一种侧重于极低延迟的流处理框架,也许是要求近实时处理的工作负载的最佳选择。该技术可处理非常大量的数据,通过比其他解决方案更低的延迟提供结果。

    流处理模式

    Storm的流处理可对框架中名为Topology(拓扑)的DAG(Directed Acyclic Graph,有向无环图)进行编排。这些拓扑描述了当数据片段进入系统后,需要对每个传入的片段执行的不同转换或步骤。

    拓扑包含:

    · Stream:普通的数据流,这是一种会持续抵达系统的无边界数据。

    · Spout:位于拓扑边缘的数据流来源,例如可以是API或查询等,从这里可以产生待处理的数据。

    · Bolt:Bolt代表需要消耗流数据,对其应用操作,并将结果以流的形式进行输出的处理步骤。Bolt需要与每个Spout建立连接,随后相互连接以组成所有必要的处理。在拓扑的尾部,可以使用最终的Bolt输出作为相互连接的其他系统的输入。

    Storm背后的想法是使用上述组件定义大量小型的离散操作,随后将多个组件组成所需拓扑。默认情况下Storm提供了“至少一次”的处理保证,这意味着可以确保每条消息至少可以被处理一次,但某些情况下如果遇到失败可能会处理多次。Storm无法确保可以按照特定顺序处理消息。

    为了实现严格的一次处理,即有状态处理,可以使用一种名为Trident的抽象。严格来说不使用Trident的Storm通常可称之为Core Storm。Trident会对Storm的处理能力产生极大影响,会增加延迟,为处理提供状态,使用微批模式代替逐项处理的纯粹流处理模式。

    为避免这些问题,通常建议Storm用户尽可能使用Core Storm。然而也要注意,Trident对内容严格的一次处理保证在某些情况下也比较有用,例如系统无法智能地处理重复消息时。如果需要在项之间维持状态,例如想要计算一个小时内有多少用户点击了某个链接,此时Trident将是你唯一的选择。尽管不能充分发挥框架与生俱来的优势,但Trident提高了Storm的灵活性。

    Trident拓扑包含:

    · 流批(Stream batch):这是指流数据的微批,可通过分块提供批处理语义。

    · 操作(Operation):是指可以对数据执行的批处理过程。

    优势和局限

    目前来说Storm可能是近实时处理领域的最佳解决方案。该技术可以用极低延迟处理数据,可用于希望获得最低延迟的工作负载。如果处理速度直接影响用户体验,例如需要将处理结果直接提供给访客打开的网站页面,此时Storm将会是一个很好的选择。

    Storm与Trident配合使得用户可以用微批代替纯粹的流处理。虽然借此用户可以获得更大灵活性打造更符合要求的工具,但同时这种做法会削弱该技术相比其他解决方案最大的优势。话虽如此,但多一种流处理方式总是好的。

    Core Storm无法保证消息的处理顺序。Core Storm为消息提供了“至少一次”的处理保证,这意味着可以保证每条消息都能被处理,但也可能发生重复。Trident提供了严格的一次处理保证,可以在不同批之间提供顺序处理,但无法在一个批内部实现顺序处理。

    在互操作性方面,Storm可与Hadoop的YARN资源管理器进行集成,因此可以很方便地融入现有Hadoop部署。除了支持大部分处理框架,Storm还可支持多种语言,为用户的拓扑定义提供了更多选择。

    总结

    对于延迟需求很高的纯粹的流处理工作负载,Storm可能是最适合的技术。该技术可以保证每条消息都被处理,可配合多种编程语言使用。由于Storm无法进行批处理,如果需要这些能力可能还需要使用其他软件。如果对严格的一次处理保证有比较高的要求,此时可考虑使用Trident。不过这种情况下其他流处理框架也许更适合。

    Apache Samza

    Apache Samza是一种与Apache Kafka消息系统紧密绑定的流处理框架。虽然Kafka可用于很多流处理系统,但按照设计,Samza可以更好地发挥Kafka独特的架构优势和保障。该技术可通过Kafka提供容错、缓冲,以及状态存储。

    Samza可使用YARN作为资源管理器。这意味着默认情况下需要具备Hadoop集群(至少具备HDFS和YARN),但同时也意味着Samza可以直接使用YARN丰富的内建功能。

    流处理模式

    Samza依赖Kafka的语义定义流的处理方式。Kafka在处理数据时涉及下列概念:

    · Topic(话题):进入Kafka系统的每个数据流可称之为一个话题。话题基本上是一种可供消耗方订阅的,由相关信息组成的数据流。

    · Partition(分区):为了将一个话题分散至多个节点,Kafka会将传入的消息划分为多个分区。分区的划分将基于键(Key)进行,这样可以保证包含同一个键的每条消息可以划分至同一个分区。分区的顺序可获得保证。

    · Broker(代理):组成Kafka集群的每个节点也叫做代理。

    · Producer(生成方):任何向Kafka话题写入数据的组件可以叫做生成方。生成方可提供将话题划分为分区所需的键。

    · Consumer(消耗方):任何从Kafka读取话题的组件可叫做消耗方。消耗方需要负责维持有关自己分支的信息,这样即可在失败后知道哪些记录已经被处理过了。

    由于Kafka相当于永恒不变的日志,Samza也需要处理永恒不变的数据流。这意味着任何转换创建的新数据流都可被其他组件所使用,而不会对最初的数据流产生影响。

    优势和局限

    乍看之下,Samza对Kafka类查询系统的依赖似乎是一种限制,然而这也可以为系统提供一些独特的保证和功能,这些内容也是其他流处理系统不具备的。

    例如Kafka已经提供了可以通过低延迟方式访问的数据存储副本,此外还可以为每个数据分区提供非常易用且低成本的多订阅者模型。所有输出内容,包括中间态的结果都可写入到Kafka,并可被下游步骤独立使用。

    这种对Kafka的紧密依赖在很多方面类似于MapReduce引擎对HDFS的依赖。虽然在批处理的每个计算之间对HDFS的依赖导致了一些严重的性能问题,但也避免了流处理遇到的很多其他问题。

    Samza与Kafka之间紧密的关系使得处理步骤本身可以非常松散地耦合在一起。无需事先协调,即可在输出的任何步骤中增加任意数量的订阅者,对于有多个团队需要访问类似数据的组织,这一特性非常有用。多个团队可以全部订阅进入系统的数据话题,或任意订阅其他团队对数据进行过某些处理后创建的话题。这一切并不会对数据库等负载密集型基础架构造成额外的压力。

    直接写入Kafka还可避免回压(Backpressure)问题。回压是指当负载峰值导致数据流入速度超过组件实时处理能力的情况,这种情况可能导致处理工作停顿并可能丢失数据。按照设计,Kafka可以将数据保存很长时间,这意味着组件可以在方便的时候继续进行处理,并可直接重启动而无需担心造成任何后果。

    Samza可以使用以本地键值存储方式实现的容错检查点系统存储数据。这样Samza即可获得“至少一次”的交付保障,但面对由于数据可能多次交付造成的失败,该技术无法对汇总后状态(例如计数)提供精确恢复。

    Samza提供的高级抽象使其在很多方面比Storm等系统提供的基元(Primitive)更易于配合使用。目前Samza只支持JVM语言,这意味着它在语言支持方面不如Storm灵活。

    总结

    对于已经具备或易于实现Hadoop和Kafka的环境,Apache Samza是流处理工作负载一个很好的选择。Samza本身很适合有多个团队需要使用(但相互之间并不一定紧密协调)不同处理阶段的多个数据流的组织。Samza可大幅简化很多流处理工作,可实现低延迟的性能。如果部署需求与当前系统不兼容,也许并不适合使用,但如果需要极低延迟的处理,或对严格的一次处理语义有较高需求,此时依然适合考虑。

    混合处理系统:批处理和流处理

    一些处理框架可同时处理批处理和流处理工作负载。这些框架可以用相同或相关的组件和API处理两种类型的数据,借此让不同的处理需求得以简化。

    如你所见,这一特性主要是由Spark和Flink实现的,下文将介绍这两种框架。实现这样的功能重点在于两种不同处理模式如何进行统一,以及要对固定和不固定数据集之间的关系进行何种假设。

    虽然侧重于某一种处理类型的项目会更好地满足具体用例的要求,但混合框架意在提供一种数据处理的通用解决方案。这种框架不仅可以提供处理数据所需的方法,而且提供了自己的集成项、库、工具,可胜任图形分析、机器学习、交互式查询等多种任务。

    Apache Spark

    Apache Spark是一种包含流处理能力的下一代批处理框架。与Hadoop的MapReduce引擎基于各种相同原则开发而来的Spark主要侧重于通过完善的内存计算和处理优化机制加快批处理工作负载的运行速度。

    Spark可作为独立集群部署(需要相应存储层的配合),或可与Hadoop集成并取代MapReduce引擎。

    批处理模式

    与MapReduce不同,Spark的数据处理工作全部在内存中进行,只在一开始将数据读入内存,以及将最终结果持久存储时需要与存储层交互。所有中间态的处理结果均存储在内存中。

    虽然内存中处理方式可大幅改善性能,Spark在处理与磁盘有关的任务时速度也有很大提升,因为通过提前对整个任务集进行分析可以实现更完善的整体式优化。为此Spark可创建代表所需执行的全部操作,需要操作的数据,以及操作和数据之间关系的Directed Acyclic Graph(有向无环图),即DAG,借此处理器可以对任务进行更智能的协调。

    为了实现内存中批计算,Spark会使用一种名为Resilient Distributed Dataset(弹性分布式数据集),即RDD的模型来处理数据。这是一种代表数据集,只位于内存中,永恒不变的结构。针对RDD执行的操作可生成新的RDD。每个RDD可通过世系(Lineage)回溯至父级RDD,并最终回溯至磁盘上的数据。Spark可通过RDD在无需将每个操作的结果写回磁盘的前提下实现容错。

    流处理模式

    流处理能力是由Spark Streaming实现的。Spark本身在设计上主要面向批处理工作负载,为了弥补引擎设计和流处理工作负载特征方面的差异,Spark实现了一种叫做微批(Micro-batch)*的概念。在具体策略方面该技术可以将数据流视作一系列非常小的“批”,借此即可通过批处理引擎的原生语义进行处理。

    Spark Streaming会以亚秒级增量对流进行缓冲,随后这些缓冲会作为小规模的固定数据集进行批处理。这种方式的实际效果非常好,但相比真正的流处理框架在性能方面依然存在不足。

    优势和局限

    使用Spark而非Hadoop MapReduce的主要原因是速度。在内存计算策略和先进的DAG调度等机制的帮助下,Spark可以用更快速度处理相同的数据集。

    Spark的另一个重要优势在于多样性。该产品可作为独立集群部署,或与现有Hadoop集群集成。该产品可运行批处理和流处理,运行一个集群即可处理不同类型的任务。

    除了引擎自身的能力外,围绕Spark还建立了包含各种库的生态系统,可为机器学习、交互式查询等任务提供更好的支持。相比MapReduce,Spark任务更是“众所周知”地易于编写,因此可大幅提高生产力。

    为流处理系统采用批处理的方法,需要对进入系统的数据进行缓冲。缓冲机制使得该技术可以处理非常大量的传入数据,提高整体吞吐率,但等待缓冲区清空也会导致延迟增高。这意味着Spark Streaming可能不适合处理对延迟有较高要求的工作负载。

    由于内存通常比磁盘空间更贵,因此相比基于磁盘的系统,Spark成本更高。然而处理速度的提升意味着可以更快速完成任务,在需要按照小时数为资源付费的环境中,这一特性通常可以抵消增加的成本。

    Spark内存计算这一设计的另一个后果是,如果部署在共享的集群中可能会遇到资源不足的问题。相比Hadoop MapReduce,Spark的资源消耗更大,可能会对需要在同一时间使用集群的其他任务产生影响。从本质来看,Spark更不适合与Hadoop堆栈的其他组件共存一处。

    总结

    Spark是多样化工作负载处理任务的最佳选择。Spark批处理能力以更高内存占用为代价提供了无与伦比的速度优势。对于重视吞吐率而非延迟的工作负载,则比较适合使用Spark Streaming作为流处理解决方案。

    Apache Flink

    Apache Flink是一种可以处理批处理任务的流处理框架。该技术可将批处理数据视作具备有限边界的数据流,借此将批处理任务作为流处理的子集加以处理。为所有处理任务采取流处理为先的方法会产生一系列有趣的副作用。

    这种流处理为先的方法也叫做Kappa架构,与之相对的是更加被广为人知的Lambda架构(该架构中使用批处理作为主要处理方法,使用流作为补充并提供早期未经提炼的结果)。Kappa架构中会对一切进行流处理,借此对模型进行简化,而这一切是在最近流处理引擎逐渐成熟后才可行的。

    流处理模型

    Flink的流处理模型在处理传入数据时会将每一项视作真正的数据流。Flink提供的DataStream API可用于处理无尽的数据流。Flink可配合使用的基本组件包括:

    · Stream(流)是指在系统中流转的,永恒不变的无边界数据集

    · Operator(操作方)是指针对数据流执行操作以产生其他数据流的功能

    · Source(源)是指数据流进入系统的入口点

    · Sink(槽)是指数据流离开Flink系统后进入到的位置,槽可以是数据库或到其他系统的连接器

    为了在计算过程中遇到问题后能够恢复,流处理任务会在预定时间点创建快照。为了实现状态存储,Flink可配合多种状态后端系统使用,具体取决于所需实现的复杂度和持久性级别。

    此外Flink的流处理能力还可以理解“事件时间”这一概念,这是指事件实际发生的时间,此外该功能还可以处理会话。这意味着可以通过某种有趣的方式确保执行顺序和分组。

    批处理模型

    Flink的批处理模型在很大程度上仅仅是对流处理模型的扩展。此时模型不再从持续流中读取数据,而是从持久存储中以流的形式读取有边界的数据集。Flink会对这些处理模型使用完全相同的运行时。

    Flink可以对批处理工作负载实现一定的优化。例如由于批处理操作可通过持久存储加以支持,Flink可以不对批处理工作负载创建快照。数据依然可以恢复,但常规处理操作可以执行得更快。

    另一个优化是对批处理任务进行分解,这样即可在需要的时候调用不同阶段和组件。借此Flink可以与集群的其他用户更好地共存。对任务提前进行分析使得Flink可以查看需要执行的所有操作、数据集的大小,以及下游需要执行的操作步骤,借此实现进一步的优化。

    优势和局限

    Flink目前是处理框架领域一个独特的技术。虽然Spark也可以执行批处理和流处理,但Spark的流处理采取的微批架构使其无法适用于很多用例。Flink流处理为先的方法可提供低延迟,高吞吐率,近乎逐项处理的能力。

    Flink的很多组件是自行管理的。虽然这种做法较为罕见,但出于性能方面的原因,该技术可自行管理内存,无需依赖原生的Java垃圾回收机制。与Spark不同,待处理数据的特征发生变化后Flink无需手工优化和调整,并且该技术也可以自行处理数据分区和自动缓存等操作。

    Flink会通过多种方式对工作进行分许进而优化任务。这种分析在部分程度上类似于SQL查询规划器对关系型数据库所做的优化,可针对特定任务确定最高效的实现方法。该技术还支持多阶段并行执行,同时可将受阻任务的数据集合在一起。对于迭代式任务,出于性能方面的考虑,Flink会尝试在存储数据的节点上执行相应的计算任务。此外还可进行“增量迭代”,或仅对数据中有改动的部分进行迭代。

    在用户工具方面,Flink提供了基于Web的调度视图,借此可轻松管理任务并查看系统状态。用户也可以查看已提交任务的优化方案,借此了解任务最终是如何在集群中实现的。对于分析类任务,Flink提供了类似SQL的查询,图形化处理,以及机器学习库,此外还支持内存计算。

    Flink能很好地与其他组件配合使用。如果配合Hadoop 堆栈使用,该技术可以很好地融入整个环境,在任何时候都只占用必要的资源。该技术可轻松地与YARN、HDFS和Kafka 集成。在兼容包的帮助下,Flink还可以运行为其他处理框架,例如Hadoop和Storm编写的任务。

    目前Flink最大的局限之一在于这依然是一个非常“年幼”的项目。现实环境中该项目的大规模部署尚不如其他处理框架那么常见,对于Flink在缩放能力方面的局限目前也没有较为深入的研究。随着快速开发周期的推进和兼容包等功能的完善,当越来越多的组织开始尝试时,可能会出现越来越多的Flink部署。

    总结

    Flink提供了低延迟流处理,同时可支持传统的批处理任务。Flink也许最适合有极高流处理需求,并有少量批处理任务的组织。该技术可兼容原生Storm和Hadoop程序,可在YARN管理的集群上运行,因此可以很方便地进行评估。快速进展的开发工作使其值得被大家关注。

    结论

    大数据系统可使用多种处理技术。

    对于仅需要批处理的工作负载,如果对时间不敏感,比其他解决方案实现成本更低的Hadoop将会是一个好选择。

    对于仅需要流处理的工作负载,Storm可支持更广泛的语言并实现极低延迟的处理,但默认配置可能产生重复结果并且无法保证顺序。Samza与YARN和Kafka紧密集成可提供更大灵活性,更易用的多团队使用,以及更简单的复制和状态管理。

    对于混合型工作负载,Spark可提供高速批处理和微批处理模式的流处理。该技术的支持更完善,具备各种集成库和工具,可实现灵活的集成。Flink提供了真正的流处理并具备批处理能力,通过深度优化可运行针对其他平台编写的任务,提供低延迟的处理,但实际应用方面还为时过早。

    最适合的解决方案主要取决于待处理数据的状态,对处理所需时间的需求,以及希望得到的结果。具体是使用全功能解决方案或主要侧重于某种项目的解决方案,这个问题需要慎重权衡。随着逐渐成熟并被广泛接受,在评估任何新出现的创新型解决方案时都需要考虑类似的问题。

    展开全文
  • 大数据 架构 数据分析工作虽然隐藏在业务系统背后,但是具有非常重要的作用,数据分析的结果对决策、业务发展有着举足轻重的作用。随着大数据技术的发展,数据挖掘、数据探索等专有名词曝光度越来越高,但是在类似...

    大数据 架构

    数据分析工作虽然隐藏在业务系统背后,但是具有非常重要的作用,数据分析的结果对决策、业务发展有着举足轻重的作用。随着大数据技术的发展,数据挖掘、数据探索等专有名词曝光度越来越高,但是在类似于Hadoop系列的大数据分析系统大行其道之前,数据分析工作已经经历了长足的发展,尤其是以BI系统为主的数据分析,已经有了非常成熟和稳定的技术方案和生态系统,对于BI系统来说,大概的架构图如下: 


    可以看到在BI系统里面,核心的模块是Cube,Cube是一个更高层的业务模型抽象,在Cube之上可以进行多种操作,例如上钻、下钻、切片等操作。大部分BI系统都基于关系型数据库,关系型数据库使用SQL语句进行操作,但是SQL在多维操作和分析的表示能力上相对较弱,所以Cube有自己独有的查询语言MDX,MDX表达式具有更强的多维表现能力,所以以Cube为核心的分析系统基本占据着数据统计分析的半壁江山,大多数的数据库服务厂商直接提供了BI套装软件服务,轻易便可搭建出一套Olap分析系统。不过BI的问题也随着时间的推移逐渐显露出来: 

    • BI系统更多的以分析业务数据产生的密度高、价值高的结构化数据为主,对于非结构化和半结构化数据的处理非常乏力,例如图片,文本,音频的存储,分析。
    • 由于数据仓库为结构化存储,在数据从其他系统进入数据仓库这个东西,我们通常叫做ETL过程,ETL动作和业务进行了强绑定,通常需要一个专门的ETL团队去和业务做衔接,决定如何进行数据的清洗和转换。
    • 随着异构数据源的增加,例如如果存在视频,文本,图片等数据源,要解析数据内容进入数据仓库,则需要非常复杂等ETL程序,从而导致ETL变得过于庞大和臃肿。
    • 当数据量过大的时候,性能会成为瓶颈,在TB/PB级别的数据量上表现出明显的吃力。
    • 数据库的范式等约束规则,着力于解决数据冗余的问题,是为了保障数据的一致性,但是对于数据仓库来说,我们并不需要对数据做修改和一致性的保障,原则上来说数据仓库的原始数据都是只读的,所以这些约束反而会成为影响性能的因素。
    • ETL动作对数据的预先假设和处理,导致机器学习部分获取到的数据为假设后的数据,因此效果不理想。例如如果需要使用数据仓库进行异常数据的挖掘,则在数据入库经过ETL的时候就需要明确定义需要提取的特征数据,否则无法结构化入库,然而大多数情况是需要基于异构数据才能提取出特征。

    在一系列的问题下,以Hadoop体系为首的大数据分析平台逐渐表现出优异性,围绕Hadoop体系的生态圈也不断的变大,对于Hadoop系统来说,从根本上解决了传统数据仓库的瓶颈的问题,但是也带来一系列的问题: 

    • 从数据仓库升级到大数据架构,是不具备平滑演进的,基本等于推翻重做。
    • 大数据下的分布式存储强调数据的只读性质,所以类似于Hive,HDFS这些存储方式都不支持update,HDFS的write操作也不支持并行,这些特性导致其具有一定的局限性。

    基于大数据架构的数据分析平台侧重于从以下几个维度去解决传统数据仓库做数据分析面临的瓶颈: 

    • 分布式计算:分布式计算的思路是让多个节点并行计算,并且强调数据本地性,尽可能的减少数据的传输,例如Spark通过RDD的形式来表现数据的计算逻辑,可以在RDD上做一系列的优化,来减少数据的传输。
    • 分布式存储:所谓的分布式存储,指的是将一个大文件拆成N份,每一份独立的放到一台机器上,这里就涉及到文件的副本,分片,以及管理等操作,分布式存储主要优化的动作都在这一块。
    • 检索和存储的结合:在早期的大数据组件中,存储和计算相对比较单一,但是目前更多的方向是在存储上做更多的手脚,让查询和计算更加高效,对于计算来说高效不外乎就是查找数据快,读取数据快,所以目前的存储不单单的存储数据内容,同时会添加很多元信息,例如索引信息。像类似于parquet和carbondata都是这样的思想。

    总的来说,目前围绕Hadoop体系的大数据架构大概有以下几种: 

    传统大数据架构 


    ​之所以叫传统大数据架构,是因为其定位是为了解决传统BI的问题,简单来说,数据分析的业务没有发生任何变化,但是因为数据量、性能等问题导致系统无法正常使用,需要进行升级改造,那么此类架构便是为了解决这个问题。可以看到,其依然保留了ETL的动作,将数据经过ETL动作进入数据存储。 

    优点:简单,易懂,对于BI系统来说,基本思想没有发生变化,变化的仅仅是技术选型,用大数据架构替换掉BI的组件。 

    缺点:对于大数据来说,没有BI下如此完备的Cube架构,虽然目前有kylin,但是kylin的局限性非常明显,远远没有BI下的Cube的灵活度和稳定度,因此对业务支撑的灵活度不够,所以对于存在大量报表,或者复杂的钻取的场景,需要太多的手工定制化,同时该架构依旧以批处理为主,缺乏实时的支撑。 

    适用场景:数据分析需求依旧以BI场景为主,但是因为数据量、性能等问题无法满足日常使用。 

    流式架构 


    在传统大数据架构的基础上,流式架构非常激进,直接拔掉了批处理,数据全程以流的形式处理,所以在数据接入端没有了ETL,转而替换为数据通道。经过流处理加工后的数据,以消息的形式直接推送给了消费者。虽然有一个存储部分,但是该存储更多的以窗口的形式进行存储,所以该存储并非发生在数据湖,而是在外围系统。 

    优点:没有臃肿的ETL过程,数据的实效性非常高。 

    缺点:对于流式架构来说,不存在批处理,因此对于数据的重播和历史统计无法很好的支撑。对于离线分析仅仅支撑窗口之内的分析。 

    适用场景:预警,监控,对数据有有效期要求的情况。 

    Lambda架构 


    Lambda架构算是大数据系统里面举足轻重的架构,大多数架构基本都是Lambda架构或者基于其变种的架构。Lambda的数据通道分为两条分支:实时流和离线。实时流依照流式架构,保障了其实时性,而离线则以批处理方式为主,保障了最终一致性。什么意思呢?流式通道处理为保障实效性更多的以增量计算为主辅助参考,而批处理层则对数据进行全量运算,保障其最终的一致性,因此Lambda最外层有一个实时层和离线层合并的动作,此动作是Lambda里非常重要的一个动作,大概的合并思路如下: 


    优点:既有实时又有离线,对于数据分析场景涵盖的非常到位。 

    缺点:离线层和实时流虽然面临的场景不相同,但是其内部处理的逻辑却是相同,因此有大量荣誉和重复的模块存在。 

    适用场景:同时存在实时和离线需求的情况。 

    Kappa架构 


    ​ Kappa架构在Lambda 的基础上进行了优化,将实时和流部分进行了合并,将数据通道以消息队列进行替代。因此对于Kappa架构来说,依旧以流处理为主,但是数据却在数据湖层面进行了存储,当需要进行离线分析或者再次计算的时候,则将数据湖的数据再次经过消息队列重播一次则可。 

    优点:Kappa架构解决了Lambda架构里面的冗余部分,以数据可重播的超凡脱俗的思想进行了设计,整个架构非常简洁。 

    缺点:虽然Kappa架构看起来简洁,但是施难度相对较高,尤其是对于数据重播部分。 

    适用场景:和Lambda类似,改架构是针对Lambda的优化。 

    Unifield架构 


    ​以上的种种架构都围绕海量数据处理为主,Unifield架构则更激进,将机器学习和数据处理揉为一体,从核心上来说,Unifield依旧以Lambda为主,不过对其进行了改造,在流处理层新增了机器学习层。可以看到数据在经过数据通道进入数据湖后,新增了模型训练部分,并且将其在流式层进行使用。同时流式层不单使用模型,也包含着对模型的持续训练。 

    优点:Unifield架构提供了一套数据分析和机器学习结合的架构方案,非常好的解决了机器学习如何与数据平台进行结合的问题。 

    缺点:Unifield架构实施复杂度更高,对于机器学习架构来说,从软件包到硬件部署都和数据分析平台有着非常大的差别,因此在实施过程中的难度系数更高。 

    适用场景:有着大量数据需要分析,同时对机器学习方便又有着非常大的需求或者有规划。 

    总结 

    以上几种架构为目前数据处理领域使用比较多的几种架构,当然还有非常多其他架构,不过其思想都会或多或少的类似。数据领域和机器学习领域会持续发展,以上几种思想或许终究也会变得过时。

    展开全文
  • 架构大数据:大数据技术及算法解析
  • 资源名称:数据架构 大数据、数据仓库以及DATA VAULT内容简介:本书是数据仓库之父Inmon的新作,探讨数据的架构和如何在现有系统中最有效地利用数据。本书的主题涵盖企业数据、大数据、数据仓库、Data Vault、业务...
  • 本书内容不错,从大数据的概念、数据采集、数据分析、实时数据处理、数据挖掘、深度学习、大数据可视化、大数据安全等各个方面都有涉及,最后还讲述了一些大公司的大数据架构,是一本了解大数据全链路不错的书籍。
  • 资源名称:架构大数据 大数据技术及算法解析内容简介:本书从大数据架构的角度全面解析大数据技术及算法,探讨大数据的发展和趋势。不仅对大数据相关技术及算法做了系统性的分析和描述,梳理了大数据的技术分类,如...
  • 大数据被称为新时代的黄金和石油,相关技术发展迅猛,所应用的行业也非常广泛,从传统行业如医疗、教育、金融、旅游,到新兴产业如电商、计算广告、可穿戴设备、机器人等。大数据技术更是国家科技发展和智慧城市建设...
  • 经过这么多年的发展,已经从大数据1.0的BI/Datawarehouse时代,经过大数据2.0的Web/APP过渡,进入到了IOT的大数据3.0时代,而随之而来的是数据架构的变化。 ▌Lambda架构 在过去Lambda数据架构成为每一个公司...
  • 架构】 Java高级架构师级别,年薪百万,这些都不是一蹴而就的,这是需要很深的积累,以及自身强大的技术能力。 大家都会选择报班或者找资料来扩充自己的知识储备,这就不得不提一下马士兵老师的Java高级架构师教程...
  • 什么是大数据架构

    2019-03-23 15:35:43
    什么是大数据架构 大数据架构是用于摄取和处理大量数据(通常称为“大数据”)的总体系统,因此可以针对业务目的进行分析。该架构可视为基于组织业务需求的大数据解决方案的蓝图。大数据架构旨在处理以下类型的工作: ...
  • 梳理了大数据的技术分类,如基础架构支持、大数据采集、大数据存储、大数据处理、大数据展示及交互,还融合了大数据行业的最新技术进展和大型互联网公司的大数据架构实践,努力为读者提供一个大数据的全景画卷。
  • 大数据架构师指南.pdf
  • 1、大数据参考架构 大数据作为一种新兴技术,目前尚未形成完善、达成共识的技术标准体系。本章结合NIST和JTC1/SC32的研究成果,结合我们对大数据的理解和分析,提出了大数据参考架构(见图5)。 大数据参考架构图 ...
  • 工业大数据技术架构白皮书.pdf,详细描述工业领域大数据的技术架构及其应用领域。
  • 关于大数据架构有很多,比如说传统的大数据架构,当然,还有很多经典的大数据架构,比如说流式架构和Kappa架构。流式架构和Kappa架构大数据中的应用还是很多的,在这篇文章中我们就给大家介绍一下关于流式架构和...
  • 大数据架构中,有两个十分常见的架构,那就是lambda架构和unifield架构,这两个架构大数据中占据着十分重要的地位,在这篇文章中我们就给大家介绍一下lambda架构和unifield架构,帮助大家更深一步的去了解大数据...
  • 今天就给大家分享大数据云计算技术架构与实践技术,因为内容过多,所以只把部分知识点拿出来粗略的介绍了一下,每个小节都有更加细化的内容,希望大家能够喜欢~~~~~~~ 主要内容 本文是从.
  • 前几天读到白发川的一篇文章《对比解读五种主流大数据架构的数据分析能力》,文中详细总结了各类数据架构的应用以及原理。作为一名在数据仓库耕耘多年的技术人员,对于其中的一些技术细节还是破解兴趣的,所以随着...
1 2 3 4 5 ... 20
收藏数 166,248
精华内容 66,499
关键字:

架构大数据