好久不上论坛，很幸运能看到许多面对问题的解决办法，确实带来了很多启发。
事实上此类问题应该有高级应用来解决。比较同意soporaeternus的说法，一门工具有其长处。不可能也不会在全部领域都能cover。

说说自己的想法：
首先如果只讨论在有限的单节点环境上如何利用资源管理优化其实是不合适的。因为资源有限，无论是内存还是CPU和IO，都往往顶不住压力，假设即使在具有完美资源管理的条件下，如果处理海量数据的时间，能足够进行一次环球旅游，那么即使实现也是无意义的。

其次，面对海量数据的处理这样时下的热门话题，其实有心可以了解一下，目前有很多面向这类数据处理的方法在快速发展，NOSQL，DFS， 共同的都是以并行计算模型和集中式高级计算为基础。而这又牵涉到很多问题，节点度，数据分配，文件索引等等等等，甚至有些像TD需要从硬件角度来解决。而这几年数据量在增大，数据种类也在增多，更多的非结构化数据和半结构化数据的出现，处理数据也不像几年前用关系型的载体或者使用商业版本的工具这么简单了。所以面对这些大多不是SAS能cover或者擅长的领域，仍然是无法讨论的。

再次，从应用角度上而言，SAS是门工具，所有的功能都是开放给user的接口，所以它不是底层。因此我们无法保证所有处理模块上都能成功运行。或许某处有个内存泄露的bug我们也不知，而SAS有又没有处理bug的接口，因此很有可能只能眼巴巴看着memory往上跳。而诸如内存管理或者系统资源管理的问题，合理是从底层来解决，但这不是SAS user的问题，而是develop SAS的disgner/programmer的问题。如果有些user有能耐处理诸如控制释放内存这类资源问题的话，其实一开始也不会选择用SAS来处理，能有足够的能力用高级语言开发个临时脚本模块就完事了。

因此虽然SAS或许还能在某些应用场合上勉强应对海量数据，但未来趋势却并不乐观。

关于大数据，也给些建议，如果是使用TB级别，有条件的话，推荐使用高性能企业级数据库（例如TD，Oracle，DB2，而MySql和PrepgSQL也可以先建集群）LOAD后再在DB中做处理比较合适，SAS/ACCESS 调用ODBC到DB或者直接连接DB，当然也可以试试High Performance，但Access最好使用explicit的方式，尽量不要libname，因为只有在explicit的方式下，才是通过SAS向DB提交语句，让所有计算压力承担在DB上，影响因素只是内网IO，而用libname则是会做parsing statement的，可能会有些计算需要等DB返还再处理，这就又回到考虑本机计算能力了。
如果超过TB级别的，至少对于分析型的应用目前还没有很好的解决方案，只能静候佳音。

最后就如sop所说，SAS是个工具但不是唯一的工具，对于数据处理而言，技术多样性是必要的，而面对各类复杂应用，了解每个方法的特点扬长避短以达到最优的能力同样也是不可忽视的。

很强大啊....不错！

没有机会碰到如此海量数据啊

天方夜谭

学习了！

想要分类海量数据集，有的话麻烦分享一下，谢谢 23578650@qq.com,最好给个链接邮箱肯定接不了大数据。

受教了

交流一下，你说SAS Access到数据库时最好使用explicit的方式，但是如果使用SAS/Access for Oracle模块直接libaname呢？不知道你有没有比较过差异。

另外，个人感觉SAS在处理处理方面有一定优势，因为不需要像数据库有复杂的事务一致性，没有那么多undo日志冗余信息，但是在SAS上处理大数据量可以尝试对数据进行压缩（CPU足够的前提）降低IO。

学习了，处理TB级的数据真得考虑这些！

MARK一下，即将要碰到大数据量的分析

学习了！！！