msgbartop
List for SAS fans and programmer
msgbarbottom

04 10月 10 SAS语言管窥 SAS_Dream 2004


这个文章最早见于2004年的sasor论坛,现在读来,仍然感觉经典。

尽管SAS经过这么多年发展,并且现在版本更新越来快,新模块和新功能如雨后春笋般冒出来,但是经典的文章仍值得再读一遍,哪怕是你读过很多遍。前一文转载了SAS的零碎印象一文,这两文每次读来都感到自己见识局限。因此,“精通“一词不管用于形容一个人的SAS技术,还是用来作为书名,值得谨慎考虑,再此,重读一些这些经典文章来提醒自己。因此,本博虽崇尚原创,并且网上的转载无数到连作者和出处都变更无数或者干脆没有,但是这里仍推荐大家重读一次经典。          saslist.net

另外,我很迷惑一点,为什么时隔五六年,还没有超过这两篇的关于SAS的中文评论出现,是没有像SAS_DREAM这样的技术高手,还是技术高手很忙?

附:

SAS语言管窥

由 SAS_Dream » 2004-3月-28 00:15

感觉SAS语言体系是庞杂多于宏大。因为很多可以称得上宏大的语系例如微软系或者现在的Java系,多是先有一个比较周全的架构,通过有序的新生、继承和变异,逐渐扩展膨胀的,语言元素之间有比较规范的关联。而SAS的语系虽有局部的架构,但就全局而言,主要是自发形成,也就是20多年的堆积和承袭。其实这也自然,SAS的应用领域靠近最终用户,模式千变万化,很难现有周全架构,只要有可行解就行了,而很多有组织的语系比较靠近系统底层,实际范畴比较集中,比较容易研究出架构。

因此,SASOR们的武艺和兵器往往是门派繁多,千变万化,但是很难有那种18般兵刃样样精通的武林宗师(如果那位知道有,麻烦通知一下,我们好沐浴焚香去拜)。

粗浅的印象是,SAS语系可以大致如下划分:

国语:Base语系

这是SASOR们不分阶级不分贫富都可以讲的话,里面就包含了常说的Data Step,Proc Step和Macro。SAS的基础语言元素主要是在这里演进而来。这个语言可以说是七十和八十年代面向过程处理语言的扛鼎之作,甚至还带有浓郁的非结构化色彩;难得的是SAS公司作为偏重技术的私人公司,二十多年以继承发展而非不断否定的方式打造Base,使得一些二十多岁“高龄”的函数和过程历久弥新,在如今面向对象的强势群体中仍以面向过程的独特魅力占有一席之地。

Data Step为处理与数据存储引擎的交互提供了规范,可以处理大量复杂的数据操作和变量操作,Data Step的底层是用C语言开发的。而Proc Step的出现则具有两重含义,一是将一些常用的过程组合归整为固定的过程调用,在语言书写上或处理效率上起到提升作用;二是确定了今后很多SAS模块语言的规范,比如PROC 的调用格式,CLASS, VAR, BY等语句,被广泛地应用在统计模块(如Proc Reg),数据访问模块(如Proc DBLoad),多维模块(Proc MDDB),数据共享模块(如Proc Server)以及很多GUI驱动的模块的shell命令(如EM中的Proc Neural)。Proc Step用Data Step和C语言结合开发而成。

Macro是Base中增强程序流程控制的语言机制。Macro并不是函数封装的概念,它的核心思路是文本替换,同操作系统shell脚本的机制相似。因此,macro的执行是依据macro定义首先进行文本替换,得出最终程序语句后再解释执行。所以在内存分配中,并不像其它语言中那样形成函数调用堆栈。所以在Macro开发中,不能像函数调用那样实现调用现场退栈式的参数传递。虽然这种机制不像函数调用那样带来更多的编程灵活性,但是由于文本替换不涉及复杂的内存分配管理,所以即使用很复杂的macro,替换的效率也很高,同时出现内存管理错误的概率也较小。由于Macro的设计含有大量的非结构性元素,所以编程的流程管理要多加注意,否则很容易造成程序可读性差的现象(事实上,看到%就想吐的现象是普遍存在的)。

