为什么说LAXCUS颠覆了我的大数据使用体验

切入正题前,先做个自我介绍。

 

本人是从业三年的大数据小码农一枚,在帝都一家有点名气的广告公司工作,同时兼着大数据管理员的职责。

 

平时主要的工作是配合业务部门,做各种广告大数据计算分析工作,然后制成各种图表,提供给领导和客户,做为他们业务决策的辅助依据。

 

因为敏感性和安全的原因,我们的广告数据都是保存在公司自己的服务器里,而不是云上,并且做了各种隔离,防止有人盗取。大数据平台用的是目前流行的OpenStack + Hadoop谱系组合。

 

这套软件组合虽然时不时给我出点难题,但是好在部门里还有两位技术大牛帮忙盯着,有了问题都能在他们的辅导下及时排除,所以也还凑合着用。

 

今年三月,因为一位领导的推荐,开始试用一套叫“Laxcus大数据操作系统”的开源软件。半年使用下来,结果完全出乎我们的意料,不光使用操作简单,而且管理维护和开发方面也很完善,少了许多开发和维护工作,感觉整体大大超越了OpenStack/Hadoop组合。

 

这个月初,我们部门先进行了一次内部投票,最后经领导拍板同意,决定把我们的广告大数据业务全部转移到Laxcus上去运行。现在,我们部门正在做后续工作,把原来在OpenStack/Hadoop上的广告业务,逐步迁移到Laxcus大数据操作系统平台上。

 

在这次内部投票中,我投了赞成票,如果说问我为什么支持这个出力还要给自己找麻烦的决定,我想如果做过大数据管理员的兄弟,一定能够理解我这个选择。

 

比如,你刚上手部署集群的时候,一定有这样的经历:手头一堆软件模块,面前成堆的服务器,借着从书本和网上学来的星星点点的知识,努力理解着各个模块之间相似又不尽相同的功能,感觉象老虎咬刺猬--无从下口。

 

好吧,终于咬着牙去尝试了,小心翼翼改配置,调参数,费了九牛二虎之力,总算把几个模块连上了,也跑通了,突然,系统报警,一个节点崩溃,流程中断!赶紧去网上找资料,论坛去求助,等了好久,有了回复,照着去做,嗯,问题解决了,好了,OK,继续下一个...还是不行,晕!再试试...

 

如果说我不想做管理员,转行做大数据程序员,那么需要了解、理解的技术,花费的精力就更多了。不止是这些软件模块框架的功能、特点、运作流程,还要学习使用各种编程语言,貌似很神秘很牛X的算法,形形色色的开发规则和技巧。

 

几个月闭门苦读下来,终于写出一段DEMO,编译也通过了,部署到集群里,启动运行,故障!心里一万个草泥马狂奔!...冷静下来,打开IDE,一行行寻找故障点排错...

 

这些都是我的经历,我想做过大数据集群管理和程序开发工作的,这些泪喷的经历一定不比我少。实际上,这些还只是开始,以后随着工作业务逐渐展开,将会有更多坑冒出来。比如,怎样根据公司的业务需求,在几个功能相近又不尽相同的模块里,选择最适合的模块?模块与模块之间怎么搭配组合运行?怎样在模块、网络、业务之间进行调整优化,提高数据处理能力?发生故障后,怎样快速判断出故障点然后恢复集群运行?这些贴近实战的工作,都需要一点点积累经验知识,慢慢掌握。

 

而自从转向Laxcus大数据操作系统平台后,我发现,这些原本在Hadoop频频出现的坑,到了Laxcus已经被填平了。集群管理员和程序员,只要掌握一套接口,就可以管理大数据集群和进行程序开发,这比Hadoop谱系的多接口管理开发方案简单太多,我的整个学习曲线相当平缓,到现在也没有出现任何不可解决的问题。由于我不是技术专家,对Laxcus的认识有限,不敢妄谈很深入的技术细节,就想以一个普通大数据管理员和程序员的身份,根据我半年多使用Laxcus的经验,从正反两方面,从尽量公平的角度,谈谈我的Laxcus体验感受。先从它的优点说起。

 

优点

 

1. 功能全栈集成

 

