数据处理

原文链接：https://mp.weixin.qq.com/s/RT7QNQNQ0NRsAmwUMtw6ig 编者荐语： Spark社区从2.3版本开始，已经可以很好的支持跑着Kubernetes上了。这对于统一资源池，提高整体资源利用率，降低运维成本（特别是技术栈归一）有着非常大的帮助。这些趋势是一个大数据人不得不重视的信号，所以一起提前了解并考虑起来吧！ 以下文章来源于容器魔方 ，作者tsjsdbd 大数据邂逅云计算 相信玩Spark的你已经注意到最新的Spark版本已经支持不做任何修改就可以直接跑在K8s上了，即以Kubernetes容器集群作为Cluster Manager的实现。 其实早在2017年底Spark 2.2版本开始的时候，Spark社区就开始合入用K8s管理Spark集群的能力，只是那时候功能上还没有很完善。加之彼时Kubernetes还没有像现在这么普及，被广泛地接受成为应用基础设施层。经过了2年了持续迭代，Spark on Kubernetes已经成为帅气的小伙，大家可以围观起来了。 其实，大数据和云计算一直分属两个不同的领域。大数据主要关注怎么将数据集中起来，挖掘数据的价值；云计算主要关注怎么更高效地使用资源，提升资源的利用效率。当大数据发展到一定阶段的时候，它就会和云计算不期而遇。 现状并不美丽 在技术层面上

文章是个人阅读《Java8实战》过程中的重点摘抄，可能晦涩，没有示例代码，后续会补充总结完善。 文章目录 本章内容 核心问题 概述 6.1 收集器简介 6.1.1 收集器作用与高级归约 6.2.1 预定义收集器 6.2 归约和汇总 6.2.1 查找流中的最大值最小值： maxBy、minBy 6.2.2 汇总 summingInt、averagingInt、summarizingInt 6.2.3 连接字符串： joining 6.2.4 广义的归约汇总： reducing 归约与收集 根据情况选择最佳方案 6.3 分组： groupingBy 6.3.1 多级分组 6.3.2 按子组收集数据 把收集器的结果转换为两一种类型：groupinBy的重载 与groupingBy联合使用的其他收集器：mapping() 6.4 分区： partitioningBy 6.4.1 分区的优势 Collectors类的静态工厂方法 6.5 收集器接口 6.6 开发收集器 6.7 小节 本章内容 用Collectors类创建和使用收集器 将数据流归约为一个值 汇总：归约的特殊情况 数据分组和分区 开发自己的自定义收集器 核心问题 1.收集器的作用是什么？核心接口是什么？ 2.Collectors常用静态方法的使用。 3.对比reduce和collect两个接口的区别。 4

很多同学是通过学习hadoop来学习大数据的,学习资料可能是以图书为主要参考方向，《hadoop权威指南》的确是一本很好的入门大数据图书，但大数据系统本身是分布式系统，所以我以为分布式系统的相关概念才是掌握大数据各类框架、知识的基础。 1 入门： hadoop框架是集存储(hdfs)、计算(mr计算模型)、资源管理(yarn)等于一体的综合框架，当然它是一个历史的阶段产物，刨除此因我们来看看大家所熟知的wordcount的具体做法(mr)是什么场景下如何进行计算的？ 1-1 分布式系统 首先wordcount程序放到传统单机模式下也可以处理，这里大家一定会想到多线程、文件切割等实现方式，简单来说并行计算的想法由来已久，随着硬件的不断进步、性能不断提升，多核计算也已发展多年了，与此同时这个世界产生的数据更是增长飞速，那么原来单机下多任务多线程的计算方式与其后的多核并行都遇到了一个处理速度与处理数据间严重不匹配的问题，如何提高计算能力是发展的必然，那么集群方式解决了计算资源水平扩展的能力并同时具有并行性，这是目前的核心思想，我们可以理解目前的集群（一个黑盒子）类比于传统单机方式，集群中的节点间并行计算涉及到了主从架构、集群管理、消息通讯、容错处理等等方面，然后这些都是分布式系统所要考虑和解决的问题，因为它本身就是分布式系统。 1-2 分布式存储 刚才简单提到了分布式系统，说到了计算方面

