<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[xiaolang85的专栏]]></title><description><![CDATA[]]></description><link>https://blog.csdn.net/xiaolang85</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; xiaolang85]]></copyright><item><title><![CDATA[如何选择分布式事务形态（TCC，SAGA，2PC，基于消息最终一致性等等）]]></title><link>https://blog.csdn.net/xiaolang85/article/details/85759536</link><guid>https://blog.csdn.net/xiaolang85/article/details/85759536</guid><author>xiaolang85</author><pubDate>Fri, 04 Jan 2019 10:18:41 +0800</pubDate><description><![CDATA[各种形态的分布式事务

分布式事务有多种主流形态，包括：

基于消息实现的分布式事务
	基于补偿实现的分布式事务
	基于TCC实现的分布式事务
	基于SAGA实现的分布式事务
	基于2PC实现的分布式事务
这些形态的原理已经在很多文章中进行了剖析，用“分布式事务”关键字就能搜到对应的文章，本文不再赘述这些形态的原理，并将重点放在如何根据业务选择对应的分布式事务形态上。

何时选择单机事务？

这个...]]></description><category></category></item><item><title><![CDATA[Kafka Offset Storage]]></title><link>https://blog.csdn.net/xiaolang85/article/details/79886029</link><guid>https://blog.csdn.net/xiaolang85/article/details/79886029</guid><author>xiaolang85</author><pubDate>Tue, 10 Apr 2018 19:14:34 +0800</pubDate><description><![CDATA[1.概述　　目前，Kafka 官网最新版[0.10.1.1]，已默认将消费的 offset 迁入到了 Kafka 一个名为 __consumer_offsets 的Topic中。其实，早在 0.8.2.2 版本，已支持存入消费的 offset 到Topic中，只是那时候默认是将消费的 offset 存放在 Zookeeper 集群中。那现在，官方默认将消费的offset存储在 Kafka 的Top...]]></description><category></category></item><item><title><![CDATA[AWK与SHELL之间的变量传递方法]]></title><link>https://blog.csdn.net/xiaolang85/article/details/79884535</link><guid>https://blog.csdn.net/xiaolang85/article/details/79884535</guid><author>xiaolang85</author><pubDate>Tue, 10 Apr 2018 17:27:21 +0800</pubDate><description><![CDATA[我认为在linux下awk是个好东东啊，处理一些文本文件会非常方便。而在Linux下嘛，经常会和shell打交道，所以awk和shell之间的变量相互传递，有时还是很有必要的，所以简单总结一下吧。 awk中使用shell中的变量一: &quot;'$var'&quot;这种写法大家无需改变用'括起awk程序的习惯,是老外常用的写法.如:var=&quot;test&quot;awk 'BEGIN{print &quot;'$var'&quot;}'这种写法...]]></description><category></category></item><item><title><![CDATA[Spark Streaming 流计算优化记录(1)-背景介绍]]></title><link>https://blog.csdn.net/xiaolang85/article/details/79820676</link><guid>https://blog.csdn.net/xiaolang85/article/details/79820676</guid><author>xiaolang85</author><pubDate>Wed, 04 Apr 2018 17:55:15 +0800</pubDate><description><![CDATA[1.背景概述业务上有一定的需求, 希望能实时地对从中间件进来的数据已经已有的维度表进行inner join, 以便后续的统计. 维表十分巨大, 有近3千万记录,约3G数据, 而集群的资源也较紧张, 因此希望尽可能压榨Spark Streaming的性能和吞吐量.技术架构大致上如下述: 数据从Kafka流入, SparkStreaming 会从HDFS中拿到维度表的数据, 与流入的消息进行计算, 最...]]></description><category></category></item><item><title><![CDATA[Spark Streaming 流计算优化记录(2)-不同时间片数据流的Join]]></title><link>https://blog.csdn.net/xiaolang85/article/details/79820664</link><guid>https://blog.csdn.net/xiaolang85/article/details/79820664</guid><author>xiaolang85</author><pubDate>Wed, 04 Apr 2018 17:54:26 +0800</pubDate><description><![CDATA[1. 不同时间片数据流的Join         初体验之后, 看了一下Spark WebUi 的日志, 发现由于Spark Streaming需要每秒跑一次, 以实时计算数据, 所以程序不得不每秒都读一次HDFS去获取数据进行inner join.         本来SparkStreaming会对其进行处理的数据进行缓存, 以减少IO和提高计算速度的, 但由于现在我们的场景是要把每秒都有新数...]]></description><category></category></item><item><title><![CDATA[Spark Streaming 流计算优化记录(3)-控制流量与join的地点]]></title><link>https://blog.csdn.net/xiaolang85/article/details/79820657</link><guid>https://blog.csdn.net/xiaolang85/article/details/79820657</guid><author>xiaolang85</author><pubDate>Wed, 04 Apr 2018 17:53:37 +0800</pubDate><description><![CDATA[4. 流量控制好像之前说过”一下子从Kafka拉取几十万条消息进行处理”的事情, 其实酱紫是不对滴, 饭要一口一口吃, 一下子吃太多, 会导致还没吃成胖子就已经被撑死的. 所以我们要对为了做压力测试而早已在Kafka中囤积多时的几十万条消息分批次进行处理, 毕竟实际跑起的时候每秒拥入我们知道, Spark Streaming进行流处理的原理是micro batch, 即把每秒或每几秒这个时间窗口内...]]></description><category></category></item><item><title><![CDATA[Spark Streaming 流计算优化记录(4)-时间都去哪儿了,关于调度与空转]]></title><link>https://blog.csdn.net/xiaolang85/article/details/79820643</link><guid>https://blog.csdn.net/xiaolang85/article/details/79820643</guid><author>xiaolang85</author><pubDate>Wed, 04 Apr 2018 17:52:50 +0800</pubDate><description><![CDATA[6. 时间都去where了,青春不能等,调度也是除了上述优化, 我们还注意到一个奇怪的现象: 怎么回事, 即使接收不到消息都要花掉5秒?!! 虽然Spark Streaming空转依然会产生空task, 这些空task依然会消耗序列化, 压缩, 调度等时间, 但也不至于那么多吧!!!我们拿一个Stage看看, 就拿处理Kafka消息的那个Stage作例子吧: Kafka没有任何消息进来的情况下, ...]]></description><category></category></item><item><title><![CDATA[Spark Streaming 流计算优化记录(5)-分区与内存的优化]]></title><link>https://blog.csdn.net/xiaolang85/article/details/79819499</link><guid>https://blog.csdn.net/xiaolang85/article/details/79819499</guid><author>xiaolang85</author><pubDate>Wed, 04 Apr 2018 16:45:16 +0800</pubDate><description><![CDATA[8. 不一定非得每秒处理一次由于Spark Streaming的原理是micro batch, 因此当batch积累到一定数量时再发放到集群中计算, 这样的数据吞吐量会更大些. 这需要在StreamingContext中设置Duration参数. 我们试着把Duration调成两秒, 这样Spark就会在接收Kafka的模块中积累了2秒的数据后, 在调度作业到集群中计算.结合上述做过的优化, 跑了...]]></description><category></category></item><item><title><![CDATA[Spark Streaming 流计算优化记录(6)-GC优化与shuffle service]]></title><link>https://blog.csdn.net/xiaolang85/article/details/79818840</link><guid>https://blog.csdn.net/xiaolang85/article/details/79818840</guid><author>xiaolang85</author><pubDate>Wed, 04 Apr 2018 16:10:31 +0800</pubDate><description><![CDATA[11. Spark应用的GC调优说到GC, 可能很多人都倾向于使用新潮的G1垃圾收集器, 特别是intel的那几个兄弟在databrick发表了篇用G1调优Spark应用的博文后, 就更多人热衷于尝试G1了.但其实我们再去年就对G1和老牌的CMS+NewPar进行过对比测试, 发现G1根本没有比CMS好, 有时候还会导致更多的FullGC, 而实际上连Oracle官方都觉得G1还没有product...]]></description><category></category></item><item><title><![CDATA[学习Spark2.0中的Structured Streaming（一）]]></title><link>https://blog.csdn.net/xiaolang85/article/details/79667743</link><guid>https://blog.csdn.net/xiaolang85/article/details/79667743</guid><author>xiaolang85</author><pubDate>Fri, 23 Mar 2018 15:04:56 +0800</pubDate><description><![CDATA[Spark2.0新增了Structured Streaming，它是基于SparkSQL构建的可扩展和容错的流式数据处理引擎，使得实时流式数据计算可以和离线计算采用相同的处理方式（DataFrame&amp;amp;SQL）。Structured Streaming顾名思义，它将数据源和计算结果都映射成一张”结构化”的表，在计算的时候以结构化的方式去操作数据流，大大方便和提高了数据开发的效率。Spark2...]]></description><category></category></item><item><title><![CDATA[spark JVM调优之原理概述以及降低cache操作的内存占比]]></title><link>https://blog.csdn.net/xiaolang85/article/details/78460206</link><guid>https://blog.csdn.net/xiaolang85/article/details/78460206</guid><author>xiaolang85</author><pubDate>Mon, 06 Nov 2017 17:57:43 +0800</pubDate><description><![CDATA[每一次放对象的时候，都是放入eden区域，和其中一个survivor区域；另外一个survivor区域是空闲的。


