twilio杂记

https://www.twilio.com 

对于开发者不很友好,虽然目前是注册就送30$,但是注册号码的话需要付费却不能从这里面扣。

可以通过verify number将你的美国号码绑定,这样打出去的号码将会使用你绑定的号码。

对于开发者来讲,还是后起之秀tropo好用。

rest api见http://www.twilio.com/docs/api/rest/

同样它也需要http 基本验证,用户名是账户sid(不是app sid),密码是token。

http://readthedocs.org/docs/twilio-php/en/latest/index.html

它也有类似phono的客户端https://www.twilio.com/docs/client

不只是因为我测试时就是生产环境的缘故,感觉sms上twilio还是要比tropo快很多。我测试tropo都是它免费的开发环境,感觉sms比较慢。

 

client部分:

用它提供的脚本地址,因为它的脚本里还具有自动更新client js脚本库版本的功能,需要解析src中的域名部分来获得新js的地址。

这个需要服务端配合,首先setup需要app sid和token,这个token是要依据权限创建的,直接使用它的php-helper来创建就比较简单。Twilio/Capability.php

其次对于需要接听电话的情况,客户端需要初始化一个agent id,这个是可以随便取的,但是与电话号码绑定的入口必须要知道这个agentid才能将会话转接到这个client。

https://www.twilio.com/docs/client/device

流程:

client 的connect会请求app的call, url

此时请求参数中caller会是client:agentid的形式。

此时如果想转接到真实电话,必须要制定dial节点的callid属性。

如果是直接打电话这个app的号码,也会请求app的call url

上面两个的direction参数都是inbound

如果是rest api方式发起outbound会话,被呼叫方接通电话后,也会请求app的call url,这时direction参数是outbound-api

 

好笑的是如果client发起的请求被转接到client本身时,这也是可以的,那就变成了自己和自己对话了。

 

下面是对于twilio和tropo使用的对比

http://pardner.com/2011/04/tropo-not-ready-for-prime-time-went-with-twilio/

作者最终选择的是twilio:

主要是tropo无声的丢失了信息而twilio却保证了不丢失。

 

REST API中查询所有买入的号码是 https://www.twilio.com/docs/api/rest/incoming-phone-numbers

Continue reading twilio杂记

heidisql mysql工具介绍

之前使用navicat lite,感觉并不好操作,能使用mysql workbentch就用mysql workbentch,mysql workbentch要装.net,有的机器还装不好,而且在win7上ui不很好用。 但是现在才发现开源免费的heidisql操作很方便,速度很快。

介绍一下它的提示功能, 在sql编辑器中,打点号,就会出现自动提示了,表名,数据库名等等。

so good.

赶快试试吧.

Continue reading heidisql mysql工具介绍

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target 纠结的java ssl请求

java请求https常常遇到证书问题,对于许多免费的自签名证书,需要手动导入到jdk keystore中去。见http://kazge.com/archives/400.html

今天却遇到GEOTrust认证的证书也需要导入的问题。

浏览器里面看这个证书是由GEOTrust认证的,浏览器没什么问题,使用java请求就抛异常。

我们知道jdk是自带GEOTrust根证书的,照理说这个认证的证书就不需要导入了。网上搜了一下,大概的原因是:这个证书域名以*开头,jdk不能handle

http://jasig.275507.n4.nabble.com/SSL-Error-td1749567.html

是不是这个原因,我没细看。

还是将证书导入到keystore保险。

导入后要重启运行在此jdk上的程序才能起效。

Continue reading sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target 纠结的java ssl请求

php之毫秒

php的毫秒是没有默认函数的,它自带的是microtime,即微秒:

1 second = 1000 milli second = 1000,000 micro second = 1000,000,000 nano second

网上抄来抄去都是microtime自带的例子,返回的还是秒。

microtime() 返回 0.1111 131231秒,空白前部分是float形式的秒数 空白部分是秒的整数部分

故要得到毫秒:

 

<?php
function getmilliseconds() {
	list ($usec, $sec) = explode(" ", microtime());
	return (int)(((float) $usec + (float) $sec) * 1000);
}
?>

ok, 看清楚了,不是那些拷来拷去的秒函数哦。

Continue reading php之毫秒

tropo杂记

发短信:

有的号码是发不到中啊国的,找了半天原因才发现要换个大城市的号码较好。如芝加哥。

