消费组应该算是kafka中一个比较有特色的设计模式了，而他的重平衡机制也是我们在实际生产使用中，无法避免的一个问题。消费组Consumer Group为kafka提供了可扩展、高容错特性的消费者机制。简单介绍下，大致有以下特点：一个Consumer Group内可以有多个Consumer实例，该实例可以是一个进程，也可以是进程下的多线程每个Consumer Group有一个唯一标识的Group ID不同Consumer Group之间相互独立，互不影响Consumer Group内实例，与订阅的topic分区关系是一对一，或一对多的关系，Consumer Group会通过Coordinator尽量保持公平分配理想情况下，我们应该设置Consumer实例的数量等于该Group订阅topic的分区总数，可以最大发挥消费性能。若设置的Consumer实例数少于订阅的分区数，则会为每个Consumer实例分配多个分区，消费性能会有所下降。若设置的Consumer实例数大于订阅的分区数，则会为每个Consumer实例分配 1 个分区进行消费，多余的Consumer实例则会闲置，只会浪费资源。重平衡重平衡（Rebalance）就是让一个Consumer Group下所有的Consumer实例,合理分配消费订阅topic的所有分区的过程。有 3 种情况会触发Consumer Group的Reba ...继续阅读 (12)

1.CPU sys 上涨背景配置机型 A机型 BCPU48C48CMEM8*32G12*16GDATA DISK12*960G SSD12*4T SSD线上某个kafka集群由于种种原因，从 24 * 机型 A 置换迁移为 12 * 机型 B。从集群总资源维度看，排除其他客观因素，置换后，CPU总核数少了一半，使用率上升其实也是预期之内的。事实上置换后，集群CPU使用率确实也由原有的 20%提升至 40%，上升了约 1 倍多。但置换后，cpu sys使用率均值约达到了 12%，较为抢眼，系统相关服务却并无异常，令人有些困惑。这个问题其实并不难解释，先说结论，因为kafka数据操作会优先在PageCache中进行，导致读写磁盘数据时是系统内核线程去操作而非用户应用层面，所以单机数据读写压力上涨后，系统内核线程的繁忙就表现为cpu sys上涨，甚至比cpu user使用还来的明显。今天就借此和大家探讨下，kafka高吞吐性能的核心之一—PageCache。2.kafka 消息存储kafka的存储设计和一般的存储设计理念也差不多，都是分缓存，持久化层，缓存数据尽量放内存，持久化数据就会考虑多副本且落盘。一般的应用引擎设计都会考虑自己来实现缓存及写盘这一套逻辑，kafka的不同之处在于他并没有自己在内存中创建缓冲区，然后再实现向磁盘write的一系列方法，而是直接站在巨人们的肩膀上，使用了 ...继续阅读 (10)