Base中有一个过程值得单独加以考察,就是Proc SQL。事实上,它实现了对SQL的兼容,给很多熟悉SQL的编程者多了一个选择。截至V8系列,Proc SQL使用的SQL是基于SQL92标准的SAS SQL超集,有很多SAS特点的语法。关于同样的处理是使用SQL还是Data / Proc Step效率高的问题可以另行讨论,简单的说,从设计思路上,SQL是基于集合的语言,而SAS是基于记录的语言;SAS的开发在SQL和Data / Proc Step上并不是协调一致的,在V6的SAS中,很多SQL操作明显比Data / Proc Step低效,在V8中,SQL有了明显改善,有些情况下会超过Data / Proc Step,但是也需具体情况具体分析,随着数据量的增长,Proc SQL不如Data / Proc Step内存管理稳定的现象会渐渐明显,效率会有较大差距;在V9开发中,SQL的势力进一步增强,提升幅度也会比以前大。

Base语言的技能和思路是SAS的基本功,也是进入至高境界的重要途径。对于初入江湖的少侠,Base语言像马步冲拳非连不可,而到了“手中无剑,心中有剑”境界的大侠,也往往只用SAS摆平一切,代码思路之惊艳让人叹为观止。

官方语言:分析语系

分析语系是以PROC STEP架构扩展一些分析模块的语言,包括STAT,OR,QC,ETS,Insight和EM的shell过程,还有用于算法扩展的IML等。

分析语言有些贵族,因为需要有相应的背景特别是统计背景的人才能讲好。换句话说,SAS的贵族气质,主要也是靠分析语言表达。

经典统计语言STAT是名门望族的常用语,每个过程都是多年的功力积累,所以即便是极为常见的过程,也是在性能、精度特别是边界条件处理上表现出众,任何一个竞争对手,如果有机会去看到STAT开发组的豪华阵容和深厚积淀,都应该知道想要技术上超越STAT要承受的压力。

经济时间序列语言ETS也是在一个专门领域练透内功的产物,支持的算法种类和可定制性十分突出。

QC和OR语言是在专门学科应用领域的力作,尤其QC,是大型分析套件中,位置十分突出,不过这个领域里竞争对手的研究也很深入,做到关键功能不逊于SAS的也有。

Insight的语言主体是PROC Insight,可以以后台批量方式完成Insight操作。

EM的语言是针对EM中的各个处理节点,提供相应的PROC集合,例如PROC DMDB来生成数据挖掘数据库,PROC TREE实现决策树,PROC NEURAL实现神经元网络,等等;这种语言扩展有很重要的意义,很多厂家在炒“in database mining”的概念,实质上就是可以用一些挖掘语言直接对数据库进行挖掘操作,而EM语言与SAS数据引擎和其它SAS语言本身就是浑然天成,优势独到。

IML是针对矩阵定义和运算的语言扩展,有些另类,但是用好了可以写出很多复杂的算法。并不是所有的人都能或者都需要学好分析语言,而且把所有分析语言都精通和熟练也非易事,但是结合实际问题和统计知识,多理解一些对于思路的发展益处多多。其实数据库领域本身是非常适合统计知识的应用的,经常为数据库管理所累的设计开发者,借助SAS实地操练一些统计知识,会发现另外一片天地,比如数据库的查询命中率优化和结果数估算,数据量推算,数据仓库里的数据质量评估和提升,数据库厂家的很多方法知识含量少得可怜,用上SAS的分析语言,往往是迎刃而解。

形体语言:Graph

SAS Graph的强项不在于免编程的易用性,而在编程语句的完备。真正掌握了Graph编程会获得极大的自由,尤其是会熟练运用Annotate之后。有两大类方向上可以施展Graph功力,一是统计分析,当年SAS的数据挖掘大师Will Potts(现在在Data-miners,与Gordon Linoff等大师共事)讲解神经元网络的时候,就是自如运用Graph语句观看效果,辅助分析,熟稔程度令人叹为观止;一是应用展示,Graph对于图形种类的支持、定制的变化、比例的调配、边界条件的处理以及大数据量绘图的优化处理上均有不俗表现,很多时候Graph结果会给应用展示增添耀眼的亮点。

Graph技能出色的SASOR,像是轻功超卓的大侠,挥洒之间,偶像感十足。

时尚语言:SCL(AF)