本文始发于个人公众号： TechFlow 近两年AI成了最火热领域的代名词，各大高校纷纷推出了人工智能专业。但其实，人工智能也好，还是前两年的深度学习或者是机器学习也罢，都离不开底层的数据支持。对于动辄数以TB记级别的数据，显然常规的数据库是满足不了要求的。今天，我们就来看看大数据时代的幕后英雄——Hadoop。 Hadoop这个关键词其实有两重含义，最早它其实指的就是单纯的分布式计算系统。但是随着时代的发展，Hadoop系统扩大，如今hadoop已经是成了一个完整的技术家族。从底层的分布式文件系统（HDFS）到顶层的数据解析运行工具（Hive、Pig），再到分布式系统协调服务（ZooKeeper）以及分布式数据库（HBase），都属于Hadoop家族，几乎涵盖了大半大数据的应用场景。在Spark没有流行之前，Hadoop一直是大数据应用中的绝对主流，即使是现在，依旧有大量的中小型公司，还是依靠Hadoop搭建大数据系统。 如今的Hadoop虽然家族庞大，但是早年Hadoop的结构非常简单，几乎只有两块，一块是分布式文件系统，这个是整个数据的支撑，另一个就是MapReduce算法。 分布式文件系统 大数据时代，数据的量级大规模增长，动辄以TB甚至PB计。对于这么海量的数据，如果我们还使用常规的方法是非常困难的。因为即使是 O(n) 的算法，将所有的数据遍历一遍

虽然NoSQL流行语火起来才短短一年的时间，但是不可否认，现在已经开始了第二代运动。尽管早期的堆栈代码只能算是一种实验，然而现在的系统已经更加的成熟、稳定。不过现在也面临着一个严酷的事实：技术越来越成熟——以至于原来很好的NoSQL数据存储不得不进行重写，也有少数人认为这就是所谓的2.0版本。这里列出一些比较知名的工具，可以为大数据建立快速、可扩展的存储库。 1. Casssandra Cassandra 最初由Facebook开发，后来成了Apache开源项目，它是一个网络社交云计算方面理想的数据库。它集成了其他的流行工具如Solr，现在已经成为一个完全成熟的大型数据存储工具。Cassandra是一个混合型的非关系的数据库，类似于Google的BigTable。其主要功能比Dynomite（分布式的Key-Value存储系统）更丰富，但支持度却不如文档存储MongoDB。Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到其他节点上去，而对Cassandra的读操作，也会被路由到某个节点上面去读取。在最近的一次测试中， Netflix建立了一个288个节点的集群 。 2. Lucene/Solr Lucene 是Apache软件基金会4 jakarta项目组的一个子项目

hadoop 集群中有两种节点，一种是namenode，还有一种是datanode。 其中datanode主要负责数据的存储，namenode主要负责三个功能，分别是(1)管理元数据 (2)维护目录树 (3)响应客户请求 首先介绍下，元数据格式 hdfs在外界看来就是普通的文件系统，可以通过路径进行数据的访问等操作，但在实际过程存储中，却是分布在各个节点上。如上图所示，是一条元数据，/test/a.log 是在hdfs文件系统中的路径，3是这个文件的副本数(副本数可以通过在配置文件中的配置来修改的)。在hdfs中，文件是进行分块存储的，如果文件过大，就要分成多块存储，每个块在文件系统中存储3个副本，以上图为例，就是分成blk_1和blk_2两个块，每个块在实际的节点中有3个副本，比如blk_1的3个副本分别存储在h0，h1，h3中。 现在由此引出一个问题，namenode中的元数据是存储在哪里的？首先，我们做个假设，如果存储在namenode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断点，元数据丢失，整个集群就无法工作了！！！因此必须在磁盘中有备份，在磁盘中的备份就是fsImage，存放在namenode节点对应的磁盘中。这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新fsImage

<script type="text/javascript"> //缓存的数据 var selected = [ { id: 09, name: '苹果', price: 3.5,checked:true }, { id: 10, name: '香蕉', price: 4.1,checked:true}, { id: 11, name: '橘子', price: 4.6,checked:true} ] //新数据[从后台获取的数据] var product = [ { id: 09, name: '苹果', price: 3.5,checked:false }, { id: 10, name: '香蕉', price: 4.1, checked:false}, { id: 11, name: '橘子', price: 4.6, checked:false}, { id: 12, name: '葡萄', price: 8.6, checked:false}, { id: 13, name: '猕猴桃', price: 7.6, checked:false} ] //.进入当前页面拿缓存数据和新数据（从后台获取的数据）进行对比，然后进行对比渲染 function arrToJson(arr,obj={}){ arr.forEach((item)=>{ // console.log(

