技术专家 专注于大数据领域 博客园地址:https://www.cnblogs.com/yangsy0915/
最近或许有伙伴发现,写技术实现及细节的变少了,更多是经历以及思想、规范。莫非是道则道,非常道,你道我也道?然,并不是:)。 当入行四五年时,个人经历中,从14年开始实习工作到15年转正,各电信项目现场跑,开发、测试、产品部署及支持运维。
随着工作年限的增长,我们从一开始负责一个功能,再到负责一个模块的数据字典及框架设计。再到负责整个系统的需求评审及架构设计。这一路见证着程序猿的成长。但当我们逐步成为一名架构师,或是一名项目管理人员时,会发现一个项目的成功,会牵扯到各式各样的问题及风险。
工作已有四年有余,从最初的亚信 到现在的 阿里。。总结了下思维模式,以个人的视角,供各位干代码的小伙伴们参考,能够深入无论 技术还是业务还是产品的本质。发现其中的规律,更好地把握自己的方向及未来。那么总的来说,我分为四种思维模式: 一、技术思维 卧槽!干代码!出bug了!没错,这就是你进步的源头。
从上一篇对Hive metastore表结构的简要分析中,我再根据数据设计的实体对象,再进行整个代码结构的总结。那么我们先打开metadata的目录,其目录结构: 可以看到,整个hivemeta的目录包含metastore(客户端与服务端调用逻辑)、events(事件目录包含table生命...
今天总结下,Hive metastore的结构设计。什么是metadata呢,对于它的描述,可以理解为数据的数据,主要是描述数据的属性的信息。它是用来支持如存储位置、历史数据、资源查找、文件记录等功能。
有人会问,为啥要用这个叫啥Kudu的,Kudu是啥? 就像官网所说,Kudu是一个针对Apache hadoop 平台而开发的列式存储管理器,在本菜鸟看来,它是一种介于hdfs与hbase的一种存储。
上次写了hive metastore的partition的生命周期,但是简略概括了下alter_partition的操作,这里补一下alter_partition,因为随着项目的深入,发现它涉及的地方较多,比如insert into 时如果路径存在情况下会调用alter_partition,调用insert overwrite语句时,也会调用该方法, 入口依旧是Hive.
最近随着项目的深入,发现hive meta有些弊端,就是你会发现它的元数据操作与操作物理集群的代码耦合在一起,非常不利于扩展。比如:在create_table的时候同时进行路径校验及创建,如下代码: 1 if (!TableType.
不要问我为什么,因为爱,哈哈哈哈。。。进入正题,最近做项目顺带学习了下hive metastore的源码,进行下知识总结。 hive metastore的整体架构如图: 一、组成结构: 如图我们可以看到,hive metastore的组成结构分为 客户端 服务端 ,那么下来我们逐一进行分析: 1、客户端 从代码的角度来看:尼玛太多了。
Hadoop的HDFS可以分为NameNode与DataNode,NameNode存储所有DataNode中数据的元数据信息。而DataNode负责存储真正的数据(数据块)信息以及数据块的ID。 NameNode上并不永久保存哪个DataNode上有哪些数据块的信息,而是通过DataNode启动时的上报,来更新NameNode上的映射表。
最近突然觉得, 很多掌握的都还是很浅的原理,需要更深入细粒度去了解整个分布式系统的运转机制。于是。。开始作死而又作死而又作死的源码之旅。 Hadoop包的功能总共有下列几类: tool:提供一些命令行工具,如DistCp,archive mapreduce,:Hadoop的Map/R...
最近做一个oracle项目迁移工作,跟着spark架构师学着做,进行一些方法的总结。 1、首先,创建SparkSession对象(老版本为sparkContext) val session = SparkSession.builder().appName("app1").getOrCreate() 2、数据的更新时间配置表,选用mysql,就是说每次结果数据计算写入mysql后,还会将此次数据的更新时间写入数据配置表。
最近没怎么写技术博客了。。原因是,跳到了曾经期望的公司,还在做技术储备。。。如今入职一个月了,已经完全进入状态。同时,也带来更多思考与感悟。 我记得第一面,是支付宝的架构师。与他聊了很多关于技术上,性能上,架构与业务上的知识。
1、数据查询 //提高聚合的性能 SET hive.map.aggr=true; SELECT count(*),avg(salary) FROM employees; //木匾不允许在一个查询语句中使用多于一个的函数(DISTINCT。
1、创建表 create table if not exists mydb.employees{ name String COMMENT 'Employee name', salary FLOAT COMMENT 'Empolyee salary', subordinates APP...
帮一个朋友写个样例,顺便练手啦~一直在做平台的各种事,但是代码后续还要精进啊。。。 1 import java.util.Date 2 3 import org.apache.hadoop.
到年底了,想着总结下所有知识点好了~今年应用的知识点还是很多的~ Hadoop生态圈: 1、文件存储当然是选择Hadoop的分布式文件系统HDFS,当然因为硬件的告诉发展,已经出现了内存分布式系统Tachyon,不论是Hadoop的MapReduce,Spark的内存计算、hive的MapReuduce分布式查询等等都可以集成在上面,然后通过定时器再写入HDFS,以保证计算的效率,但是毕竟还没有完全成熟。
要完整去学习spark源码是一件非常不容易的事情,但是咱可以积少成多嘛~那么,Spark Streaming是怎么搞的呢? 本质上,SparkStreaming接收实时输入数据流并将它们按批次划分,然后交给Spark引擎处理生成按照批次划分的结果流: SparkStreaming提供了表示连续数据流的、高度抽象的被称为离散流的Dstream,可以使用kafka、Flume和Kiness这些数据源的输入数据流创建Dstream,也可以在其他Dstream上使用map、reduce、join、window等操作创建Dsteram。
假设客户端分别发送了两个数据包D1和D2给服务器,由于服务器端一次读取到的字节数是不确定的,所以可能发生四种情况: 1、服务端分两次读取到了两个独立的数据包,分别是D1和D2,没有粘包和拆包。 2、服务端一次接收到了两个数据包,D1和D2粘合在一起,被称为TCP粘包。
spark呢,对Netty API又做了一层封装,那么Netty是什么呢~是个鬼。它基于NIO的服务端客户端框架,具体不再说了,下面开始。 创建了一个线程工厂,生成的线程都给定一个前缀名。 像一般的netty框架一样,创建Netty的EventLoopGroup: 在常用...
自己对着源码敲一遍练习,写上注释。发现NIO编程难度好高啊。。虽然很复杂,但是NIO编程的有点还是很多: 1、客户端发起的连接操作是异步的,可以通过在多路复用器注册OP_CONNECTION等待后续结果,不需要像BIO的客户端一样被同步阻塞。
如何能更好的运用与监控sparkSQL?或许我们改更深层次的了解它深层次的原理是什么。之前总结的已经写了传统数据库与Spark的sql解析之间的差别。那么我们下来直切主题~ 如今的Spark已经支持多种多样的数据源的查询与加载,兼容了Hive,可用JDBC的方式或者ODBC来连接Spark SQL。
之前阅读也有总结过Block的RPC服务是通过NettyBlockRpcServer提供打开,即下载Block文件的功能。然后在启动jbo的时候由Driver上的BlockManagerMaster对存在于Executor上的BlockManager统一管理,注册Executor的BlockManager、更新Executor上Block的最新信息、询问所需要Block目前所在的位置以及当Executor运行结束时,将Executor移除等等。
我们又都知道,Spark中任务的处理也要考虑数据的本地性(locality),Spark目前支持PROCESS_LOCAL(本地进程)、NODE_LOCAL(本地节点)、NODE_PREF、RACK_LOCAL(本地机架)、ANY(任何)几种。
shuffle。。。相当重要,为什么咩,因为shuffle的性能优劣直接决定了整个计算引擎的性能和吞吐量。相比于Hadoop的MapReduce,可以看到Spark提供多种计算结果处理方式,对shuffle过程进行了优化。
源码层面整理下我们常用的操作RDD数据处理与分析的函数,从而能更好的应用于工作中。 连接Hbase,读取hbase的过程,首先代码如下: def tableInitByTime(sc : SparkContext,tableName : String,columns : Strin...
我们都知道Spark的每个task运行在不同的服务器节点上,map输出的结果直接存储到map任务所在服务器的存储体系中,reduce任务有可能不在同一台机器上运行,所以需要远程将多个map任务的中间结果fetch过来。
sparkContext创建还没完呢,紧接着前两天,我们继续探索。。作死。。。 紧接着前几天我们继续SparkContext的创建: 接下来从这里我们可以看到,spark开始加载hadoop的配置信息,第二张图中 new出来的Configuration正是hadoop的Configuration。
额,没忍住,想完全了解sparksql,毕竟一直在用嘛,想一次性搞清楚它,所以今天再多看点好了~ 曾几何时,有一个叫做shark的东西,它改了hive的源码。。。突然有一天,spark Sql突然出现,如下图: = =好了,不逗了,言归正传。
紧接着昨天,我们继续开搞了啊。。 1、下面,开始创建BroadcastManager,就是传说中的广播变量管理器。BroadcastManager用于将配置信息和序列化后的RDD、Job以及ShuffleDependency等信息在本地存储。
即日起开始spark源码阅读之旅,这个过程是相当痛苦的,也许有大量的看不懂,但是每天一个方法,一点点看,相信总归会有极大地提高的。那么下面开始: 创建sparkConf对象,那么究竟它干了什么了类,从代码层面,我们可以看到我们需要setMaster啊,setAppName啊,set blabla啊。
环境极其恶劣情况下: import org.apache.spark.SparkContext import org.apache.spark.rdd.RDD import org.apache.spark.
1、代码中尽量避免group by函数,如果需要数据聚合,group形式的为rdd.map(x=>(x.chatAt(0),x)).groupbyKey().mapValues((x=>x.toSet.size)).collection() 改为 rdd.map(x=>(x.chatAt(0),x)).countByKey();或进行reduceByKey,效率会提高3倍。
有许多场景下,我们需要进行跨服务器的数据整合,比如两个表之间,通过Id进行join操作,你必须确保所有具有相同id的数据整合到相同的块文件中。那么我们先说一下mapreduce的shuffle过程。 Mapreduce的shuffle的计算过程是在executor中划分mapper与reducer。
Spark 内部管理机制 Spark的内存管理自从1.6开始改变。老的内存管理实现自自staticMemoryManager类,然而现在它被称之为”legacy”. “Legacy” 默认已经被废弃掉了,它意味着相同的代码在1.5版本与1.6版本的输出结果将会不同。
ZooKeeper是以Fast Paxos算法为基础的,Paxos 算法存在活锁的问题,即当有多个proposer交错提交时,有可能互相排斥导致没有一个proposer能提交成功,而Fast Paxos作了一些优化,通过选举产生一个leader (领导者),只有leader才能提交proposer,具体算法可见Fast Paxos。
数据集成是把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中,从而为企业提供全面的数据共享。 一、模型分类 (1)联邦式数据库系统(Federated Distributed Database System),这种分布式数据库的特点是结点自治和没有全局数据模式,每个结点所看到的数据模式仅仅限于此结点所用到的数据。
DOM和SAX DOM的全称是Document Object Model,也即文档对象模型。基于DOM的XML分析器将一个XML文档转换成一个对象模型的集合,应用程序挣是通过对这个对象模型的操作,来实现对XML文档数据的操作。
给数组赋值:通过fill方法。 对数组排序:通过sort方法,按升序。比较数组:通过equals方法比较数组中元素值是否相等。查找数组元素:通过binarySearch方法能对排序好的数组进行二分查找法操作。
HashMap 一、HashMap基本概念: HashMap是基于哈希表的Map接口的实现。此实现提供所有可选的映射操作,并允许使用null值和null键。此类不保证映射的顺序,特别是它不保证该顺序恒久不变。
最近几个月一直在做基于storm的流式处理,索性整理下所有的知识点与技术知识。 一、数据准备 1、首先,我们需要用户的所有数据,使用MapReduce进行数据处理,生成业务宽表导入hbase与Redis,用于后续实时处理直接从Redis中获取相应数据,减少读写磁盘IO的消耗。
通过算法小组给出的聚合文件,我们需要实现一种业务场景,通过用户的消费地点的商户ID与posId,查询出他所在的商圈,并通过商圈地点查询出与该区域的做活动的商户,并与之进行消息匹配,推送相应活动信息到用户手机。
1.对象的创建 虚拟机遇到一条new指令时,首先会去检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有,则必须先进行相应的类的加载。
package foo; import org.apache.commons.cli.BasicParser; import org.apache.commons.cli.CommandLine; import org.
进程 虽然进程构成了分布式系统中的基本组成单元,但是操作系统提供的用于构建分布式系统的进程在粒度上还是太大了,而就粒度而言,将每个进程细分为若干控制线程的形式则更加合适。 为了程序执行的需要,操作系统创建多个虚拟处理器,每个虚拟处理器运行一个程序。
一、面向消息的持久通信 消息队列系统为持久异步通信提供多种支持,本质是提供消息的中介存储能力,这样就不需要消息发送方和接收方在消息传输过程中都保持激活状态。 消息队列模型 应用程序可以通过在特定队列中插入消息来进行通信。
由于没有存储共享器,分布式系统中的所有通信都是基于底层消息交换的。如果进程A要与进程B通信,A必须首先在自己的地址空间中生成该消息,再执行一个系统调用,通知操作系统将该消息通过网络发送给B。 为了使一组计算机能够通过网络相互通信,它们必须使用相同的协议。
研究生阶段学习的分布式原理与泛型几乎忘完了,当初不怎么懂。。。现在工作中发现大数据技术的底层还是分布式系统,那么重新拾起,总结下~ 一、分布式系统简介 分布式系统是若干独立计算机的集合,这些计算机对于用户来说就像是单个相关系统。
Parquet是面向分析型业务的列式存储格式,由Twitter和Cloudera合作开发,2015年5月从Apache的孵化器里毕业成为Apache顶级项目,那么这里就总结下Parquet数据结构到底是什么样的呢? 一个Parquet文件是由一个header以及一个或多个block块组成,以一个footer结尾。
package com.practice.util; import java.util.HashMap; import java.util.List; import java.util.Map; import java.