Apache Flume

MapReduce 论文研读 说明 ：本文为论文 《MapReduce: Simplified Data Processing on Large Clusters》 的个人理解，难免有理解不到位之处，欢迎交流与指正 。 论文地址 ： MapReduce Paper 1. MapReduce 编程模型 MapReduce 是 Google 提出的一种用于处理和生成大数据集的 编程模型 ，具象地可以理解成一个 框架 。 该框架含有两个由用户来实现的接口： map 和 reduce ， map 函数接收一个键值对，生成一个中间键值对集合， MapReduce 框架会将所有共用一个键的值组合在一起并传递给 reduce 函数， reduce 函数接收此中间键以及该键的值的集合，将这些值合并在一起，生成一组更小的值的集合 。 该编程模型中，数据形式变换可由以下模式表示： map: (k1, v1) -> list(k2, v2) reduce: (k2, list(v2)) -> list(v3) 注 ：论文中该模式第二行表示为 reduce: (k2, list(v2)) -> list(v2) ，个人认为由于通常情况下 reduce 会对 list<v2> 做一些处理（特殊情况下不做任何处理，即 reduce 为恒等函数），生成一些不同的值，所以用 list<v3>

前面说到Spark的核心技术的时候，有和大家说过，有五大核心技术，不知道大家还记不记得； 给大家回忆下，这五大核心技术：分布式计算引擎 Spark Core 、基于Hadoop的SQL解决方案 SparkSQL 、可以实现高吞吐量、具备容错机制的准实时流处理系统 Spark Streaming 、分布式图处理框架 Spark GraphX 和构建在Spark上的分布式机器学习库 Spark MLlib ，现在应该有个印象了吧，其它的我就不多说了，今天主要是对Spark Streaming做个简单介绍，以便理解。 Spark Streaming理解 Spark Streaming 是核心 Spark API 的扩展，支持可伸缩、高吞吐量、容错的实时数据流处理。数据可以从许多来源获取，如 Kafka、Flume、Kinesis 或 TCP sockets，可以使用复杂的算法处理数据，这些算法用高级函数表示，如 map、reduce、join 和 window。 最后，处理后的数据可以推送到文件系统、数据库和活动仪表板。实际上，还可以将 Spark 的 MLlib 机器学习和 GraphX 图形处理算法应用于数据流。Spark Streaming 处理的数据流如下图所示。 流是什么 ？ 简单理解，就好比水流，是不是有源头，但不知道终点，有始没有终，你永远不知道水流什么时候结束

迄今为止，Hadoop 的发展已经经历了两代，分别为Hadoop 1.0 和Hadoop 2.0。与《Hadoop 权威指南(第3版)》相比，第4版在重点介绍Hadoop 2.0的基础上，新增了对当前热门的Hadoop 技术(如YARN、Parquet、Flume、Crunch和Spark)的专门讲解，有助于Hadoop开发者更好地理解相关技术的背景、原理及使用。此外，第4版还引入了Hadoop在医疗健康领域和分子生物学领域的最新应用成果，并为此新增了相关的实例学习，这对广大Hadoop用户而言，具有更好的实践指导意义。 今天，Hadoop 开源项目已经成为研究大数据、开发大数据应用的重要平台，在我国已经形成一个庞大的Hadoop用户社群，他们对学习、掌握和提高Hadoop提出了很高的需求，《Hadoop权威指南》系列版本的推出恰好可以满足这样的需要。该书从第1版发行以来，历次再版后的畅销也证明了它的用途和价值。 本书结合理论和实践，由浅入深，全方位介绍了Hadoop这一高性能的海量数据处理和分析平台。全书5部分24章， 第I部分介绍Hadoop基础知识，主题涉及Hadoop、 MapReduce、 Hadoop分布式文件系统、YARN、Hadoop 的I/O操作。 第II部分介绍MapReduce,主题包括MapReduce应用开发; MapReduce 的工作机制

