可扩展的任务调度器框架
前言
平常在项目中我们经常会有一些后台的定时或者间隔的任务，比如间隔或者定时计算、数据规则判断告警等。如果需要统一灵活的配置管理，并支持大量任务的扩展，我们是否可以考虑做一个统一的调度管理框架呢?
下面是基于个人现实中的一些情况，提炼实现的一个可扩展的任务调度框架…
##
##
总结
此项目github地址: scheduler
]]>可扩展的任务调度器框架
平常在项目中我们经常会有一些后台的定时或者间隔的任务，比如间隔或者定时计算、数据规则判断告警等。如果需要统一灵活的配置管理，并支持大量任务的扩展，我们是否可以考虑做一个统一的调度管理框架呢?
下面是基于个人现实中的一些情况，提炼实现的一个可扩展的任务调度框架…
##
##
此项目github地址: scheduler
]]>使用pandas生成日报图表并发送邮件
平常我们在项目中可能会用到Prometheus这样的监控报警系统,来了解项目系统内部的实际运行状态，以及做趋势分析、对照分析、告警与故障定位、数据可视化等。
虽然他有诸多优点，但是对于小项目来说，这个又有点太重。如果我们想在小项目里做一些简单的数据分析和可定制化的报表生成，是否有简单可复用的方法呢？有的！下面我们就用pandas结合python其他的一些基本的库，来做一个日报图表生成发送的小模板。
基本每日数据简略如下 :
| 请求编号 | 产品 | 查询状态 | 结果数据 | 创建时间 | 更新时间 |
|---|---|---|---|---|---|
| 10001 | 产品1 | 成功 | … | 2020-11-09 12:00:01 | 2020-11-09 12:01:03 |
| 10002 | 产品2 | 成功 | … | 2020-11-09 12:03:01 | 2020-11-09 12:04:03 |
| 10003 | 产品2 | 失败 | … | 2020-11-09 12:05:01 | 2020-11-09 12:06:12 |
| 10004 | 产品3 | 特殊失败 | … | 2020-11-09 12:06:01 | 2020-11-09 12:06:15 |
| … | … | … | … | … | … |
1 | DBUtils==2.0 |
整个小项目分为获取数据、清洗数据、分析数据、生成图表、发送邮件大致几个模块。
1 | #!/usr/bin/env python |
1 | # -*- coding: utf-8 -*- |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
def _get_range_data(self, begin_date, end_date):
"""
获取起止日期之间的数据
"""
STATUS_SUCCESS = 1 # 查询成功
STATUS_CreditA_FAIL = 2 # A数据源查询失败
STATUS_QUERYING = 3 # 查询中
STATUS_CreditB_FAIL = 4 # B数据源查询失败
STATUS_CreditC_FAIL = 5 # C数据源查询失败
STATUS_CreditD_FAIL = 6 # D数据源查询失败
total_cnt = 0 # 总量
success_cnt = 0 # 成功量
querying_cnt = 0 # 查询中量
fail_cnt = 0 # 失败量
special_fail_cnt = 0 # 特殊失败量
begin_date_str = datetime.datetime.strftime(begin_date, '%Y-%m-%d')
sql = '''
SELECT status, count(1) FROM {}
where source = 1 and method regexp 'rule' and created_at >= %s and created_at < %s
group by status
'''.format(self.credit_table) # 按照查询状态统计
values = [begin_date, end_date]
for row in db_interface.db1.select(sql, values):
total_cnt += int(row[1]) # 总量统计
if int(row[0]) == STATUS_SUCCESS:
success_cnt += int(row[1]) # 成功量统计
elif int(row[0]) == STATUS_QUERYING:
querying_cnt += int(row[1]) # 查询中统计
else:
# 失败量统计
fail_cnt += int(row[1])
# 失败细分统计
if self.credit_type == 'CreditA' and int(row[0]) == STATUS_CreditA_FAIL:
# A数据源失败
special_fail_cnt += int(row[1])
elif self.credit_type == 'CreditB' and int(row[0]) == STATUS_CreditB_FAIL:
# B数据源失败
special_fail_cnt += int(row[1])
elif self.credit_type == 'CreditC' and int(row[0]) == STATUS_CreditC_FAIL:
# C数据源失败
special_fail_cnt += int(row[1])
elif self.credit_type == 'CreditD' and int(row[0]) == STATUS_CreditD_FAIL:
# D数据源失败
special_fail_cnt += int(row[1])
data = [begin_date_str, self.credit_type, total_cnt, success_cnt,
querying_cnt, fail_cnt, special_fail_cnt] # 近几天时间序列数据
return data
def get_summary_data(self):
"""获取近几天的数据"""
sum_datas = list()
today = datetime.date.today()
# 日期起始列表
days_range = range(1, self.report_days + 1, 1) # self.report_days 是类的近几日的报告天数，可根据需求动态配置
date_pairs = [(today - datetime.timedelta(days=i), today - datetime.timedelta(days=i - 1)) for i in days_range]
for date_pair in date_pairs:
data = self._get_range_data(date_pair[0], date_pair[1])
sum_datas.append(data)
return sum_datas
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
def get_yestoday_data(self, include_today=False):
"""获取前一日数据
include_today为True时，即为获取截止到当前时间的今天的数据，默认为获取昨天的数据"""
datas = list()
end_date = datetime.date.today()
begin_date = end_date - datetime.timedelta(days=1)
begin_date_str = datetime.datetime.strftime(begin_date, '%Y-%m-%d')
end_date_str = datetime.datetime.strftime(end_date, '%Y-%m-%d')
if include_today:
end_date += datetime.timedelta(days=1)
begin_date += datetime.timedelta(days=1)
sql = """ SELECT {} FROM {}
WHERE source = 1 AND created_at >= %s AND created_at < %s
""".format(self.query_fileds, self.credit_table) # 参数为要查询的字段和表名，可配置
values = [begin_date_str, end_date_str]
for row in db_interface.db1_check.select(sql, values):
record = [int(r) if index <= 1 else r for index, r in enumerate(row)] # apply_id/uniq_id 和status转int
datas.append(record)
return datas
使用pandas将获取到的数据清理转换为DataFrame,根据需求，进行轴的转换以及聚合分析
1 | credit_name_map['CreditA'] = 'A数据源' |
1 | # 选取想要分析的列生成DataFrame |
matplotlib对于处理好的数据生成对应的柱状图、折线图等1 | #!/usr/bin/env python |
1 | # 汇总数据 |
1 | credit_name_map = OrderedDict() |
行列数据添加相应的html代码，使得能在邮件中显示
1 | #!/usr/bin/python |
1 | table_datas = table_data_df.values.tolist() |
使用smtplib 和 email，添加对应配置，方邮件
1 | #!/usr/bin/python |
这样一个基本的数据获取、分析、生成报表发送邮件的基本框架就搭好了，当然还可以配置定时任务，来定时生成。或者对于异常的数据进行特殊告警发送。
此项目github地址: daily_report
这只是一个基本的数据生成报表发送的简单示例，如果数据更加复杂，我们可能需要利用pandas进行更加精细的操作.
或者如果有很多这样的项目需要数据可视化和实时告警，那么我们还是推荐使用Prometheus这样的工具，来配合云平台或者容器平台。
使用cookiecutter初始化可自定义的GO项目模板
##
项目github地址: https://github.com/cgDeepLearn/initgo
]]>Java使用itext解析pdf签章
许多业务交易（包括金融、法律和其他受管制交易）都要求在对文档进行签名时提供较高程度的保证。当以电子方式分发文档时，收件人务必可以：
那么我们怎么通过程序鉴别一个带有电子签章的pdf签章的有效性呢？
电子签章有签名时间，签章有效期起止时间，从这三个时间我们就可以看一些基本的签章有效性和时间是否合理(是否被篡改)。
我们利用itext来解析电子签章。
通过读取pdf的url，将内容加载到流中
1 | public static InputStream getInputStreamByUrl(String strUrl) { |
我们主要用到com.itextpdf.text.pdf里的三个：AcroFields、PdfReader、security.PdfPKCS7
1 | import com.google.gson.Gson; |
这样我们可以获取到三个时间了，一般可以通过签名时间和有效期时间是否为同一天或者看当前日期是否在有效期内来判断签章的有效期行，此外我们也可以利用函数来判断:
1 | PdfPKCS7 pkcs7 = fields.verifySignature(name); // 获取签名的pkcs7数据 |
有时候我们设计到pdf合同的有效性的时候，可以用itextpdf来读取解析其签章时间来判定合同签章的有效性。
快速开发你的小服务
现在微服务盛行，很多项目依赖一些协同工作小而自治的服务。那么对于python，虽然有grpc、nameko这样的微服务框架，或者Flask、Django这样的web框架。我们是否可以编写一个轻量可复用的服务框架呢？
python: 2.7+/3.6+
主要库：PyMySQL、redis、DBUtils、requests、supervisor、urllib3、Werkzeug、gevent、gunicorn
我们主要使用Werkzeug、gevent、gunicorn来实现。
Werkzeug是一个WSGI工具包，他可以作为一个Web框架的底层库。它可以作为一个 Web 框架的底层库，因为它封装好了很多 Web 框架的东西，例如 Request，Response 等等,例如 Flask 框架就是一 Werkzeug 为基础开发的.
Gevent是一个基于greenlet的Python的并发框架，以微线程greenlet为核心，使用了epoll事件监听机制以及诸多其他优化而变得高效。
Gunicorn是一个unix上被广泛使用的高性能的Python WSGI UNIX HTTP Server。和大多数的web框架兼容，并具有实现简单，轻量级，高性能等特点。
一般微服务都是本质上是一些数据库简易CRUD操作的集合，一个服务基本包含数据库连接、日志记录，业务逻辑等。那么我们看看这些的基本实现.
mysql我们使用pymysql和DBUtils做一个连接池，缓存我们使用redis.
操作数据库我们也使用了日志记录，日志记录实现请看下段。
1 | #!/usr/bin/env python |
使用logging模块，配置轮转
1 | #!/usr/bin/env python |
我们编写了一个expose装饰器来做路由:
1 | #!/usr/bin/env python |
对应url_map绑定到环境:
1 | #!/usr/bin/env python |
请求/test响应示例
1 | #!/usr/bin/env python |
如果我们想要新增一个路由，只需再server模块增加对应处理即可
业务逻辑简答示例
1 | #!/usr/bin/env python |
我们使用gevent协程工作方式，配置对应服务器ip、端口、进程数等参数。
1 | #!/usr/bin/env python |
脚本里使用gunicorn启动服务、通过kill命令停止、重载或者重启服务。
1 | !/bin/sh |
请求：
1 | curl http://127.0.0.1:10001/test -d '{"order_id":12345}' |
返回:
1 | {"order_id": 12345,"uuid": "e3bd4a7e-35eb-11eb-bd7e-5254008f07ce","err_msg":"ok","err_code":0,"data": {"timestamp":1589193745,"result":1}} |
以上我们使用Werkzeug、gevent、gunicorn实现了一个轻量的python服务，修改配置、添加对应业务逻辑即可快速开发一个业务对应的微服务。项目git代码: https://github.com/cgDeepLearn/pyserver
此外
supervisor来控制服务的监控拉起。docker来进行容器化管理使用cookiecutter来生成可配置的代码
使用serviceMesh 来进行服务注册发现
select模块以及IO多路复用
Python中的select模块专注于I/O多路复用，提供了select, poll, epoll三个方法(其中后两个在Linux中可用，windows仅支持select)，另外也提供了kqueue方法(freeBSD系统).
select()的机制中提供一fd_set的数据结构，实际上是一long类型的数组， 每一个数组元素都能与一打开的文件句柄（不管是Socket句柄，还是其他文件或命名管道或设备句柄）建立联系，建立联系的工作由程序员完成， 当调用select()时，由内核根据IO状态修改fd_set的内容，由此来通知执行了select()的进程哪一Socket或文件可读或可写。
select主要用于socket通信当中，能监视我们需要的文件描述符变化。
Select在Socket编程中还是比较重要的，可是对于初学Socket的人来说都不太爱用Select写程序，他们只是习惯写诸如connect、accept、recv或recvfrom这样的阻塞程序（所谓阻塞方式block，顾名思义，就是进程或是线程执行到这些函数时必须等待某个事件的发生，如果事件没有发生，进程或线程就被阻塞，函数不能立即返回）。
可是使用Select就可以完成非阻塞（所谓非阻塞方式non-block，就是进程或线程执行此函数时不必非要等待事件的发生，一旦执行肯定返回，以返回值的不同来反映函数的执行情况，如果事件发生则与阻塞方式相同，若事件没有发生，则返回一个代码来告知事件未发生，而进程或线程继续执行，所以效率较高）方式工作的程序，它能够监视我们需要监视的文件描述符的变化情况——读写或是异常。
进程指定内核监听哪些文件描述符(最多监听1024个fd)的哪些事件，当没有文件描述符事件发生时，进程被阻塞；当一个或者多个文件描述符事件发生时，进程被唤醒。
当我们调用select()时：
1 | fd_r_list, fd_w_list, fd_e_list = select.select(rlist, wlist, xlist, [timeout]) |
可接受四个参数（前三个必须）:
select方法用来监视文件描述符(当文件描述符条件不满足时，select会阻塞)，当某个文件描述符状态改变后，会返回三个列表
1 | # coding=utf-8 |
1 | # coding=utf-8 |
1 | # coding=utf-8 |
运行server端和client端，客户端1,2均能连接。
但是以上程序并不能同时对客户端的输入同时响应处理(两个客户端连接都没关闭的情况下)，下面就来介绍I/O多路复用的例子
1 | # coding=utf-8 |
1 | # coidng=utf-8 |
分别运行服务端和客户端程序：
1 | python select_multi_server.py |
1 | python select_multi_client.py |
多次运行程序，你会发现客户端程序返回结果里的received后面的略有不同，你发现其中的原因了吗！
select, poll, epoll 都是I/O多路复用的具体的实现，之所以有这三个存在，其实是因为他们出现是有先后顺序的。
I/O多路复用这个概念被提出来以后， select是第一个实现 (1983 左右在BSD里面实现的)。
select 被实现以后，很快就暴露出了很多问题:
FD_SETSIZE。于是14年以后(1997年）一帮人又实现了poll, poll 修复了select的很多问题
其实拖14年那么久也不是效率问题， 而是那个时代的硬件实在太弱，一台服务器处理1千多个链接简直就是神一样的存在了，select很长段时间已经满足需求。
但是poll仍然不是线程安全的， 这就意味着，不管服务器有多强悍，你也只能在一个线程里面处理一组I/O流。你当然可以那多进程来配合了，不过然后你就有了多进程的各种问题。
于是5年以后, 在2002, 大神 Davide Libenzi 实现了epoll.
epoll 可以说是I/O 多路复用最新的一个实现，epoll 修复了poll 和select绝大部分问题, 比如：
epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中，而只在epoll_ctl时把current挂一遍（这一遍必不可少）并为每个fd指定一个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数，而这个回调函数会把就绪的fd加入一个就绪链表）。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd（利用schedule_timeout()实现睡一会，判断一会的效果，和select实现中的第7步是类似的）。
select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。
select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。
1 | import socket |
1 | import socket |
1 | #!/usr/bin/env python |
1 | import socket |
本文总结了I/O多路复用的三种方式select、poll、epoll，并使用python下select模块实现了以其为基础的时间戳服务端和客户端。
]]>Socket套接字
socket起源于Unix，而Unix/Linux基本哲学之一就是“一切皆文件”，对于文件用【打开】【读写】【关闭】模式来操作。
socket就是该模式的一个实现，socket即是一种特殊的文件，一些socket函数就是对其进行的操作（读/写IO、打开、关闭）
- socket和file的区别
1. file模块是针对某个指定文件进行【打开】【读写】【关闭】
2. socket模块是针对 服务器端 和 客户端 Socket 进行【打开】【读写】【关闭】
下面我们通过几种不同方式来实现时间戳服务器端和客户端：TCP、UDP、SocketServer TCP、Twisted Reactor TCP
1 | ss = socket() # 创建服务器套接字 |
1 | #!/usr/bin/env python |
1 | cs = socket() # 创建客户端套接字 |
1 | #!/usr/bin/env python |
1 | $ python tsTserv.py |
1 | $ python tsTclnt.py |
1 | ss = socket() # 创建服务器套接字 |
1 | #!/usr/bin/env python |
1 | cs = socket() # 创建客户端套接字 |
1 | #!/usr/bin/env python |
1 | #!/usr/bin/env python |
1 | #!/usr/bin/env python |
1 | #!/usr/bin/env python |
1 | #!/usr/bin/env python |
我们用几种方式实现了一个时间戳服务器和客户端,下次我们将学习IO多路复用及python下的select模块
gRPC 是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计。目前提供 C、Java 和 Go 语言版本，分别是：grpc, grpc-java, grpc-go. 其中 C 版本支持 C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持.
gRPC 基于 HTTP/2 标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。
在 gRPC 里客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端应用的方法，使得您能够更容易地创建分布式应用和服务。与许多 RPC 系统类似，gRPC 也是基于以下理念：定义一个服务，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个 gRPC 服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法。
gRPC 客户端和服务端可以在多种环境中运行和交互 - 从 google 内部的服务器到你自己的笔记本，并且可以用任何 gRPC 支持的语言来编写。所以，你可以很容易地用 Java 创建一个 gRPC 服务端，用 Go、Python、Ruby 来创建客户端。此外，Google 最新 API 将有 gRPC 版本的接口，使你很容易地将 Google 的功能集成到你的应用里。
gRPC 默认使用 protocol buffers，这是 Google 开源的一套成熟的结构数据序列化机制（当然也可以使用其他数据格式如 JSON）。正如你将在下方例子里所看到的，你用 proto files 创建 gRPC 服务，用 protocol buffers 消息类型来定义方法参数和返回类型。你可以在 Protocol Buffers 文档找到更多关于 Protocol Buffers 的资料。
1 | $ python -m pip install --upgrade pip |
1 | # 在之前激活的虚拟环境下运行 |
同时还要安装gRPC tools:
1 | pip install grpcio-tools googleapis-common-protos |
1 | git clone -b v1.15.0 https://github.com/grpc/grpc |
在 examples/python/helloworld 目录中:
1 | python greeter_server.py |
1 | python greeter_client.py |
Congratulations! You’ve just run a client-server application with gRPC.
创建我们例子的第一步是定义一个服务：一个 RPC 服务通过参数和返回类型来指定可以远程调用的方法。 gRPC 通过 protocol buffers 来实现。
我们使用 protocol buffers 接口定义语言来定义服务方法，用 protocol buffer 来定义参数和返回类型。客户端和服务端均使用服务定义生成的接口代码。
这里有我们服务定义的例子，在 helloworld.proto 里用 protocol buffers IDL 定义的。Greeter 服务有一个方法 SayHello ，可以让服务端从远程客户端接收一个包含用户名的 HelloRequest 消息后，在一个 HelloReply 里发送回一个 Greeter。这是你可以在 gRPC 里指定的最简单的 RPC - 你可以在教程里找到针对你选择的语言更多类型的例子。
1 | syntax = "proto3"; |
一旦定义好服务，我们可以使用 protocol buffer 编译器 protoc 来生成创建应用所需的特定客户端和服务端的代码 - 你可以生成任意 gRPC 支持的语言的代码，当然 PHP 和 Objective-C 仅支持创建客户端代码。生成的代码同时包括客户端的存根和服务端要实现的抽象接口，均包含 Greeter 所定义的方法。
1 | python -m grpc_tools.protoc -I . --python_out=. --grpc_python_out=. helloworld.proto |
这生成了 helloworld_pb2.py和helloworld_pb2_grpc.py两个文件 ，包含我们生成的客户端和服务端类，此外还有用于填充、序列化、提取 HelloRequest 和 HelloResponse 消息类型的类。
greeter_server.py 实现了 Greeter 服务所需要的行为。
正如你所见，Greeter 类通过实现 sayHello 方法，实现了从 proto 服务定义生成的helloworld_pb2.BetaGreeterServicer 接口：
1 | class Greeter(helloworld_pb2.BetaGreeterServicer)： |
为了返回给客户端应答并且完成调用：
用我们的激动人心的消息构建并填充一个在我们接口定义的 HelloReply 应答对象。将 HelloReply 返回给客户端。
需要提供一个 gRPC 服务的另一个主要功能是让这个服务实在在网络上可用。
greeter_server.py 提供了以下代码作为 Python 的例子。
1 | server = helloworld_pb2.beta_create_Greeter_server(Greeter()) |
在这里我们创建了合理的 gRPC 服务器，将我们实现的 Greeter 服务绑定到一个端口。然后我们启动服务器：服务器现在已准备好从 Greeter 服务客户端接收请求。我们将在具体语言对应的文档里更深入地了解这所有的工作是怎样进行的。
首先我们看一下我们如何连接 Greeter 服务器。我们需要创建一个 gRPC 频道，指定我们要连接的主机名和服务器端口。然后我们用这个频道创建存根实例。
1 | channel = implementations.insecure_channel('localhost', 50051) |
现在我们可以联系服务并获得一个 greeting ：
1 | response = stub.SayHello(helloworld_pb2.HelloRequest(name='you'), _TIMEOUT_SECONDS) |
greeter_client.py完整代码如下:
1 | import grpc |
你可以尝试用同一个语言在客户端和服务端构建并运行例子。或者你可以尝试 gRPC 最有用的一个功能 - 不同的语言间的互操作性，即在不同的语言运行客户端和服务端。每个服务端和客户端使用从同一过 proto 文件生成的接口代码，则意味着任何 Greeter 客户端可以与任何 Greeter 服务端对话。
1 | python route_guide_server.py |
1 | python route_guide_client.py |
helloworld 使用了最简单的 grpc 通信方式: 类似 http 协议的一次 request+response.
根据不同的业务场景, grpc 支持 4 种通信方式:
官方提供了一个 route guide service 的 demo, 应用到了这 4 种通信方式, 具体的业务如下:
1 | syntax = "proto3"; |
proto 中想要表示流式传输, 只需要添加 stream 关键字即可
同样的, 使用 protoc 生成代码:
1 | python -m grpc_tools.protoc --python_out=. --grpc_python_out=. -I. route_guide.proto |
生成了 route_guide_pb2.py 和route_guide_pb2_grpc.py 文件
1 | import json |
处理 json 的过程很简单, 解析 json 数据得到由坐标点组成的数组
怎么处理流式数据呢?. 答案是 for ... in + yield
1 | """The Python implementation of the gRPC route guide server.""" |
1 | """The Python implementation of the gRPC route guide client.""" |
1 | -------------- GetFeature -------------- |
本文主要介绍了grpc下python的基本运行方式，以及grpc的四种通信方式。
]]>MySQL datamasking using ProxySQL
操作环境一览:
- 操作系统： CentOS7
- MySQL: 5.5
- ProxySQL: 1.4.9
- ProxySQL主机IP: 192.168.48.100
- MySQL主库IP: 192.168.48.120
顾客表示例：
1 | +----+-----------+-------------+------------+------------------+----------+ |
我们可以在后端mysql主库上(192.168.48.120)创建该测试顾客表:
1 | CREATE USER 'proxysql'@'192.168.48.120' IDENTIFIED BY '123456'; |
1 | create database test; |
1 | GRANT ALL ON test.customers TO 'proxysql'@'192.168.48.120'; |
1 | proxysql需要依赖一些perl库，所以使用yum安装 |
1 | /etc/init.d/proxysql start |
将mysql服务器ip换成你的mysql服务器ip
1 | ProxySQL> INSERT INTO mysql_servers(hostgroup_id,hostname,port) |
在mysql主库(192.168.48.120)中添加账号proxysql及密码，以及授权
1 | GRANT ALL ON *.* TO 'proxysql'@'192.168.48.120' IDENTIFIED BY '123456'; |
在proxysql主机的mysql_users表中添加刚才创建的账号，proxysql客户端需要使用这个账号来访问数据库。
1 | load mysql users to runtime; |
ProxySQL有查询重写(Query Rewrite)功能，如果你想要重写查询，你必匹配查询的原始语句(使用match_pattern)，因为原始查询语句需要被重写。
1 | ProxySQL> INSERT INTO mysql_query_rules (rule_id,active,username,match_pattern,error_msg) |
1 | mysql -uproxysql -p123456 -h 192.168.48.100 -P 6033 |
1 | mysql> select * from test.customers; |
Yeah!我们根据配置的mysql_query_rules成功阻断了对customers表上的SELECT*操作.
1 | ProxySQL> INSERT INTO mysql_query_rules (rule_id,active,username,match_pattern,replace_pattern,apply) |
WOOhoo!我们成功实现了只显示卡号后4位！
1 | ProxySQL> SAVE MYSQL QUERY RULES TO DISK; |
我们需要对更多的表和字段做更多的datamasking(例如姓名字段做隐藏等)，我们就需要编写更多的查询规则(mysql_query_rules),并在管理连接中添加到mysql_query_rules表中.
]]>Python是面向对象的编程语言，它提供了一些内置的编程机制，使得开发者可以适当地实现多重继承。但是我们仍然应该尽量避开多重继承。
若一定要利用多重继承所带来的便利及封装性，那就编写mix-in类。mix-in是一种小型的类，它只定义了其他类可能需要提供的一套附加方法，而不定义自己的实例属性，此外，它也不要求使用者调用自己的__init__构造器。
现在，要把内存中的Python对象转换成字典形式，以便将其序列化，那我们就不妨把这个功能写成通用的代码，以便其他类使用。
1 | # ToDictMixin类 |
使用ToDictMixin把二叉树表示为字典:
1 | # 二叉树类 |
现在，我们可以把一大批互相关联的Python对象都轻松地转换成字典：
1 | tree = BinaryTree(1, |
mix-in的最大优势在于，使用者可以随时安插这些通用的功能，并能在必要的时候覆写它们。
下面定义的这个BinaryTree子类，会持有指向父节点的引用。如果采用默认的ToDictMixin.to_dict来处理它，那么程序就会因为循环引用而陷入死循环(parent)。
1 | class BinaryTreeWithParent(BinaryTree): |
解决办法是在BinaryTreeWithParent里覆写ToDictMixin._traverse方法，令该方法只处理与序列化有关的值，从而使mix-in的实现代码不会陷入死循环：
1 | # 覆写_traverse方法，不再遍历父节点，而是只把父节点所对应的数值插入到最终生成的字典里面 |
调用BinaryTreeWithParent.to_dict看看:
1 | root = BinaryTreeWithParent(1) |
定义了BinaryTreeWithParent._traverse方法之后，如果其他类的某个属性也是BinaryTreeWithParent类型，那么ToDictMixin会自动处理好这些属性:
1 | class NamedSubTree(ToDictMixin): |
多个mix-in之间也可以相互组合。例如，可以编写这样一个mix-in，它能够为任意类提供通用的JSON序列化功能。我们可以假定：继承了mix-in的哪个类，会提供名为to_dict的方法(此方法有可能是那个类通过多重继承ToDictMixin而具备的，也有可能不是)。
1 | # import json first |
请注意，JsonMixin类既定义了实例方法，有定义了类方法。这两种行为都可以通过mix-in来提供。在本例中，凡是想继承JsonMixin的类，只需符合两个条件即可:
我们用下面这个继承了mix-in组件的数据类来表示数据中心的拓扑结构:
1 | class DatacenterRack(ToDictMixin, JsonMixin): |
对这样的类进行序列化，以及从JSON中加载它，都是比较简单的。下面的这段代码，会重复执行序列化及反序列化操作，以验证这两个功能有没有正确地实现出来。
1 | serialized = """{ |
使用这种mix-in的时候，既可以像本例这样，直接继承多个mix-in组件，也可以先令继承体系中的其他类继承相关的mix-in组件，然后再令本类继承那些类，以达到同样的效果
本文主要记录在Ubuntu 16.04操作系统中搭建GitLab服务器的操作记录
GitLab 是一个用于仓库管理系统的开源项目。使用Git作为代码管理工具，并在此基础上搭建起来的web服务.可通过Web界面进行访问公开的或者私人项目,它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释.可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库,团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用.
1 | sudo apt-get install curl openssh-server ca-certificates postfix |
Internet Site这一项，确定1 | curl https://packages.gitlab.com/gpg.key 2> /dev/null | sudo apt-key add - &>/dev/null |
sudo vim /etc/apt/sources.list.d/gitlab-ce.list,加入如下语句：
1 | deb https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/ubuntu xenial main |
1 | sudo apt-get update |
会下载400多MB的，安装完成会占用1GB多的空间，请确保服务器空间充足
1 | sudo gitlab-ctl reconfigure |
1 | sudo gitlab-ctl status |
得到如下结果，说明Gitlab运行正常
1 | run: gitaly: (pid 25122) 1215s; run: log: (pid 17658) 2960s |
1 | sudo vim /etc/gitlab/gitlab.rb |
1 | - external_url 'http://gitlab.example.com' |
1 | ## 开放自定义端口访问(上面定义的9876端口) |
sshd和postfix服务1 | sudo service sshd start |
浏览器输入http://192.168.2.200:9876(如果使用的默认端口则为http://192.168.2.200),将192.168.2.200替换为你的服务器地址.
第一次进入后会出现修改密码的页面
输入密码确认。其默认用户为root
然后可以修改用户名密码或者注册新用户等
当然也可以从github等仓库导入
这和github等相同
]]>快来动手试试吧，简直太棒了
Cookiecutter可以让你快速从模板中建立工程，cookiecutter-django则是Django的模板，可以快速生成Django大型项目模板。其特性如下:
首先, get Cookiecutter.相信我,它棒极了:
1 | pip install "cookiecutter>=1.4.0" |
然后用Cookiecutter-django来生成一个Django项目:
1 | cookiecutter https://github.com/audreyr/cookiecutter-pypackage.git |
你需要在引导下填一些values,例如:
1 | Cloning into 'cookiecutter-django'... |
根据你的需要来选择一些选项。注: project_slug是你的项目名(在路径中体现)
进入项目根目录:
1 | cd my_first_django_project |
在github创建一个repo,关联你的项目，并首次push:
1 | git init |
选择Django安装版本(修改requirements/base.txt):
1 | django==1.11.2 |
数据库如果选择了Postgresql(Postgresql的安装使用情参考Postgresql安装配置),需安装psycopg2依赖:
1 | ## requirements/local.txt |
在激活的虚拟环境下安装依赖:
1 | $ pip install -r requirements\local.txt |
如果生成项目时选项pycharm填入了y,下面我们来配置一下。
File - Settings -> Languages and Frameworks -> Django.
Enable Django Support我们需要为Django数据库配置Postgresql数据库地址，我们点击Environment variavles 的 ... ,添加DATABASE_URL变量(注DATABASE_URL在conf.setting中使用):
1 | python manage.py migrate |
阅读英文指南:
1 | https://cookiecutter-django.readthedocs.io/en/latest/ |
python协程的演化
Python由于众所周知的GIL的原因,同一时刻只能有一个线程在运行，那么对于CPU密集的程序来说，线程之间的切换开销就成了拖累，而以I/O为瓶颈的程序正是协程所擅长的：
多任务并发（非并行），每个任务在合适的时候挂起（发起I/O）和恢复(I/O结束)*
Python中的协程经历了很长的一段发展历程。其大概经历了如下三个阶段：
我们用斐波那契数列做个例子
1 | def normal_fib(n): |
如果我们仅仅是需要拿到斐波那契序列的第n位，或者仅仅是希望依此产生斐波那契序列，那么上面这种传统方式就会比较耗费内存。这时生成器的特性就派上用场了—> yield!!!
我们用yield实现菲波那切数列。
1 | def gen_fib(n): |
当一个函数中包含yield语句时，python会自动将其识别为一个生成器。这时fib(20)并不会真正调用函数体，而是以函数体生成了一个生成器对象实例。
yield在这里可以保留gen_fib函数的计算现场，暂停gen_fib的计算并将b返回。而将fib放入for…in循环中时，每次循环都会调用next(fib(20))，唤醒生成器，执行到下一个yield语句处，直到抛出StopIteration异常。此异常会被for循环捕获，导致跳出循环。
send 事件驱动，生成器进化成协程
1 | import time |
协程更多详细信息请移步python coroutine这里~
yield from用于重构生成器，简单的，可以这么使用：
1 | def copy_fib(n): |
这种使用方式很简单，但远远不是yield from的全部。yield from的作用还体现可以像一个管道一样将send信息传递给内层协程，并且处理好了各种异常情况，因此，对于coro_fib也可以这样包装和使用：
1 | def copy_coro_fib(n): |
asyncio是一个基于事件循环的实现异步I/O的模块。通过yield from，我们可以将协程的控制权交给事件循环，然后挂起当前协程；之后，由事件循环决定何时唤醒协程,接着向后执行代码。
使用asyncio.coroutine装饰器
1 | # 并发处理两个快慢不一的斐波那契生成函数 |
运行结果如下:
1 | ... |
清楚了asyncio.coroutine和yield from之后，在Python3.5中引入的async和await就不难理解了：
可以将他们理解成asyncio.coroutine/yield from的完美替身。当然，从Python设计的角度来说，async/await让协程表面上独立于生成器而存在，将细节都隐藏于asyncio模块之下，语法更清晰明了。
async/await 示例:
1 | # 使用 async/await 关键字 |
可以发现相比上面yield from的版本只改变了以下两点:
async关键字，更加清晰表明这是一个协程yield from 换成了await关键字示例程序中都是以sleep为异步I/O的代表，在实际项目中，可以使用协程异步的读写网络、读写文件、渲染界面等，而在等待协程完成的同时，CPU还可以进行其他的计算。协程的作用正在于此。
]]>考虑用concurrent.futures来实现平行计算或并发处理
编写Python程序时,我们可以利用CPU的多核心通过平行计算来提升计算任务的速度。很遗憾，Python的全局解释器(GIL)的存在使得我们没有办法用线程实现真正的平行计算。
为了实现平行计算，我们可以考虑用C语言扩展或者使用诸如Cython和Numba等开源工具迁移到C语言。但是这样做大幅增加了测试量和风险。于是我们思考一下：有没有一种更好的方式，只需使用少量的Python代码，即可有效提升执行效率，并迅速解决复杂的计算问题。
我们可以试着通过内置的concurrent.futures模块来利用内置的multiprocessing模块实现这种需求。这样的做法会以子进程的形式，平行运行多个解释器，从而利用多核心CPU来提升执行速度(子进程与主解释器相分离，所以它们的全局解释器锁也是相互独立的)。
现在给出一个列表，列表里每个元素是一对数，求出每对数的最大公约数
1 | numbers = [(1963309, 2265973), (2030677, 3814172), |
1 |
|
我们用map来试运行一下:
1 | import time |
下面我们用conccurrent.futures来模拟多线程和多进程
concurretn.futures的ThreadPoolExecutor1 | from concurrent.futures import ThreadPoolExecutor |
两个线程用了和上面差不多的时间，而且比上面还慢一些，说明多线程并不能平行计算，而且开线程也有耗费。
concurrent.futures的ProcessPoollExecutor1 | from concurrent.futures import ProcessPoolExecutor |
在双核电脑上运行上面程序发现比之前两个版本运行快很多。这是因为ProcessPoolExecutor会利用multiprocessing模块所提供的的底层机制来逐步完成下列操作：
为了实现平行计算，multiprocessing模块和ProcessPoolExecutor类在幕后做了大量的工作。如果改用其他的语言来写，那么开发者只需一把同步锁或一项原子操作，就可以把线程之间的通信过程协调好。而在Python中，我们却必须使用开销较高的multiprocessing模块,其开销之所以大，原因就在于主进程与子进程之间，必须进行序列化和反序列化操作，这些是导致大量开销的来源。
对于某些较为孤立，且数据利用率高的任务来说，上述方案非常适合。如果执行的运算不符合上述特征，那么multiprocessing所产生的的开销可能并不能使程序加速。在这种情况下，可以求助multiprocessing所提供的的一些高级机制，如内存共享(shared memory)、跨进程锁定(cross-process lock)、队列(queue)和代理(proxy)等。
用concurrent.futures的ThreadPoolExecutor类处理对于大量I/O操作的并发任务的示例。非常值得参考的实现。
flags_common.py是一些默认参数和函数接口以及argparse。
flags_sequential.py是单线程依序下载以及进度条显示实现。
flags_threadpool.py是利用concurrent.futures的多线程操作实现。
1 | """Utilities for second set of flag examples. |
1 | """Download flags of countries (with error handling). |
1 | """Download flags of countries (with error handling). |
考虑用协程来并发的运行多个函数
我们可以用线程来运行多个函数，使这些函数看上去好像是在同一时间得到执行的。然而，线程有三个显著的缺点：
Lock, Queue等)来协调这些线程，这使得多线程的代码，要比单线程的过程式代码更加难懂。这些复杂的多线程代码，会逐渐令程序变得难以扩展和维护。占用大量内存，每个正在执行的线程，大约占据8MB内存。如果只开十几个线程，多数计算机还是可以承受的。启动的开销比较大。如果程序不停地依靠创建新线程来同时执行多个函数，并等待这些线程结束，那么使用线程所引发的开销，就会拖慢整个程序的速度。Python的协程(coroutine)可以避免上述问题，它使得Python程序看上去好像是在同时运行多个函数。协程的实现方式，实际上是对生成器的一种扩展。启动生成器协程所需的开销，与调用函数的开销相仿。处于活跃状态的协程，在其耗尽之前，只会占用不到1KB的内存。
每当生成器函数执行到yield表达式的时候，消耗生成器的那段代码，就通过send方法给生成器回传一个值。而生成器在手熬了经由send函数所传进来的这个值后，这个值会绑定给yield关键字左边的变量；如果yield关键字右边有表达式，那么yield表达式右侧的内容会当成send方法的返回值(没有的话其实返回的是None)，返回给外界(调用方).关键的一点是，协程在 yield 关键字所在的位置暂停执行。在赋值语句中， = 右边的代码在赋值之前执行。下面我们结合两个例子来看看。
1 | def my_coroutine(): |
注1: 在生成器上面调用send方法，我们要先调用next函数(这叫预激协程)，以便将生成器推进到第一条yield表达式那里
该示例在协程每收到一个数值，就会产出当前所统计到的最大值
1 | def maximize(): |
上面的代码范例中，第一条yield语句中的yield关键字后面没有跟随内容，其意思是，把外面传进来的首个值，当成目前的最大值。
此后生成器会屡次执行while循环中的那条yield语句，以便将当前统计到的最大值告诉外界，同时等候外界传入下一个待考察的值。
协程在yield关键字所在的位置暂停执行。在赋值语句中， = 右边的代码在赋值之前执行。即各个阶段都在yield表达式中结束，先产出值然后在yield出暂停，等待外界传入值。下一个阶段都从那一行代码开始
协程可以通过yield的输出值来推进其他的生成器函数，使得那些生成器函数也执行到它们各自的下一条yield比到时处。接连推进多个独立的生成器，即可模拟出Python线程的并发行为，令程序看上去好像是在同时运行多个函数
从一个字典中读取虚构的七年级男女学生的体重和身高。例如，’boys;m’ 键对应于 9 个男学生的身高（单位是米）， ‘girls;kg’ 键对应于 10 个女学生的体重（单位是千克）。这个脚本把各组数据传给前面定义的 averager 协程，然后生成一个报告。
1 | # -*- coding: utf-8 -*- |
1- 与示例 16-13 中的 averager 协程一样。这里作为子生成器使用。
2- main 函数中的客户代码发送的各个值绑定到这里的 term 变量上。
3- 至关重要的终止条件。如果不这么做，使用 yield from 调用这个协程的生成器会永
远阻塞。
4- 返回的 Result 会成为 grouper 函数中 yield from 表达式的值。
5- grouper 是委派生成器。
6- 这个循环每次迭代时会新建一个 averager 实例；每个实例都是作为协程使用的生成器对象。
7- grouper 发送的每个值都会经由 yield from 处理，通过管道传给 averager 实例。 grouper 会在 yield from 表达式处暂停，等待 averager 实例处理客户端发来的值。 averager 实例运行完毕后，返回的值绑定到 results[key] 上。 while 循环会不断创建 averager 实例，处理更多的值。
8- main 函数是客户端代码，用 PEP 380 定义的术语来说，是“调用方”。这是驱动一切的函数
9- group 是调用 grouper 函数得到的生成器对象，传给 grouper 函数的第一个参数是results，用于收集结果；第二个参数是某个键。 group 作为协程使用。
10- 预激 group 协程。
11- 把各个 value 传给 grouper。传入的值最终到达 averager 函数中 term = yield 那一行； grouper 永远不知道传入的值是什么。
12- 把 None 传入 grouper，导致当前的 averager 实例终止，也让 grouper 继续运行，再创建一个 averager 实例，处理下一组值。
生存(alive,用*表示)或空白(empty,用-表示)状态。基于规则我们可以将整个程序分成三个阶段:count_neighbors, step_cell, display
我们定义一个协程来获取周围细胞的生存状态。协程会产生一个自定义的Query对象，每个yield表达式的结果，要么是ALIVE，要么是EMPTY。其后count_neighbors生成器会根据相邻细胞的状态，来返回本细胞周围的存活细胞数(生成器return语句在python3中才可用，实际是把结果作为StopIteration异常的value属性传给了调用者)
1 | from collections import namedtuple |
我们用虚构的数据来测试一下这个count_neighbors协程.
下面这段代码，会针对本细胞的每个相邻细胞，向生成器索要一个Query对象，并产出Query namedtuple。然后通过send方法把状态发给协程，使count_neighbors协程可以收到上一个Query对象所对应的状态(注意我们上文提到的yield表达式一行执行顺序–先右再左)
1 | it = count_neighbors(10, 5) |
计算出了细胞周围的存活数量，我们就需要根据这个数量来更新细胞的状态。并把得到的状态传给外部调用者。
这里我们自定义了一个Transition对象，它表示坐标位于(y,x)的细胞的下一轮的状态。
1 | Transition = namedtuple('Transition', ('y', 'x', 'state')) # state即是下一轮的状态 |
下面我们用虚拟数据来测试一下step_cell协程：
1 | it = step_cell(10, 5) |
上面演示了在网格中一个细胞的一次前进。下面我们把step_cell组合到新的simulate协程之中。新的协程会多次通过yield from 表达式，来推进网格中的每一个细胞。把每个细胞处理完后，simulate协程会产生TICK对象，用以表示当前这一代的细胞已经全部迁移完毕。
1 | TICK = object() |
为了在真实环境中运行simulate，我们需要把网格中的每个细胞状态表示出来。我们定义一个Grid类，来代表整张网格：
1 | class Grid(object): |
我们定义了__getitem__和__setitem__两个元方法来设置和获取state。下面我们看一下Grid的显示：
1 | grid = Grid(5, 9) |
这个函数把网格内的所有细胞都向前推进一步，待各细胞状态迁移完成后，这些细胞就构成了一张新的网格，该函数会把新的网格返回给调用者。
1 | def live_a_generation(grid, sim): |
live_a_generation是将当前细胞向前推进一步，现在我们把每一代的结果都显示出来
1 | class ColumnPrinter(object): |
我们来看看效果：
1 | columns = ColumnPrinter() |
上面这套的实现方式，其最大优势在于：开发者能够在不修改game_logic函数的前提下，更新该函数外围的那些代码。
上面这套范例代码，演示了如何用协程来分离程序中的各个关注点，而关注点的分离，正是一条重要的原则。
线性方法的优化
三种线性方法的优化方法：
Limited-memory BFGS(L-BFGS)有限记忆BFGSNormal equation solver for weighted least square用于加权最小二乘法的正态方程求解器Iteratively reweighted least squares(IRLS)迭代重新加权最小二乘 L-BFGS是拟牛顿方法家族里的一个优化算法，解决min w∈R d f(w)形式的优化问题。L-BFGS方法以二次方程来逼近目标函数来构造Hessian矩阵，不考虑目标函数的二阶偏导数。Hessian矩阵由先前的迭代评估逼近，所以不像直接使用牛顿方法一样可垂直扩展（训练特征的数目）。所以L-BFGS通常比其他一阶优化方法能更快收敛。
象限有限记忆拟牛顿(OWL-QN)算法是L-BFGS的扩展，它可以有效处理L1和弹性网格正则化。L-BFGS在Spark MLlib中用于线性回归、逻辑回归、AFT生存回归和多层感知器的求解。
MLlib 通过WeightedLeastSquares实现了加权最小二乘法的方程求解器。
Spark MLlib目前支持正态方程的两种求解器：Cholesky分解法和拟牛顿法(L-BFGS / OWL-QN)。乔列斯基因式分解依赖于正定的协方差矩阵（即数据矩阵的列必须是线性无关的），并且如果违反这种条件将会失败。即使协方差矩阵不是正定的，准牛顿方法仍然能够提供合理的解，所以在这种情况下，正规方程求解器也可以退回到拟牛顿法。对于LinearRegression和GeneralizedLinearRegression估计，这种回退目前总是启用的。
WeightedLeastSquares支持L1，L2和弹性网络正则化，并提供启用或禁用正则化和标准化的选项。在没有L1正则化的情况下（即α = 0），存在解析解，可以使用乔列斯基(Cholesky)或拟牛顿(Quasi-Newton)求解器。当α > 0时 不存在解析解，而是使用拟牛顿求解器迭代地求出系数。
为了使正态方程有效，WeightedLeastSquares要求特征数不超过4096个。对于较大的问题，使用L-BFGS代替。
MLlib 通过IterativelyReweightedLeastSquares实现迭代重新加权最小二乘（IRLS）。它可以用来找到广义线性模型(GLM)的最大似然估计，在鲁棒回归和其他优化问题中找到M估计。有关更多信息，请参阅迭代重新加权的最小二乘法以获得最大似然估计，以及一些鲁棒性和抗性替代方法。
它通过以下过程迭代地解决某些优化问题：
由于它涉及到WeightedLeastSquares每次迭代求解加权最小二乘（WLS）问题，因此它还要求特征数不超过4096个。目前IRLS被用作GeneralizedLinearRegression的默认求解器。
更多详细信息请查阅Spark ml-advanced
模型选择, 超参调整
ML Tuning: model selection(模型选择) and hyperparameter tuning(超参调整)
本节介绍如何使用MLlib的工具来调整ML算法和管道。内置的交叉验证和其他工具允许用户优化算法和管道中的超参数。
ML中的一个重要任务是Model Selection(选择模型)，或者使用数据为给定任务找到最佳模型或参数。这也被称为Tuning(调整)。调整可以是以针对三个Estimators算子如LogisticRegression进行调整，也可以对整个Pipeline进行调整。用户可以一次对Pipeline整体进行调整，而不是对Pipeline的每个元素单独进行调整。
MLlib支持使用CrossValidator和TrainValidationSplit的工具进行模型选择。这些工具需要下列项目：
在较高层面上，这些模型选择工具的工作如下：
其中，对于回归问题评估器可选择RegressionEvaluator，二值数据可选择BinaryClassificationEvaluator，多分类问题可选择MulticlassClassificationEvaluator。评估器里默认的评估准则可通过setMetricName方法重写。
用户可通过ParamGridBuilder构建参数网格。
CrossValidator将数据集划分为若干子集分别地进行训练和测试。如当k＝3时，CrossValidator产生3个训练数据与测试数据对，每个数据对使用2/3的数据来训练，1/3的数据来测试。对于一组特定的参数表，CrossValidator计算基于三组不同训练数据与测试数据对训练得到的模型的评估准则的平均值。确定最佳参数表后，CrossValidator最后使用最佳参数表基于全部数据来重新拟合Estimator。
示例：
注意对参数网格进行交叉验证的成本是很高的。如下面例子中，参数网格hashingTF.numFeatures有3个值，lr.regParam有2个值，CrossValidator使用2折交叉验证。这样就会产生(3*2)*2 = 12中不同的模型需要进行训练。在实际的设置中，通常有更多的参数需要设置，且我们可能会使用更多的交叉验证折数（3折或者10折都是经使用的）。所以CrossValidator的成本是很高的，尽管如此，比起启发式的手工验证，交叉验证仍然是目前存在的参数选择方法中非常有用的一种。
有关API的更多详细信息，请参阅CrossValidatorPython文档。
1 | from pyspark.ml import Pipeline |
output:
1 | Row(id=4, text='spark i j k', probability=DenseVector([0.627, 0.373]), prediction=0.0) |
Find full example code at “examples/src/main/python/ml/cross_validator.py” in the Spark repo.
除了交叉验证以外，Spark还提供 TrainValidationSplit 用以进行超参数调整。和交叉验证评估K次不同， TrainValidationSplit 只对每组参数评估一次。因此它计算代价更低，但当训练数据集不是足够大时，其结果可靠性不高。
与交叉验证不同， TrainValidationSplit仅需要一个训练数据与验证数据对。使用训练比率参数将原始数据划分为两个部分。如当训练比率为0.75时，训练验证分裂使用75%数据以训练，25%数据以验证。
与交叉验证相同，确定最佳参数表后，训练验证分裂最后使用最佳参数表基于全部数据来重新拟合Estimator。
有关API的更多详细信息，请参阅TrainValidationSplitPython文档。
1 | from pyspark.ml.evaluation import RegressionEvaluator |
output:
1 | +--------------------+--------------------+--------------------+ |
Find full example code at “examples/src/main/python/ml/train_validation_split.py” in the Spark repo.
更多相关信息请查阅Spark ml-tuning
Frequent Pattern Mining
Frequent Pattern Mining：频繁项目，项目集，子序列或其他子结构的挖掘通常是分析大规模数据集的第一步，这已经成为数据挖掘领域的一个活跃的研究课题。我们将用户引用到Wikipedia的关联规则学习中以获取更多信息。
FP-growth算法在Han等人的文章“ Mining frequent patterns without candidate generation”中描述，其中“FP”代表频繁模式。给定交易数据集，FP增长的第一步是计算项目频率并识别频繁项目。与为同样目的而设计的Apriori-like算法不同，FP-growth的第二步使用后缀树（FP-tree）结构来编码事务，而不显式生成候选集合，这通常是耗费的。第二步之后，可以从FP-tree中提取频繁项目集。在这里spark.mllib，我们实现了FP-growth的并行版本，称为PFP(详细请查看Li等人：PFP:Parallel FP-growth for query recommendation)。PFP根据事务的后缀分配增长的FP-树的工作，因此比单机实现更具可扩展性。
spark.ml FP的增长实现需要以下（超）参数：
minSupport
一个项目组的最小支持被确定为频繁的。例如，如果一个项目在5个交易中出现3个，则它具有3/5 = 0.6的支持。
minConfidence
生成关联规则的最低置信度。信心是一个关联规则被发现是真实的指标。例如，如果交易项目集X出现4次，X 并且Y只出现2次，则规则的置信度为X => Y2/4 = 0.5。该参数不会影响对频繁项目集的挖掘，但指定从频繁项集生成关联规则的最小置信度。
numPartitions
用于分配工作的分区数量。默认情况下，param未设置，并使用输入数据集的分区数量。
FPGrowthModel规定：
freqItemsets
DataFrame格式的频繁项目集(“items”[Array]，“freq”[Long])
associationRulesminConfidence以DataFrame(“antecedent”[Array],”consequent”[Array],
“confidence”[Double])格式在上面生成的关联规则。
transform
对于每个交易itemsCol，transform方法将比较其项目与每个关联规则的前提。如果记录包含特定关联规则的所有前提条件，则该规则将被视为适用，并将其结果添加到预测结果中。变换法将所有适用规则的后果总结为预测。预测列具有相同的数据类型，itemsCol并且不包含中的现有项目itemsCol。
1 | from pyspark.ml.fpm import FPGrowth |
output:
1 | +---------+----+ |
Find full example code at “examples/src/main/python/ml/fpgrowth_example.py” in the Spark repo.
更多相关信息请查阅Spark FPGrowth
推荐算法
协同过滤常被用于推荐系统。这类技术目标在于填充“用户－商品”联系矩阵中的缺失项。Spark.ml目前支持基于模型的协同过滤，其中用户和商品以少量的潜在因子来描述，用以预测缺失项。Spark.ml使用交替最小二乘（ALS）算法来学习这些潜在因子。
spark.ml有以下参数：
注意：用于ALS的基于DataFrame的API目前仅支持整数类型的用户和项目ID。用户和项目ID列支持其他数字类型，但ID必须在整数值范围内。
基于矩阵分解的协同过滤的标准方法中，“用户－商品”矩阵中的条目是用户给予商品的显式偏好，例如，用户给电影评级。然而在现实世界中使用时，我们常常只能访问隐式反馈（如意见、点击、购买、喜欢以及分享等），在spark.ml中我们使用“隐式反馈数据集的协同过滤“来处理这类数据。本质上来说它不是直接对评分矩阵进行建模，而是将数据当作数值来看待，这些数值代表用户行为的观察值（如点击次数，用户观看一部电影的持续时间）。这些数值被用来衡量用户偏好观察值的置信水平，而不是显式地给商品一个评分。然后，模型用来寻找可以用来预测用户对商品预期偏好的潜在因子。
我们调整正则化参数regParam来解决用户在更新用户因子时产生新评分或者商品更新商品因子时收到的新评分带来的最小二乘问题。这个方法叫做“ALS-WR”,它降低regParam对数据集规模的依赖，所以我们可以将从部分子集中学习到的最佳参数应用到整个数据集中时获得同样的性能。
在使用ALSModel进行预测时，通常会遇到测试数据集中用户和/或物品在训练模型期间不存在的情况。这通常发生在两种情况下：
默认情况下，Spark NaN在当用户和/或物品因素不存在于模型中时，Spark在ALSModel.transform时使用NAN作为预测。这在生产系统中可能是有用的，因为它表示一个新的用户或物品，所以系统可以做出一个决定，作为预测。
然而，这在交叉验证期间是不好的，因为任何NaN预测值都将导致NaN评估度量的结果（例如在使用RegressionEvaluator时）。这使得模型无法作出选择。
Spark允许用户将coldStartStrategy参数设置为“drop”，以便删除DataFrame包含NaN值的预测中的任何行。评估指标然后在非NaN数据上计算，并且这是有效的。下面的例子说明了这个参数的用法。
注意：目前支持的冷启动策略是“nan”（上面提到的默认行为）和“drop”。未来可能会支持进一步的策略。
在以下示例中，我们将从MovieLens数据集中加载评分数据 ，每行由用户，电影，评分和时间戳组成。然后，我们训练一个ALS模型，默认情况下，这个模型的评级是明确的（implicitPrefs是false）。我们通过测量评级预测的均方根误差来评估推荐模型。
1 | from pyspark.ml.evaluation import RegressionEvaluator |
output:
1 | Root-mean-square error = 1.742790392299329 |
Find full example code at “examples/src/main/python/ml/als_example.py” in the Spark repo.
如果评分矩阵是从另一个信息源（即它是从其他信号推断）得出，可以设置implicitPrefs以true获得更好的效果：
1 | als = ALS(maxIter=5, regParam=0.01, implicitPrefs=True, |
更多相关信息请查阅spark 协同过滤
聚类算法
本节介绍MLlib中的聚类算法(KMeans, LDA, GMM)。在基于RDD-API聚类指南里还提供了有关这些算法的相关信息。
K-means是一个常用的聚类算法来将数据点按预定的簇数进行聚集。K-means算法的基本思想是：以空间中k个点为中心进行聚类，对最靠近他们的对象归类。通过迭代的方法，逐次更新各聚类中心的值，直至得到最好的聚类结果。
假设要把样本集分为c个类别，算法描述如下：
（1）适当选择c个类的初始中心；
（2）在第k次迭代中，对任意一个样本，求其到c个中心的距离，将该样本归到距离最短的中心所在的类；
（3）利用均值等方法更新该类的中心值；
（4）对于所有的c个聚类中心，如果利用（2）（3）的迭代法更新后，值保持不变，则迭代结束，否则继续迭代。
MLlib工具包含并行的K-means++算法，称为kmeans||。Kmeans是一个Estimator，它在基础模型之上产生一个KMeansModel。
| Param name(参数名称) | Type(s)(类型) | Default(默认) | Description(描述) |
|---|---|---|---|
| featuresCol | Vector | “features” | Feature vector(特征向量) |
| Param name(参数名称) | Type(s)(类型) | Default(默认) | Description(描述) |
|---|---|---|---|
| predictionCol | Int | “prediction” | Predicted cluster center(预测的聚类中心) |
1 | from pyspark.ml.clustering import KMeans |
output:
1 |
|
Find full example code at “examples/src/main/python/ml/kmeans_example.py” in the Spark repo.
LDA（Latent Dirichlet Allocation）是一种文档主题生成模型，也称为一个三层贝叶斯概率模型，包含词、主题和文档三层结构。所谓生成模型，就是说，我们认为一篇文章的每个词都是通过“以一定概率选择了某个主题，并从这个主题中以一定概率选择某个词语”这样一个过程得到。文档到主题服从多项式分布，主题到词服从多项式分布。
LDA是一种非监督机器学习技术，可以用来识别大规模文档集（document collection）或语料库（corpus）中潜藏的主题信息。它采用了词袋（bag of words）的方法，这种方法将每一篇文档视为一个词频向量，从而将文本信息转化为了易于建模的数字信息。但是词袋方法没有考虑词与词之间的顺序，这简化了问题的复杂性，同时也为模型的改进提供了契机。每一篇文档代表了一些主题所构成的一个概率分布，而每一个主题又代表了很多单词所构成的一个概率分布。
LDA被实现为一个Estimator,既支持EMLDAOptimizer和OnlineLDAOptimizer，并生成一个LDAModel作为基础模型。如果需要的话，专家用户可以将EMLDAOptimizer生成的LDAModel映射到一个DistributedLDAModel
1 | from pyspark.ml.clustering import LDA |
output:
1 | The lower bound on the log likelihood of the entire corpus: -797.8018456907539 |
Find full example code at “examples/src/main/python/ml/lda_example.py” in the Spark repo.
二分K均值算法是一种层次聚类算法，使用自顶向下的逼近：所有的观察值开始是一个簇，递归地向下一个层级分裂。分裂依据为选择能最大程度降低聚类代价函数（也就是误差平方和）的簇划分为两个簇。以此进行下去，直到簇的数目等于用户给定的数目k为止。二分K均值常常比传统K均值算法有更快的计算速度，但产生的簇群与传统K均值算法往往也是不同的。
BisectingKMeans是一个Estimator，在基础模型上训练得到BisectingKMeansModel。
1 | from pyspark.ml.clustering import BisectingKMeans |
output:
1 | Within Set Sum of Squared Errors = 0.11999999999994547 |
Find full example code at “examples/src/main/python/ml/bisecting_k_means_example.py” in the Spark repo.
混合高斯模型描述数据点以一定的概率服从k种高斯子分布的一种混合分布。Spark.ml使用EM算法给出一组样本的极大似然模型。
GaussianMixture被实现为一个Estimator,并生成一个GaussianMixtureModel基本模型。
| Param name | Type(s) | Default | Description |
|---|---|---|---|
| featuresCol | Vector | “features” | Feature vector |
| Param name | Type(s) | Default | Description |
|---|---|---|---|
| predictionCol | Int | “prediction” | Predicted cluster center |
| probabilityCol | Vector | “probability” | Probability of each cluster |
1 | from pyspark.ml.clustering import GaussianMixture |
output:
1 | Gaussians shown as a DataFrame: |
Find full example code at “examples/src/main/python/ml/gaussian_mixture_example.py” in the Spark repo.
更多相关信息请查阅Spark Clustering文档