OpenStack Days China参会有感——GIS距主流IT还有多远


前几天有幸参加了OpenStack Days China的两天技术峰会,集合了全球及国内顶尖的OpenStack技术专家,为我们分享了许多关于OpenStack的技术报告。


有许多人参加类似技术峰会都有这些感受:


1、一般主会场的领导和院士发言基本没有什么干货,也就是对我们实际工作没有太大帮助

2、一般讲的不错的都是公司的CEO、CTO等,但是他们都是公司商业因素占据很多,技术并不是他们实干,好像也没有什么收获

3、一般分享干货的实践者往往讲的水平一般,枯燥乏味,太干了,干的让人无法消化


当然,我觉得现如今充满浓重商业元素的技术峰会,你不要抱着演讲者的技术方案刚好能解决我现有的技术问题,其实我们更应该听的是:


1、关于院士战略方向的引导,未来的趋势,国家的政策引导方向

2、关于公司产品的商业模式,产品未来发展,如何将技术与产品及商业结合,推广,如果你是个产品经理,就需要不仅是在技术上把关,更重要的是如何让用户和产品建立依赖关系

3、关于纯技术分享,我们应该了解该技术是否已经成熟,已经被更有实力的公司淌过坑,他们的技术架构,技术方案能不能为我所借鉴,至少我原来希望POC的功能已经被证实了,原来这个技术也可以这样用,当然分享完毕之后直接与技术人员进行沟通,建立联系,都是非常好的事情。



关于这次峰会的感受.....

每次参加云计算或者OpenStack相关的技术讲座都会有不同的认识,自从接触了开源技术,就好象打开了世界之窗,让我可以放眼整个世界,也让我感觉以前的思想封闭和目光短浅,当然,自从接触了OpenStack,我也深刻的感受到开源技术发展的潮流是大势所趋,发展速度的迅猛让我始料未及,每个人作为互联网的一端的协作也让我惊叹,谈谈这次技术上的变化吧:


1、OpenStack已经成熟了,已经可以在生产环境了

如果你还在考察OpenStack作为一个开源技术的稳定性,可能就失去机会了,现在我们已经不在向前几年来讨论OpenStack的稳定性了(虽然也有很多的Bugs),而是讨论如何将OpenStack的产业做的更大,就相当于从6年前只有两个项目,发展到现在几十个顶级项目和数百个衍生项目,而且Openstack不再仅仅只能做私有云,它还可以做公有云,这方面华为一直有非常成熟的案例(包括分享了德国电信的公有云案例)。


2、现在大家分享的技术已经不再仅仅着眼于那几个耳熟能详的项目了,更多的新生项目被越来越多的提及到了

前两年的技术峰会,大家还在讨论如何为Neutron解决相关问题,如何为Cinder添加新的存储驱动,但是,现在,更多的厂商把他们的目光投入到了一些具有发展潜力的项目中来,一方面说明那些项目已经足够成熟,另一方面也可能是厂商为了自己能够立足于OpenStack的技术圈,能够在一些潜在项目的发展出自己的商业模式以及领先地位,也获得更多的话语权,所以才有向九州云分享的Kolla项目,寄云分享的Murano项目,IBM分享的Magnum项目、Heat项目,华为分享的Senlin项目,Tricircle项目等。


3、越来越多的OpenStack的Core Reviewer为我们带来最前沿的技术讲座

这次峰会上至少有5位OpenStack各个项目的Core Reviewer为我们带来了技术讲座,他们作为项目的核心代码贡献者,直接为我们介绍了关于这个项目的发展方向,项目的典型问题解析,项目的相关应用等,深感他们还真是年轻,又一次感受到时代、环境、氛围可能会改变一个人的发展方向,有了互联网、有了开源、有了分享精神,让科技的进步更加的迅速。

当然,我也不禁要吐槽一下,可能我并不是对每个项目都了解,也可能是我个人的问题,我还是建议开发者在演讲技巧和表达方面多多下工夫,如果两者能够完美结合,那真是一件好事情。


4、容器时代的来临已经无法阻挡了

OpenStack已经发展6年了,容器已经发展3年了,当容器刚刚出来的时候,大家可能还在争论云平台与容器谁能把谁PK掉,但是随着技术的不断发展,以及大家对这两种技术的认识深入,技术融合才是王道。


OpenStack现在有多个容器相关的项目,Big Tent上有Magnum,Kolla,Kuryr,Murano,新项目有Higgins,其他子项目有nova-docker,libvert-lxc,Heat docker plugin,等等,特别是Kolla项目的提出,也就是通过容器来为OpenStack的部署提供一个更加简单、低门槛的技术方案,由于OpenStack是天生分布式和服务化的技术架构,通过容器将服务化分为微服务化,既可以简化原来复杂的部署方案(包括高可用),最大的好处就是解决了OpenStack的升级问题,大家对OpenStack没半年一次升级又爱又恨,爱的是又有大量的组件成熟了,又有大量的新组件涌入出来了,又恨的是我该如何选择呢,我已经部署好的OpenStack如何升级呢?有了Kolla,So Easy,大家可以关注一下关于九州云参与的Kolla项目吧。