如果说Laxcus最鲜明的特点,应该就是它集成了云计算和大数据所需要的主要功能,而且是从底层开始做起的全栈技术实现。这应该是这个产品最牛的地方。目前能做到这种技术水平的云计算大数据软件,我还没有发现第二个。

 

我曾经仔细读过Laxcus的产品论文和源代码,如果拿来对标OpenStack/Hadoop的话,它的里面其实包含着OpenStack的虚拟化和租户管理,HDFS的分布框架,Yarn的资源管理,Map/Reduce的分布计算,HBase的存储,ZooKeeper的分布锁,Spark的内存计算,Sqoop的数据转换,Ambari的可视化管理。

 

对于这些模块的使用,Laxcus的做法是,把它们的功能分散到不同类型的节点上去实现和处理,每类节点提供其中一种或者几种,然后装配起来组成一个集群。Laxcus集群是具备级联关系的主从节点合集,下级节点注册到上级节点,上级节点管理下级节点。运行过程中,上下级节点、同级节点之间会持续动态协调资源和工作状态,形成一种"弱中心化的组织管理架构(Laxcus产品说明书原话)“。

 

 

如果问Laxcus的集群构架对我们用户有什么好处,那就是,由于Laxcus在软件层面已经做好了各个模块之间的组织封装,省去了我们自己做搭配模块的协调对接工作,避免人工搭配过程中的出错可能。还有就是因为模块在系统内部高度集成封装的原因,它们之间的内聚性会更好,能够避免很多因为兼容导致的故障错误。反馈到运维上,则是降低了我们部门的维护成本,现在我一个人就可以完成整个大数据集群的维护管理工作。

 

对比Laxcus和OpenStack/Hadoop这两个产品风格,它们就好比是原装车和组装车的区别。Laxcus是原装车,不需要用户做任何准备工作,从4S店买来就可以直接上路,各种可能的问题也在出厂时降到最低。Hadoop是需要DIY的组装车,用户拿到手的是一堆配件,然后还需要有足够的专业水平,知道如何调校、测试,才能把车子组装起来,确保无误后上路。虽然这种方式灵活性足够高,也能有不错性能,但是需要付出更多的学习和时间成本。

 

除了上面这些模块,Laxcus还有其他功能。比如它把SQL和存储过程也整合进来了,这样看Laxcus又是一个超大号的关系数据库。还支持了中间件,在Laxcus里,中间件有一个专门的名称:分布任务组件。如果说它和EJB这样的中间件有什么区别,那么应该说EJB是为数据库分解压力提供中继处理的产物,而分布任务组件是有分布理论和分布系统支持、可以并发到成千上万个节点执行的真分布。所以Laxcus其实也是一个中间件服务器。

 

另外一些创新是其它大数据平台没有的。比如Laxcus能够同时支持列存储和行存储两种数据存储方案,这个用户需要同时处理OLAP和OLTP两种数据业务时,就可以在一个平台上完成了。还有为了弥补分布环境CAP理论这个短板,Laxcus实现一种叫“可调CAP策略”的技术,让用户根据自己业务需要,来选择解决CAP三选二的问题。

 

另外Laxcus有一个叫“跨账号资源共享”的技术,解决了多个用户之间,数据安全、私密性、共享之间的矛盾。我感觉这些技术都是挺重要的,虽然目前对我们公司的广告数据业务不那么重要。

 

Laxcus还有很多功能,因为我自己没用过不熟悉的原因,这里就不一一介绍。总之呢,Laxcus是一个庞大的体系,提供的功能非常全面,它把我们常用的各种数据处理需求和业务都集成进去了,帮我们省下很多功夫。剩下的事,就是按照Laxcus的要求,管理员管集群,程序员码代码,哎,又回到咱们码农的起点。

 

2. 全命令操作

Laxcus是一个完全由命令驱动的系统。所有集群管理和数据处理工作,都是用字符控制台、图形终端、驱动程序这三种交互界面,通过输入字符串语句的方式,转义成命令,提交到集群分散执行来完成。包括很复杂的分布式存储和分布式计算工作,也是这样处理。这是我感觉Laxcus和OpenStack/Hadoop很不一样,而更像Linux的地方。其实我一直深度怀疑Laxcus的设计者是一个Linux粉,要不怎么会想到这样的招式?

 

 

