Python中使用 sqlalchemy 访问数据库和简单操作

在我们的数据仓库设计中,python 是我们用来连接各个数据库和应用逻辑的纽带。python 几乎无所不能,反正性能上有要求的就交给 java,要快速开发的逻辑多变的就交给 python。

python 中访问数据库最有名的就是 sqlalchemy 包了。

from sqlalchemy import create_engine, MetaData, Table
from sqlalchemy.sql import select, insert

engine = create_engine('mysql+pymysql://macmini:***@192.168.199.***:3306/test?charset=utf8mb4', pool_recycle=3600)
meta = MetaData(bind=engine)
students = Table("students", meta, autoload=True, autoload_with=engine)

conn = engine.connect()

s = select([students])
result = conn.execute(s)

print(s)

for row in result:
    print(row)

 

通过 sqlalchemy 访问 mysql 数据库,需要先创建一个 engine 对象,输入 mysql 的 ip 地址和用户名密码。后面的就简单了。

sqlalchemy 访问数据库可以用 orm 或者称之为 Expression Language 的方法,上面例子里面的 select 方法就是属于 sqlaclchemy 的快速语言方法,s 变量是用来检验的生成的 sql 语句,

看一下结果就很明白了,列出了sql语句(一般是不需要的),以及 select 的查询结果:

SELECT students.id, students.name, students.sex, students.age, students.tel
FROM students

(1, ‘王刚’, ‘男’, 20, ‘13811371377’)
(2, ‘张三’, ‘男’, 30, ‘16512341234’)

下面则是 insert 的用法,是不是非常简洁,这样的写法避免了 sql 语句的啰嗦,抽象起来,就可以用在业务逻辑复杂多变的场景了,即便是所谓写死的业务逻辑,这样也比较容易看懂,而一般的 sql 语句非常不容易调试:

conn.execute(students.insert(), [
    {'name' : '张三', 'sex' : '男', 'age' : 30, 'tel' : '16512341234'},
    ])

 

PyCharm 开发环境中出现中文显示不正常怎么办

说明一下,不是说python程序代码中文显示为,也不是说python程序怎么输出中文,而是 pycharm,这个开发神器有时候也会莫名其妙的让开发环境 ide 里面的中文显示不正常,比如中文的文件名,或者 git 提交的中文注释,都变成了一个个框。

我再mac 下用新版本的 pycharm 5.0.3 ,一切正常,但是到了windows 下,就出现了上面说的问题。解决方法就是到 Settings-Appearance,下面有一个字体选择,修改为 微软雅黑,肯定就没事了,ide 会提示这是覆盖了默认的字体什么的,也不用管了。

好了,中文文件名等都正常了。和 utf-8 之类没有关系。

Jupyter 4.1 发布

一开始学习python的时候,并没有觉得当时还叫 ipython 有什么太大用处,不过最近因为研究 pandas 之类,交互很多,即便用 pycharm 这样强大的工具,也觉得有点不方便,每次运行-修改-再运行,浪费了不少时间,而 ipython,现在的 Jupyter,的确是很方便,python社区的力量着实强大而令人佩服。想起曾经也是强大的 delphi,多少有点唏嘘。

Jupyter 4.10 更新内容还是不少,详情看这里

用 conda 安装很方便。

其中的重新快速启动 python 内核功能不错,至少我之前测试 pandas 处理千万条记录的时候,还是一直需要这样的暴力方式的。

牵手

这半年,看着家里好些老人,身体抱恙,在病床上。

此刻的中国,看病的确是劳民伤财,也无奈的很。

之前算过,按照现在的价钱,即便有医保之类,一个人至少要留个30万,才能生得起病,看得起病。

这也是说说容易,还是平时心情舒畅最重要。

放下名利之心,否则,心中总是牵挂着那些,怎么会轻松。

医院里,嘈杂得很,想明白这些,不得不想明白这些,挺好的。

父母,爱人,长辈和小辈,牵手不容易,不要轻易放弃。

