Me refiero a estar codegueando durante gran parte del día. Supongo que los Data estaran haciendo otras cosas como implementando graficos, haciendo algun modelo y analizando los datos pero para ello utilizando código (Python o R).
¿Un programador podría dedicarse al mundo de Big Data?
¿Puede tener ventaja respecto a gente con Mates o Economía peladas?
#2 Trabajas en el sector?
Estas programando gran parte del día en Python o en R? O tienes otras labores fuera de codeguear?
#4 del arte o del erte? No te han dado la prestación aún?
Bromas aparte.
Que es 'analizando los datos'? Pensar?
El 80% de la ciencia de datos es analizar los propios datos, el otro 20 es llorar porque tienes unos datos de mierda
#1 Me dedico a ello.
La respuesta real depende mucho del sector.
No es lo mismo ser Data Scientist en Banca, Finanzas o Gaming (Mobile, MMO, MOBA, o Gambling), que ser consultor en Data Science, trabajando sobre proyecto firmado.
En las primeras, eres más una piedra angular, un punto de conocimiento, o una transformación de datos en información accionable.
En las segundas, eres un programador especializado en Estadistica y Matematicas, que necesita dar una evaluacion objetiva a una solicitud de un cliente.
En ambos casos vas a usar SQL, R, Python. En casos puntuales dependiendo del sector, NoSQL (Cassandra, Neo4j, Mongo), y Google Spreadsheets, Qlikview, Chartio, Tableau, PowerBI, etc...
Ya para cerrar:
¿Un programador podría dedicarse al mundo de Big Data?
Si, y un estadístico, y alguien que viene de filología de lengua sueca. Todo depende de la capacidad de aprendizaje y capacidad analitica. Y ya, si me apuras, la capacidad de comunicar los resultados.
¿Puede tener ventaja respecto a gente con Mates o Economía peladas?
Si te refieres un programador puro con los conocimientos de estadística básicos vs un Matemático / Estadístico puro. La respuesta es si.
Porque lo que tu sabrías programar con un código bonito, pero básico en su función, ellos te harán un código poco optimo y chapucero, pero contesta con muchísima mejor precisión el problema.
Si ya saltamos en un programador experimentado, y un matemático/estadístico que sepa programar decentemente, estos segundos superan de calle al programador.
EDIT: Corroboro lo de #4 . No, no estás todo el dia programando R/Python/SQL.
Es más, al menos en mi caso, de las 8h al día, quizá programar programar, 1h-3h depende del día. El resto, analizar dashboards, setear AB Tests, evaluar resultados, assessment de riesgos, asistir a mil reuniones, y cuando decimos que no se debe hacer release de algo que da dinero pero no es significativo, poder explicar el porque xD
#6 Por mi experiencia de +8 años en big data, en diferentes ámbitos (sector público, automoción, IoT, ...) tus porcentajes estan al revés.
Al respecto a lo q necesitas saber, en muy pocos sitios te mueves con conocimientos avanzados de estadística. Pierdes mucho más tiempo haciendo q la puta herramienta, lenguaje de moda, etc ... reconozca adecuadamente el formato de los datos de mierda con los q estás trabajando.
Si no estas en un área de BI puro, vas a programar para normalizar el dato, programar para integrar el dato, y programar para mostrar el dato en de uno a n dashboards. Normalmente los conocimientos de estadística/matemáticas van más en el último paso, y como ya digo, normalmente no es algo muy avanzado, cualquiera puede hacerlo.
Obviamente siempre.tw vas a encontrar el caso q maneja estadísticas complejas, pero no es habitual.
#10 Discrepo.
Eso que has descrito, es la realidad en las empresas que no están, o están empezando a trabajar con una cultura orientada a datos. Empresas maduras a nivel de datos, el Data Scientist no hace NADA de lo que has citado. Quizá, si me apuras, programar un poquito de código R/Python (con el que se mueva mejor, yo me decanto por R).
#10D10X:Si no estas en un área de BI puro, vas a programar para normalizar el dato, programar para integrar el dato, y programar para mostrar el dato en de uno a n dashboards. Normalmente los conocimientos de estadística/matemáticas van más en el último paso, y como ya digo, normalmente no es algo muy avanzado, cualquiera puede hacerlo.
En la empresa en la que trabajo, hay un equipo especifico para la extracción de datos, ya sean datos in-house (tracks, push de nuestro back end, apis externas, apis internas, etc), los transforma con etl's dependiendo del source, y nos los deja bien frescos en la BBDD. Hablo del manejo de cerca de 20-30GB de datos nuevos procesados en las BBDD al dia aproximadamente, con tablas de más de 1 billón (americano) de rows. (Sí, hacer un select * from table, literalmente, si no le pones un timeout, o matas la máquina, o matas la ram de tu ordenador)
En el equipo de Data Science, leemos esos datos para hacer los análisis, modelos de predicción, análisis de series temporales, clasificadores, etc...
Si es una empresa digitalizada, como las que he citado antes, Finanzas, Seguros, Banca, Gaming, donde las decisiones se basan en los datos que se generan y procesan, el Data Scientist programa lo justo y necesario. Se le paga por el valor de su trabajo y lo que aporta, no por el picar mas o menos código.
Ahora bien, si me dices que es una empresa de 20-30 trabajadores, la cosa cambia, porque el "Data Scientist", directamente es un One-Man-Army.
Yo te hablo de empresas de 300+ trabajadores, con un equipo/departamento de Datos/Analytics de 30 personas o más.
#5Yonki_Kong:Que es 'analizando los datos'? Pensar?
Te daré un ejemplo de un dia cualquiera de un Data Scientist/Analyst (aunque este ejemplo, es mas para analyst que scientist, pero en el fondo, uno es el paso previo al otro)
Pongamos que hipotéticamente eres un Data Analyst/Scientist en tu puesto de trabajo, y se te acerca tu manager, product manager, VP of Marketing, o quien sea. Y te dice "Los datos de ingresos de este mes, son más bajos. Que ha pasado?"
Puedes hacer tres cosas:
Opción 1
"Pues que han bajado" -> Easy, te despide xD
Opción 2
Miras los dashboard, miras los datos del mes y ves claramente que hay una tendencia que baja" -> Comentas que ha habido una tendencia a la baja. Obviamente él lo sabe, y con cara de asombro te dirá que lo sabe, y que mires porque.
Opción 3
Ves esos datos, y antes de decirle nada, miras la fuente de los datos (da igual si la has hecho tu u otra persona). Lo primero que miras, es que el proceso (en este caso una query SQL, por ejemplo) funciona correctamente, para asegurarnos que no hay errores. Obviamente, si no hay errores y baja, harás una exploración de datos pasados, compararas periodos temporales, para saber si hay estacionalidad o no. Si la hay, puede ser un factor, pero no puedes quedarte en eso, porque del mismo modo que dices que lo es, yo te digo que no. Y no tienes mas argumentos que defiendan tu postura. Por lo que lo que harás ahora, será mirar que cambios se han hecho en tu producto (aplicación, inversión de marketing, etc...). Si hay errores de versión, en el caso de una app, errores de login, en el caso de un juego, caídas de retención. Errores en la pasarela de compras... etc...
En el fondo, lo que harás será investigar, y buscar métricas que puestas en conjunto todas ellas, te expliquen lo que ha pasado. Sin embargo, si tu solo presentas eso, haces un report. No haces un análisis. Un análisis, requiere de un pensamiento critico, hypothesis testing, o lo que viene siendo el plantear una serie de hipótesis y validarlas o refutarlas. Cuando mediante esto, has conseguido entender lo que ha pasado realmente, tu tienes los datos. Y las queries. Pero tienes que transformar el análisis técnico, datos, en información accionable, de tal manera que alguien que NO sepa NADA de código, estadística o matemáticas, entienda a la perfección que ha pasado, y mediante las recomendaciones que le has dado, tome una decisión. Una presentación, suele ser lo ideal. Y allí prepárate, porque como decía Hexan antes, te preguntaran cosas que ellos consideran magia, cajas negras, cuando en el fondo, es un trabajo mental y asociativo en base a datos objetivos.
Con esto, te puedes hacer una ligera idea de que es un "análisis". Y como puedes ver, es algo más que simplemente "Pensar" haha
Sobre los tiempos de un análisis o un problema, generalmente (para un buen análisis)
Parte 1 - Definir problema, objetivos, que se pretende contestar o conseguir, y qué hipótesis planteas para llegar a eso. 15%
Parte 2 - Programar para conseguir los datos . 25%
Parte 3 - Analizar los datos obtenidos y validar/refutar hipótesis. 25%
Parte 4 - Estructurar la información accionable, conclusiones, recomendaciones, y next-steps de modo que hasta un niño de 10 años lo comprenda 35%
1, 2 y 3 son iterativos, ya que conforme avanzas, vas descubriendo cosas que amplían o reducen el "scope" del problema, o lo complican, y tienes que tomar decisiones de si quieres acotar el problema, o bien su totalidad (incrementando el tiempo que te llevara hacerlo, y por lo general, los costes)
Welcome to the red pill of the Data Science (embedded en empresa, la versión de consultoría ni idea).
PS. No he detallado nada puramente de la rama pura de DS (machine learning, modelado, clustering, predicción, etc...) ya que da para tochos aun mas grandes xD
Sorry por el tochopost
#11 Ya se que no siempre es asi, por ese le puse que si no tienen un area de BI puro, va a ser el chico para todo. De los sitios en los que he estado, ha primado mas lo segundo que lo primero, ya sea empresas grandes o pequeñas.
Q es cierto que desde que empece con esto, la cosa ha mejorado mucho, la figura del Data Scientist ni siquiera se buscaba al principio, y ahora esta muy extendido. Pero sigo pensando que, en general, el sector es aun muy poco maduro en España y es mas facil caer en un sitio donde tienes que buscarte las vueltas a simplemente hacer trabajo de DS. O al menos, es mi percepcion actual, que puede ser que simplemente aun no me tocase el proyecto de Data Scientist bueno, no es mi rama principal y a pesar de haber trabajado en eso, no es a lo q me dedico.
Lo bonico que sería poder decir una frase estadísticamente correcta y coherente y que todo el mundo te entendiera....
Lo jodido es que después de una frase rollo: - No podemos decir que esto no sea así porque blablabla -
Siempre saltan: - Entonces si no podemos decir que no.. significa que podemos afirmar decir que ... -
y tu: - no, eso no lo puedes afirmar y eso no es lo que he dicho. No puedes hacer tal afirmación con estos datos -
Respuesta: 
Se montan unos bucles muy divertidos.
Parte de mi trabajo es analizar datos, que no big data, de ensayos de laboratorio y las risas en las reuniones a veces se oyen hasta dentro del laboratorio.
#13 Buah, es la risa cuando pasa eso xD
Lo mejor es cuando explicas los errores tipo uno y tipo dos xD
SIEMPRE, siempre, pongo en la seccion de las presentaciones un reminder con esta imagen
#11richmonde:de más de 1 billón (americano) de rows.
Lo que vienen siendo mil millones de filas. Qué manía con americanizar el lenguaje.
Depende, yo me dedico actualmente a esto y te explico.
Mi TFM que no tiene nada que ver con mi curro:
Python para extraer datos.
R para el machine learning.
Mi trabajo:
SQL a tope
Power BI - DAX a tope.
Una cosa es big data para extraer y analizar mediante IA, lo otro Business Intelligence, que es presentar los datos de una forma agradable e intuitiva para que se tomen mejor las decisiones.
O al menos, así lo veo yo.
Para el desempeño de lo primero hay que saber programar y una buena base matemática/física con su correspondiente lógica (Yo carezco de las 3).
Para el de lo segundo, basta con un par de cursos de Udemy. Aunque si vas a trabajar de esto te van a pedir una titulación del cristo de la repolla que nada tiene que ver, pero bueno.
#10D10X:En la empresa en la que trabajo, hay un equipo especifico para la extracción de datos, ya sean datos in-house (tracks, push de nuestro back end, apis externas, apis internas, etc), los transforma con etl's dependiendo del source, y nos los deja bien frescos en la BBDD
Venía a decir esto. Yo no me dedico a este sarao pero mi novia si y se dedica al tema ETL. Luego le pasa los datos a "los tíos del Excel" que les llama y esos ya hacen los análisis requeridos.
#20Infortunio:Y es divertido? Te llena?
Divertido el trabajo per se, no lo es más, o menos, que un Front-end, un backend, cliente, o sistemas. Se me da bien, y me gusta cuando las cosas salen como esperas (lo cual como digo antes, no siempre pasa). Si me dices que si es más divertido que ser profesor de dibujo, pues no lo se.
Llenarme? Soy una persona siempre muy analitica, fuera del trabajo también. Aunque como de dice más arriba, mi trabajo es mas saber recomendar bien, en base a los análisis, que no picar código. Ayudar a otras personas, para llegar a un bien común mayor, satisface bastante. Y ahora que tengo a 3 personas a cargo, si consigo que esas personas crezcan como lo he hecho yo y lleguen a ser iguales o incluso mejores que yo, me gustará, la verdad.
#22 A ver si he leído bien. Lo que es el trabajo puro y duro, es un coñazo en si. Luego tiene otras recompensas no inherentes a ese puesto de trabajo, como poder formar a la gente o estar orgulloso del trabajo bien hecho, la satisfacción del cliente, también extrapolable a otros trabajos.
No estoy menospreciando nada, solo intento comprender la naturaleza del mismo ya que soy un profano. Por ejemplo, a mi me mataría trabajar en una fábrica realizando tareas rutinarias igual que me mataría hacerlo en una oficina revisando albaranes una y otra vez. Igual que estar delante del ordenador "mirando datos". Por eso mi pregunta. ¿Hay sitio para la creatividad en estos trabajos? ¿Hay retos a tu inteligencia, tareas nuevas que tengas que enfrentar y que le den un poco de chispa al trabajo o al final son rutinas que se siguen para verificar, analizar y entender esos datos?
#23Infortunio:¿Hay sitio para la creatividad en estos trabajos?
Si. El como quieras solucionar el problema y presentar resultados, generalmente sueles tener carta blanca.
#23Infortunio:¿Hay retos a tu inteligencia, tareas nuevas que tengas que enfrentar y que le den un poco de chispa al trabajo o al final son rutinas que se siguen para verificar, analizar y entender esos datos?
Siempre. Ningún análisis, ni problema, tiene la misma solución.
En resumen. Ellos te preguntan por un problema, situación, o expectativa. El como llegues y lo comuniques, tienes libertad. (O al menos, en mi experiencia actual. Nadie me ha dicho tienes que hacerlo así y darmelo asa)
#6 Yo incluso le daría la vuelta a esos porcentajes, la higiene de datos de las empresas es de cachondeo.