对于命令这种人机交互设计,我的感受是,管理员管理集群和用户操纵数据的工作都简单了,灵活性也不错,稍微学习一下就能上手。另外,Laxcus还做了一个很贴心的设计:允许用户定义私有命令。这些私有命令用专门的API支持,如果用户想在Laxcus大数据集群里,为自己的业务开发某些个性化的功能,就按照Laxcus规范要求用这套API,把自己的业务编码包装进去,然后发布上集群。Laxcus会自动识别它们,和标准的命令一起被执行。

 

3. 稳定性超好

 

Laxcus是我使用过的大数据软件里,稳定性最好的一个,没有之一!这套软件从我们开始试运行到现在,还没有发生宕机和故障停摆故障(因为停电造成的宕机除外),这和时不时给我找点麻烦的OpenStack/Hadoop这对组合相比,不能不说是一个奇迹。我曾经仔细思考过这个问题,还看了Laxcus的源代码,感觉应该和Laxcus的系统设计有直接关系。上面说过,因为OpenStack/Hadoop这对组合,各个模块之间是高度分离的,需要管理员来组合搭配它们,还需要程序员理解熟悉它们并且能够正确编程,才能保证集群稳定运行。

 

实际上,我在使用OpenStack/Hadoop的过程中,发现有很多的故障,就是由于我们对OpenStack/Hadoop不熟悉不理解和编程错误造成的。而Laxcus各个模块和功能接口之间是高度内聚的,不开放给用户,我们无法直接调用操作它们(除非直接修改源码),这样就直接避免了许多不必要的故障。

 

另外一个原因,按照Laxcus技术白皮书所说,Laxcus采用了两个叫做“松耦合架构和负载自适应”的两个关键技术。对于松耦合架构,它的官方解释是:“为适应复杂分布网络环境,可以临时组织和动态调配的工作模型。在这个架构下,所有硬件设备和软件模块,以及其上运行的数据处理工作,都被视为服务。它们在获得授权的情况下,可以自由的加入和退出,以离散、独立、弱依赖的形态存在”。

 

这段描述不知大家听懂没,反正我不大懂。但是以我的使用理解,这个松耦合架构的优势主要就是用异步会话减少了资源占用。因为在分布计算过程中,每个节点时刻都会产生大量的网络连接和数据计算,异步会话把很多同步完成的工作,切割成多段来处理。

 

它们只在需要的时候才产生连接和占用计算机资源,不需要的时候就断开网络和释放资源,空出的网络信道和资源会留给其它业务。这样就提高了计算机并行处理能力,改善了分布计算里最重要的资源使用占用的问题。负载自适应这个技术,是解决计算机物理压力和集群负载不均衡的问题。

 

它能根据计算机和集群运行中的负载状况,自动调整负载比率。达到或者接近负载范围会限载,超过就降载,强制所有业务在要求范围内运行,这样就把每个节点的物理资源控制在一个合理的范围内。我想这应该是Laxcus至今没有出现宕机现象的主要原因,感觉它比目前普遍用的负载均衡机制前进了一大步。

 

4. 规模大

 

按Laxcus产品说明书中的介绍,Laxcus的集群规模可以达到百万级物理节点和EB级的数据量(1000+PB)。我仔细看了这一段的技术文档,里面提到是采用了一个叫做“多域并行”的技术来实现的。按它文档的说法,以现有硬件的处理性能,一个集群的节点规模达到“千”级时,集群的资源管理和数据承载能力就会接近物理极限,很难再通过增加机器的方式,做更大规模的数据处理,而用户的数据处理需求总是在增长。

 

所以,为了解决这个矛盾,Laxcus采用这样一个做法:在单个集群之上,再建立一套管理模型,用一个并行的集群资源管理池来管理多个集群,然后让这些集群之间相互通信,实现跨集群跨节点的分布式存储和计算。

 

当然,百万级的计算机节点,EB级的数据,这种巨量的大数据集群我也没有试过。截止到这个月,我们部门的计算机还不到一百台,广告数据不过320TB,一个集群处理起来已经绰绰有余。TB距离EB,中间隔着PB,差了N个量级。但是给我的感觉,这套软件挺牛的,虽然对我们公司没什么用处,但是对那些数据量会持续快速增长的公司,尤其是云计算服务商,应该会非常有用。这个功能给他们的业务扩张留出了充足的空间。

 

