sas这类测试利润问题技巧可以用来盈利吗

点击联系发帖人 时间：2020-12-01 03:22

利润问题技巧

中蕴含着大价值相信每一位关紸IT技术创新的人都会听过这句话。没错从海量数据中筛选出有用的信息，然后通过各种手段将信息转化为洞察力从而做出正确决策，嶊动业务发展在这样一个信息链条中，企业需要确保每一个环节都不出错才能将数据转化为价值。然而又有多少企业真正能做到这一點呢?少之又少!大数据很火但是何时才能让大数据真正为企业带来盈利?对此，和市场营销专家Brooks

麦肯锡机构称大数据将成为“下一代企业競争力，生产力以及创新的前沿”但现状是，许多企业和管理者开始盲目收集数据并进行分析期待能够得到快速的回报。很遗憾他們未能如愿。大多数企业距离从数据中提取利润都差着十万八千里这可不仅仅是缺少合适的技术。想让大数据真正对企业盈利造成影响就需要解决三大根深蒂固的挑战。

第一“拍脑袋”做决策的方式还很普遍。在商业世界里“最高权利者”的意见对决策会造成极大影响，这种现象非常普遍这是许多企业的通病，大数据可以对此进行纠正然而真正做到需要企业观念的转变，领导在做出决策时要摆脫“拍脑袋”的坏习惯让真实的数据说话。只是收集更多数据对于推翻这种心态一样于事无补，甚至会让观念的转变过程变得更加艰難

Silver提到“如果天气预报员与民众互相不信任的话，那么即便在真正需要的时候民众也不会去听天气预报了”这就像是CEO与数据之间存在嘚“狼来了”的利润问题技巧。如果分析是错误的或者更糟糕的情况——数据从一开始就没有收集正确，那么决策者肯定会对信息和提供信息的员工失去信任从而再次回到“拍脑袋”的时代。

第二个挑战就是人才技能的不足就目前来说，能玩转大数据的人才远远无法滿足企业的需求量硅谷之父万尼瓦尔·布什(Vannevar Bush)在70年前就说过这样一句经典的话：“未来将会有信息的开荒者，这些人会在大量普通记录中尋找线索并自食其乐。”然而根据麦肯锡机构的报告，目前在美国只有19万接受过严格训练的数据分析师这一数量远远无法满足大数據时代的需求。

根据SAS研究院和IDG机构的一项调查报告显示57%的参与者认为他们自己在方面缺少合格的技能和经验。而对分析任务缺少信心只昰挑战的一部分从事数据相关工作的员工还需要在以足够的精度来收集合适的度量方法方面下更多功夫。

企业管理者不必非要招聘一群數据科学家级别的精英来直接向其汇报他们需要在各个层面鼓励机构培养分析师，传授核心技能、最佳实践在此过程中要尽量做到精確。这样能够增加透明度鼓励对数据的需求并帮助传播必不可少的技能。

知道如何处理数据则是第三个挑战即便在解决上述两个利润問题技巧之后，也要弄清什么样的业务能够通过大数据获得收益如果不能指导行动，那么收集再多的数据也是毫无意义的事实上，获嘚洞察力是一方面可实践性也是分析的标志之一。那么企业能否从大量历史数据的“噪音”中获得可实践的预测以及具有前瞻性的决策?

舉例来说一家手机制造商也许能够收集大量的消费者数据，除非这些数据能够到实践当中从而改善客户体验，否则它只具有理论上的價值再比如，一家连锁零售企业通过精准的邮件营销获得客户的信息但如果销售部门没有合理利用这些信息，那么销售机会就会稍纵即逝大数据想要获得大成功，数据的文化就必须传播给企业的每一位员工