当eden区域和一个survivor区域放满了以后（spark运行过程中，产生的对象实在太多了），就会触发minor gc，小型垃圾回收。把不再使用的对象，从内存中清空，给后面新创建的对象腾出来点儿地方。


清理掉了不再使用的对象之后，那么也会将存活下来的对象（还要继]]></description><category></category></item><item><title><![CDATA[spark性能调优（三）shuffle的map端内存缓冲reduce端内存占比]]></title><link>https://blog.csdn.net/xiaolang85/article/details/78458298</link><guid>https://blog.csdn.net/xiaolang85/article/details/78458298</guid><author>xiaolang85</author><pubDate>Mon, 06 Nov 2017 15:39:31 +0800</pubDate><description><![CDATA[性能优化 shuffle


spark.shuffle.file.buffer，默认32k
spark.shuffle.memoryFraction，0.2


map端内存缓冲，reduce端内存占比；很多资料、网上视频，都会说，这两个参数，
是调节shuffle性能的不二选择，很有效果的样子，实际上，不是这样的。


以实际的生产经验来说，这两个参数没有那么重要，往往来]]></description><category></category></item><item><title><![CDATA[Spark的性能调优]]></title><link>https://blog.csdn.net/xiaolang85/article/details/78457833</link><guid>https://blog.csdn.net/xiaolang85/article/details/78457833</guid><author>xiaolang85</author><pubDate>Mon, 06 Nov 2017 15:05:33 +0800</pubDate><description><![CDATA[基本概念和原则