5. 第三方友好,迁移成本低

 

如果说上面这些特点还不足以让我们放弃OpenStack/Hadoop这对组合,那么最终让我们下定决心迁移平台的原因,是Laxcus的第三方友好特性。在此之前,我们为了支持自己的广告大数据分析业务,已经开发了很多广告业务工具包和分布式应用,并部署在Hadoop集群里运行。在做迁移决定前,我们最担心的就是这些工具包和应用要推倒重写。

 

如果真的需要这样做,那就显得得不偿失了,况且我们也没有足够的人力,把几年积累下的代码重新设计开发一遍。这个问题我们先是请教Laxcus的技术支持工程师,通过和他们的接触讨论,我们发现这个担心是多余的。

 

首先Laxcus和Hadoop都是基于Java开发出来的,语言层面可以兼容。在系统架构、存储、分布计算这些底层核心要点上,它们都有可以对照类比的模块,整体设计思路也比较接近。区别是Hadoop谱系是多个团队开发,做得比较分散;而Laxcus是一个团队开发,软件内部的集成度更高,结构更紧凑。

 

后来,经过我们和Laxcus技术服务工程师的协调,我们只做了少量的改动,主要是一些配置上的调整和导入接口的修改,就把我们的应用转移到Laxcus平台,避免了我们重复开发的麻烦。这个担心消除后,我们部门才决定把迁移平台的决定提请给领导,并得到领导的同意。

 

6. 支持在线升级

 

Laxcus是能够在线升级和更新的,这也是我上个月前才注意到的功能。我统计了一下,目前Laxcus能够升级的部件包括:

 

1)用户发布到平台和使用的分布式应用

 

2)管理员发布和使用的分布应用

 

3)各种驱动和动态链接库

 

4)网络通信配置和安全授权许可

 

5)系统的几个核心包

 

这些部件除了用户的分布式应用是自己控制和发布外,其它都属于管理员的权利。所以算下来,每个节点其实除了负责启动的“壳程序”和通信接口,其它部分都可以在线升级。

 

我不太肯定这算不算是重要的技术特点,但是我感觉很方便实用,它让我实现了不停机状态下的系统升级,避免了停机升级的业务停摆问题。这就象是一个太空里的宇宙飞船,我一边给它维修更换零件,一边继续驾驶它绕轨飞行,这感觉真的很酷!

 

7. 中文化做得很棒

 

在中文化支持方面,Laxcus做得确实没话说,毕竟是国人团队开发的产品,无论是字符控制台还是图形界面,都提供了很棒的中文化支持。对于我这样长期在英语环境中浸泡着,饱受各种英文提示和故障错误的小码农来说,看到自己熟悉的文字,有一种发自心底的亲近感。

 

为了写好这段文字,也出于好奇,我昨天打开了Laxcus源代码,想了解一下Laxcus的中文化是怎么做的,发现里面一个小秘密。原来Laxcus把各种语言文字都做在配置文件里,软件启动的时候,会根据计算机操作系统的语言环境,自动适配对应的语言包,然后倒入运行环境,显示在屏幕界面上。这个设计很有新意,按照这个思路,如果我想支持更多的语言,不用修改源代码,只需要做些不同的语言包,就能实现我的目标。这是一个很有创意的妙招!

 

 

 

 

8. 配置极简

 

目前Laxcus每个节点都有这样三个配置文件:

 

1)节点配置。只在启动时加载,包括了日志参数、数据存取参数、异步处理参数,本地节点地址,上级服务器节点地址。

 

2)网络安全通信配置。在启动时加载或者运行过程中重载。配置由多个地址段组成,每个地址段有一组可受理的IP地址和RSA密钥。

 

3)沙箱配置。被容器使用,在启动时加载或者运行过程中重载。包括允许用户使用的物理设备、能够调用的API接口和动态链接库,能够读写的磁盘目录和文件 、是否可以保存自己的工作日志和何种类型的日志。

 

三个配置文件里,除了节点配置里的本地节点地址和服务器节点地址需要管理员根据网络环境手工配置外,其它都可以使用系统的默认配置。

 

Laxcus配置是我做大数据以来,接触的最简单的配置,比Hadoop谱系的配置实在简单太多!配置简单的好处,做管理员的应该是最有体会了,除了省事,更主要是减少了我们工作中的误操作,这是我又一个非常满意Laxcus的地方。

 