当然,不仅仅是Kolla项目,我参与的讲座中,尤其是Paas和SaaS厂商,容器的微服务化已经被广泛应用,容器技术大家一定要关注。


5、超融合软硬一体化的产品

大家知道,超图软件在2015年用户大会就推出了超图云GIS一体机,也就是为用户提供一个一站式、开箱即用的软硬一体化的解决方案,当然,看到此次展会越来越多的厂商将他们的理念和产品推出来的时候,我也会超图软件能有这个一个前瞻的决策而高兴。


我在此次展会上看到了三家产品,九州云的AnmiBus超融合一体机,海云捷讯的超融合一体机,书生云的超融合一体机,前两者还直接将他们的产品进行了展示,更不用说华为本身也有自己的产品,他们共同的特性就是提供在硬件适配优化的基础上,提供以OpenStack为基础的云平台(在此基础上定制开发),然后使用Ceph作为分布式存储的解决方案(书生云有自己的SurFS),这样就实现了类似超融合的软硬一体化方案(Server SAN),当然,类似产品我在其他展会也见过,软硬一体化的方案是未来的趋势,对于用户来说,他们不管技术如何实现,他们只管这些技术是否能够为我们的业务所用,所以,让用户精力放在业务创新上,而不是他们不擅长的建设云上的确是一个很好的发展思路。


6、纯英文的PPT展示

这可能是一个细节,而且这都是在九州云的讲座中看到的,这并不是为了装B,由于现在OpenStack的圈子里面,每个公司最大的资本就是技术人才,这些技术人才就是能够为OpenStack社区贡献多少个Commit,每个项目中有多少来自XX公司的Core,这样大家才会信服你们公司的技术实力,而且所谓的技术秀就是我是否能解决你们不能解决的问题,所以,大家都需要在OpenStack社区混,而且要与全球顶尖的开发者一块协同,你需要的不仅仅是写代码,用英文添加代码注释,用英文进行Readme说明,用户英文进行PPT的各个峰会的演讲展示,这需要养成习惯,同时我也了解到,在九州云很多开发者已经不再将Windows作为他们的日常办公环境,全部Linux来培养自己的习惯和使用能力,这无疑也是为自己提供一个国际化互通互联的环境。


7、OpenStack真的需要团队才能玩的转

大家可以看到,凡是我们看到的OpenStack初创公司,都是拿了风投的,都是从IBM、Intel、华为等知名企业跳槽出来的,而OpenStack技术需要硬件技术(服务器、网络、存储、安全)、操作系统、数据库、虚拟化(KVM、Xen等)、开发技术、运维等,如果你能够集合这种专家,你才有可能将OpenStack技术形成产品,然后你还需要营销、市场、商务进行变现,所以,如果你还在沉浸在代码开发中,你可以抬起头看看或者了解一下衍生技术,他会让你的level上升一个新的高度。


当然,开源也是双刃剑,你永远不知道未来出现一个新技术完全把你颠覆掉。


8、OpenStack与Ceph真是天生绝配

现在越来越多的厂商已经不再争论分布式存储是用GlusterFS、GPFS、GFS还是Ceph,Ceph已经成为各个厂商进行分布式存储方案的标配,Ceph我研究的较少,也没有什么过多的发言权。



==========================================================

作为一个GIS从业人员,我从中能够有什么收获呢?或者说我为什


么要关注他呢?


我们这个博客叫GIS+,我们是以GIS为技术核心,然后将主流的IT技术与GIS技术进行融合,为GIS用户提供更好的解决方案,当然,大家看到我博客的内容基本都是纯IT的相关文章,其实想要实现GIS+,需要一个过程。


可以说,对于GIS,我的理解还是有一些的,但是做GIS+,我觉得首先要了解这些+的东西,例如我需要深刻理解云计算、大数据、容器是什么,能做什么,是否已经成熟,是否已经有相关案例,那些我可以为我们的GIS所用,这需要一个过程去学习和思考,另外我现在所谓的GIS,其实就是SuperMap,作为一个商业软件,我只能自己去慢慢影响我的相关产品经理同事,但我无法决定,有些时候我可能改变思路,在现有产品形态的基础上,将用户业务与先进技术进行结合,为用户提供相关的解决方案。


例如,我们也为用户推出过基于云架构和消息机制的分布式数据处理方案,这里面就是在已有的Supermap产品形态下,通过开源的技术特点进行整合和逻辑提供出来的。


那么我听这些讲座听什么呢?


1、新技术的发展思路

