数据管理比以往更加复杂,到处都是大数据,包括每个人的想法以及不同的形式:广告 、 社交图谱、信息流 、推荐 、市场、 健康、 安全、 政府等等。过去的三年里,成千上万的技术必须处理汇合在一起的大数据获取,管理 和分析;技术选型对IT部门来说是一件艰巨的任务,因为在大多数时间里没有一个综合的方法来用于选型。 当自己面临选择的时候,通常会问如下的问题: 什么时候需要考虑在IT系统中使用大数据? 准备好使用了么? 从哪里开始? 感觉大数据只是一种市场趋势,我还是应该去做么?这些问题萦绕着CIO和CTO们,当决定部署一个全局化分布式大数据架构时,可能会把企业置于危险之中。 本章目的时定义大数据的表征—换句话说,就是什么时候需要考虑将大数据放入架构。 但是,也指出了各种大数据技术的区别,能够理解在何种情况使用哪种技术。 最后, 基于真实世界的例子,构建了典型分布式大数据架构的基础模型。 基于不同的需要,可能选择开始大数据项目s: 因为所需处理的数据容量, 因为系统中数据结构的多样性, 因为扩展性问题, 或者因为需要削减数据处理的成本。 本节中,将看到怎样的征兆意味着一个团队需要开始一个大数据项目了。 数据大小那些事 除了技术和架构考虑,需要面对典型大数据用例的使用场景。它们部分和特殊的工业领域相关; 另外的部分可能适应于各种领域。这些考虑一般都是基于分析应用的日志,例如web访问日志,应用服务器日志,和数据库日志,但是也可以基于各种其他的数据源例如社交网络数据。当面对这些使用场景的时候,如果希望随着商务的增长而弹性扩展,就需要考虑一个分布式的大数据架构。 客户行为分析 感知客户, 或者叫做 “360-度客户视角”可能是最流行的大数据使用场景。客户视角通常用于电子商务网站以及开始于一个非结构化的点击流—换而言之, 由一个访客执行的主动点击和被动的网站导航操作组成。通过计算和分析点击量和面向产品或广告的印象,可以依赖行为而适配访客的用户体验, 目标是得到优化漏斗转换的见解。 情绪分析 公司关注的是其在社交网络上所被感知的形象和声誉; 把可能使他们声名狼藉的负面事件最小化并充分利用正面事件. 通过准实时爬下大量的社交数据,可以提取出社交社区中关于品牌的感受和情绪,从而找到影响用户并练习他们,改变并强化与这些用户的交互。 CRM Onboarding 基于访客的社交行为,可以将客户的行为分析和数据的情感分析结合在一起。公司希望将这些在线数据源和已经存在的离线数据结合在一起,这叫做 CRM (customer relationship management) onboarding, 以便于得到更好和更准确的客户定位. 进而,公司能够充分利用这一定位,从而建立更好的目标系统使市场活动的效益最大化。 预测 Hadoop发布版 在一个连贯,弹性和一致的架构中分别下载相关项目,然后尝试创建或组装它们 使用一个广泛流行的 Hadoop分发版, 已经装配或创建好了这些技术. Cloudera CDH Cloudier在Hadoop基础组件上增加了一个内部机构组件的集合; 这些组件被设计成给你更好的集群管理和搜素体验。部分组件列表如下: Impala: 一个实时,并行化,基于SQL的引擎来搜索 HDFS Cloudera Manager: 这是Cloudier的控制台,用来管理和部署Hadoop集群内的Hadoop组件. Hue: 一个用于执行用户交互数据操作和执行脚本的控制台,可以操作集群内不同的Hadoop组件. Figure 1-1 解释了Cloudera’s Hadoop分发包有如下组件分类: 橙色部分是Hadoop核心栈. 粉色部分是 Hadoop 生态系统项目 蓝色部分是 Cloudera的特使组件. Figure 1-1. Cloudera Hadoop发布版 Hortnworks HDP Hortnworks 是一个百分之百的开源而且使用了稳定的组件包,而不是1Hadoop 项目中最新的分发版本。它增加了一个组件管理控制台来与Cloudera Manager对比。Figure 1-2 展示了Hortonworks 发布版与Figure 1-1 相应的分类:绿色部分是Hortonworks的特殊组件. Hadoop Distributed File System (HDFS)你可能疑虑摄取到Hadoop集群中的数据存储到哪里。一般都在一个专有的系统上,叫做HDFS。HDFS的核心特性:
HDFS 是Hadoop集群中数据存储的头等公民。数据在集群数据节点中自动复制。 Figure 1-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 流水线. Figure 1-4. Flume architecture 通过 Flume, 可以将web服务器产生的不同日志文件移动到HDFS. 牢记我们工作在一个分布式的架构,可能包含有负载均衡器,HTTP servers,应用服务器,访问日志等等 . 我们是一不同的方式充分利用这些资源,使之能够被Flume流水线处理 . 详情参见 flume.apache.org. Apache SqoopSwoop是一个从结构化数据库传说大量数据到HDFS. 使用它,既可以从一个外部的关系型数据库将数据导入到HDFS, Hive, 或者 HBase, 也可以Hadoop 集群导出到一个关系型数据库或者数据仓库. Sqoop 支持主流的关系型数据库例如Oracle, MySQL, 和Postgres. 这个项目把你从写脚本传输数据中解脱出来;它提供了高性能数据传输的特性.因为关系型数据库中的数据增长迅速, 最好从开始就定义那些快速增长的表,然后使用Sqoop将数据周期性地传输到Hadoop,以便用于分析. 然后,结合Hadoop与其他数据,可以使用Sqoop 导出数据注入到BI 分析工具中. 详情参见 sqoop.apache.org. 处理语言一旦数据到了HDFS,可以使用不同的处理语言从原始数据得到最好的结果. Yarn: NextGen MapReduceMapReduce 是第一代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, 和处理模型是如何组织的. 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 KafkaApache Kafka 是一个由Linkedin开发的订阅-发布消息的分布式应用。Kafka经常与 Apache ActiveMQ 或者RabbitMQ对比, 但根本不同是Kafka 没有实现JMS (Java Message Service). 然而, Kafka是一个持久化消息的高吞吐量系统 , 支持队列和话题语意, 使用 ZooKeeper形成集群节点。 Kafka 实现了订阅-发布的企业级集成,支持并行化,以及性能和容错的企业级特性。 Figure 1-6 给出了订阅-发布架构的高层视角,消息在broker传输,服务于分区的话题。 Figure 1-6. Kafka partitioned topic example 使用 Kafka在我们架构中的引导点 ,主要用于接受数据并推送到Spark Streaming. 详情参见 kafka.apache.org. 机器学习当我们以无限收敛模型处理小数据采样时,在架构中讨论机器学习还为时尚早。我们是充分利用现有的分层或特殊语言来使用机器学习,例如 Spark MLlibMLlib是Spark上的机器学习库, 充分利用了 Spark Direct Acyclic Graph (DAG) 执行引擎, 所提供的API 集合方便地集成到Spark中. 它由各种的算法组成 :基本统计, 逻辑回归, k-means 聚类, 从混合高斯到奇异值分解以及多维朴素贝叶斯。 通过 Spark MLlib 这些开箱即用算法,可以用几行代码就能过简单地训练数据并构建预测模型a 详情参见 spark.apache.org/mllib. NoSQL 存储NoSQL 存储是数据架构的基础组件,因为它们可以摄取大量数据,提供弹性伸缩,高可用性以及开箱即用。Couchbase 和 ElasticSearch是两种我们聚焦的技术,先做简单讨论,稍后使用它们。 CouchbaseCouchbase是一个面向文档的NoSQL数据库,提供了一个灵活的模型轻松缩放,以及一致性的高性能。使用 Couchbase作为文档数据存储,基本上重定向从前端来的所有查询 到 Couchbase 防止了关系型数据库的高吞吐量读操作。详情参见 couchbase.com. ElasticSearchElasticSearch 是一种非常流行的 NoSQL 技术,拥有可伸缩分布式索引引擎和搜索特性,相当于一般架构中Apache Lucene 加上实时数据分析和全文搜索.
Figure 1-7 展示了Elastic产品的结构. Figure 1-7. ElasticSearch products 如前图所示, Elastic 也提供了商用产品例如Marvel,基于Kibana的一个监控控制台; Shield, 一个安全框架, 例如提供授权和认证; Watcher, 一个告警和通知系统. 但本书中不使用这些商用产品。我们主要使用ElasticSearch作为搜索引擎来持有Spark产生的产品。在处理和聚合之后,数据在ElasticSearch中被索引,使第三方系统通过ElasticSearch引擎查询数据。另一方面,我们也使用 ELK来处理日志和虚拟化分析,而不只是平台操作视角。详情参见 elastic.co. 记住所有这些大数据技术,现在来构建我们的架构。 架构概览从高层视角来看, 我们的架构看起来象另一个电子商务应用架构,需要如下: Figure 1-8 展示了这些不同应用如何在该架构组织起来的。 Figure 1-8. Architecture overview 日志摄取日志摄取应用被用作消费应用日志例如web 访问日志. 为了简化使用场景,提供一个web访问日志,模拟访客浏览产品目录,这些日志代表了点击流日志,既用作长时处理也用作实时推荐。架构有两个选项:第一个是以Flume来传输日志;第二个是以LEK 来创建访问分析。 Figure 1-9 展示了ELK 和Flume是如何处理日志的. Figure 1-9. Ingestion application 我们在架构中使用ELK ,因为LEK的三个产品无缝集成,能够比使用Flume给我们更多的价值 。 机器学习机器学习应用接收数据流,构建推荐引擎。这一应用使用一个基本的算法来基于Spark MLlib 介绍 机器学习的概念。 Figure 1-10 展示了该机器学习应用如何使用Kafka 接收数据,然后发送给Spark 处理,最后在ElasticSearch 建立索引为将来使用做准备。 Figure 1-10. Machine learning 处理引擎处理引擎是该架构的心脏; 它接收各种源的数据,代理合适模型的处理。 Figure 1-11 展示了由Hive组成的处理引擎如何接收数据,以及Spark的实时/准实时处理。 Figure 1-11. Processing engine 这里使用Kafka 与 Logstash结合把数据分发给ElasticSearch. Spark位于 Hadoop 集群的顶端, 但不说必须的。为了简化起见,本书不建立 Hadoop集群,而是以standalone模式运行Spark。显然,应用同样可以部署在所选择的Hadoop 发布版上。 来源:36大数据,作者:数据有意思 |
|
来自: 郑公书馆298 > 《军工技术与装备发展》