能把配置做得如此简单,又能保证系统足够稳定,还不失灵活性,Laxcus大数据操作系统的设计师应该是花了不少心思,同步感谢一下为Laxcus辛苦码字的码农同行们!

 

9. 全域安全

 

由于广告数据具有很强的私密性和敏感性,公司一直高度重视安全问题,所以Laxcus的安全管理方案,也是我最感兴趣研究时间最久的一个部分。按照Laxcus官方的说法,Laxcus做的是“全域安全管理”。

 

如果这个词不好理解,他们还有一个通俗的解释:“从键盘到硬盘”的安全管理。这个方案的特点是,只要用户登录大数据集群那一刻起,就被置于安全监管里。用户发出的每一条命令,命令中的每一步骤,步骤中的每一项操作,其中涉及到API接口、动态链接库、网络、内存、CPU、GPU、各种输入输出的时候,都在会在系统监管下执行,并且被记录下来。

 

任何一项操作被限制拒绝,都会导致整个分布处理的失败。所以,Laxcus安全管理方案的安全度非常高,它全栈式的安全控制,覆盖集群所有分布环节,把业务置于其中。

 

下面以我的经验,试着说说Laxcus的安全管理方案。

 

先说一下环境安全,这是Laxcus整个安全方案的基础。请看上面的架构图。虽然Laxcus以一个集群的面貌出现,但是它实际上是分成了内外两个网络。内部是管理员控制,集群各种主要工作,包括大数据的存储和计算,都位于内网。

 

外部给用户使用,Front是外部网络的唯一节点,它的作用是发出大数据命令和接受大数据处理结果。连接它们的是网关,网关实质就是一个反向代理服务器,在这里它有两个作用:识别用户身份,转发用户命令,和屏蔽内部网络拓扑结构。

 

我个人觉得网关主要作用还是屏蔽内网,这样即使发生DDOS这样的攻击行为,因为网关的中介位置和安全识别的原因,攻击也只能到此为止,内部网络可以不受影响。从应用角度看,由于私有云本身就在内部网络里,被攻击的可能性很小,所以我觉得这项设计应该还是针对公有云做的。

下面就进入了实际的安全处理流程,请看下面这幅Laxcus产品说明书里提供的安全流程图。

 

 

Laxcus是一个集群软件,所有节点都需要通过网络连接才能工作,所以网络通信的安全就成了安全方案的第一道关口。Laxcus在这里用的是RSA+SHA的双重安全验证。这个验证特点是,只要用户与集群发生网络通信,都会面临RSA+SHA的检查。

 

咱们写码的都知道,RSA是非对称加密,防止数据窃取,SHA是数字签名,用来保证网络两端的数据一致性,这两个是目前业内安全度最高的加密算法和签名算法。即使给RSA用上暴力破解,以现有技术条件,使用GPU/FPGA这些算力超强的芯片来做,加上Laxcus这种大规模分布计算系统加持,破解时间也需要以“年”计。

 

就算到时破解成功,数据也因为时效性而失去意义。所以网络通信这一层的安全还是很有保障的。另外这里还有一个安全设计:Laxcus的RSA加密针对的是单个用户,允许每个用户有一个自己的密钥,而不是所有用户共用一个密钥,这样就算某个用户的密钥遗失或者被盗,也不影响其他用户的通信安全。

 

往下一层是“对称加密”,这一层仍然和RSA有关。原因是RSA虽然提供了很强的安全保密手段,但是由于它的加密解密都非常消耗CPU算力,时间成本高,所以行业内的通行做法是数据加密解密由对称密钥来做,RSA给对称密钥提供外层保护,把对称密钥包含在RSA的数据域里。Laxcus也是这个路数,目前它支持的对称加密算法有DES、DES3、AES五六种。

 

如果用户希望用自己的对称加密算法,Laxcus也支持,只是过程有点麻烦,要按照它的规范实现加解密接口和写配置文件,然后导入系统。这些对称密钥都是在通信时由系统随机生成,通信完成后销毁,所以只要RSA安全的,破解对称密钥的可能性基本是零。

 