SCL隶属于AF模块,是SAS语言中具有面向对象特征的开发语言。它的主创人之一据说是在SAS总部的一位台湾设计师,而且是OOP里还算开始比较早的开发语言。SAS一度想利用SCL与业界的流行开发语言体系接轨,其间加大投入,但是由于这个领域自身变幻莫测,SAS又不是领头羊,因而SCL在最近版本中具有极强的“时尚色彩”,所谓“时尚”,就是容易张扬也容易过气。SCL的名字也经历着变化,原先叫Screen Control Language,老老实实地想做GUI,后来叫SAS Component Language,俨然一副改天换地挑大梁的架势。而现在,Java在研发中的呼声很高,SCL的前景就很微妙,因为新派的Java系开发者对SCL和Base知道得相对较少,而传统的了解Base的SCL开发者转型Java也并非易事,SCL逐渐从前台退到后台,甚至重点集中到了通信接口层。因此,SCL是否会就此过气,很多人在怀疑中… ….

个人的观点是,SCL还是一套很漂亮的开发语言,自己建立了一套变量规范和流控体系,特别是OOP的体系,虽然C或者Java的熟手会看着怪怪的,但是实用性和效率上还是有自己的特点。SCL中的最重要的数据结构是SCL List,这是一种类似于Java数组的树形数据结构,这是一个兼顾灵活性和处理效率的设计,整个对象体系在这个结构上做文章,核心思路简明精炼;同时在与SAS数据引擎的交互上有突出的便利性。

至于SCL中的一些可视控件,也就是众多的FRAME元素,虽然在某些方面有特点,但总体上是乏善可陈。

SCL的使用主要集中在应用开发特别是一些前端开发上,但是AF,以及利用AF开发的EIS等模块都有些前景未卜,到底如何投入精力去掌握SCL,是个值得思考的问题。

劳工号子:引擎类语言MDDB和SPDS

这里没有丝毫贬义,因为使用多维引擎MDDB或者并行引擎SPDS的开发者,多是责任多于成就感,劳累多于飘逸的苦行者。

SAS MDDB是SAS用于多维处理的模块,现在有更时髦的名字SAS OLAP Server,后台的核心语言元素是Proc MDDB,这是个处理多维存储的功能强大的过程,想充分发挥SAS多维引擎优势的开发者,不妨着力修炼一下这个过程步。

SPDS是SAS用于并行处理的数据引擎,其实是SAS的数据引擎宗师Ami自创的一套独立的并行数据库,和Base SAS特点迥异。Base SAS对于SPDS的处理就像连接Oracle等外部数据库,Base语法用于SPDS很大程度是为了程序书写形式的兼容,而要想真正发挥SPDS的并行优势,需要掌握一套基于SPDS的SQL,和SQL Pass Through的连接语法。SPDS的名气不是很大,但在有经验的设计师调配之下,它发挥的性能是惊人的。

但是这两个语言的问题是,当劳工渐渐转变为白领以后,劳工号子就可能变了… …OLAP和SPDS是SAS V9和以后版本表面封装的重点,语法变化和依附性变化都会很大,所以旧船票是否能登上明天的客船还是一个谜… …

外地语言 Connect / Share和外语Access

Connect和Share是本地SAS调用远程SAS进程的通讯机制,SAS的C/S架构使用对等主机的概念,SAS主机之间可以通过Connect语言中的Rsubmit块、Proc Upload/Proc Download等语言元素互相提交任务,反馈结果。Share语言的主体是Proc Server,通过这个过程,将SAS数据和计算共享给远程SAS主机或是ODBC,JDBC接口。

ACCESS模块的功能是使SAS可以和很多异构数据库进行双向透明的交互。V8以后的ACCESS可以通过Base语言中Libname的扩展节省编程语句的复杂度,但是在必要的时候,仍可以通过ACCESS、DBLoad等过程来处理灵活复杂的要求。

其它边远地区的方言

还有很多模块可以通过Proc Step扩展或SAS函数的形式拓展SAS语系的范围。这里不再赘述。

原创文章: ”SAS语言管窥 SAS_Dream 2004“,转载请注明: 转自SAS资源资讯列表

本文链接地址: http://saslist.net/archives/87


09 9月 10 关于SAS的零碎印象 SAS_Dream 2004-03-26