首先，要搞清楚Spark的几个基本概念和原则，否则系统的性能调优无从谈起：




每一台host上面可以并行N个worker，每一个worker下面可以并行M个executor，task们会被分配到executor上面去执行。Stage指的是一组并行运行的task，stage内部是不能出现shuffle的，因为shuffle的就像篱笆一样阻止了并行task的运行，]]></description><category></category></item><item><title><![CDATA[ganglia配置文件详解]]></title><link>https://blog.csdn.net/xiaolang85/article/details/78395426</link><guid>https://blog.csdn.net/xiaolang85/article/details/78395426</guid><author>xiaolang85</author><pubDate>Mon, 30 Oct 2017 17:44:46 +0800</pubDate><description><![CDATA[本文主要介绍了Ganglia 的gmetad和gmond的配置文件

Gmetad

gmetad（Ganglia Meta Daemon）是一种安装在主机上用来收集和汇聚gmond所收集的指标数据的守护进程。gmetad默认使用RRD文件收集和汇聚指标数据，也可以通过配置gmetad将指标数据转送到诸如Graphite的外部系统。
gmetad通过tcp端口8651侦听远程gmetad]]></description><category></category></item><item><title><![CDATA[布隆过滤器(Bloom Filter)详解]]></title><link>https://blog.csdn.net/xiaolang85/article/details/78062734</link><guid>https://blog.csdn.net/xiaolang85/article/details/78062734</guid><author>xiaolang85</author><pubDate>Fri, 22 Sep 2017 14:39:23 +0800</pubDate><description><![CDATA[布隆过滤器［1］（Bloom Filter）是由布隆（Burton Howard Bloom）在1970年提出的。它实际上是由一个很长的二进制向量和一系列随机映射函数组成，布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率（假正例False
 positives，即Bloom Filter报告某一元素存在于某集合中，但是实际上]]></description><category></category></item><item><title><![CDATA[G1垃圾回收器调优]]></title><link>https://blog.csdn.net/xiaolang85/article/details/77994510</link><guid>https://blog.csdn.net/xiaolang85/article/details/77994510</guid><author>xiaolang85</author><pubDate>Fri, 15 Sep 2017 18:21:31 +0800</pubDate><description><![CDATA[了解如何针对评估、分析和性能来调整和调优 G1 GC。