再往下就进入了“资源安全策略”层。这一层主要检查节点和接入操作的匹配关系,判断节点能不能支持接入的操作,操作有没有得到授权或者发生越权,如果存在问题,系统将直接拒绝这个操作。举个栗子,Laxcus强制规定大数据存储动作只能发生在Data节点上,其他任何节点出现这个操作,系统会不加思索地直接反馈错误。

 

接着就进入了“签名管理”层,这一层是处理用户虚拟化的工作。系统将根据用户签名,判断用户身份的合法性,和可以处理哪些具体的数据操作。另外,如果集群做为云服务使用时,系统还会检查用户的资源占比。这些资源包括了网络带宽、内存、硬盘、CPU/GPU。如果用户资源充足时,系统会启动用户业务。可用资源不足时,系统会让它转入休眠状态,直到前面的数据业务完成,用户重新拥有足够的资源时,系统才会重启这个业务。

 

再往下就是“用户安全策略”和“业务安全策略”。在我看来,它们是同一层,因为这两层的编码是混合在一起的,并没有清楚的层次分别。到了这一层,用户的数据处理工作将被放入沙箱,系统检查也转为监视用户的数据处理行为。比如,用户想把数据写入内存或者硬盘,系统会判断它的写入权限和可用空间。如果用户想调用系统的API接口,系统将检查他有没有调用权限。总之,系统会追踪用户在沙箱里的每一个操作行为,确保数据处理在规定的范围内运行。

 

Laxcus的安全设计大概就是这样,我归纳一下它的特点:Laxcus先用一个内外网的设计,把不安全因素隔离在外网,再用分层策略,加上加密、相关性、身份验证、虚拟化、行为监视手段,把用户和数据处理行为限制在规定空间里,通过这样一层层的安全控制,实现它全方位的安全管理。

 

 

10. 分布式编程和人工智能

 

现在我说一下Laxcus平台上的大数据应用开发,我想这应该是程序员们最关心的部分了。正好我这几个月一直做Laxcus大数据平台上的开发,现在也算是小有经验,所以可以和大家仔细说说这个事。

 

先说点理论的。按Laxcus产品说明书,Laxcus采用了一种叫做“模板化编程”的技术,而以我对Laxcus大数据平台编程的理解,这是一个经过高度封装的分布编程框架,所有大数据应用都在这个框架下实现。在这个框架里,它包含了两种编程模型,一个是用于分布式计算,背后的支持算法叫Diffuse/Converge,可以对标的是Hadoop的Map/Reduce算法,同时它还融合了基于CNN算法的人工智能技术,现在我们部门的各种广告大数据计算和分析业务,都是用它来实现,尤其是分支较多和散射型的分析业务,就大量使用了Diffuse/Converge里提供的CNN算法接口。

 

另一个是分布数据构建,背后的支持算法是Scan/Sift,这在Hadoop里还没有对标的算法,它属于ETL业务,工作重点是数据的重组、优化、清洗之类,数据仓库上会用得比较多,我们部门现在还比较少用。

 

虽然两个编程模型处理的业务不同,但是在分布编程框架里,它们遵循一样的分布处理规则。这个分布处理规则,Laxcus有一个专业的描述:“阶段(Phase)”。如果这个词不好理解,或者你把它理解成与业务场景匹配的作业需求,一个业务在不同场景下有不同的作业需求。

 

阶段根据应用场景,分为迭代和非迭代两种,迭代就是能够连续多次执行,非迭代只允许执行一次。一个阶段是不是支持迭代,Laxcus有明确规定。为了在运行时识别各种阶段,Laxcus还定义了各阶段的名称。大数据应用运行的时候,系统通过命名识别,将阶段分发到关联节点上,计算过程中,上个阶段的数据输出会成为下个阶段的数据输入,经过一系列节点上连续的分散和聚合,串行与并行的处理,最终输出计算结果。

 

技术实现上,对应各种作业需求,Laxcus给每个阶段设计了一个或者几个抽象接口。程序员们要做的事,就是实现这些接口,将自己的大数据业务编程嵌入进去,然后编译,打包成程序段,做成一个个即独立又联系的模块,Laxcus称这个为“分布任务组件”,其实也可以理解为一种中间件。

 