SAS_Dream大侠的《关于SAS的零碎印象》,可谓是给我们启蒙SAS的盘古般的大作。大作2004-03-26 17:26首发于sasor.feoh.net,虽然很多人用SAS很多年,但是读了这篇之后,才渐渐识得SAS的庐山真面目。尽管这篇文章已经问世六载,我也看了很多遍,每次读来都倍感有收获,因此仍完整地转载于此,以饲读者。

关于SAS的零碎印象

注:SAS_Dream于 2004-03-26 17:26发表 在论坛sasor.feoh.net

不管你以何种方式接触SAS,不管你接触SAS已经多久,“SAS是什么”,始终是一个几乎无法回答的问题。

不同应用领域的人使用的SAS特性差异,可以大到像不同公司的产品。所以,SAS交流大会,经常听到的惊呼是“啊,SAS还可以这样做”,而发出这样惊呼的人,不乏很多资深者。

因此有种说法是“SAS博大精深”,可是事实上似乎不是SAS本身而是SAS涉足的领域博大精深。去考察一下SAS产品和方案模块的各个细分市场,几乎每个都是竞争对手强悍,业内知识浩繁;再去考察SAS的各种成功案例,主要的成分往往都是使用者的智慧积累而非产品功能,与同业软件并无大异,很多时候案例的吸引力是决策分析领域相对于其它领域的吸引力,不是产品本身的吸引力。其实,公平的说法好像应该是,使用SAS的人,往往是愿意在决策分析方向上不断思考的人,他们会通过SAS产品,在决策分析领域进行深入实践,最终形成一个博大精深的气候。

很多情况下,SAS用户所做的事情已经让SAS厂家感到非常惊异,所以说“SASOR博大精深”仿佛更贴切些。

从SAS发展的功能范围,时间跨度和地域差异上去思考一下,也许可以离“SAS是什么”的回答更近一些。

SAS的功能范围,大致上是从专业统计分析到企业级应用,从工具销售到解决方案销售逐渐演进的。从90年代初开始,也就是SAS V6系列的产品起,SAS加大了企业应用类模块的开发和推广,主要是数据存储管理,复杂报表工具,大型分析套件,前端应用开发工具,企业应用系统管理工具,还有针对性更强的特定应用套件,2000年以后,更是把专业咨询服务作为发展重点,所谓的解决方案,就是定制的系列产品线+特定内容的咨询服务的收费组合。十几年的发展,按照现在国内软件企业的流行说法,已经形成了“几横几纵”的格局,横指的就是从数据管理,分析建模到前端展现各个环节的工具层,纵指的是金融、电信等行业和细分行业的针对性方案,组合了各种工具和服务。这种变化带来了积极的影响,但是也同样也遭遇了更多的强劲对手,更遭遇到了企业级应用领域的诸多难题,客观的讲,SAS在这些问题的解决上并不明显比对手好。到目前为止SAS在企业应用领域的声誉并没有超过在专业统计分析领域的声誉,即便是革新时期声名鹊起的代表作Enterprise Miner,在很大程度上也是借助了经典统计算法的扎实基础。所以,很多关于“SAS好还是不好”的争论,放在不同的应用层面,结论会大有不同。

个人看法是,SAS具备“两强一有”的特点,就是分析强,处理强,企业级应用的大体功能环节都有。SAS的分析功能,综合考虑其深度和广度,至今还是业界最高地位,其它产品如S-Plus,SPSS等,综合比较很难占到上风,当然,反过来说SAS的优势也不是绝对的;

处理功能说起来有点像一滩浑水,因为处理的范畴很大,但是通常讲,把数据从原始状态转换成适合于各种分析的状态,不考虑回滚、事务等特征,SAS在语言功能上的丰富性是有优势的,它的分析对手尤其是强调免编程的对手,在这方面功能不免捉襟见肘,它的处理对手尤其是数据库系的对手,在针对分析的变换上也是心有余而力不足,其实在很多情况下,这个优势比分析优势还大,只不过这个领域比较模糊,不容易形成明确印象罢了;至于说到企业级的应用,不论从数据仓库工具,OLAP工具,报表工具,到风险管理方案,市场营销分析方案,大大小小SAS还都有,和其它厂家一样,这年头也是言必称CRM,数据仓库和Java。就是这“两强一有”,让SAS在决策分析领域有独特的地位。