2013 年 8 月发布
垃圾优先型垃圾回收器 (G1 GC) 是适用于 Java HotSpot VM 的低暂停、服务器风格的分代式垃圾回收器。G1 GC 使用并发和并行阶段实现其目标暂停时间，并保持良好的吞吐量。当 G1 GC 确定有必要进行垃圾回收时，它会先收集存活数据最少的区域（垃圾优先）。
垃圾回收器 (GC) 是一个内存管理]]></description><category></category></item><item><title><![CDATA[Hbase集群运维及应用性能优化总结（hbase1.20+）]]></title><link>https://blog.csdn.net/xiaolang85/article/details/77371599</link><guid>https://blog.csdn.net/xiaolang85/article/details/77371599</guid><author>xiaolang85</author><pubDate>Fri, 18 Aug 2017 16:20:53 +0800</pubDate><description><![CDATA[（一）. 操作系统 
     
      1. 足够大的内存


      2. 操作系统64位，jdk64位


      3. 设置linux swap空间的swappiness=0
   
          a1. 永久有效设置（需系统重启） sudo
vim /etc/sysctl.conf 在这个文档的最后加上这样一行:
　　             v]]></description><category></category></item><item><title><![CDATA[phoenix-4.8.0本地索引实现原理]]></title><link>https://blog.csdn.net/xiaolang85/article/details/77100247</link><guid>https://blog.csdn.net/xiaolang85/article/details/77100247</guid><author>xiaolang85</author><pubDate>Fri, 11 Aug 2017 16:58:14 +0800</pubDate><description><![CDATA[1. 前言

phoenix有全局索引以及本地索引（可变与不可变等其它的且不谈），全局索引理解应该比较简单，如果让我自己去实现Hbase的索引应该想到的也是全局索引这种方式。本地索引适用于写比较频繁，储存空间受限的情况。


Local indexing targets write heavy, space constrained use cases.


phoenix-4.8.]]></description><category></category></item><item><title><![CDATA[phoenix-4.8.0整合hbase-1.2.0-cdh5.8.0]]></title><link>https://blog.csdn.net/xiaolang85/article/details/77100175</link><guid>https://blog.csdn.net/xiaolang85/article/details/77100175</guid><author>xiaolang85</author><pubDate>Fri, 11 Aug 2017 16:53:18 +0800</pubDate><description><![CDATA[1. 前言

phoenix-4.8.0版本已经出了挺长一段时间了，之前一直有用开4.6版本，不过4.6版本的本地索引还不成熟，而且也存在着一些bug，在网上找到一些对旧版本的本地索引的描述


APPROACH 1 is a good start for local indexes, but I think we are not getting the full benefits fo]]></description><category></category></item><item><title><![CDATA[HBase应用设计性能优化方法总结]]></title><link>https://blog.csdn.net/xiaolang85/article/details/77070208</link><guid>https://blog.csdn.net/xiaolang85/article/details/77070208</guid><author>xiaolang85</author><pubDate>Thu, 10 Aug 2017 18:41:19 +0800</pubDate><description><![CDATA[本文主要是从HBase应用程序设计与开发的角度，总结几种常用的性能优化方法。有关HBase系统配置级别的优化，这里涉及的不多，这部分可以参考：淘宝Ken
 Wu同学的博客。

[转发者注明： 关于使用多线程去读取hbase全表数据，推荐先将rowkey根据线程的个数划分为多段，然后将每段 start-key ~ end-key丢给线程去执行！]

1. 表的设计

1.1 Pre-C]]></description><category></category></item></channel></rss>