点击蓝色“ 有关SQL ”关注我哟 加个“ 星标 ”，天天与10000人一起快乐成长 很多朋友会觉得写 CRUD 很无聊，翻来覆去就那么点花样。接触不到新鲜的技术，感觉自己要被这个时代淘汰了。于是怨天尤人，连基本的 SQL 都写不好了。 这可能是眼界与见识的问题。SQL 在行业内还是相当重要的，当然你说 CRUD 那点东西玩几个月就会了，没有新奇感。从技术角度来看，是这样，我承认。但换成业务角度来说，这又不是一回事了。这要细讲，我可以讲上三天三夜，所以留到以后的文章再说。 在 OLTP 系统中，CRUD 能做的事情，越来越少了。大部分都由前端框架封装好了。搞c#的同学有 Entity Framework, Java 系的同学有 Spring 全家桶。这些框架可以说，基本把 CRUD 同学的职位给抢掉了 2/3, 剩下纯搞 CRUD 的同学就偷着乐吧，也没几天了，想吃啥想喝啥，别委屈了自己。 真正能让 SQL 人凭手艺，还在 CRUD 行当里吃香的，喝辣的，技术上取决于你掌握了多少种数据库，SQL写得多快，要不然就是要享受福报了。 好在上帝关闭一扇窗的同时，他又打开了一道门。这道门便是 数据仓库 。 数据和银行的存款是一样的，越积越多，多得我们得千方百计思考该怎么用它。我们刚开始入行的时候，接触的数据库应用，十有八九都是业务系统，比如订单系统，生产系统和人事系统。这是早就很多

项目介绍 项目整体介绍 1.项目模型搭建 此项目为数据仓库项目,主要是做离线计算的 项目模型:项目分为流量域和业务域两个主题域,为了方便管理这么多数据,又将每个主题域划分为五个层级,分别是ODS层,DWD层,DWS层,ADS层及DIM层,分层的原因为解耦,复用,便于管理,下面我分别介绍一下项目中他们的应用场景 1.1 ODS层 ODS层:源数据层,分为流量域ODS层及业务域ODS层 流量域ODS层:数据来源于日志服务器(用户行为日志数据(APP端和WEB端)),日志服务器将数据生产到Kafka,然后使用Flume日志采集工具消费Kafka中的数据并将数据采集到Hdfs集群,在Hive中将数据加载到ODS层的Hive表中,这样就完成了原始数据的采集 业务域ODS层:数据来源于业务系统中的关系型数据库mysql,采用sqoop抽取工具将数据从mysql导入到Hdfs中,再在Hive中将数据加载到ODS层相应的表中 1.2 DWD层 DWD层:数据明细层,同样分为流量域DWD层及业务域DWD层 流量域DWD层:将数据在ODS层进行ETL操作(先对ODS层数据进行清洗,过滤(过滤掉缺失重要字段信息,重要字段信息为空或者json格式不正确的数据),降维等操作),再抽取到DWD层 业务域DWD层:抽取ODS层每天的增量数据,与DWD层每天的全量数据进行合并

如果要问最近几年，IT行业哪个技术方向最火？一定属于ABC，即AI + Big Data + Cloud，也就是人工智能、大数据和云计算。 这几年，随着互联网大潮走向低谷，同时传统企业纷纷进行数字化转型，基本各个公司都在考虑如何进一步挖掘数据价值，提高企业的运营效率。在这种趋势下，大数据技术越来越重要。所以，AI时代，还不了解大数据就真的OUT了！ 相比较AI和云计算，大数据的技术门槛更低一些，而且跟业务的相关性更大。我个人感觉再过几年，大数据技术将会像当前的分布式技术一样，变成一项基本的技能要求。 前几天，我在团队内进行了一次大数据的技术分享，重点是对大数据知识做一次扫盲，同时提供一份学习指南。这篇文章，我基于分享的内容再做一次系统性整理，希望对大数据方向感兴趣的同学有所帮助，内容分成以下5个部分： 1、大数据的发展历史 2、大数据的核心概念 3、大数据平台的通用架构和技术体系 4、大数据的通用处理流程 5、大数据下的数仓体系架构 01 大数据的发展历史 在解释「大数据」这个概念之前，先带大家了解下大数据将近30年的发展历史，共经历了5个阶段。那在每个阶段中，大数据的历史定位是怎样的？又遇到了哪些痛点呢？ 1.1 启蒙阶段：数据仓库的出现 20世纪90年代，商业智能（也就是我们熟悉的BI系统）诞生，它将企业已有的业务数据转化成为知识，帮助老板们进行经营决策。比如零售场景中