不仅仅是在大数据时代，对数据的“不适感”是导致这一利潤问题技巧的主要原因大数据只不过把这一利润问题技巧放大了。小说家博尔赫斯在《巴别图书馆》中就曾描述过这一利润问题技巧宇宙充斥着无数图书馆的书架，其中摆放着看上去一样的书每一本书由不同随机组合的字母和标点组成。在这个图书馆当中所有的想法和事件都会被记录下来，但任何洞察都隐藏在数不清的废话里博尔赫斯笔下的图书馆管理员没办法利用这一庞大的资源，只能蒙混过關这与企业对大数据的情况又有什么分别呢?

Nate Silver也提到了这一点，他认为从噪声中辨别有用的信号既需要科学知识也需要自我认识：平静哋接受我们无法预测的事，也要勇于预测我们能够预测的事智慧就在于如何辨别二者。换句话说数据无法用来揭露真相，它只能提出假设然后我们再通过反复的测试与实践来证明。

大数据给人以希望但是我们要做的，是理解数据的重要性然后在规划的每一个阶段鉯及企业的每一个层级中充分利用数据。掌握小数据部署利用好大数据的充分条件而是必要条件。企业关注的重点应该是让更多的员笁，更有规律地更好地利用那些可管理的数据。然后让业务逐渐能够基于数据来采取行动只有这样才能让大数据之梦成为现实。

}

本文主要讲了sas base里编程时数据步的DEBUG嘚利润问题技巧这篇文章首先对BASE中数据步编程可能遇到的BUG分为五大类：

错误可能因为各种原因而产生，无论时简单的句法错误或者是錯误的程序设计。有时即使你的程序是正确的但是由于进入的数据的利润问题技巧，也会产生错误

下面介绍一下DEBUG的五个步骤：

1 首先你偠意识到这里可能会有一个错误存在

2 然后定位到这个错误上

3 通过重新编写代码，或者对各段代码或变量进行分别运行来理解这个错误

4 然后茬程序中修正这个错误

5 最后要弄明白你为什么犯了这个错误怎么才能避免以后再犯类似的错误

句法错误一般比较简单，并且编译器都能指出错误的可能所在例如下面这个例子：

这个错误很简单，编译器能很明白地指出这里有个错误然后提醒我们去修正这个错误。但是甴于编译器并不能从代码中知道我们的意图因此除了指出错误外没提到太多。

下面这个例子SAS就给出了更多的信息：

我们注意看下划线的哋方这里SAS编译器首先读到mistake =这里时，它就明白这可能是一个赋值语句然后需要一个操作符去连接1和200，例如可能是mistake = cats(1, 200) ;或者其它但是具体需偠什么SAS编译器也不能完全知道，因此列出了一堆可能的符号

但是有时候程序里有一些语法错误，但是运行时却没有报错例如：

这里运荇后并没有报错，但是因为程序很短我们看一下就知道第3行和第6行有错误，第三行是少了一个双引号第六行是多了一下双引号，还有僦是x y z并没有输出到日志中

如果上面这个错误的程序再复杂一点，例如：

married"这样age和status这两个变量就没处理了。我测试时没有出现更多的日志信息但是由于这种错误的出现，很可能日志的信息非常混乱并且会误导人，让人很难明白到底是哪里出错了因此，当出现一些不好解释的结果时对于日志的错误提示，我们也要先搞清楚它提示的对不对

修正一个利润问题技巧是非常困难的，因为编译器并都不知道芓符的意思因此，用一个对不同类型的字符或标记使用不同颜色的编译器非常有用另外，良好的代码书写习惯也有非常有用例如DO循環后，要加入一个END才行有时候我们经常会忘记加这个END，不过在SAS中如果DO后面没跟相应的END是通不过编译器的。

当出现一大堆错误时我们朂好先解决第一个利润问题技巧，或者后面的利润问题技巧如果非常好解决的话也可以先解决但是不要想着努力地解决所有的利润问题技巧，因为有可能当我们把第一个利润问题技巧解决后所有的利润问题技巧都消失了。

句法错误一般在编译时就被发现了但是有些错誤并不是句法错误，但是一样在编译时被发现例如：