1.hadoop是什么？ hadoop之父是Doug Cutting。是由很多技术框架组成的生态系统，包括数据库（nosql）。Apache开源框架集群，做分布式计算和离线运算、实时运算。 受Google三篇论文启发出现的。（GFS、MapReduce、Big Table数据库） GFS、MapReduce、Hbase 搜索引擎的原理？ 爬虫和搜索。一般称为搜索引擎。称为站内搜索。 2.解决问题？ ·海量数据的存储（HDFS） ·海量数据的分析模型（MapReduce） ·资源管理调度（YARN）：从MapReduce中分离出来的。 狭义的hadoop：由HDFS和MapReduce组成。 spark、storm；运算框架 3.场景1：假设myqsl中有几十个T的数据。 在hadoop中，一般的解决方式是把mysql中的记录导出为文本文件。或者生成为文本文件。再对本文件进行处理。 hive认识sql语句。 4.Hadoop具体能干什么？ 狭义hadoop擅长海量离线日志分析。 广义hadoop擅长海量离线日志分析、在线实时日志分析、海量数据的存储等。 5.怎样解決海量数据的存储？ ①怎样解决存储？ NFS系统：通过节点的文件夹或文件的共享实现大数据量的存储。可以通过文件共享的协议，把很多节点上面的相关文件夹进行共享， 在另外一台机器上进行挂载。挂载到本地某个目录下面

1.前言 数据处理大概分为两个类型，联机事务处理(OLTP)和联机分析处理(OLAP) OLTP是 online Transaction processing ， 联机事务处理系统。主要目标是数据的处理，而不是数据的分析。OLTP系统的主要关注点是记录事务当前的更新，增加，删除等操作，类似于对MySQL数据库的操作。OLTP的查询比较简短，需要比较少的处理时间和较少的空间。 OLAP是 On-Line Analytical Processing ，联机分析处理系统。OLAP主要目标是数据分析而不是数据处理。允许用户查看不同维度的数据，可以从大型数据库中提取信息并进行分析来做决策。 2.OLTP 我们常说的 数据库 存储的是实时的业务数据，设计是为了业务的读写 它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。 高并发处理业务的时候，出现的瓶颈是CPU与磁盘子系统。常见的优化方式是Cache技术和优化索引。 应用在常见的网站业务上 3.OLAP 我们常说的 数据仓库 存储的多为历史数据，设计是为了分析大量的数据 一般针对某些主题的历史数据进行分析，支持管理决策。 在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽） 应用场景

Spark是一种分布式计算框架，对标Hadoop的MapReduce；MapReduce适用于离线批处理（处理延迟在分钟级）而Spark既可以做离线批处理，也可以做实时处理（SparkStreaming） 　　①Spark集批处理、实时流处理、交互式查询、机器学习与图计算一体 　　②Spark实现了一种分布式的内存抽象，称为弹性分布式数据集；RDD允许用户在执行多个查询时显式地将工作集缓存在内存中，后续的查询能够重用工作集，极大提升了查询速度。 一个Hadoop的Job通常经过以下几个步骤： 　　①从HDFS中读取输入数据 　　②在Map阶段使用用户定义的mapper function，然后将结果spill到磁盘 　　③在Reduce阶段从各个处于Map阶段的机器读取Map计算的中间结果，使用用户自定义的reduce function，通常最后把结果写回HDFS 　　Hadoop的问题在于，一个Hadoop Job会进行多次磁盘读写，比如写入机器本地磁盘，或是写入分布式文件系统中（这个过程包含磁盘的读写以及网络传输）。考虑到磁盘读取比内存读取慢了几个数量级，所以像Hadoop这样高度依赖磁盘读写的架构就一定会有性能瓶颈；而且有些场景比如一些迭代性质的算法（逻辑回归）会重复利用某些Job的结果，导致触发重新计算带来大量的磁盘I/O。 Spark没有像Hadoop那样使用磁盘读写