Elasticsearch: 权威指南

Elasticsearch 是一个分布式、可扩展、实时的搜索与数据分析引擎。

Elasticsearch 不仅仅只是全文搜索,它还支持结构化搜索、数据分析、复杂的语言处理、地理位置和对象间关联关系等,同时它具备水平伸缩性和集群监控等完备的功能。

Elasticsearch – The Definitive Guide(英文版)

阅读全文

构建用户激励体系—3种激励方式与3类激励体系

 1.概念

首先说一下用户激励体系的概念,这个没有明确的说法,笔者根据自己的理解给出这样的定义:用户激励体系,也称用户激励机制,是为了让用户持续使用产品而设计的一套游戏规则。

概念的核心在于所要达到的目的,即让用户持续使用产品。之所以把它称为游戏规则,因为笔者认为游戏是最能让人持续不断投入时间甚至上瘾的活动,好的激励体系最期望达到

阅读全文

初学者理解 LSTM 网络

经常接触LSTM,GRU,RNN这些模型,对于LSTM的印象只是知道它用来解决梯度消失梯度爆炸问题,对于长距离的句子的学习效果不好的问题,而且大概知道里面是加了一些参数,加了门单元来选择忘记和记住一些信息。但是具体公式没有推过,所以理解的不够深。

阅读全文

成长之路—对线上心存敬畏

最近遇到一个事,小同学上线出了bug,导致线上出现了一个case,说大不大,说小也不小,因为是半夜12点左右被发现的,晚上紧急上线是需要发邮件找两边经理审批才能上,这位同学担心大家都睡了,不好意思打扰,就打算第二天再上。

这个事让我想起来的一句话:“对线上要心存敬畏”。

阅读全文

成长之路—每天问自己3个问题

最近有些事情的推进不是很顺利,团队里很多人看着都很忙,但是都在做我们最应该做的“最重要的事”吗?你有在抢下属的活干吗?计划里排的对应的目标、收益、优先级够清晰吗?让团队振奋人心的战略规划在推动逐步落地吗?

思来想去,每天问自己3个问题: 1.你的“个人价值”主要是什么?<span

阅读全文

成长之路—《杰克·韦尔奇自传》读后感

讲述了通用董事长杰克·韦尔奇20多年的职业历程,前半部分讲述如何从普通职员一步一步成为董事长以及上任后对通用的文化、核心竞争力的重塑,后半部分大多是资本运作相关。

学到的观点:

1、关于表现不好的员工

阅读全文

如何用python解析mnist图片

MNIST 数据集是一个手写数字识别训练数据集,来自美国国家标准与技术研究所National Institute of Standards and Technology (NIST)。训练集 (training set) 由来自 250 个不同人手写的数字构成,其中 50% 是高中学生,50% 来自人口普查局 (the Census Bureau) 的工作人员。测试集(test set) 也是同样比例的手写数字数据。

MNIST 数据集可在 http://yann.lecun.com/exdb/mnist/ 获取, 它包含了四个部分:

  • Training set images: train-images-idx3-ubyte.gz (9.9 MB, 解压后 47 MB, 包含 60,000 个样本)
  • Training set labels: train-labels-idx1-ubyte.gz (29 KB, 解压后 60 KB, 包含 60,000 个标签)
  • Test set images: t10k-images-idx3-ubyte.gz (1.6 MB, 解压后 7.8 MB, 包含 10,000 个样本)
  • Test set labels: t10k-labels-idx1-ubyte.gz (5KB, 解压后 10 KB, 包含 10,000 个标签)

因数据集是按特殊格式压缩存储的,所以如果在训练或应用模型时想看一下原图就会比较困难,本文讲解如果反向解析这个数据集。

一、mnist数据结构

可以看出在train-images.idx3-ubyte中,第一个数为32位的整数(魔数,图片类型的数),第二个数为32位的整数(图片的个数),第三和第四个也是32为的整数(分别代表图片的行数和列数),接下来的都是一个字节的无符号数(即像素,值域为0~255),因此,我们只需要依次获取魔数和图片的个数,然后获取图片的长和宽,最后逐个像素读取就可以了。

如何使用python解析数据呢? 首先需要安装python的图形处理库PIL,这个库支持像素级别的图像处理,对于学习数字图像处理有很大的帮助。安装完成之后,就可以进行图像的解析了。

sudo pip install Pillow   #PIL python image library

首先打开文件,然后分别读取魔数,图片个数,以及行数和列数,在struct中,可以看到,使用了’>IIII’,这是什么意思呢?意思就是使用大端规则,读取四个整形数(Integer),如果要读取一个字节,则可以用’>B’(当然,这里用没用大端规则都是一样的,因此只有两个或两个以上的字节才有用)。

