SAS语言管窥 (ZT)

建不了的模。

SAS语言管窥 (ZT)
( X- E9 N+ Y% T! c2 m' Z( n3 }这篇文章转贴自mysas.net。对SAS编程了解的人读后会很有感受。
9 J$ {2 W4 i6 N4 t# p2 @
感觉SAS语言体系是庞杂多于宏大。因为很多可以称得上宏大的语系例如微软系或者现在的Java系，多是先有一个比较周全的架构，通过有序的新生、继承和变异，逐渐扩展膨胀的，语言元素之间有比较规范的关联。而SAS的语系虽有局部的架构，但就全局而言，主要是自发形成，也就是20多年的堆积和承袭。其实这也自然，SAS的应用领域靠近最终用户，模式千变万化，很难现有周全架构，只要有可行解就行了，而很多有组织的语系比较靠近系统底层，实际范畴比较集中，比较容易研究出架构。
因此，SASOR们的武艺和兵器往往是门派繁多，千变万化，但是很难有那种18般兵刃样样精通的武林宗师（如果那位知道有，麻烦通知一下，我们好沐浴焚香去拜）。

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


0 b4 P. R& Z2 x6 x6 s  O) U: }, m国语：Base语系
/ q. h; P* A! |4 U3 Y7 R/ V% O这是SASOR们不分阶级不分贫富都可以讲的话，里面就包含了常说的Data Step，Proc Step和Macro。SAS的基础语言元素主要是在这里演进而来。这个语言可以说是七十和八十年代面向过程处理语言的扛鼎之作，甚至还带有浓郁的非结构化色彩；难得的是SAS公司作为偏重技术的私人公司，二十多年以继承发展而非不断否定的方式打造Base，使得一些二十多岁“高龄”的函数和过程历久弥新，在如今面向对象的强势群体中仍以面向过程的独特魅力占有一席之地。
* x* m# Z# q9 u% ?0 V6 z' S& tData 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语言结合开发而成。
7 }7 g; J) y) j2 ~; G6 }% l- _  C: VMacro是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的势力进一步增强，提升幅度也会比以前大。
0 B( |6 ^' I$ R( n* S8 O/ lBase语言的技能和思路是SAS的基本功，也是进入至高境界的重要途径。对于初入江湖的少侠，Base语言像马步冲拳非连不可，而到了“手中无剑，心中有剑”境界的大侠，也往往只用SAS摆平一切，代码思路之惊艳让人叹为观止。
' [9 T. J9 W1 |: r1 N3 m
官方语言：分析语系
分析语系是以PROC STEP架构扩展一些分析模块的语言，包括STAT，OR，QC，ETS，Insight和EM的shell过程，还有用于算法扩展的IML等。
分析语言有些贵族，因为需要有相应的背景特别是统计背景的人才能讲好。换句话说，SAS的贵族气质，主要也是靠分析语言表达。
: E1 f. K+ w4 K5 p3 ?* l经典统计语言STAT是名门望族的常用语，每个过程都是多年的功力积累，所以即便是极为常见的过程，也是在性能、精度特别是边界条件处理上表现出众，任何一个竞争对手，如果有机会去看到STAT开发组的豪华阵容和深厚积淀，都应该知道想要技术上超越STAT要承受的压力。
0 ^- e  s8 U. a! C- f经济时间序列语言ETS也是在一个专门领域练透内功的产物，支持的算法种类和可定制性十分突出。
QC和OR语言是在专门学科应用领域的力作，尤其QC，是大型分析套件中，位置十分突出，不过这个领域里竞争对手的研究也很深入，做到关键功能不逊于SAS的也有。
Insight的语言主体是PROC Insight，可以以后台批量方式完成Insight操作。
1 q* a- x# }; j" OEM的语言是针对EM中的各个处理节点，提供相应的PROC集合，例如PROC DMDB来生成数据挖掘数据库，PROC TREE实现决策树，PROC NEURAL实现神经元网络，等等；这种语言扩展有很重要的意义，很多厂家在炒“in database mining”的概念，实质上就是可以用一些挖掘语言直接对数据库进行挖掘操作，而EM语言与SAS数据引擎和其它SAS语言本身就是浑然天成，优势独到。
IML是针对矩阵定义和运算的语言扩展，有些另类，但是用好了可以写出很多复杂的算法。
并不是所有的人都能或者都需要学好分析语言，而且把所有分析语言都精通和熟练也非易事，但是结合实际问题和统计知识，多理解一些对于思路的发展益处多多。其实数据库领域本身是非常适合统计知识的应用的，经常为数据库管理所累的设计开发者，借助SAS实地操练一些统计知识，会发现另外一片天地，比如数据库的查询命中率优化和结果数估算，数据量推算，数据仓库里的数据质量评估和提升，数据库厂家的很多方法知识含量少得可怜，用上SAS的分析语言，往往是迎刃而解。
0 |  r/ g* c: x
形体语言：Graph
SAS Graph的强项不在于免编程的易用性，而在编程语句的完备。真正掌握了Graph编程会获得极大的自由，尤其是会熟练运用Annotate之后。有两大类方向上可以施展Graph功力，一是统计分析，当年SAS的数据挖掘大师Will Potts（现在在Data-miners，与Gordon Linoff等大师共事）讲解神经元网络的时候，就是自如运用Graph语句观看效果，辅助分析，熟稔程度令人叹为观止；一是应用展示，Graph对于图形种类的支持、定制的变化、比例的调配、边界条件的处理以及大数据量绘图的优化处理上均有不俗表现，很多时候Graph结果会给应用展示增添耀眼的亮点。
Graph技能出色的SASOR，像是轻功超卓的大侠，挥洒之间，偶像感十足。
6 [6 Q8 @/ H! G

; ?% A& m( |. O时尚语言：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数据引擎的交互上有突出的便利性。
* `2 ]# z; `& w  y& P# {& A/ Q( f至于SCL中的一些可视控件，也就是众多的FRAME元素，虽然在某些方面有特点，但总体上是乏善可陈。
5 e2 m. n# o) ~8 p! v: WSCL的使用主要集中在应用开发特别是一些前端开发上，但是AF，以及利用AF开发的EIS等模块都有些前景未卜，到底如何投入精力去掌握SCL，是个值得思考的问题。

9 m4 ]" p2 N. s* H劳工号子：引擎类语言MDDB和SPDS
" g; N3 [7 P5 h% E( d. @这里没有丝毫贬义，因为使用多维引擎MDDB或者并行引擎SPDS的开发者，多是责任多于成就感，劳累多于飘逸的苦行者。
* M% o- ~% O4 S/ w9 ISAS MDDB是SAS用于多维处理的模块，现在有更时髦的名字SAS OLAP Server，后台的核心语言元素是Proc MDDB，这是个处理多维存储的功能强大的过程，想充分发挥SAS多维引擎优势的开发者，不妨着力修炼一下这个过程步。
0 p) ?3 r' G+ M3 z: l4 B6 a' _1 CSPDS是SAS用于并行处理的数据引擎，其实是SAS的数据引擎宗师Ami自创的一套独立的并行数据库，和Base SAS特点迥异。Base SAS对于SPDS的处理就像连接Oracle等外部数据库，Base语法用于SPDS很大程度是为了程序书写形式的兼容，而要想真正发挥SPDS的并行优势，需要掌握一套基于SPDS的SQL，和SQL Pass Through的连接语法。SPDS的名气不是很大，但在有经验的设计师调配之下，它发挥的性能是惊人的。
但是这两个语言的问题是，当劳工渐渐转变为白领以后，劳工号子就可能变了… …OLAP和SPDS是SAS V9和以后版本表面封装的重点，语法变化和依附性变化都会很大，所以旧船票是否能登上明天的客船还是一个谜… …

! P+ c- O- S8 T5 ~& A$ Z: r外地语言 Connect / Share和外语Access
6 l. U& p- A- R' m# j$ Q. J0 EConnect和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等过程来处理灵活复杂的要求。
5 }( Y# Z6 O2 F5 X6 Q) j
/ Y+ I5 G1 W, M: ^' `6 p* K  D% b其它边远地区的方言
4 N' o9 h2 S# P  L) n: t还有很多模块可以通过Proc Step扩展或SAS函数的形式拓展SAS语系的范围。这里不再赘述。
0 ?$ Y8 L1 l) \8 S1 ?( @" `1 ^9 k

深V礼

干的漂亮，发帖多多，收获多多

深V礼

干的漂亮，发帖多多，收获多多