Continue reading tropo杂记

ie圆角,19px,挥之不去的最小高度

拿别人做的圆角模板,在非IE下好好地,到IE下就是变了形。原因是td中那个高度老是莫名其妙的有19px。

后来看到这篇文章:

http://dancewithnet.com/2007/07/26/ie6-height-bug/

在IE6中设置display:block的空容器一个较小高度时,如<p style="height:1px;"></p>,会发现其高度不能小于某个值,比如在字体大小为12px时这个值是15px,在浏览器默认字体大小时这个值为19px,你可以通过调整IE6中的“查看>字体大小”来观看这个高度的变化。解决方案:

  1. 设置font-size:0,但是这个容器的高度最小为2px,所以没有办法实现高度为1px的效果
  2. 在容器中增加内容或其他空标签,如&nbsp;、<br />,并设置line-height:0,但该容器会存在一个和其父容器字体大小有关的外边距,这个问题在IE7中也会出现,
  3. 在容器中增加内容或其他空标签,同时设置font-size:0,line-height:0,
  4. 上述解决方案在某些字体下会有非常大难以预料的变化,如font-family:fixedsys;时
  5. 设置zoom:0.03,这个会受到font-size、font-family的影响而显示不同效果,并且在IE7下不可见,如
  6. 设置overflow:hidden,这是目前看到的最完美的解决方案

 

照此,我将样式设置为overflow:hidden

将td中的img改为td背景图片,//使用img就会撑大

在td中增加&nbsp;

增加样式line-height:0

这才解决问题。

Continue reading ie圆角,19px,挥之不去的最小高度

bit单位大小

style="width: 858px; height: 363px">

1 kB = 1024 B (kB - kilobajt) 千 1 MB = 1024 kB (MB - megabajt) 兆 1 GB = 1024 MB (GB - gigabajt) 吉 1 TB = 1024 GB (TB - terabajt) 太 1 PB = 1024 TB (PB - petabajt) 拍 1 EB = 1024 PB (EB - eksabajt) 艾 1 ZB = 1024 EB (ZB - zettabajt) 皆 1 YB = 1024 ZB (YB - jottabajt) 佑 1 BB = 1024 JB (BB - brontobajt)

Continue reading bit单位大小

【转】为什么Hadoop将一定会是分布式计算的未来?

按:

好文就得收藏,本文较为宏观的介绍了hadoop的历史,功能等。

 

为什么Hadoop将一定会是分布式计算的未来?

版权声明:

写本文由leftnoteasy发布于http://leftnoteasy.cnblogs.com 本文可以被全部或者部分的使用,但请注明出处,如果有问题,可以联系wheeleast (at) gmail.com, 也可以加我的新浪微博:http://weibo.com/leftnoteasy

前言:

  很久没有写写博客了,之前主要是换工作,耽误了很多的时间,让人也变得懒散,不想花大时间来写东西。另外就是也确实没有什么自己都觉得有意思的东西拿来写写,对一般的知识什么的,我比较倾向于往evernote上面记笔记。不过最近对于Hadoop看得比较多,对它的发展也比较关心,最近了解得越多,也就越相信Hadoop的未来,这里写一篇文章与大家分享分享,为什么我相信Hadoop一定是分布式计算的未来。

写在前面的话:

  今天听同事分享了一篇很有意思的讲座,叫做"Why Map-Reduce Is Not The Solution To Your Big-Data Problem"(为什么Map-Reduce不是你的“大数据”问题的解决方案)。同事很牛,也分享了很多非常有价值的观点,不过他预言Map-Reduce将会在5年之内消失(而且还呼吁有做存储方面的牛人来预言一下,Hdfs将在5年之内消失),这个话题如果成立的话,让我这个目前在Hadoop工程师,感到无比的压力。这里不为了争个你死我活,只是谈谈自己的一些想法。另外由于这位同事的分享是内部进行的,这里就不透露分享中具体的内容了,只谈谈自己的观点。

  (本文需要对Hadoop有一定的基础方可理解)