什么是大端规则呢?不懂的可以百度一下,这个不再赘述(http://baike.baidu.com/link?url=Bgg8b0vRr3b_SeGyOl8U4DmAbIQT9swGuNtD_21ctEI_NliqsQ-mKF73YT90EILF2EQy50mEua_M4z6Cma3rmK)

然后对于每张图片,先创建一张空白的图片,其中的’L’代表这张图片是灰度图,最后逐个像素读取,然后写进空白图片里,最后保存图片,就可以了

二、mnist标签数据结构

可以发现,与上面的非常相似,只不过这里每一个字节变成了标签而已(标签大小为0~9)

三、解析mnist图片和标签数据

好了,通过上述讲解,最后我们可以通过python将mnist解析出来了,看一下效果:

解析出的图片数据:

解析出的label:

程序源代码如下:

#!/usr/bin/env python # -*- coding: utf-8 -*- from PIL import Image import struct #import matplotlib.pyplot as plt #import numpy as np # 读取mnist图片 def read_image(filename): f = open(filename, 'rb') index = 0 buf = f.read() f.close() numRows = 28 numColumns = 28

阅读全文

小猪学Paddle—线性回归之房价预测

上次我们进行了简单的环境安装和模型应用尝试,今天开始通过paddlepaddle的房价预测看一下简单的线性回归有监督模型是怎么训练出来的。

简单点说就是根据一份有标注的数据集,包含了某地区房屋的相关信息(feature)及该类房屋的标注平均价格(label),用来训练一个可以根据feature预测label的模型。具体数据字段一共14个,包含13个feature和1个label,含义如下:

属性名 解释 类型
CRIM 该镇的人均犯罪率 连续值
ZN 占地面积超过25,000平方呎的住宅用地比例 连续值
INDUS 非零售商业用地比例 连续值
CHAS 是否邻近 Charles River 离散值,1=邻近;0=不邻近
NOX 一氧化氮浓度 连续值
RM 每栋房屋的平均客房数 连续值
AGE 1940年之前建成的自用单位比例 连续值
DIS 到波士顿5个就业中心的加权距离 连续值
RAD 到径向公路的可达性指数 连续值
TAX 全值财产税率 连续值
PTRATIO 学生与教师的比例 连续值
1000(BK – 0.63)^2,其中BK为黑人占比 连续值
LSTAT 低收入人群占比 连续值
MEDV 同类房屋价格的中位数 连续值

数据示例:

整个训练过程大概分为读取数据集、定义网络结构/cost损失函数/训练参数/训练优化器、进行多轮模型迭代训练、选择训练误差最小的模型、应用模型。具体就不再赘述了,可以先阅读一下paddlepaddle的文档:http://www.paddlepaddle.org/docs/develop/book/01.fit_a_line/index.cn.html

下边是训练过程的代码和自己的理解注释,有错误欢迎指正:

vim housing_train.py #!/usr/bin/env python # -*- coding: utf-8 -*- import os import paddle.v2 as paddle import paddle.v2.dataset.uci_housing as uci_housing with_gpu = os.getenv('WITH_GPU', '0') != '0' def main(): # 0.init paddle初始化定义跑模型的设备 paddle.init(use_gpu=with_gpu, trainer_count=1) # 1.读取data数据

阅读全文

Jupyter Notebook 快速入门

Jupyter Notebook(此前被称为 IPython notebook)是一个交互式笔记本,支持运行 40 多种编程语言。在本文中,我们将介绍 Jupyter notebook 的主要特性,以及为什么对于希望编写漂亮的交互式文档的人来说是一个强大工具。

在开始使用 notebook 之前,我们先需要安装该库。你可以在 Jupyter 官网上找到完整的步骤。

aliyun安装步骤

#0.install sudo pip install jupyter nbconvert matplotlib sudo yum install pandoc texlive tkinter tcl-devel tk-devel -y #1.get passwd sign ipython from notebook.auth import passwd; passwd() input password && get sha1 password Out[1]: 'sha1:f29ffxxxxxx:c5a57c13ee9a56618f83b3c53621xxxxxxxxxxxx' #2.conf jupyter notebook --generate-config mkdir

阅读全文

小猪学Paddle—安装和训练示例

官网:http://www.paddlepaddle.org/

Github:https://github.com/PaddlePaddle/Paddle

中文手册:http://www.paddlepaddle.org/docs/develop/documentation/fluid/zh/getstarted/index_cn.html

安装和测试过程:

#On CentOS 7 su root #安装依赖 yum install python python-devel -y pip install --upgrade pip --default-timeout 600 #安装paddlepaddle pip install paddlepaddle --default-timeout 600 #创建测试脚本 mkdir /home/work/paddle && cd /home/work/paddle vim housing.py import

阅读全文

Kafka深度解析

背景介绍

Kafka简介

Kafka是一种分布式的,基于发布/订阅的消息系统。主要设计目标如下:

  • 以时间复杂度为O(1)的方式提供消息持久化能力,并保证即使对TB级以上数据也能保证常数时间的访问性能
  • 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输
  • 支持Kafka Server间的消息分区,及分布式消息消费,同时保证每个partition内的消息顺序传输
  • 同时支持离线数据处理和实时数据处理

为什么要用Message Queue

  • 解耦
    在项目启动之初来预测将来项目会碰到什么需求,是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束
  • 冗余
    有时在处理数据的时候处理过程会失败。除非数据被持久化,否则将永远丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。在被许多消息队列所采用的”插入-获取-删除”范式中,在把一个消息从队列中删除之前,需要你的处理过程明确的指出该消息已经被处理完毕,确保你的数据被安全的保存直到你使用完毕。
  • 扩展性
    因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的;只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
  • 灵活性 & 峰值处理能力
    在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见;如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住增长的访问压力,而不是因为超出负荷的请求而完全崩溃。
  • 可恢复性
    当体系的一部分组件失效,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。
  • 送达保证
    消息队列提供的冗余机制保证了消息能被实际的处理,只要一个进程读取了该队列即可。在此基础上,IronMQ提供了一个”只送达一次”保证。无论有多少进程在从队列中领取数据,每一个消息只能被处理一次。这之所以成为可能,是因为获取一个消息只是”预定”了这个消息,暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息,否则这个消息会被放回队列中去,在一段可配置的时间之后可再次被处理。
  • 顺序保证
    在许多情况下,数据处理的顺序都很重要。消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。IronMO保证消息浆糊通过FIFO(先进先出)的顺序来处理,因此消息在队列中的位置就是从队列中检索他们的位置。
  • 缓冲
    在任何重要的系统中,都会有需要不同的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行—写入队列的处理会尽可能的快速,而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流经过系统的速度。
  • 理解数据流
    在一个分布式系统里,要得到一个关于用户操作会用多长时间及其原因的总体印象,是个巨大的挑战。消息系列通过消息被处理的频率,来方便的辅助确定那些表现不佳的处理过程或领域,这些地方的数据流都不够优化。
  • 异步通信
    很多时候,你不想也不需要立即处理消息。消息队列提供了异步处理机制,允许你把一个消息放入队列,但并不立即处理它。你想向队列中放入多少消息就放多少,然后在你乐意的时候再去处理它们。

常用Message Queue对比

  • RabbitMQ
    RabbitMQ是使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP, SMTP, STOMP,也正因如此,它非常重量级,更适合于企业级的开发。同时实现了Broker构架,这意味着消息在发送给客户端时先在中心队列排队。对路由,负载均衡或者数据持久化都有很好的支持。
  • Redis
    Redis是一个基于Key-Value对的NoSQL数据库,开发维护很活跃。虽然它是一个Key-Value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作,各执行100万次,每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明:入队时,当数据比较小时Redis的性能要高于RabbitMQ,而如果数据大小超过了10K,Redis则慢的无法忍受;出队时,无论数据大小,Redis都表现出非常好的性能,而RabbitMQ的出队性能则远低于Redis。
  • ZeroMQ
    ZeroMQ号称最快的消息队列系统,尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列,但是开发人员需要自己组合多种技术框架,技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式,你不需要安装和运行一个消息服务器或中间件,因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库,可以使用NuGet安装,然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列,也就是说如果down机,数据将会丢失。其中,Twitter的Storm中默认使用ZeroMQ作为数据流的传输。
  • ActiveMQ
    ActiveMQ是Apache下的一个子项目。 类似于ZeroMQ,它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ,它少量代码就可以高效地实现高级应用场景。
  • Kafka/Jafka
    Kafka是Apache下的一个子项目,是一个高性能跨语言分布式Publish/Subscribe消息队列系统,而Jafka是在Kafka之上孵化而来的,即Kafka的一个升级版。具有以下特性:快速持久化,可以在O(1)的系统开销下进行消息持久化;高吞吐,在一台普通的服务器上既可以达到10W/s的吞吐速率;完全的分布式系统,Broker、Producer、Consumer都原生自动支持分布式,自动实现复杂均衡;支持Hadoop数据并行加载,对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理,这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统,除了性能非常好之外,还是一个工作良好的分布式系统。

Kafka解析

Terminology

  • Broker
    Kafka集群包含一个或多个服务器,这种服务器被称为broker
  • Topic
    每条发布到Kafka集群的消息都有一个类别,这个类别被称为topic。(物理上不同topic的消息分开存储,逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处)
  • Partition
    parition是物理上的概念,每个topic包含一个或多个partition,创建topic时可指定parition数量。每个partition对应于一个文件夹,该文件夹下存储该partition的数据和索引文件
  • Producer
    负责发布消息到Kafka broker
  • Consumer
    消费消息。每个consumer属于一个特定的consuer group(可为每个consumer指定group name,若不指定group name则属于默认的group)。使用consumer high level API时,同一topic的一条消息只能被同一个consumer group内的一个consumer消费,但多个consumer group可同时消费这一消息。

Kafka架构

如上图所示,一个典型的kafka集群中包含若干producer(可以是web前端产生的page view,或者是服务器日志,系统CPU、memory等),若干broker(Kafka支持水平扩展,一般broker数量越多,集群吞吐率越高),若干consumer group,以及一个 Zookeeper 集群。Kafka通过Zookeeper管理集群配置,选举leader,以及在consumer group发生变化时进行rebalance。producer使用push模式将消息发布到broker,consumer使用pull模式从broker订阅并消费消息。

Push vs. Pull

作为一个messaging system,Kafka遵循了传统的方式,选择由producer向broker push消息并由consumer从broker pull消息。一些logging-centric system,比如Facebook的 Scribe 和Cloudera的 Flume ,采用非常不同的push模式。事实上,push模式和pull模式各有优劣。

push模式很难适应消费速率不同的消费者,因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息,但是这样很容易造成consumer来不及处理消息,典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。

Topic & Partition

Topic在逻辑上可以被认为是一个在的queue,每条消费都必须指定它的topic,可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以水平扩展,物理上把topic分成一个或多个partition,每个partition在物理上对应一个文件夹,该文件夹下存储这个partition的所有消息和索引文件。


每个日志文件都是“log entries”序列,每一个 log entry 包含一个4字节整型数(值为N),其后跟N个字节的消息体。每条消息都有一个当前partition下唯一的64字节的offset,它指明了这条消息的起始位置。磁盘上存储的消费格式如下:

message length : 4 bytes (value: 1+4+n)

“magic” value : 1 byte

crc : 4 bytes

payload : n bytes

这个“log entries”并非由一个文件构成,而是分成多个segment,每个segment名为该segment第一条消息的offset和“.kafka”组成。另外会有一个索引文件,它标明了每个segment下包含的 log entry 的offset范围,如下图所示。


因为每条消息都被append到该partition中,是顺序写磁盘,因此效率非常高(经验证,顺序写磁盘效率比随机写内存还要高,这是Kafka高吞吐率的一个很重要的保证)。

每一条消息被发送到broker时,会根据paritition规则选择被存储到哪一个partition。如果partition规则设置的合理,所有消息可以均匀分布到不同的partition里,这样就实现了水平扩展。(如果一个topic对应一个文件,那这个文件所在的机器I/O将会成为这个topic的性能瓶颈,而partition解决了这个问题)。在创建topic时可以在 $KAFKA_HOME/config/server.properties 中指定这个partition的数量(如下所示),当然也可以在topic创建之后去修改parition数量。
# The default number of log partitions per topic. More partitions allow greater
# parallelism for consumption, but this will also result in more files across
# the brokers.
num.partitions=3

在发送一条消息时,可以指定这条消息的key,producer根据这个key和partition机制来判断将这条消息发送到哪个parition。paritition机制可以通过指定producer的paritition. class这一参数来指定,该class必须实现 kafka.producer.Partitioner 接口。本例中如果key可以被解析为整数则将对应的整数与partition总数取余,该消息会被发送到该数对应的partition。(每个parition都会有个序号)

import kafka.producer.Partitioner; import

阅读全文

MongoDB 3.2.x 分片搭建

5台分片服务器建立 解压

tar zxvf /data/mongo.tgz -C /data mkdir /data/mongo/conf mkdir /data/mongo/logs mkdir /data/mongo/databases mkdir /data/mongo/databases/shard1 mkdir /data/mongo/databases/shard2 mkdir /data/mongo/databases/shard3 vi /data/mongo/conf/shard1.conf shardsvr=true replSet=shard1 port=10001 dbpath=/data/mongo/databases/shard1 logpath=/data/mongo/logs/shard1.log directoryperdb=true storageEngine=wiredTiger wiredTigerCacheSizeGB=2 syncdelay=30 wiredTigerCollectionBlockCompressor=zlib oplogSize=2048 logappend=true journal=false slowms=200 fork=true rest=true httpinterface=true vi

阅读全文