之前和大家聊过kafka是如何保证消息不丢失的，今天再讲讲在不丢消息的同时，如何实现精确一次处理的语义实现。消息组件对消息的可靠性保障，常见的模式有3种：最多一次(at most once)：消息可能会丢失，但不会重复至少一次(at least once)：消息不会丢失，但有可能重复精确一次(exactly once)：消息不会丢失，且不会重复，精准一次发送kafka默认情况下，提供的是至少一次的可靠性保障。即broker保障已提交的消息的发送，但是遇上某些意外情况，如：网络抖动，超时等问题，导致Producer没有收到broker返回的数据ack，则Producer会继续重试发送消息，从而导致消息重复发送。相应的，如果我们禁止Producer的失败重试发送功能，消息要么写入成功，要么写入失败，但绝不会重复发送。这样就是最多一次的消息保障模式。但对于消息组件，排除特殊业务场景，我们追求的一定是精确一次的消息保障模式。kafka通过幂等性（Idempotence）和事务（Transaction）的机制，提供了这种精确的消息保障。幂等这里就不多说幂等的含义了，不清楚的自己查下资料。Producer默认不是幂等性的，向分区发送数据时，可能会出现同一条消息被发送多次导致消息重复的情况。但只需增加一些参数，即可开启幂等性。123props.put(“enable.idempotence”, ...继续阅读 (7)

今天和大家聊一下，kafka对于消息的可靠性保证。作为消息引擎组件，保证消息不丢失，是非常重要的。那么kafka是如何保证消息不丢失的呢？前提条件任何消息组件不丢数据都是在特定场景下一定条件的，kafka要保证消息不丢，有两个核心条件。第一，必须是已提交的消息，即committed message。kafka对于committed message的定义是，生产者提交消息到broker，并等到多个broker确认并返回给生产者已提交的确认信息。而这多个broker是由我们自己来定义的，可以选择只要有一个broker成功保存该消息就算是已提交，也可以是令所有broker都成功保存该消息才算是已提交。不论哪种情况，kafka只对已提交的消息做持久化保证。第二，也就是最基本的条件，虽然kafka集群是分布式的，但也必须保证有足够broker正常工作，才能对消息做持久化做保证。也就是说kafka不丢消息是有前提条件的，假如你的消息保存在 N 个kafka broker上，那么这个前提条件就是这 N 个broker中至少有 1 个存活。只要这个条件成立，kafka就能保证你的这条消息永远不会丢失。如何保证消息不丢一条消息从产生，到发送到kafka保存，到被取出消费，会有多个场景和流程阶段，可能会出现丢失情况，我们聊一下kafka通过哪些手段来保障消息不丢。生产端Producer端可能会丢失消息 ...继续阅读 (9)

今天继续和大家聊一下，kafka的各种发行版。kafka历经数年的发展，从最初纯粹的消息引擎，到近几年开始在流处理平台生态圈发力，衍生出了各种不同特性的版本。你了解几种kafkakafka的确有好几种，这里我不是指他的版本，是指存在多个组织或公司发布不同特性的kafka。你应该听说过Linux发行版，比如我们熟知的CentOS、RedHat、Ubuntu等，它们都是Linux系统，其实就是因为它们是不同公司发布的Linux系统，即不同的发行版。kafka也同样有多个发行版。Apache KafkaApache Kafka是最“正统”的kafka，也应该是你最熟悉的发行版了。自kafka开源之初，它便在Apache基金会孵化并最终毕业成为顶级项目，也被称为社区版kafka。重要的是，它是后面其他所有发行版的基础。也就是说，后面提到的其他发行版，要么是原封不动地继承了Apache Kafka，要么是在此之上扩展了新功能，总之Apache Kafka是我们学习和使用kafka的基础。Cloudera/Hortonworks KafkaCloudera提供的CDH和Hortonworks提供的HDP是最常见的大数据平台，里面集成了目前主流的大数据框架，能够帮助用户实现从分布式存储、集群调度、流处理到机器学习、实时数据库等全方位的数据处理。我了解到很多创业公司在搭建数据平台时首选就是这两个产 ...继续阅读 (10)

上篇文章我们了解到，如果一个topic分区越多，理论上整个集群所能达到的吞吐量就越大。那么，分区数越多就越好吗？显然不是。今天我们来聊下kafka在分区数过多的情况下，会带来哪些弊端。内存开销客户端producer有个参数batch.size默认为16KB。它会为每个分区缓存消息，一旦批次数满了后，将消息批量发出。一般来说，这个设计是用于提升吞吐性能的。但是由于这个参数是partition级别的，如果分区数越多，这部分缓存所需的内存占用也会越多。假如有10000个分区，按照默认配置，这部分缓存就要占用约157MB的内存。而consumer端呢？抛开拉取数据所需的内存不说，单说线程的开销。如果还是10000个分区，同时consumer线程数要匹配分区数的话(大部分情况下是最佳的消费吞吐量配置)，那么在consumer client就要创建10000个线程，也需要创建大约10000个Socket去获取分区数据，这里面的线程切换的开销本身就已经不容小觑了。服务器端的开销也不小，如果阅读kafka源码的话就会发现，服务器端的很多组件在内存中维护了partition级别的缓存，比如controller，FetcherManager等，因此分区数越多，这种缓存的成本就越大。文件句柄开销每个分区在文件系统上会对应一个目录，用于存储维护kafka数据日志。该目录通常会有3个文件，.log，.ind ...继续阅读 (10)

分区(partition)概念要讲kafka分区数和吞吐量的关系，首先得理解什么是分区(partition)。Partition是作用于具体的Topic而已的，而不是一个独立的概念。Partition能水平扩展客户端的读写性能，是高吞吐量的保障。通俗的讲，Partition就是一块保存具体数据的空间，本质就是磁盘上存放数据的文件夹，所以Partition是不能跨Broker存在的，也不能在同一个Broker上跨磁盘。对于一个Topic，可以根据需要设定Partition的个数。数据持久化时，每条消息都是根据一定的分区规则路由到对应的Partition中，并append在log文件的尾部(这一点类似于HDFS)，如上图；在同一个Partition中消息是顺序写入的且始终保持有序性；但是不同Partition之间不能保证消息的有序性(高吞吐量的保障)。kafka就是通过使用分区的设计将topic的消息打散到多个分区分布保存在不同的broker上，实现了producer和consumer消息处理的高吞吐量。吞吐量关系在kafka中，Partition并不是最小的数据存储单元。Partition下还可以细分成Segment，每个Partition是由一个或多个Segment组成。但patition是kafka并行操作的最小单元。在producer和broker端，向每一个分区写入数据是可以 ...继续阅读 (12)

生产环境kafka集群，在数据量大的情况下，会出现单机各个磁盘间的占用不均匀情况，经常出现“一边倒”的情形。原因探究这是因为kafka只保证分区数量在各个磁盘上均匀分布，但它无法统计每个分区实际占用磁盘空间。因此很有可能出现某些分区消息数量巨大导致占用大量磁盘空间的情况。在1.1版本之前，用户对此基本没有优雅的处理方法，即便手动迁移日志文件和offset信息，也需要重启生效，风险极高。因为1.1之前kafka只支持分区数据在不同broker间的重分配，而无法做到在同一个broker下的不同磁盘间做重分配。1.1版本正式支持副本在不同路径间的迁移，具体的实现细节详见kafka官方wikiKIP-113。目录间迁移步骤假设我在server.properties文件中配置了多个日志存储路径(代表多块磁盘)，如下所示：123# A comma seperated list of directories under which to store log fileslog.dirs=/data1/kafka-logs,/data2/kafka-logs,/data3/kafka-logs然后我创建了一个9分区的topic，并发送了900W条消息。查询这些目录发现Kafka均匀地将9个分区分布到这三个路径上，如下所示：1234567891011121314> ll /data1/kafka-lo ...继续阅读 (20)

生产环境的kafka集群扩容，是一个比较常见的需求和操作。然而kafka在新增节点后并不会像elasticsearch那样感知到新节点加入后，自动将数据reblance到整个新集群中，因此这个过程需要我们手动分配。分区重分配方案扩容后的数据均衡，其本质就是对topic进行分区重分配，数据迁移的过程。在执行分区重分配的过程中，对集群的影响主要有两点：分区重分配主要是对topic数据进行Broker间的迁移，因此会占用集群的带宽资源；分区重分配会改变分区Leader所在的Broker，因此会影响客户端。针对以上两点，第一点可以在晚间业务低峰时操作，必要时还可以和业务沟通，临时缩短数据保存时间，加快迁移，减少带宽影响时间。针对第二点，有两个方案：整个分配方案分成两个步骤：1）手动生成分配方案，原有分区Leader位置不改变，只对副本进行分区重分配；2）等待数据迁移完成后，再手动更改分区分配方案，目的是均衡Leader。直接用Kafka官方提供的分区重新分配工具生成分区重分配方案，直接执行分区重分配。重分配方案分析方案一方案一理论对客户端影响最小，把整个分配方案分成了两个步骤，也就是将对集群的带宽资源与客户端的影响分开了，对过程可控性很高。但问题是，如果集群中的某些topic，比如有64个分区，3副本，共192个副本，就需要在保持原有分区Leader位置不变的情况下，手动均衡其余副本，这个 ...继续阅读 (7)

通过之前一系列的文章叙述，想必大家都对dr.elephant有了一个较为清晰的了解。通过自己线上经验的积累，以及和一些读者的交流，我汇总了一些大家在实战中遇到的问题和解决方案。常规问题由于在和读者交流的过程中，发现大家技术水平参差不齐，本着科普性文章的初衷，这里先讲一些比较基础的要点，大佬们可以忽略，直接跳过。在打包时，需要对照自己的Hadoop或者Spark版本，修改compile.conf文件中的版本号。否则有可能出现采集不到集群作业信息的情况。最好将自己Hadoop集群的相关配置文件都拷贝到dr.elephant的app-conf目录下。统一自己Hadoop集群的环境变量。数据库问题Database ‘default’ is in an inconsistent state!启动失败并出现这个报错，一般是play框架的evolution问题，解决方法如下：停止dr.elephant并确保进程已kill删除原来的数据库并重新建库配置app-conf/elephant.conf中jvm_props="-Devolutionplugin=enabled -DapplyEvolutions.default=true"，开启evolution，使其能够自动初始化表结构。Specified key was too long; max key length is 767 bytes [ER ...继续阅读 (7)

你可以使用Dr. Elephant来分析你的作业（只需在搜索页贴入你的作业ID），就可以知道你的作业有哪些地方需要优化。加速你的作业流一般对于特定的作业，最好有自己的配置。大多数情况下，作业的默认配置无法提供最佳性能。尽管作业调优比较费劲，但一些简单的调整往往也能带来不错的效果。需要特别注意的是mapper和reducer的数量，io和内存使用的配置，以及生成的文件数量。对这几个参数进行调整，让参数更适合当前的任务，可以极大的提升任务的执行性能。Apache的官网中Hadoop Map/Reduce Tutorial这篇文章提供很多详细且有用的调试建议，有兴趣的可以仔细看看。常规建议逐步调优很重要对于Pig作业来说，如果使用默认参数来设置reducer的数量，这对作业的性能可能是致命的。一般来说，对每个Pig作业，都花一些时间来调优参数PARALLEL是非常值得做的。例如：1memberFeaturesGrouped = GROUP memberFeatures BY memberId PARALLEL 90;文件数vs块数量为了防止NameNode崩溃，存大文件比小文件更合理。NameNode每存储一个文件大概消耗70 bytes，每存储一个块大概消耗60 byte。一般情况下，对于任务来说，使用一个较大的文件要比使用十个小文件的效率高一些。在大规模集群下，这10 byte的差距 ...继续阅读 (11)

目标Dr.Elephant这个项目是希望构建一个可以自动优化hadoop mapreduce相关函数的调优框架。在这种情况下，是为了函数消耗最少的资源来完成作业。我们还希望在未来的版本将作业时间也作为函数资源消耗的参考指标。我们使用迭代算法和粒子群优化算法进行自动调优。这些迭代通过分析作业的多次运行结果来完成，我们已经在15-20次的作业中优化了20-30%的资源。自动优化从作业的默认参数开始，并且在每次运行之后计算判断当前参数是否适合，并且根据算法建议新的参数。为了与Dr.Elephant交互，开发了getCurrentRunParameters新API，它返回给定作业当前运行的参数。组件守护进程自动调优模块中有以下4个守护进程：基线计算：该Daemon通过Dr.Elephant的历史数据平均值来计算新作业应当消耗的资源和时间作业完成检查器：一旦修改了新的调优参数来执行作业，该Daemon将继续轮询作业直到完成。对于Azkaban调度器则使用Azkaban rest API打分器（Fitness Computation Daemon）：一旦作业完成（成功/失败），该Daemon将根据作业消耗的资源和数据大小来评判参数集是否合适参数生成器（Param Generator）：一旦设置好当前的参数集，该Daemon就会生成新的参数建议。目前我们使用PSO算法进行新的参数建议。Rest ...继续阅读 (4)

度量指标资源用量资源使用情况是你作业在GB小时内使用的资源量。计量统计我们将作业的资源使用量定义为任务容器大小和任务运行时间的乘积。因此，作业的资源使用量可以定义为mapper和reducer任务的资源使用量总和。范例12345678Consider a job with:4 mappers with runtime {12, 15, 20, 30} mins.4 reducers with runtime {10 , 12, 15, 18} mins.Container size of 4 GBThen,Resource used by all mappers: 4 * (( 12 + 15 + 20 + 30 ) / 60 ) GB Hours = 5.133 GB HoursResource used by all reducers: 4 * (( 10 + 12 + 15 + 18 ) / 60 ) GB Hours = 3.666 GB HoursTotal resource used by the job = 5.133 + 3.6666 = 8.799 GB Hours浪费的资源量这显示了作业以GB小时浪费的资源量或以浪费的资源百分比。计量统计1234567891011121314151617181920212223To cal ...继续阅读 (15)

本节介绍如何使用Dr.Elephant来进行任务查看，分析，搜索，比较等。仪表盘Dr.Elephant的启动首页正如你所见组件集群统计信息这个页面包含了集群最近的统计信息。列出了最近24小时分析过的作业数量，可进行优化的作业数量和待优化的作业数量。最新分析这一部分列出了最近一段时间分析的任务搜索页搜索页允许你通过一下选项过滤搜索作业和工作流：作业ID：输入作业的ID，可以搜索一个特定的任务或者任务流。返回作业详情页面。工作流执行ID/URL：使用作业流的执行ID或者URL（例如Azkaban的作业流），可以搜索到被这个作业流触发的所有任务。用户名：提交任务的用户名任务类型：搜索特定类型的所有任务待优化等级：每个任务被Dr.Elephant诊断完以后，就会生成一份详细的诊断报告，其中就包括该任务的待优化等级。我们可以基于待优化等级搜索任务。例如，我们在待优化等级输入框中输入”severe（严重)”，搜索结果就会包含至少被一个启发式算法诊断为”severe”的所有任务。在该例子中，搜索时还可以同时指定启发式算法，那么搜索结果就只包含被该启发式算法诊断为”severe”的所有任务。任务结束日期：我们也可以使用任务结束时间作为搜索条件。在”from”和”to”这两个输入框中，可以分别设定起始时间和结束时间。这个时间段是一个左闭右开的区间 （[from, to)），包含from这个时间点，但 ...继续阅读 (4)

Dr.Elephant设置请按照快速安装说明操作here.先决条件Play/ActivatorHadoop/Spark on Yarn为了在本地部署Dr.Elephant测试，你需要安装Hadoop(version 2.x)或者Spark(Yarn mode, version > 1.4.0)，以及资源管理服务和历史作业服务（可以用伪分布式）。关于伪分布式模式在YARN上运行MapReduce作业相关说明可以在这里找到。如果还没设置环境变量，可以导入HADOOP_HOME变量12$>exportHADOOP_HOME=/path/to/hadoop/home$>exportHADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop将hadoop的home目录添加到系统变量下，因为Dr.Elephant会调用到hadoop的某些类库1$>exportPATH=$HADOOP_HOME/bin:$PATH确保历史作业服务器正常运行，因为Dr.Elephant需要依赖他运行1$>$HADOOP_HOME/sbin/mr-jobhistory-daemon.sh start historyserver数据库Dr.Elephant需要一个数据库来存储相关祖业信息和分析结果数据本地配置并启动一个mysql。可以从以下链接获取最新版的mysql：https://www.mys ...继续阅读 (6)

redis架构分析上篇我们讲解完 Redis Sentinel 原理之后，接下来讲解常用的 Redis 高可用架构。Redis Sentinel 集群 + 内网 DNS + 自定义脚本Redis Sentinel 集群 + VIP + 自定义脚本封装客户端直连 Redis Sentinel 端口JedisSentinelPool，适合 JavaPHP 基于 phpredis 自行封装Redis Sentinel 集群 + Keepalived/HaproxyRedis M/S + KeepalivedRedis ClusterTwemproxy+sentinel+KeepalivedCodisPikaRedis Sentinel 集群 + 内网 DNS + 自定义脚本上图是已经在线上环境应用的方案。底层是Redis Sentinel集群，代理着 Redis 主从，Web 端连接内网 DNS 提供服务。内网 DNS 按照一定的规则分配，比如 xxxx.redis.cache/queue.port.xxx.xxx，第一个段表示业务简写，第二个段表示这是 Redis 内网域名，第三个段表示 Redis 类型，cache 表示缓存，queue 表示队列，第四个段表示 Redis 端口，第五、第六个段表示内网主域名。当主节点发生故障，比如机器故障、Redis 节点故障或者网络不可达，Sent ...继续阅读 (6)

快速安装说明Step 1：在GitHub上注册一个账号，并fork一份Dr. Elephant项目代码。Step 2：检出代码。12$> gitclonehttps://github.com//dr-elephant$>cddr-elephant*Step 3：先决条件：你必须先安装play或者activator命令行。下载activatorzip包https://downloads.typesafe.com/typesafe-activator/1.3.12/typesafe-activator-1.3.12.zip，解压并添加activator命令到你自己的环境变量$PATH。对于老版的play，你需要添加paly命令并替换activator。12exportACTIVATOR_HOME=/path/to/unzipped/activatorexportPATH=$ACTIVATOR_HOME/bin:$PATHDr.Elephant将分析数据结果存储在MySQL数据中。如果你还没装，请先安装好MySQL。（推荐5.5以上版本）为了正常使用Dr. ElephantUI界面，需要安装npm及其依赖123sudo yum install npmsudo npm install -g bowercdweb; bower install;cd..最后，你还需要安装好Hadoop或者Sp ...继续阅读 (4)

系统环境要求Dr. Elephant依赖于YARN的资源管理服务器和历史作业记录服务器，来获取作业详细信息和记录。YARN作业及其分析的详细信息将存储在当前配置的后端mysql中。因此在运行Dr. Elephant前，必须安装好MySQL和hadoop 2。从#162开始，将不再支持JAVA 6。集群部署Dr. Elephant部署配置将配置文件的目录复制到集群的每台机器上配置环境变量$ELEPHANT_CONF_DIR指向到你的配置文件目录1$>exportELEPHANT_CONF_DIR=/path/to/conf/dirAirflow和Oozie配置如果你使用Airflow或Oozie调度系统，则需要编辑你$ELEPHANT_CONF_DIR目录下的SchedulerConf.xml的配置文件：Airflow，设置airflowbaseurl配置属性指向你的Airflow服务Oozie，设置oozie_api_url配置属性指向你的Oozie调度服务的API地址对于Oozie可以额外设置其他跟多可选属性，有关 更多信息，请参阅SchedulerConf.xml相关文档二进制部署SSH连接到集群机器切换到合适的部署用户1sudo -iu解压dr-elephant二进制包启动/停止dr-elephant进入dr-elephant根目录想启动dr-elephant，请允许启 ...继续阅读 (8)

简介Dr. Elephant是一个Hadoop和Spark的性能监控和调优工具。它能自动采集作业的度量指标并分析他，然后以简单明了的方式展现出来。Dr. Elephant的设计思想是通过作业分析结果来指导开发者进行作业调优，从而提升开发者效率和集群资源的利用率。Dr. Elephant使用了一组可配置的插件式启发算法来分析hadoop和spark作业并提供优化建议。然后针对结果数据来建议如何调整作业。这个算法还计算了作业的许多其他度量标准，用来为集群作业优化提供了有价值的参考信息。为什么要使用Dr.Elephant?大多数Hadoop优化工具，不管是开源还是商业的，都被设计用来采集系统资源指标和监控集群资源信息。他们大多数专注于简化Hadoop集群的部署和管理。很少有工具来帮助用户优化Hadoop作业流的。少数的几个可用工具要么扩展性差，要么不支持快速发展的Hadoop框架。Dr. Elephant能很好支持Hadoop生态框架以及后续的新框架，同时对Spark的支持也很友好。你同时也可以通过插件的方式配置各种你喜欢的启发式算法。旨在帮助Hadoop和Spark的用户了解他们的内部工作流，并帮助他们轻松优化他们的作业。核心功能点基于自定义规则的可配置启发式插件，用于诊断作业任务和Azkaban集成，并支持任何Hadoop调度框架，比如：Oozie统计历史作业和工作流的性能指标Job ...继续阅读 (10)

kafka中文文档：http://kafka.apachecn.orggithub：https://github.com/apachecn/kafka-doc-zh ...继续阅读 (11)

pyenv实现多个python版本并存由于python 2和3存在不小的区别，尤其个别第三方库并不是都兼容，所以有时候我们需要在同一台服务器上运行多个不同的python版本1.安装pyenv(1)安装到$HOME/.pyenv目录:1gitclonehttps://github.com/yyuu/pyenv.git ~/.pyenv(2)配置环境变量12echo'export PYENV_ROOT="$HOME/.pyenv"'>> ~/.bash_profileecho'export PATH="$PYENV_ROOT/bin:$PATH"'>> ~/.bash_profile(3)添加pyenv初始化到你的shell并生效123echo'eval "$(pyenv init -)"'>> ~/.bash_profileecho'eval "$(pyenv virtualenv-init -)"'>> ~/.bash_profilesource~/.bash_profile2.安装需要的python版本查看可安装版本：1234567891011121314151617181920212223242526272829303132[db_dlp@prd-bigdata20 ~]$ pyenv install --listAvailable versions:2.1.32.2.32.3 ...继续阅读 (9)

1.前置准备上篇文章我讲了安装CDH的一些前置准备，可以参考《CDH安装前置基础准备条件》一文，这里就不再多说。到此已完成：集群服务器配置，包括安装操作系统、关闭防火墙、同步服务器时钟等；外部数据库安装CDH和CM版本均为5.14且已配置本地yum源2.Cloudera Manager安装2.1.安装Cloudera Manager Server1.yum安装Cloudera Manager Server1yum -y install cloudera-manager-server2.安装完成后，初始化数据库：1234[root@bigdata02 yum.repos.d]# /usr/share/cmf/schema/scm_prepare_database.sh mysql cm cm passwordJAVA_HOME=/usr/java/jdk1.8.0_67-clouderaVerifying that we can write to /etc/cloudera-scm-serverCreating SCM configuration file in /etc/cloudera-scm-serverExecuting:  /usr/java/jdk1.8.0_67-cloudera/bin/java -cp /usr/share/java/mysql-connector- ...继续阅读 (4)

CDH安装前置基础准备条件1.基础环境1.1.节点规模测试环境，最小规模，最少4台服务器。一台做管理节点Cloudera Manager和NameNode等，另外三台用作worker，DATANODE节点，这种最小规模一般仅用于开发和测试。如果是生产环境，最少6台，3台管理节点包括1个Cloudera Manager，2个NameNode做高可用，3个工作节点。常见的较小规模的生产系统一般为10-20台。###1.2.操作系统CDH支持大部分主流的64位操作系统，我这里会以centos 6.9部署CDH 5.14版本为例子。其他CDH版本及其对应的操作系统版本可参考：CDH版本及其支持的操作系统版本1.3.安装用户可以用root，或具有免密sudo权限的用户###1.4.硬件要求要评估群集的硬件和资源分配，其实需要分析要在群集上运行业务的负载情况，以及将要部署的CDH组件。还应该考虑存储和处理的数据大小，工作负载的频率，需要运行的作业并发数量以及应用程序所需的资源。所以硬件配置需要视具体情况而定。测试集群最低要求：CPU：最少4 cores内存：最少16GB网络：千兆及以上磁盘：视情况而定这里我使用的服务器配置是：CPU：56 cores内存：14*16GB网络：双万兆网卡绑定磁盘：24*1.2T SAS(2.5 10K)1.4.1.磁盘要求所有节点服务器系统盘可以使用raid1或 ...继续阅读 (13)

中文文档:http://sklearn.apachecn.org/cn/0.19.0/tutorial/basic/tutorial.html英文文档:http://sklearn.apachecn.org/en/0.19.0/tutorial/basic/tutorial.htmlGitHub:https://github.com/apachecn/scikit-learn-doc-zh（觉得不错麻烦给个Star，我们一直在努力）贡献者:https://github.com/apachecn/scikit-learn-doc-zh#贡献者内容提要在本节中，我们介绍一些在使用 scikit-learn 过程中用到的 机器学习 词汇，并且给出一些例子阐释它们。机器学习：问题设置一般来说，一个学习问题通常会考虑一系列 n 个 样本 数据，然后尝试预测未知数据的属性。 如果每个样本是 多个属性的数据 （比如说是一个多维记录），就说它有许多“属性”，或称 features(特征) 。我们可以将学习问题分为几大类:监督学习, 其中数据带有一个附加属性，即我们想要预测的结果值（ 点击此处 转到 scikit-learn 监督学习页面）。这个问题可以是:分类: 样本属于两个或更多个类，我们想从已经标记的数据中学习如何预测未标记数据的类别。 分类问题的一个例子是手写数字识别，其目的是将每个输入向量 ...继续阅读 (9)

中文文档:http://sklearn.apachecn.org/cn/0.19.0/tutorial/basic/tutorial.html英文文档:http://sklearn.apachecn.org/en/0.19.0/tutorial/basic/tutorial.htmlGitHub:https://github.com/apachecn/scikit-learn-doc-zh（觉得不错麻烦给个Star，我们一直在努力）贡献者:https://github.com/apachecn/scikit-learn-doc-zh#贡献者安装 scikit-learnNote:如果你想为这个项目做出贡献，建议你安装最新的开发版本.安装最新版本Scikit-learn 要求:Python (>= 2.7 or >= 3.3)NumPy (>= 1.8.2)SciPy (>= 0.13.3)如果你已经有一个安全的 numpy 和 scipy，安装 scikit-learn 的最简单的方法是使用 pip1pip install -U scikit-learn或者 conda:1conda install scikit-learn如果您还没有安装 NumPy 或 SciPy，还可以使用 conda 或 pip 安装这些。 当使用 pip 时，请确保使用 binary wheels，并且 ...继续阅读 (12)

有将近一周没有写文章了，经历了一场所有IT从业者的梦魇——数据丢失。一块1T的移动硬盘中，约500G的分区数据无故消失，想必挺多人都遇上过这种事，无奈，尽快尝试恢复，能恢复多少是多少了。分区格式由于此块移动硬盘经常要在windows和mac平台来回切换使用，在不纠结单文件4GB的限制的情况下，当时使用的FAT32格式。还好此类格式和NTFS格式较为常见，恢复起来也较为容易。这里要说一下：FAT32格式磁盘可在windows和mac平台读写，但有单个文件4GB限制；NTFS完美兼容windows平台，但在mac平台下，默认为只读，但是通过魔改mac系统配置或者通过第三方插件可以取得写入权限；exfat格式同样兼容windows和mac平台读写，但是此类格式不太稳定，会有丢数据的现象，且一旦出问题，一般技术手段，基本难以恢复数据。恢复工具市面上硬盘数据恢复工具很多，大多是无法完全恢复丢失数据的。一般个人不是很重要的数据，且文件格式比较常规的，在数据丢失后立马停止文件写入，尝试修复还是有可能恢复90%+的数据的。这里说一下，我亲身试用过的一些工具，希望可以帮到有需要的朋友们，少走弯路。EasyRecovery (Kroll Ontrack)注意括号内软件厂商名字，由于市面上还有很多国产山寨数据恢复工具也叫EasyRecovery（大小写，空格啥的不同），名字上基本难以区分，所以要注意厂商 ...继续阅读 (7)

初识consulConsul是什么?Consul是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul是分布式的、高可用的、 可横向扩展的。它具备以下特性:服务发现Consul的客户端可提供一个服务，比如 api 或者mysql，另外一些客户端可使用Consul去发现一个指定服务的提供者。通过DNS或者HTTP接口可以很容易的找到他所依赖的服务。健康检查Consul客户端可提供任意数量的健康检查，指定一个服务(比如:webserver是否返回了200 OK 状态码)或者使用本地节点(比如:内存使用是否大于90%). 这个信息可由operator用来监视集群的健康。服务发现组件用来避免将流量发送到不健康的主机。Key/Value存储应用程序可根据自己的需要使用Consul的Key/Value存储.比如动态配置,功能标记,协调,领袖选举等等,简单的HTTP API让他更易于使用。多数据中心Consul支持开箱即用的多数据中心.这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。Consul面向DevOps和应用开发者友好，使他适合现代弹性的基础设施。Consul架构Consul是一个分布式高可用的系统。Agent与一个和多个Consul Server 进行交互.Consul Server 用于存放和复制数据.server自行选举一个lead ...继续阅读 (8)

前言本期原本计划是写些redis高可用架构选型，分析，及实战，发现篇幅过长，所以拆开来写了。这期先讲一些官方提供的高可用功能，主从，sentinel，以及redis cluster。Redis-ReplicationRedis 支持简单且易用的主从复制（master-slave replication）功能， 该功能可以让从服务器(slave server)成为主服务器(master server)的精确复制品。以下是关于 Redis 复制功能的几个重要方面：Redis 使用异步复制。 从 Redis 2.8 开始， 从服务器会以每秒一次的频率向主服务器报告复制流（replication stream）的处理进度。一个主服务器可以有多个从服务器。不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器， 多个从服务器之间可以构成一个图状结构。复制功能不会阻塞主服务器： 即使有一个或多个从服务器正在进行初次同步， 主服务器也可以继续处理命令请求。复制功能也不会阻塞从服务器： 只要在 redis.conf 文件中进行了相应的设置， 即使从服务器正在进行初次同步， 服务器也可以使用旧版本的数据集来处理命令查询。复制功能可以单纯地用于数据冗余（data redundancy）， 也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）： 比如说， 繁重的 SORT ...继续阅读 (9)

redis简介Redis是一个开源（BSD许可），内存存储的数据结构服务器，可用作数据库，高速缓存和消息队列代理。它支持字符串、哈希表、列表、集合、有序集合，位图，hyperloglogs等数据类型。内置复制、Lua脚本、LRU收回、事务以及不同级别磁盘持久化功能。如今，互联网业务的数据正以更快的速度在增长，数据类型越来越丰富，这对数据处理的速度和能力提出了更高要求。Redis 是一种开源的内存非关系型数据库，给开发人员带来的体验是颠覆性的。在自始至终的设计过程中，都充分考虑高性能，这使得 Redis 成为当今速度最快的 NoSQL 数据库。redis特性Redis的数据类型：字符串、列表（lists）、集合（sets）、有序集合（sorts sets）、哈希表（hashs）Redis和memcache相比的独特之处：redis可以用来做存储（storge）、而memcache是来做缓存（cache）。这个特点主要是因为其有“持久化”功能存储的数据有“结构”，对于memcache来说，存储的数据，只有一种类型——“字符串”，而redis则可以存储字符串、链表、集合、有序集合、哈希结构持久化的两种方式：Redis将数据存储于内存中，或被配置为使用虚拟内存。实现数据持久化的两种方式：使用截图的方式，将内存中的数据不断写入磁盘（性能高，但可能会引起一定程度的数据丢失）使用类似mysql的 ...继续阅读 (11)

ES选型elasticsearch-2.3.4相关组件：elasticsearch-jdbc-2.3.4.0-distkibana-4.5.4-linux-x64.tarelasticsearch-analysis-ik-1.9.4elasticsearch-analysis-pinyin-1.7.4_bigdesk_head以ES2.3.4为基准，其他组件已为测试后最新可用版本，高于以上版本则不兼容。ES特性SuggestionDiscoverySuggestionDiscovery的职责是发现建议词；建议词的来源可以是商品的分类名称、品牌名称、商品标签、商品名称的高频词、热搜词，也可以是一些组合词，比如“分类 + 性别”和“分类 + 标签”，还可以是一些自定义添加的词；建议词维护的时候需要考虑去重，比如“卫衣男”和“卫衣 男”应该是相同的，“Nike”和“nike”也应该是相同的；由于建议词的来源通常比较稳定，所以执行的周期可以比较长一点，比如每周一次；SuggestionCounterSuggestionCounter的职责是获取建议词关联的商品数量，如果需要可以进行一些聚合操作，比如聚合分类和标签；SuggestionCounter的实现的时候由于要真正地调用搜索接口，应该尽量避免对用户搜索的影响，比如在凌晨执行并且使用单线程调用；为了提升效率，应该使用Elasticsea ...继续阅读 (6)