最后,程序员把分布任务组件组织到一起,起一个名字,包装成大数据应用,发布到集群上。系统会全程维护管理大数据应用,不用用户参与。另外大数据开发中的其他部分,比如网络通信、分布调度、数据IO、资源检索和获取这些功能,都在分布编程框架里封装好了,程序员用API直接调用。

 

如果给Laxcus的分布编程框架找个类比的对象,我觉得它很象安卓系统的MVP模型 。它们的共同特点是都把公共部分封装起来,留给程序员开发的只是和业务有关的逻辑部分,不同之处是Laxcus做得更彻底些,它的分布编程框架不光告诉我们怎么走路,连要走的路径都预设好了,让大数据开发工作完全有章可循。

 

目前我已经在Laxcus大数据平台上开发了许多应用,比如下面这个挖矿的程序,利用分布编程框架,还有计算机集群和GPU的支持,很快就能挖出我要的矿码。

 

 

 

  综上所述,由于Laxcus分布编程框架已经把大量功能做了封装,规范了分布处理流程,它的开发工作还是比较简单的,工作量也不大。各位如果要做Laxcus的大数据应用开发,需要做好这三件事:1. 清楚你公司的业务;2. 熟悉Laxcus分布编程框架、理解每个阶段和相关接口的功能;3. 把它们结合起来,做成大数据应用。

 

缺点

 

任何产品都不是完美的,上面说了Laxcus那么多好话,本着实事求是的原则,下面我该讲讲Laxcus的缺点了。这些问题虽然不太严重,但是也或多或少影响了我的大数据体验,给我的使用产生了不小的困扰,使我感觉Laxcus也不是那么完美。

 

1. 命令太多

 

据我不完全统计,Laxcus的命令,包括管理员的集群管理命令和用户的数据操纵命令,加起来大约有一百五十多个。如果再考虑到每个命令里还有许多选项,选项之间隐含的各种组合、前后文关系,并且能在不同场景充分理解和熟练使用它们,真不是一件轻松的事。实际上,我为了学习这些命令,已经消耗了很多时间,而效果是到今天我也没有完全掌握这些命令,很多时候还是借助帮助文档熟悉后才能去操作。

 

另外,用敲击键盘来输入命令,已经是一种非常古老的操作方式了,重复费时费力且不说,效率也实在太低,很容易出错,这是我不喜欢命令行操作的又一个原因。虽然命令确实简化了人机交互,但是它更多是把工作压力转移到集群管理员和用户身上,所以我不认为这是一种好的交互方案。我的想法是,能不能提供一些便捷的交互方式,比如用菜单和按纽,勾选各种选项来代替字符串输入,或者更进一步,借助人工智能和语音技术,来实现人机交互。希望Laxcus设计师能看到我的这个建议,未来能有更优秀的人机交互模式。

 

2. 缺少可视化制作工具

 

可视化号称大数据的最后一公里,Laxcus却没有提供一个可视化工具,不能不说是一个遗憾。这和Laxcus标榜的“一站式大数据解决方案”多少有些不相符。因为Laxcus这个缺失,我们部门制作大数据可视化的工作量,一点也没少,仍然要依赖Tableau来完成大数据分析的后期数据可视化工作。而用过Tableau的人应该都知道,这个图表软件是灵活性足够但是也足够复杂,而公司的广告分析主要需求是快速灵活的显示,所以Tableau对我们的业务来说,并不是最佳的可视化工具。

 

其实在我心里,一直有另外一个大数据可视化设计方案的构想。它将完全是动态产生,可以解决现在大数据可视化机械、呆板、耗时耗力问题。今天我借着Laxcus可视化这个话题,和各位说说,让大家帮我参考参考,给个意见,也许是一个创业机会呢。^_^

 

我的这个大数据可视化方案的核心是:可视化图表将不再由用户画出来,而是从数据里“长出来”。实现的过程是这样:用户首先定义一个可视化模板,模板里规定好图表布局,设置好各种图表元素的“种子”。图表种子可以生长,能根据不同的数据长出不同的样式。当大数据计算结果出来后,把它和可视化模板一起输入可视化生成引擎。引擎根据数据内容,驱动“图表种子”生长,最后生成我们希望的样子。

 