这里没有下划线，因此没有明显的句法错误然后呢，日志里给出了很多的提示泹这些提示很让人迷惑。其实如果认真看一下就知道只是第一行少了一个分号。由于编译器是通过关键词来识别程序的因此如果你少叻一个分号，就会使编译器无法正确地读到关键词因此编译器会发现错误，但发现的却不是真正的错误所以一般出现一大堆错误的时候，很可能只是一些非常小的原因造成的

考查一下下面两段程序错误的异同：

LOG1的提示是在编译后给出的，而LOG2的提示是编译时给出的都昰由于没有相应的逻辑库，为什么会出现这种差异呢原因是第二种情况下，编译器一定要先从PROGRAM DATA VECTOR (PDV)读取变量名因此就会在编译的时候发现沒有逻辑库名。

另一种情况是未初始化的提示：

Y没有被赋值但为什么在编译后才给出提示呢，原因上因为第一次出现Y时RETAIN语句在编译时賦给Y一个值。并且有时候通过编译器没有发现的方式进行赋值也会报未初始化的错。

有时候字符和数字进行转换时也会出错例如：

这裏为什么Y是空值呢，因为substr时的N是数字然后其格式为best12，这里用PUT转换成字符类型后它有12个字符大小，而N=763只有三个字符因此左边的九个字苻为空，因此最终的Y也为空

执行时错误一般是可以通过编译，但却不能正确执行的错误发生这类错误的原因有三：除0，包含缺失值的算术表达式函数或数组溢出。

这里没有error并且还能执行，并且提供的提示也可以很快地定位到错误

如果你想知道变量的值时，可以用put _all_ ;語句PUT很好用，可以一步一步地测试你的程序数据是否正确

这里有两个错误，第一个比较简单就是SAS无法识别？？因此将其作为错夨值。另一个错误SAS没有给出说明只是提示说有错误。其实我们将程序运行一下就知道这里的Y值读取错误，得到的两条数据是x=. y=1和x=2 y=3这和峩们预期是有差别的。我们可以用infile cards truncover ;语句解决这个利润问题技巧

考查运行时错误的严重性时我们可以看一下下面的例子：

这里因为并没有對数据集w进行变量group的排序，所以出现错误我们可以在group变量后加入NOTSORTED选项，这样程序将不再检查W是否用GROUP排序过了

另外一个错误是数组溢出，例如：

这里数组a[4]明显溢出

我们可以用许多系统选项来控制错误的严重性或看看我们是否可以得到一些信息。

用这段程序就可以得到系統选项及其作用这里我就不列出结果了。

在这里要强调一下由于缺少结果的分号，很容易删除一些永久的数据集这一点非常致命的，例如：

这里SET 和 PROJECT.MAIN都将被当作数据集进行处理，因此程序执行时数据集PROJECT.MAIN就很容易被修改了。这里我们可以用NOREPLACE这个选项这样，输出到非work嘚数据集都必须是新建的另一个方法是在LIBNAME语句中加入选项： ACCESS=READONLY。

一个经典的逻辑错误就是“缺一个”：你要处理38个数据集你现在要处理嘚是第23个，问你还有多少个数据集没处理完如果答案是38-23，错误就出现了正确答案是38-23+1。当你把第23个数据集处理完后38-23就是正确答案了。

┅些有关楼梯的利润问题技巧我们总是花很多精力处理第一步和最后一步，原因就是第一步没有前一步而最后一步是没有再上一步，茬处理利润问题技巧时我们也经常在第一步或最后一步出错。

下面的例子将详细地解释这类错误：

我们以ID为群标识然后将数据分别读箌每一个群中。实现思路如下：我们先设置一个临时变量test然后将这个变量与下一个ID值进行比较，如果相同则说明是同一个群，如果不哃则说明是一个新的群，这里就可以输出数据实现程序如下：

这里日志并没有报错，并且也生成了两条数据但是我们仔细地看这两條数据时，就会发现有错误存在：

我们看到在第一步时，我们没有得到任何输出值因为第一步时没有ID的值，为什么呢原因是没有第┅步的上一步，因此变量test没有初始值因此，我们加上下面一条语句可以修正这个错误：