2016 伊始二三事

不得不承认,已经是中年大叔的我,要面对的事情一下子多了起来,碰的不巧,就会一起压过来。

刘兄又从美国回来,以前cc的几位老同事,小聚了一下,席间大数据与各类计算机名词乱飞,想起来,当年在cc时候,我们也是一起认真做事,只是后来实在有点无聊,绝对算是人生一段经历。印象中最深刻的有一次,小年夜吧,我,刘,侯,算是值班,中午在对面的一个什么咖啡馆吃简餐,讨论着iphone的游戏吧,回到空荡荡的办公室,几个人都有点无聊。而因为有过那样的几年,我特别珍惜此刻,我知道很多习惯了的东西会以为是本该如此,而忽略了背后的不容易。

一位工作五年的同事,要去创业,在大家最忙碌的时候,一直想着这些,也不是时间管理很强的人,自然会出很多纰漏。这几年听到最多就是创业,有那么容易么?

看到很多年轻的朋友们很努力,有的却发力过猛,不知道什么时候,好像发财成了很多人首要的梦想。

每个人自己的生活方式,有价值即可,但是人人想发财,极强的投机心理,躁动的生活方式,我很难理解。

也或许年少总要轻狂一下,不去多批判别人了,自己按照自己想要的生活方式进行,也好。

今夜,我们聊聊大数据(3) – 大数据的起源

大数据和其他很多概念一样,和科幻小说也有点渊源,不得不说,科幻小说的作家们都是具有无比的想象力。

最早提出大数据概念的是我在少年时代就非常崇拜的科幻小说作家:艾萨克·阿西莫夫,这位拿过七次科幻小说最高奖雨果奖的大师在其科幻巨作《基地》中提出了“心理史学”,利用宇宙级大数据分析预知世界文明的未来。1965年《基地》系列得到雨果奖“史上最佳科幻小说系列”

300px-Isaac_Asimov_on_Throne

阿西莫夫和坎贝尔(其编辑)联手为“基地系列”打造出一门全新的统计科学,称之为“心理史学”,这门学问由书中数学家 哈里·谢顿 穷尽毕生之力创建,根据大规模的人类活动数据,预测未来走向,规模一旦小于一颗星球或是一座帝国,结果就会失准。谢顿运用此一科学,预见银河帝国的殒落,整片银河将因此进入长达三万年的黑暗时期,直到第二帝国建立。

阿西莫夫从1942年写到1986,共有14册长篇,和数不清的短篇小说。我在国内的购书网站上看到过好几个版本的译作,值得一读。

在这部科幻小说中,人类的计算能力已经达到了无以伦比的境界,不是天气预报、商品推荐、个人信用这些了,而是国家、星球、宇宙的发展。所以将《基地》小说作为大数据的起源也算实至名归(目前的技术和作者的想象还相差甚远)。

科幻小说中的场景还是需要靠真实世界中辛勤努力,这方面的接棒者则是著名的 Google 公司。

2003年,Google在19th ACM Symposium on Operating Systems Principles (SOSP‘03)上发表论文,提出了 Google File System(GFS),支持以搜索引擎为典型实例的大规模、分布式、数据密集应用,解决了海量数据的底层存储和检索问题。2004年,Google 接着在 6th Symposium on Operating Systems Design & Implementation (OSDI 2004)上发表论文,提出了著名的 Map Reduce 计算架构及其实现,解决了海量数据的分布式计算处理问题。2006年,Google 又在 OSDI2006 上发表论文,提出了 Big table 架构及其实现,解决了海量数据,尤其是海量超链接数据的结构化存储和检索问题。

Google 的上述三篇经典论文,真正突破了云计算和大数据应用的主要瓶颈,奠定了这两个相关领域的应用基础和研究基础。这三篇论文所发表的研究成果,是 Google 公司每天都在实际运行的系统、无数用户每天都在实际应用的技术,经受住了实践的检验。这三篇论文对于云计算和大数据两个领域的研究和产业应用的影响是深远的。