由于超图产品也有关于OpenStack、容器以及未来大数据的产品形态和解决方案,所以要去了解这些技术动态、新特性,为产品自身的迭代把握方向。


2、做一个权威和专业的售前角色

目前,GIS相关的项目要与大数据和云计算结合,那么我要有非常专业和扎实的技术基础,并不是了解所有的技术细节,但是对于相对比较深入的技术方案,技术原理,技术架构都需要去了解,那么参会会为我提供一个非常快速的学习捷径。


3、加强自身的学习和实践

每次参会,我第一个工作,把我的PPT再修改一下,当然了不是因为百度事件的问题,而是我可能又学习了一些东西,对一些东西体会又有不同的见解,我需要修改内容,为用户呈现的东西更加符合用户的需求。


另外就是自己搭建环境去真正的体会和实践,这非常重要,看别人的东西10遍,不如自己去操作记忆深刻,我有一个体会,就是我最近发布了两篇关于Docker Registry和Docker Swarm的文章,其实我们超图研究院内部已经有同事发布了,我也看了一下,感觉很简单,但是每次都没有印象,最后还是下定决心要自己实践,真正做了才知道,这里面还是有很多细节去处理。


4、另外就是听人家CEO、CTO、技术专家的演讲技巧

我一直不推荐埋头苦干的老黄牛,我希望不仅自己干了东西,还要勇于去表达,特别是作为技术型工作你需要将自己的产品向客户进行推广,PPT是最常见的方式,所以我也要学习人家是如何推广自己的产品,这样也可以为我所用。当然,你也会发现,现在越来越多的厂商也特别注重PPT的美观了,尽管院士们一直对这个嗤之以鼻....



那么GIS到底离主流IT(互联网公司、技术初创公司等)差距有多


其实这本来就是一个不公平的话题,本身GIS技术就是落后于IT技术发展的,而现在WebGIS、移动GIS、云GIS都是以IT技术的发展趋势之后而慢慢发展起来的,但是现在GIS厂商在发展好自身的GIS技术基础上,已经不再会等这些主流技术完全成熟了,他们会积极的去与新技术跟进,因为时间谁都耗不起,这是一场赌注,当然他们会希望赢。


超图软件作为国内最大的GIS平台提供商最大的优势就是自主可控,源代码掌握在自己手里面,我们自己可以评估技术发展方向,积极去拥抱新技术,积极发展GIS与新技术的产品形态,我觉得作为GIS平台提供商我们是有差距,但是这些差距我们会积极学习去弥补。


但是我觉得最大的差距还是在开发商。


为什么这么说,由于GIS服务的用户都是政府,政府现在的状态已经由原来的相对保守到现在积极接纳新事物,尤其是克强总理的互联网+的提出,更是让政府也积极去拥抱新技术,所以他们做的项目一定要有云计算、大数据的元素,所以我觉得我们的用户思路没有问题。


为什么说开发商呢?以云GIS项目为例,现在我见过的大部分案例还在停留在虚拟化的层次上,也就是这个系统原来在物理服务器上,然后我再云环境下,创建一个相同配置的虚拟机来运行,无论是从架构设计、功能设计都没有真正使用云架构的思想,比如分布式、消息服务、异步、弹性伸缩、无状态、服务化等,因为开发商的代码积累和熟练工还停留在原来的基础上,他们稍作改变就能够交工,这是一个可靠性的保障。


当然,如果完全按照云架构的思想,这基本上等于推到重来,谁来把握工期,谁来确定这条路能走通,谁来完成这个项目的研发,谁来把握项目质量都是一个未知问题。


而且现在搞GIS的开发者,还是最关注代码层次的实现,对架构、新技术还无暇关注(项目催促紧),所以,云GIS项目往往出现一种情况就是一个思想保守的老司机,驾驶这一个先进的特斯拉,确实跑不快,也不敢跑。


总结


不是到感受这么多,当然了,希望能够为各位提供一些经验的分享,也希望能有更多的GISer加入到开源技术中,为GIS+的真正开展相互协作,共同努力!




本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。

Flume性能测试报告 - 2016-07-16 17:07:11

1. 测试环境 1.1 硬件 CPU:Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz(8核) 内存:16G 1.2 软件 Flume:1.6.0 Hadoop:2.6.0-cdh5.5.0 Kfaka:2.11-0.9.0.1 JDK:1.8.0_91-b14 64位 1.3 测试文件 文件大小:107M ,共490010条记录 1.4 Flume配置 (1)Source配置 Flume Source采用spooldir的方式,直接读取预先准备好的测试文件。 agent .
我最近研究了hive的相关技术,有点心得,这里和大家分享下。 首先我们要知道hive到底是做什么的。下面这几段文字很好的描述了hive的特性: 1.hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供完整的sql查询功能,可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低,可以通过类SQL语句快速实现简单的MapReduce统计,不必开发专门的MapReduce应用,十分适合数据仓库的统计分析。 2.Hive是建立在 Hadoop 上的数据仓