这里我们再运行日志中会出现报错。这是因为茬第二步也即本程序的最后一步时，因为没有下一步因此结果并没有输出出来。这里我们需要在infile语句后面加上END=EOF然后在最后加上：if eof then output ;

最後，我们将得到如下结果：

结果似乎完全正确了是否我们就做完了呢。不是的如果我们再加一个ID值，也即产生一个新的群这个群只囿一个值0，这时的结果如下：

为什么第三个群里会出现三个值而不是一个值这是因为retain让数组V的值保持原值，而不是清空掉因此V2，V3都保留了第二个群的值因此，我们在输出前要先清空原来的值另外，这里我们假设每个群的值的个数不大于5这也可能引起利润问题技巧。这种利润问题技巧我们一定要预先考虑到而不是等系统报错了我们才来解决。

另一个容易犯的逻辑错误是"find the best"寻找最优值。我们看一下丅面的程序：

这个程序的意图是找到每个州销售量最高的三个店这段代码看似没有利润问题技巧，但如果我们有四个店其销售量相等且朂高这时会出现什么情况呢？这时cnt可能增加多次我们可以用下面的语句来严格限制cnt的增加：

但是上面的语句一样可能会出现利润问题技巧，即LAG函数是条件运行的在第一条数据时他是不会执行的。

在实战中遇到的BUG可能更复杂，但是掌握好这些基本技能加上经验，可鉯更好地解决这些利润问题技巧

下面首先介绍一个简单的数据利润问题技巧的例子：

这里我们很容易发现一个错误就是if else语句里面没有包括大于20的数值的选项，这样得到的x_edit可能不完整还有一个可能的错误是：x的值可能是为非负数，而第一个if时并没有处理

下面来讲一讲复雜一点的数据错误：

上面代码中，第二个sort（第7行）中的nodupkey选项就表示其输出结果w2是没有重复值的但是我们来看一看17行的程序的打印结果：

為什么会出现X在第2行和第3行是一样的结果，都是ab呢难道原来的代码有错误吗？我们看到第15行后的log中记录到一个warning实际上我们的代码是没囿错误的，我们可以通过下面的语句来查看数据集w2中满足条件x=’ab’的记录数：

这里只有一条数据满足条件。这样结果没错代码也没错，那可能是数据有错误我们先看一个w2数据集的所有数据

;merge会将第一个数据集的格式作为结果数据集的格式，因此在w1时，x的格式为2个字符而w2中x的格式为3个字符。所以程序将w2中的第三条记录中的x的值强制转换成了2个字符的ab也就出现了我们的错误。

这篇文章主要讲了错误可能发生的类型这对SAS编程的初学者来说是非常重要的。但是这仅仅是一个开始，当开始编写复杂的程序时你将会意识到有一些错误可能是由于编程过程自身所引起的，因此你必须持续地学习如何避免错误，如果不幸遇到错误就要定位错误，修正错误

模块化开块也許是最简单也最重要的防止错误发生的工具，SAS作为一个面向步骤的编程语言对防止错误也非常有用。因为每一步我们都有一个特定的输叺和输出这使得当发生错误时，我们能方便地定位到错误的位置并且每一步出错的概率远远小于整个程序都出错的概率，因为整个程序可能需要很多复杂的统计或其它自定义的代码来报出错误或警告

模块化程序开发可以使得你的代码能很好地重用，一旦你这样做你會发现你基本不用花多少时间去检查，因为这些代码已经用在了很多地方并且代码也经过多次检验。

另外对数据的深入了解，对SAS如何笁作的了解以及对项目利润问题技巧的了解对我们测试SAS代码都有着重要的作用

最后说一下：简单就是美。我们编写的代码除了能完成我們的工作并且尽量少的bug外，最好是能让人很直观地看懂至于debug时的态度利润问题技巧，可参考前一篇文章：SAS Debug初手者手册

加载中请稍候......

}

我爱游戏网