Hadoop为何物?

  虽说Hadoop的名声很大,但是总还是有同学不太了解的,这里一笔带过一下。

  Google分布式计算三驾马车:

  Hadoop的创始源头在于当年Google发布的3篇文章,被称为Google的分布式计算三驾马车(Google还有很多很牛的文章,但是在分布式计算方面,应该这三篇的影响力最大了):http://blog.sina.com.cn/s/blog_4ed630e801000bi3.html,链接的文章比我介绍得更清晰,当然最好还是看看原文了,这是做分布式系统、分布式计算的工程师必修课。

  Google File System用来解决数据存储的问题,采用N多台廉价的电脑,使用冗余(也就是一份文件保存多份在不同的电脑之上)的方式,来取得读写速度与数据安全并存的结果。

  Map-Reduce说穿了就是函数式编程,把所有的操作都分成两类,map与reduce,map用来将数据分成多份,分开处理,reduce将处理后的结果进行归并,得到最终的结果。但是在其中解决了容错性的问题。

  BigTable是在分布式系统上存储结构化数据的一个解决方案,解决了巨大的Table的管理、负载均衡的问题。

  Google就靠着这几样技术,在搜索引擎和广告方面取得了举世瞩目的成就。不过Google不是傻的,这三篇文章虽然都是干货,但是不是直接就可以用的。话说Google发表了这三篇文章后,在学术界引起了轩然大波,大家对这三样东西提起了浓厚的兴趣,都想着是不是可以实现一下,以为己用。

  Doug Cutting:

  Doug Cutting之前是一个非常有名的开源社区的人,创造了nutch与lucene(现在都是在Apache基金会下面的),nutch之前就实现了一个分布式的爬虫抓取系统。等Google的三驾马车发布后,Doug Cutting一看,挖靠这么厉害的技术,于是就实现了一个DFS(distributed file system)与Map-Reduce(大牛风范啊),集成进了Nutch,作为Nutch的一个子项目存在。那时,是2004年左右。

  在互联网这个领域一直有这样的说法:

  “如果老二无法战胜老大,那么就把老大赖以生存的东西开源吧”

  当年与Google还是处在强烈竞争关系的Yahoo!于是招了Doug兄进来,把老大赖以生存的DFS与Map-Reduce开源了。开始了Hadoop的童年时期。差不多在2008年的时候,Hadoop才算逐渐成熟。

  现在的Hadoop:

  现在的Hadoop不仅是当年的老二Yahoo的专用产品了,从Hadoop长长的用户名单中,可以看到Facebook,可以看到Linkedin,可以看到Amazon,可以看到EMC, eBay,Tweeter,IBM, Microsoft, Apple, HP...(后面的一些未必是完全使用)。国内的公司有淘宝、百度等等。

  我来定义一下Hadoop:

  Hadoop是一套开源的、基础是Java的、目前能够让数千台普通、廉价的服务器组成一个稳定的、强大的集群,使其能够对pb级别的大数据进行存储、计算。已经具有了强大稳定的生态系统,也具有很多使用的延伸产品。比如做查询的Pig, 做分布式命名服务的ZooKeeper, 做数据库的Hive等等。

为什么世界上只有一个Hadoop?

  我的前公司是国内某一个著名互联网公司的子公司,专注做云计算,我也在这个公司最兴盛的时候进入,当时宣传的口号是“做最好的云计算”,就是希望自己开发一套存储计算系统(就是类似于前面提到过的dfs与map-reduce),并且克服一些Hadoop的缺点(比如说用c++去实现,克服Java的一些性能问题)。后来结局可能大家也猜到了,投入了很多钱,招了不少牛人,确实也做出了还算不错的云计算(至少在国内是数一数二的)。但是最终不管从稳定性还是效率上还是scalable来说,都远远被Hadoop甩在了后面。虽然我前公司这个云计算项目是否会成功,这里没办法预测,但是前途终究还是比较黯淡的。

  最近一年还听说国内不少的互联网巨头都成立了云计算部门,做“自己的”云计算,有些小得像创业时期一样的公司,都宁愿自己写一套map-reduce框架,不愿意直接使用Hadoop。可能这个跟国人的想法,武功秘笈一定要自己藏着,不让别人学,传男不传女。对别人白给你的东西,非常不放心,觉得大家都能学到的东西,肯定竞争力是不够的。

  除开心态问题不谈,但从技术实力上来说,一般国内公司的核心开发团队的能力和当年的Yahoo!比,还是有非常大的差距的,至少像是Doug兄这样的大牛是很罕见的,从开发者的实力来说,就差了不止一个档次。

  其次从积累来说,Hadoop从初创到现在也经过了至少7年的积累的,碰到过很多刁钻客户的问题都慢慢克服了(比如Facebook的超大数据存储),带给用户的经验教训是很充足的,比如说性能调优这一块,就有非常多的文章去介绍。而自己开发一个,什么都需要从头再来。

  最后也是最重要的是,Hadoop形成了一个强大稳定的生态系统,里面有生产者(共享改进的代码、fix bug),也有消费者(使用项目并且反馈经验),Hadoop的用户也可以获得较大的经济利益(不花钱买软件,还可以增加效率)。对于一个开源社区来说,构建出一个完整的生态系统是非常非常的困难,一旦构造出来了,项目就会很稳定的往前去进步。