这三篇论文出来之后,掀起了云计算和大数据应用和研究的热潮,Amazon、微软等纷纷推出了自己云计算平台。作为对 Google 上述三篇论文的开源实现,Hadoop 的出现让更多的草根研究者也有机会玩儿云计算和大数据,一时间各种层次的学术论文和应用系统汗牛充栋。

我们今天几乎所有对大数据的应用实践,不管是 Amazon 的 aws,还是国内的阿里云等等,技术基础都源于此。单就这一点来说,我们要感谢 Google。

Hadoop 是非 Google 体系中大数据平台的基石之作,其衍生出非常庞杂的体系,之后将继续介绍 Hadoop 是如何诞生以及壮大,Yahoo 和 Apache 在其中的伟大作用,以及这个奇怪的单词到底什么意思。

  • 艾萨克·阿西莫夫部分文字介绍和照片来自维基百科-艾萨克·阿西莫夫条目
    ** Google 三篇论文介绍部分来自于:应该做什么样的研究:以Google为例 (http://blog.sciencenet.cn/blog-64396-649988.html)

日本仙台东京游-第三天(上)之山形县藏王

决定去藏王御釜纯属巧合。在网上找仙台周边的游记,看到最多的是山寺和山形。

山寺:顾名思义有座庙,1100多年前建造的名刹立石寺,据说要爬近一个小时,1015级阶梯,放弃了。

山形:山形县的县都,古时候是城下町(以城郭为中心所成立的都市)。山形是电视剧《阿信》的拍摄地(还记得这位坚韧的妇人么?大长今和她比起来就实在不值得一提了),周边有两处著名的温泉:银山和藏王。两个地方都要从山形站坐大巴才能到,去哪个呢?一直摇摆不定,直到某日在一个台湾旅友的游记里看到御釜的照片。一贯喜欢不走寻常路的我们决定还是去藏王看看。而且十月的日本东北山区,红叶应该已经很漂亮了。(所以这两篇的标题就不再是仙台了,到了山形县了)

藏王的御釜:御釜就是一个湖,属强酸性湖,据说只有一种硅藻类生物得以生存,因此湖水终年呈现着翡翠绿与靛蓝的混浊色彩,与周围火山灰岩形成强烈对比。

藏王最出名的,除了御釜,还有树冰,喜欢滑雪的可以趁冬季来此观树冰、滑雪和泡温泉。(以下关于树冰的介绍和照片摘自藏王温泉缆车的官方网站:http://zaoropeway.co.jp/cn/index.html)

藏王的树冰规模为世界屈指可数,是由生长于亚高山带的针叶树大白叶冷杉林,受到冰雪覆盖所形成的大自然神秘奇景。雪云之中的云粒(过冷却水滴)与树枝、树叶的撞击下冻结成如虾尾状,雪片落入缝隙中,再渐渐成块变硬。在一连串的现象不断反复后,即形成此种令人叹为观止的树冰姿态。(这些照片已经感觉不在地球上了?以后一定要冬天的时候去一趟!)

藏王-风景1

藏王-风景2

藏王-风景3

从仙台到藏王的交通分两步,先从仙台到山行,再坐大巴上山到藏王御釜:

第一步:仙台到山形

再次感受下日本人的严谨:(同样来自缆车的官网)

藏王路线图

因为有JR PASS,我们选择第一种方案,坐仙山线到山形(也是小火车,无须换票)

仙山线

第二步:山形到藏王温泉到御釜

山形到藏王温泉可以搭山交大巴,每天有15班,大概每1小时有一班。(山交巴士時刻表:http://www.yamakobus.co.jp/rosenbus/jikoku/frame/zaoonsen.html)

藏王温泉到御釜有两种方法:

1 搭乘缆车到藏王山顶站,然后按照下面的地图走走走,10+10+30+40分钟后就可以到啦。。。
2 或者,搭直达车到御釜。但是,每天只有9:30一班车,13:00回程。

藏王-登山地图

我们这种脚力欠佳的人当然是选后者啦。所以必须一早起来赶7:07的JR才能坐到9:30的班车。天看着阴沉沉的,不知道能否一睹御釜的真容。惴惴不安中,坐上了早班JR。

仙台-早上

仙台-火车站

中途路过的小站,古朴的候车室,仿佛时光从未流逝:

藏王-候车室

8:32到达山形站,除了规模,绝对完胜国内所有的高铁站。

山行-火车站

山行-西点

山行-巴士站

山行-车站外

出口左手边是巴士站,售票处碰到一个英文非常好的老爷爷。这几天被日本英文折磨的我们都快感动到哭了。老爷爷不卖票,而是让我们到旁边的自动售票机上购票。(在日本随处可见这样的自动售票机,特别是一些规模比较小的饭店,基本每家每口一台。在人工贵如金的日本,自动售票机是个很好的选择,节约人手的同时,加快顾客购买的速度,同时也可保证营业额的安全。之后在东京一个拉面店,因为在自动售票机前犹豫和嘀咕,被唯一在煮面的中国籍店员关注而解决了问题,也算有趣的经历。)

山行-车票自动售票机

够先进吧,但是没有英文,我们还是看不懂。老爷爷又很耐心地从柜台后面出来,教我们怎么买票,该买哪种票。这里要注意,老爷爷让我们只买单程票(2050/人),下山的车钱让直接给司机,原因没有搞懂,后来我们也就是这样操作的,所以在日本还是要准备一些现金的,包括藏王御釜里面的商店也都是不收信用卡的。

山行-巴士站2

9:30 大巴准时发车。一路上山,随着海拔升高,红叶也从偶尔惊鸿一现到满眼的五彩山岭。一路上山,没有停车拍照的时间,略有些可惜。

藏王-云和田野

藏王-田野

藏王-风景5

11点准时到达御釜。

藏王御釜

天依然阴沉,一阵阵薄雾飘过,十月在仙台、山行县里还是初秋的感觉,一件薄外套足够了,但是山上0度左右,非常冷,围巾和厚外套是必须的,连不怕冷的日本人也没有短装的打扮了。

藏王-温度计

御釜还在若隐若现中,先去了旁边的刈田嶺神社奧之宮:

藏王-神社

OLYMPUS DIGITAL CAMERA

OLYMPUS DIGITAL CAMERA

偶然一回首,御釜就这样突然出现在眼前,只是实在不巧,雾非常重:

藏王-御釜1

OLYMPUS DIGITAL CAMERA

藏王御釜是一个圆型的火口湖,为刈田岳、熊野岳、五色岳三峰所环绕,因形呈釜状故被称为“お釜(OKAMA)”,釜在日文中又有锅子的意思。湖水会随着太阳光照射角度的不同,而变换着深青靛蓝的光泽,所以又昵称为“魔女的眼睛”,又因阳光照射的角度不同,湖水颜色会产生变化,所以又叫五色湖。

藏王-五色岳

看到御釜,实在抵挡不住外面的寒冷,到休息站来点热乎乎的午餐吧:

藏王-午餐

山顶餐厅这份全素的定食相当于人民币40元,味道不输山下的餐厅。更可贵的是即便是餐盘也绝无油腻感,碗碟没有一个有缺口。

在餐厅还闹了个小小的笑话,这里也是自动售票机点单,凭号领取。但是叫号是全日文的,而且没有同步的电子显示屏。我们只好守在发餐窗口,等着叫了号没人来取且看着像我们点的就是我们的了。

回到休息站时间尚早,又忍不住买了一份当地特产:毛豆年糕。从小吃惯盐水烤毛豆的上海人表示完全无法接受甜的毛豆配糖年糕,敢于尝鲜的可以试试看,日本人真的在美食上动足了脑筋研究。

藏王-绿豆

吃完饭,有了热量,在藏王山顶继续寻觅美景。太阳出来了,但是雾没有褪尽,御釜只能是模糊的样子了。

藏王-藏王古道

藏王-风景4

藏王-红豆

藏王-山上红叶

一点下山的车准时出发,本来打算到藏王温泉下车再坐趟缆车来回看看红叶的,因时间问题还是没成行,很遗憾。藏王温泉和御釜只用大半天时间是不够,如果在藏王温泉住两天是最好的(贴张官网的美图大家一起流流口水吧)

藏王-红叶

上山时候,看到一位日本老者在亲人的搀扶下,慢慢的走着。

藏王-登山

雾重路艰难,只要有目标,慢慢走就是了,沿途也都是风景。

从藏王下来,时间还早,我们在山行县的城市兜兜看看,依然那么干净,而且工作日的下午路上几乎没有什么人。下一篇再见。

山行-城市

今夜,我们聊聊大数据(2) – 多大才算大

这几年,IT圈内,谁不说说大数据和云计算,感觉就是落伍了。这样的名词还有很多,包括O2O、乔布斯等。浮躁之心的确是我们难以逾越的心魔。

大数据技术肯定有其存在的道理,Google、Apache等世界顶级的IT公司和组织为此做出了卓越的贡献,我坚决的不认为大数据是一个伪命题,并且大数据和相关的技术已经为我们展现了其魅力。但是为什么,还是让我们困惑:

  1. 多大才算大数据?
  2. 大数据用在哪里?
  3. 大数据和传统的数据库技术有什么区别?

关于什么是大数据有标准答案后面会说到,所以先来简单回答一下第二个问题。

谈及大数据一定是有应用场景的,肯定不是所有的数据库应用场景都需要和能使用大数据技术的。

数据的使用,在于应用场景和价值体现,而不是炫技。某些hadoop,或者spark系统的举例可以只加载了几千行的数据,但这是举例。一般来说,数据量没有达到1T规模的,用传统的数据技术在绝大多数场景下都可以满足应用。

维基百科中文版给的定义是: 大数据由巨型数据集组成,这些数据集大小常超出人类在可接受时间下的收集、庋用、管理和处理能力。“庋用”是一个很不常用的词语,对照英文版的定义:Big data usually includes data sets with sizes beyond the ability of commonly used software tools to capture, curate, manage, and process data within a tolerable elapsed time. “curate”也可以翻译成“策展”,用英文解释这个词更加明白一些:select, organize, and look after the items in (a collection or exhibition).

维基百科指出到大数据的大小经常改变,截至2012年,单一数据集的大小从数太字节(TB)至数十兆亿字节(PB)不等。

像在我们公司的一些主要应用,一个应用有几十乃至百来张表是很正常的,光用记录行数只能描述数据库的部分复杂度,而数据的容量的确是最客观的一个指标。从数据量来说,我们公司的业务数据差不多在2T左右,每天增加的量在1G左右,当然随着业务量的飞速发展和数据越来越多,增速很快。

我觉得谈大数据,至少需要1-2T这样的数据量,那么后面说到的大数据技术就可能比较合适了。维基上说得好:指的是所涉及的数据量规模巨大到无法通过人工,在合理时间内达到截取、管理、处理、并整理成为人类所能解读的形式的信息。在总数据量相同的情况下,与个别分析独立的小型数据集(data set)相比,将各个小型数据集合并后进行分析可得出许多额外的信息和数据关系性,可用来察觉商业趋势、判定研究质量、避免疾病扩散、打击犯罪或测定即时交通路况等;这样的用途正是大型数据集盛行的原因。

小结一下,大数据和传统数据最大的区别就是数据量要大,并且需要在指定的时间(当然越快越好)内完成复杂的处理。从目前来说,数据量的底限至少是1T。只有合适的应用场景才需要大数据技术。

worldrecord_pb_01S-360x200

worldrecord_pb_02S-360x200

worldrecord_pb_03S-360x200

接下来,让我们追本溯源,谈谈大数据的由来,hadoop等一堆名词的意义。

图片来源:Sybase IQ: A World Record in Pictures