关于“SAS是不是好用”的问题,一种说法是“SAS是架钢琴”,上手不容易,但是可以玩到至高境界,而其它竞争对手如S-Plus和SPSS则像“电子琴”,上手容易,想玩儿的很深很灵活比较难;的确,SAS的学习曲线初期是比较长,不仅对用户,甚至对工程师内部学习都是这样,而真正事倍功半的境界需要较长的积累;不过现在的事实是,SAS和竞争对手都在向“合成器”这个方向上使力,做成傻瓜加专家都适用,“演奏”都可以登得厅堂的产品,所以SAS开始发力前端,甚至Java架构不离口,但是在这方面,毕竟是晚生后辈,而其它竞争对手也是全力以赴,或加强后端,或收购合并,像SPSS收购了ISL的Clementine,在数据挖掘上从易用性到功能上对SAS形成了极大冲击,要知道ISL是业界最早以产品化思路研发数据挖掘的公司之一,功能设计上的功力也非同一般;目前,SAS这架钢琴的学习曲线尚未明显缩短,而以Clementine、QuadStone为代表的产品在功能深度上的迫近却是咄咄逼人,SAS的排位也因此变得微妙。

另一种解决易用性的方法是加入向导服务,也就是,“SAS的人教你弹钢琴”,是SAS卖服务的思路,存在的问题是:“造钢琴和保养钢琴的知识不代表能弹好琴,或者教好琴”,很多决策分析应用服务的成熟性和重用性都相对不高,连达到ERP的规范级别都难,要想用好不仅仅是看懂语法那么简单,“钢琴教师”需要懂产品,懂行业,可以举一反三,还要有传授知识的方法,这些往往靠多年的专业服务经验积累。SAS的服务经验多来自参与项目人员的自发经验积累,水平高低往往看各人的造化,以商务模式有组织的发展专业服务,SAS公司自身也需要一个积累学习的过程,并不像商务宣传口号那般简单;所以,在很多场合下,“SAS是不是好用”,还要看用户自身的水准,以及与产品服务的沟通。

从公司发展的时间阶段来说,SAS公司的策略也如其它厂家一样,在各个阶段有明显变化,特别是从2000年以后,SAS在推广策略上进入了大转型阶段,从公司CI,到产品组织,都不断地变化着。这一点从SAS网站上可以明显看出。很多时候,SAS在新版本的更新中,不是在开发新的功能,而是重新拆分和合并模块组合,改变宣传口径,有些换汤不换药的感觉,同时,在过渡期,也造成了相应的混乱;常有的情形是,看到一个神奇的名称,仔细一打听原来是几个老模块改了个名字,或者是,老用户突然在新版本找不到自己熟悉的模块调用了;V9很多变化是这种重组的结果,相对来说算是一个总结,但是这种架构是否稳定到下一版本,也很难说。所以考察SAS方案,不仅要听其言,还要观其形,更要摸摸它的模块……

对于SAS功能和发展方向的转型,各个地域消化并不均衡,有些时候,不同SAS分公司的对于SAS的推广,也让人有天壤之别的感觉。比如历来SAS有北美和欧洲两大强势阵营的划分,北美阵营以工具销售为主,强调软件的通用功能和强壮性,而希望用户及推广伙伴去开发针对性应用,欧洲阵营重视开发有针对性的应用,强调根据具体应用特点自己主动进行二次开发,认为对用户的适用性比软件的绝对性能重要,结果经常是欧洲开发了一些应用,反响比较好的,拿回北美总部去做引擎整合。因此,看欧洲和北美的客户案例,感觉不一样。再看亚太区,日本是传统的统计分析工具式的销售仍占主导,单纯的Base 或加上STAT的组合销量很旺,用户的应用是扎实稳健,但是技术的发展有些滞后;台湾是在V6的时候重点推广了QC和针对性OLAP应用,一时成为亚太的亮点;韩国则是骤然加速,在电信流失分析和制造行业管理分析上成为领头羊;说到中国,则像现在很多领域的发展一样,有的方面很前卫,有的方面又滞后得多,有极强的动态性。所以,如果有机会去亚太转转,不同人讲的SAS故事会让你想“这是一家公司的产品吗”……

原创文章: ”关于SAS的零碎印象 SAS_Dream 2004-03-26“,转载请注明: 转自SAS资源资讯列表

本文链接地址: http://saslist.net/archives/72