webSocket使用教程 - 2016-07-16 14:07:11

webSocket使用教程 Gson简介 GSON是Google开发的Java API,用于转换Java对象和Json对象 gson和其他现有java json类库最大的不同时gson需要序列化的实体类不需要使用annotation来标识需要序列化的字段,同时gson又可以 通过使用annotation来灵活配置需要序列化的字段。在Java开发中,有时需要保存一个数据结构成字符串,可能你会考虑用Json,但是当 Json字符串转换成Java对象时,转换成的是JsonObject,并不是你想要的Class类
目录 目录 前言 Openstack基金委员会 Openstack贡献者须知 注册Openstack In Launchpad 生成并上传OpenPGP密钥 生成并上传SSH公钥 Join The OpenStack Foundation 签署CLA贡献者协议 参考资料 前言 由Openstack基金委员会管理的Openstack社区,现在已经成为了全球第二大开源社区仅次于Linux社区,所以也有人将Openstack定义为下一个Linux。就从我个人角度出发,我认为Openstack和Linux不属于同
文本详细介绍了HDFS中的许多概念,对于理解Hadoop分布式文件系统很有帮助。 1. 介绍 在现代的企业环境中,单机容量往往无法存储大量数据,需要跨机器存储。统一管理分布在集群上的文件系统称为分布式文件系统。而一旦在系统中,引入网络,就不可避免地引入了所有网络编程的复杂性,例如挑战之一是如果保证在节点不可用的时候数据不丢失。 传统的网络文件系统(NFS)虽然也称为分布式文件系统,但是其存在一些限制。由于NFS中,文件是存储在单机上,因此无法提供可靠性保证,当很多客户端同时访问NFS Server时,很容
首先,在这里首先感谢台湾林智仁先生的开源工具包libsvm。使SVM算法更加普及。大家可以到下面的libsvm官网去了解相关的信息。 Libsvm官方网站- https://www.csie.ntu.edu.tw/~cjlin/libsvm/ 其次,我在使用过程中发现,先生svm_scale文件中无法将经过规约的文件输出到本地txt文件中,只能在控制台重定向,而我并不想在程序运行中打开控制台进行较为繁琐的操作。 所以我改造了svm_scale文件,实现了文件的写入,在这里可以和大家分享一下。 改造后新增参

Sqoop-1.4.5用户手册 - 2016-07-15 17:07:22

本文以 Sqoop User Guide (v1.4.5) 为主,对Sqoop-1.4.5的用户手册进行翻译,同时会结合一些实际操作中的注意事项一并写入。由于原文档很长,本文首先会以实际使用到的部分为主,逐步进行完善。 1、Introduction Sqoop是一个用于在Hadoop和关系型数据库之间流转数据的一个工具。可以使用Sqoop将数据从关系型数据库系统(RDBMS)比如MySQL或者Oracle导入到Hadoop分布式文件系统(HDFS)上,然后数据在Hadoop MapReduce上转换,以及
前言 近日在线上发现有些mapreduce作业的执行时间很长,我们需要解决这个问题。输入文件的大小是5G,采用了lzo压缩,整个集群的默认block大小是128M。本文将详细描述这次线上问题的排查过程。 现象 线上有一个脚本,为了便于展示,我将这个脚本重新copy了一份并重命名为zzz。这个脚本实际是使用Hadoop streaming运行一个mapreduce任务,在线上执行它的部分输出内容如下: 可以看到map任务划分为1个。这个执行过程十分漫长,我将中间的一些信息省略,map与reduce任务的执行

Hadoop+Hive部署安装配置 - 2016-07-15 17:07:47

最近结合具体的项目,搭建了Hadoop+Hive,在运行Hive之前要首先搭建好Hadoop,关于Hadoop的搭建有三种模式,在以下的介绍中,我主要的采用的是Hadoop的伪分布安装模式。写下来给各位分享。 准备工作: 以上所有的下载的安装包和解压后文件均在/usr/local/hadoop目录 1、 分别ssh到每台服务器上 ,在root用户下修改hostname su root vim /etc/sysconfig/network 如上图所示,HOSTNAME=master vim /etc/hos
本文主要结合Spark-1.6.0的源码,对Spark中任务调度模块的执行过程进行分析。Spark Application在遇到Action操作时才会真正的提交任务并进行计算。这时Spark会根据Action操作之前一系列Transform操作的关联关系,生成一个DAG,在后续的操作中,对DAG进行Stage划分,生成Task并最终运行。整个过程如下图所示,DAGScheduler用于对Application进行分析,然后根据各RDD之间的依赖关系划分Stage,根据这些划分好的Stage,对应每个Sta