Estoy ayudando a unos colegas a migrar de SAS a R. Están lejos, en un país de vino y carne al que alguna vez he de ir. Hemos quedado en que si alguna vez borran el último de sus SAS del disco duro, los ayudo gratis. Si no, cuando vaya, me tendrán que pagar hasta el último peso en lifaras y libaciones.
Tienen procesos que ejecutaban en SAS. Algunos los iban reescribiendo en R. Se sienten más cómodos en SAS pero cuando éste se queda corto, recurren a R. Es una aproximación «todo o nada».
Existe una estrategia más eficiente y más, término de moda, vírica. Porque es posible correr R y SAS conjuntamente en un mismo proceso. El objetivo es muy evidente: ir sustituyendo progresivamente código SAS por código de R hasta que no quede nada del primero.
Hay manuales de migración de Windows a Linux y multitud de descripciones de casos de éxito. A ver cuándo podemos crear una guía similar (junto con multitud de casos de éxito) de migraciones a entornos de trabajo analíticos libres y verdaderamente productivas.
Tiempo al tiempo, todo llegará, estoy totalmente convencido.
5 años. Sucederá en 5 años. R es la estrella en el ámbito universitario y en el momento en que esos universitarios sean profesionales «impondrán» sus herramientas.
Yo de todos modos no soy tan drástico como Carlos. No quiero sacar a Jim de la lista Forbes de las 100 personas más ricas del mundo. Abogo por una solución en la que SAS y R convivan para que, al final, se imponga el sentido común y, en unos negocios se utilice R y en otros se utilice SAS.
El mayor óbice para que eso suceda es la gran cantidad de código propietario (en oposición a libre o de fuente abierto) que integra SAS. Los ingenieros de SAS han desarrollado y patentado multitud de métodos para cada procedimiento que permiten optimizar la ejecución de los programas y explotar gran variedad de sus facetas matemáticas. Bien es cierto que buena parte de estos algoritmos se encuentran documentados profusamente en los manuales de ayuda (en formato PDF) que se ofrecen en su web oficial.
Para sustituir completamente SAS por R, sería necesario reimplementar todo este código fuente sobre R y liberar su licencia para que pasara a ser GNU o similar.
En una organización concreta, todo dependerá de la complejidad de los procesos de datos que se realicen. Bien es cierto que R permite efectuar procesamientos bastante complejos y que añade nuevas funcionalidades que no existen en SAS.
Yo apuesto por el modelo mixto, me parece la misma discusión de Windows-Unix, PC o Mac, IE o Firefox… cada uno tiene su público. Además, creo que es precisamente en las aplicaciones más sencillas donde será más fácil abrir brecha, y no en las más sofisticadas. Creo que la principal ventaja de R de cara a su aplicación masiva en las grandes empresas no es que incorpore los últimos, mejores y más sofisticados algoritmos, si no su coste, que permitirá iniciar la andadura analítica a empresas medianas que no pueden actualmente planteárselo por costes. Y si no pensad en los modelos, y algoritmos que más utilizáis en la práctica y pensad en cuantos tienen menos de 10 años de historia. Por cierto, se que en general los que visitamos este blog lo utilizamos poco, pero me consta que en muchas aplicaciones lo que más se utiliza es MATLAB, y creo que es mucho más fácil que R se meriende a éste último ¿Qué opináis?
Lo has dicho Fernando, el modelo mixto es la solución, peeeeero a medio plazo. Precisamente es uno de los motores que impulsa esta web. Evidentemente la intención no es eliminar SAS de una organización para usar R. La intención es acercar R al ámbito empresarial (el manual de Rcommander va a ir encaminado esto). Y una vez usen R dentro de las grandes organizaciones podrán decidir que les interesa a largo plazo (ojo que en las universidades dejará de estudiarse SAS).
Por ejemplo el lugar en el que yo trabajo NUNCA se podrá emplear R para el «data management» (un poco de pedantería BI nunca viene mal). Pero no es necesario que se gaste miles de euros en un entorno SAS. Se puede funcionar con SAS, WPS y R. Optimizaría los costes y tendría la posibilidad de acceder a las posibilidades de R.
A propósito de algo que dices se me ocurre una pequeña encuesta (por curiosidad) sobre cuánta gente ha podido estudiar SAS en la universidad. Yo la verdad es que me considero un privilegiado por ello, me consta que en muchas universidades, incluso en estudios de estadística, no se dispone del software, evidentemente por temas de coste. Y me refiero a estudiarlo de verdad, no a que en un master te cuenten que existe y te pongan unas capturas de pantalla del EG…
Yo también creo que R no puede ser utilizado como una herramienta «pàra mover datos» de un sitio para otro (que es para lo que se utiliza hoy en día SAS en casi todas las empresas).
Para eso ya existen bases de datos, lenguajes como PL/SQL, el mismo SQL y otros. Incluso SAS base, claro. No es el mercado al que me refiero.
Tampoco el del BI más clásico: cubos, informes, etc. De Pentaho, Business Objects, Microstrategy, etc. para arriba hay un universo de soluciones abiertas, cerradas, mejores y peores. Incluso SAS, de nuevo.
Otra cosa distinta es SAS/STAT, SAS/EM, etc. Existe, bien es cierto, código «heredado» en ciertas organizaciones que impide ir y, de repente, migrar. Pero sí que se pueden ir reemplazando trozos progresivamente hasta que no quede nada del sistema original utilizando soluciones como la que proponía arriba.
De hecho, el motivo por el que publiqué esta entrada es que conozco una gente que está migrando a R desde SAS y éste documento les va a ayudar a dar el paso.
Dicho eso, si yo fuese una empresa o un organismo público, me cuidaría muy mucho de mantener mis datos en un formato propietario y que sólo se puede leer con un software de un vendedor dado.
Yo también creo que R no puede ser utilizado como una herramienta «pàra mover datos» de un sitio para otro (que es para lo que se utiliza hoy en día SAS en casi todas las empresas).
Para eso ya existen bases de datos, lenguajes como PL/SQL, el mismo SQL y otros. Incluso SAS base, claro. No es el mercado al que me refiero.
Tampoco el del BI más clásico: cubos, informes, etc. De Pentaho, Business Objects, Microstrategy, etc. para arriba hay un universo de soluciones abiertas, cerradas, mejores y peores. Incluso SAS, de nuevo.
Otra cosa distinta es SAS/STAT, SAS/EM, etc. Existe, bien es cierto, código «heredado» en ciertas organizaciones que impide ir y, de repente, migrar. Pero sí que se pueden ir reemplazando trozos progresivamente hasta que no quede nada del sistema original utilizando soluciones como la que proponía arriba.
De hecho, el motivo por el que publiqué esta entrada es que conozco una gente que está migrando a R desde SAS y éste documento les va a ayudar a dar el paso.
Dicho eso, si yo fuese una empresa o un organismo público, me cuidaría muy mucho de mantener mis datos en un formato propietario y que sólo se puede leer con un software de un vendedor dado.