Hadoop的优势

  之前分析了一些“虚”的东西,比如生态系统什么的,这里说说一些实际的东西。

  Benchmark:

  Hadoop现在保持了很多漂亮的记录:

  存储:现在世界上最大的Hadoop集群目前在Facebook,可以存储30PB的数据

  计算:Hadoop是目前Terasort记录的保持者(参见:http://sortbenchmark.org/),Terasort是给出1TB的随机数据,看谁能够在最短的时间内完成排序,Hadoop使用了1400多个节点,在2分钟内完成1T的数据排序。

  这里顺便说一下,之前给出网站里面有很多的benchmark,可以看到Hadoop的集群是最大的,使用的机器最多的,像是TritonSort这样的集群,使用了区区50多个节点,最终的结果并不比Hadoop差太多,但是这里得注意一下。TritonSort是专门用来做排序的,里面加入了相当多的优化,但是Hadoop是一个通用的集群,并没有为了一种任务进行如此多的优化。从用户的角度上来说,愿意花钱去买一个只会排序的电脑是意义不那么大的。

image

  注:左右两边属于两种不同的terasort,hadoop是其中一种的记录保持者

  能做什么?

  前面说的基本的存储和计算Hadoop是一定能胜任的,下面谈谈一些“高级”的功能。

  常见的数据库操作,比如orderby、select这样的操作都可以的,Hive就是支持这样的Sql模型,能够将Sql语句最终转化到Map-Reduce程序中去。其性能和可用性已经得到了证明,Facebook就用它做了不少的数据分析的工作

  常见的机器学习、矩阵分析算法,目前Mahout作为一个发展迅速的项目,在逐渐填补Hadoop在机器学习领域的空白,现在常见的分类、聚类、推荐、主成分分析算法(比如SVD)都已经有相应的Map-Reduce实现了。虽然目前从用户群和效率上来说是不够的,但是从它的发展来说应该会很快的达到工业界的标准

Hadoop的劣势

  现在Hadoop依然有很多的问题没有解决,这让有些人非常的怀疑Hadoop的未来,这里谈谈Hadoop的一些重要的劣势

  HA(High Availability)高可用性:

  这一点是Hadoop非常弱的一个缺点,不管是Hdfs还是Map-reduce,都是采用单master的方式,集群中的其他机器都是与一台中心机器进行通信,如果这个中心机器挂了,集群就只有不工作了(不一定数据会丢失,但是至少需要重启等等工作),让可用性变得更低。这个一般叫做单点失败(single point of failure,SPOF)。

  虽然现在有些公司已经给出了解决方案,比如EMC就有用Vmware搭建虚拟集群,对master节点进行镜像备份,如果master挂掉,那么立刻换上镜像备份的机器,使其可用性变高,不过这个终究不是一个内置的解决方案,而且Vmware这一套东西也并不便宜。

  不过之后这个问题将会得到非常好的解决,我在Hadoop的未来这一章将说以说。

  Hadoop目前解决得不那么好的一些算法:

  Join等:

  Map-Reduce还有一个问题是,对于Join这个最常见的数据库操作,支持力度还是不够,特别是针对那种上TB的数据,Join将会很不给力,现在已经有了一些解决方案,比如说SIGMOD'2010的这篇文章:

  A Comparison of Join Algorithms for Log Processing in MapReduce

  不过在现在的情况下,只有尽量的避免大数据库的Join操作

  需要进行很多轮迭代、循环的算法:

  对于循环,Map-Reduce稍好,比如矩阵计算,高斯消元法这样的,循环的次数的确定的算法,实现起来还是不难,只是有点慢。但是迭代就更麻烦了,因为现在的Map-Reduce的mapper和reducer是不太方便去弄这样的终止条件。

  还有就是迭代次数超多的算法(比如说矩阵的SVD分解),在超大矩阵的情况下,迭代次数可能会上亿次。而Map-Reduce在每次迭代的时候都会把数据往文件里面读写一遍,这样的浪费的时间是巨大的。

  其实Map-Reduce不是绝对没有办法去解决这些问题,而只是现在这个还不是最重要的日程,Hadoop还有很多很多的东西可以优化,比如说前面提到的HA,这些东西只有往后放放,我将在之后的Hadoop的未来部分,谈谈未来版的Hadoop怎么去解决这些问题。

  编程复杂,学习曲线陡峭:

  对于一般的map-reduce框架,hello world程序就变成了word count,就是给出一堆的文本文件,最终统计出里面每一个不同的单词出现的次数,这样一个简单的任务(可能在linux shell下一行就写出来了),在Map-reduce中需要几十行,一般新人从理解word count到写出自己的word count,到跑通,一个星期是肯定需要的。这样陡峭的学习曲线让许多人难以深入。

  另外还有一点Hadoop被人所诟病的是,代码丑陋,虽然Hadoop是用高级语言Java写成的,但是里面对每一个步骤都要分成mapper和reducer,这个被戏称为新时代的汇编语言。

  一般来说,做数据分析的人程序都写得不咋地(强哥这样的达人除外),能写写matlab,R,或者spss就差不多了,如果要让他们去写map-reduce,那就等于叫他们别干活了。而大数据的重要的作用就是用来做数据分析,Hadoop的未来发展必须得抓住这群数据分析师的心。

  其实现在已经有一些实验中的产品,让用户可以用高级语言编程,不会再看到丑丑的map-reduce了。我在前公司的时候就与团队一起做了还不错的尝试,至少,数据分析师可以用Python来编程了。map-reduce变成了一个底层的东西,现在不是某些人在分析性能的时候就贴上汇编代码吗,之后可能会变成在前段的程序效率不行的时候,就贴上后端Java的map-reduce程序。

  所以对这个难题之后肯定会解决掉,底层分布式程序开发与用户将被清楚的分开,之后想要写word-count一定会像hello world一样简单。

Hadoop的未来怎么样?

http://www.slideshare.net/hortonworks/apache-hadoop-023 (hadoop 0.23)

  给出这样的一个官方文档,谈谈之后的hadoop的发展。目前的hadoop的稳定版是0.20.x,这个0.23是个未来版,估计将在今年的Q4进行beta的发布(目前看起来,至少代码是写了很多了) 。

  HDFS Federation

  首先是一个叫做HDFS Federation的东西,它将hdfs的命名空间进行了扩展,目前的HDFS的所有文件的meta信息都保存在一台机器的内存中,使得HDFS支持的文件数目是有限的,现在进行了这样改动后,将hdfs的命名空间做成了分布式的,对之后方便对不同的用户文件夹进行管理,还有从HDFS的实现上来说,都会更为简单。

  下一代的Map-Reduce:

   节点数:从目前的4000增加到6000-10000台

   并发的任务数:从目前的40000增加到100000

   更高级的硬件支持,目前支持的硬件主要是8core, 16G ram, 4T disk, 之后将会支持16+core, 48/96G ram, 24/48T disk

   架构的改变,对现在的JobTracker-TaskTracker的结构做了很大的改进,现在会用ZooKeeper去保存master的状态,避免了之前提到的SPOF

   更多的编程模式的支持(这个很重要)

   比如MPI,迭代程序的处理,并且在Hadoop中运行这些类型的编程模式,并且这些程序将会被Hadoop统一管理

总结:

   之前谈了Hadoop的优势、劣势等等,综合来说就是,优势是很明显的(比如这么多牛公司在用,并且也贡献了很多的代码),远远超出了其他的分布式系统,劣势虽然不小,但是改进这些不足的地方是在计划中,已经在实施了。而且Hadoop不仅在学术界或者是工业界,都有很高的地位,综合了这些天时地利人和,那前途还是非常光明的

Continue reading 【转】为什么Hadoop将一定会是分布式计算的未来?

Pagination


Total views.

© 2013 - 2019. All rights reserved.

Powered by Hydejack v6.6.1