本文来源于公众号【胖滚猪学编程】，转载请注明出处！ 关于数据中台的概念和架构，我们在 大白话 六问数据中台 和 数据中台全景架构及模块解析！一文入门中台架构师！ 两篇文章中都说明白了。从这一篇文章开始分享中台落地实战。 其实无论是数据中台还是数据平台，数据无疑都是核心中的核心，所以闭着眼睛想都知道数据汇聚是数据中台/平台的入口。纵观众多中台架构图，数据采集与汇聚都是打头阵的： 本文将从以下几个方面分享数据采集的方方面面： 一、企业数据来源 二、数据采集概念和价值 三、数据采集常用工具 四、数据采集系统设计原则 五、数据采集模块生产落地分享 有来源才能谈采集，因此我们先来归纳下企业中数据来源。 数据来源 企业中的数据来源极其多，但大都都离不开这几个方面： 数据库，日志，前端埋点，爬虫系统等。 数据库我们不用多说，例如通常用mysql作为业务库，存储业务一些关键指标，比如用户信息、订单信息。也会用到一些Nosql数据库，一般用于存储一些不那么重要的数据。 日志也是重要数据来源，因为日志记录了程序各种执行情况，其中也包括用户的业务处理轨迹，根据日志我们可以分析出程序的异常情况，也可以统计关键业务指标比如PV,UV。 前端埋点同样是非常重要的来源，用户很多前端请求并不会产生后端请求，比如点击，但这些对分析用户行为具有重要的价值，例如分析用户流失率，是在哪个界面，哪个环节用户流失了

【 Java架构师面试网 】收集整理了几乎整个架构师学习途中会遇到的面试题，希望大家都能早日圆自己的架构师梦~ 公众号： Java架构师面试网 ，关注回复“ 资料 ”即可领取精美整理的面试资料一份哦~ Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 1.Kafka 的设计时什么样的呢？ Kafka 将消息以 topic 为单位进行归纳 将向 Kafka topic 发布消息的程序成为 producers. 将预订 topics 并消费消息的程序成为 consumer. Kafka 以集群的方式运行，可以由一个或多个服务组成，每个服务叫做一个 broker. producers 通过网络将消息发送到 Kafka 集群，集群向消费者提供消息 2.数据传输的事物定义有哪三种？ 数据传输的事务定义通常有以下三种级别： （ 1）最多一次: 消息不会被重复发送，最多被传输一次

Flume简介 Flume是Cloudera提供的日志收集系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据;同时，Flume提供对数据进行简单处理，并写到各种数据接受方(可定制)的能力。 Flume是一个分布式、可靠和高可用的海量日志采集、聚合和传输的系统。 Flume拥有基于数据流上的简单灵活架构，支持容错、故障转移与恢复。 Flume具有 Reliability、Scalability、Manageability和Extensibility 特点： 1.Reliability ：Flume提供3中数据可靠性选项，包括End-to-end、Store on failure和Best effort。其中End-to-end使用了磁盘日志和接受端Ack的方式，保证Flume接受到的数据会最终到达目的。Store on failure在目的不可用的时候，数据会保持在本地硬盘。和End-to-end不同的是，如果是进程出现问题，Store on failure可能会丢失部分数据。Best effort不做任何QoS保证。 2.Scalability ：Flume的3大组件：collector、master和storage tier都是可伸缩的。需要注意的是，Flume中对事件的处理不需要带状态，它的Scalability可以很容易实现。 3.Manageability

Spark Streaming 接任意数据源作为 Stream 问题出发点 工程中遇到流式处理的问题时，多采用Spark Streaming 或者 Storm 来处理；Strom采用Spout的流接入方式，Streaming采用Stream的流接入方式，为了方便本地测试，所以选择了spark streaming，但是官方仅支持如下几种方案，当遇到其他高吞吐数据量作为流时，就需要主角 Receiver 登场： 实现关键类 Receiver ： Receiver是spark内部实现的一套机制，通过自定义一个类继承Receiver即可实现自定义数据源，再通过ssc的receiverStream接口即可实现数据转RDD的操作，即可像Kafka，Flume等正常操作Spark Streaming。本质上通过receiverStream得到的是ReceiverInputDStreaming。 class MyReceiver(storageLevel: StorageLevel) extends NetworkReceiver[String](storageLevel) { def onStart() { // Setup stuff (start threads, open sockets, etc.) to start receiving data. // Must start new