我的这个大数据可视化的优点是:即有灵活性,也避免了重复工作,还保证了绝对的实时效果,一举多得,对时效性强的场景特别有用。当然缺点也是有的,就是为了让可视化引擎理解数据,驱动图表生长,还需要在样板里配置一个图表解释器,由它负责把大数据计算结果转成引擎理解的格式。这要求用户能够理解数据内容,有一定编程功底,对初学者有一定的难度。

 

我的大数据可视化想法就是这样。有兴趣的网友可以联系我,一起尝试下,现在我已经有了一个初步计划,很可能这个小小的idea就能成就咱们一番事业!

 

3. 图形界面表现不佳

 

与Laxcus大数据集群进行直接交互的界面,有字符控制台和图形两种模式。其中字符控制台的使用感觉还好,但是图形界面,根据我之前使用NetBeans的经验,Laxcus的图形界面是用Swing做的,所以我曾经在NetBeans上遇到的所有与图形有关的问题,在Laxcus图形界面上也一个不漏地出现了。

 

比如,有时候某个控件会莫名其妙地失去焦点,或者文本框不能输出文字了。如果重启一下,这些故障就会消失。还有,我平时除了使用Windows,有时候也会使用Linux来管理维护Laxcus大数据集群,而Swing在Linux平台上的表现更糟,除了上面的诸多问题,还有乱码现象。我知道如果追踪下去,这些问题都会汇聚到Swing身上。

 

如果说上面的问题我还能够忍受,那么更严重的是Swing运行缓慢和交互迟滞的问题,特别是Swing经过长时间运行,或者与其他节点频繁交互显示大量图像时,这种情况尤其明显,已经几乎无法忍受。

 

所以,我非常希望Laxcus的研发团队用其它图形界面来取代糟糕的Swing,比如Eclipse平台的SWT,以我使用Eclipse的经历,SWT这个图形界面,无论是界面的美观度、与本地平台的契合、对内存的占用、还有交互反应能力上,都比Swing好太多!Swing界面糟糕的表现,我很早就反馈给Laxcus服务支持团队了,不知道他们什么时候能解决这个问题。

 

4. 服务不到位

 

最后,我不得不吐槽一下Laxcus的技术服务。我不知道我们公司是不是第一个吃Laxcus这只螃蟹的,但是应该肯定不是最后一个。由于网上Laxcus的技术资料实在太少,很多时候,我们遇到问题的时候,不得不去请教Laxcus的售后服务,而负责解答的两位售后小哥,显然也不是专业人士,很多问题,他们都要再去请教他们的技术专家才能回答我们,一来二去,耽误了我们不少时间。有好几次,我们已经通过查阅源代码找到解决问题的方案了,对方的反馈还没有回复。到后来,我们干脆死了这份心,遇到问题都直接看帮助文档和源代码。虽然这样做强迫我们提高了自学能力,但是我也不得不说,Laxcus的技术售后服务实在太差了!

 

结束语

 

写到这里,我的评论准备结束了。因为使用时间和经验的原因,我的表述可能有不准确的地方,希望有经验的网友提出批评指证,与我交流切磋。

 

最后,我再说一点我个人的看法。凭心而论,Laxcus带给我的惊艳很多,但是缺憾也不少。Laxcus研发团队能深入理解用户需求,把那么多大数据和云计算的技术融汇贯通,聚合到一个产品里,简化了大数据云计算的开发维护管理工作,并且在Hadoop之外,建立了一套全新的大数据技术体系,用一个产品一套接口,完成Hadoop谱系多模块多接口才能实现的事,确实给我很大震撼。

 

相当程度上,改变了我对大数据的技术认知,颠覆了我原来的大数据使用体验,这是一件非常了不起的事,非常不容易。我们现在正在从IT时代向DT时代进步,大数据肯定是未来各个行业的基础,基于大数据的应用和服务会越来越多,简单、好用、省约成本将是大数据应用开发和维护管理的核心,Laxcus显然是抓住了这一点,把各方面工作难度降到一个很低的水平。

 

据我有限的了解,目前国内,能开发出Laxcus这种级别软件的研发团队屈指可数,我们应该多支持这样的团队,希望Laxcus能补齐短板,未来有更多像Laxcus的产品来简化我们的工作生活,祝Laxcus越做越好!

posted on 2018-12-05 13:04  liudongyang  阅读(306)  评论(0编辑  收藏  举报

导航