Libraries
Deployment
Científicos de Datos Sin Conocimientos de Ingeniería de Datos Se Enfrentarán A La Cruda Realidad
OPINION.Probablemente haya leído algún artículo sobre la diferencia entre un científico de datos y un ingeniero de datos. Siempre he pensado que la distinción es clara. Los ingenieros de datos preparan los datos para su uso y luego los científicos de datos trabajan con esos datos.Sin embargo, mi opinión sobre esta distinción ha cambiado drásticamente después de empezar a trabajar como científico de datos.Photo by Ben White on UnsplashTodo en la ciencia de datos comienza con los datos. Tu modelo de aprendizaje automático es tan bueno como los datos que se introducen en él. Si entra basura, sale basura. Un científico de datos no puede hacer magia para crear un producto valioso sin los datos adecuados.Los datos adecuados no siempre están disponibles para los científicos de datos. En la mayoría de los casos, será responsabilidad del científico de datos convertir los datos en bruto a un formato adecuado.A menos que trabaje en una gran empresa tecnológica que tenga equipos separados de ingenieros de datos y científicos de datos, debe poseer la capacidad y las habilidades para manejar algunas tareas de ingeniería de datos. Estas tareas cubren una amplia gama de operaciones y me explayaré sobre ello en la parte restante del artículo.En cualquier caso, ¿cuál es la diferencia?Me gustaría exponer mi opinión sobre la relación entre el trabajo de un ingeniero de datos y un científico de datos.Un ingeniero de datos es un ingeniero de datos. Un científico de datos debería ser tanto un científico de datos como un ingeniero de datos.Puede parecer una afirmación discutible. Sin embargo, me gustaría destacar que mi opinión era diferente antes de empezar a trabajar como científico de datos. Solía pensar en los ingenieros de datos y en los científicos de datos como entidades separadas.Por ejemplo, los ingenieros de datos realizan un conjunto de operaciones conocido como ETL (extracción, transformación y carga). Abarca los procedimientos para recopilar datos de una o más fuentes, aplicar algunas transformaciones y luego cargarlos en una fuente diferente.Definitivamente, no me sorprendería que se esperara que un científico de datos realizara operaciones ETL. La ciencia de los datos sigue evolucionando y la mayoría de las empresas no tienen claramente separadas las funciones de ingeniero de datos y de científico de datos. Como resultado, un científico de datos debería ser capaz de realizar algunas tareas de ingeniería de datos.Si espera trabajar únicamente en la ejecución de algoritmos de aprendizaje automático con datos listos para su uso, se enfrentará a la cruda realidad poco después de empezar a trabajar como científico de datos.Es posible que tengas que escribir algunos procedimientos almacenados en SQL para preprocesar los datos del cliente. También es posible que recibas los datos del cliente de varias fuentes diferentes. Su trabajo consistirá en extraerlos y combinarlos. A continuación, tendrá que cargarlos en una única fuente. Para escribir procedimientos almacenados eficientes, se necesitan amplios conocimientos de SQL.La parte de transformación de los procedimientos ETL implica muchos pasos de limpieza y manipulación de datos. SQL puede no ser la mejor opción si se trabaja con datos a gran escala. La informática distribuida es una mejor alternativa en estos casos. Por lo tanto, un científico de datos también debería estar familiarizado con la computación distribuida.Su mejor amigo en la computación distribuida puede ser Spark. Es un motor de análisis utilizado para el procesamiento de datos a gran escala. Podemos distribuir tanto los datos como los cálculos en clústeres para conseguir un aumento sustancial del rendimiento.Si estás familiarizado con Python y SQL, no te será difícil acostumbrarte a Spark. Puedes utilizar las características de Spark con PySpark, que es una API de Python para Spark.Lea También: Una Guía Para Principiantes - Apache SparkCuando se trata de trabajar con clusters, el entorno óptimo es la nube. Hay varios proveedores de la nube, pero AWS, Azure y Google Cloud Platform (GCP) están a la cabeza.Aunque el código de PySpark es el mismo para todos los proveedores de la nube, la forma de configurar el entorno y crear clusters cambia entre ellos. Permiten crear clusters utilizando tanto scripts como la interfaz de usuario.La computación distribuida en clústeres es un mundo completamente diferente. No se parece en nada a hacer análisis en tu ordenador. Tiene una dinámica muy diferente. Evaluar el rendimiento del clúster y elegir el número óptimo de trabajadores para un clúster serán sus preocupaciones predominantes.Lea También: * El Data Scientist "Full Stack"* Todo Lo Que un Científico de Datos Debe Saber Sobre la Gestión de Datos (Pero Tiene Miedo de Preguntar)
Machine Learning
Libraries
Deployment
Flask
Creando Todo El Pipeline De Machine Learning Con PyCaret y Python
Este tutorial cubre todo el proceso de Machine Learning, desde la ingestión de datos, el preprocesamiento, el entrenamiento del modelo, el ajuste de hiperparámetros, la predicción y el almacenamiento del modelo para su uso posterior.Completaremos todos estos pasos en menos de 10 comandos de construcción natural y muy intuitivos de recordar, como por ejemplo:create_model(),
tune_model(),
compare_models()
plot_model()
evaluate_model()
predict_model()
Flask
Deployment
Libraries
Construye Un Dashboard De Datos En La Web En Sólo Minutos Con Python
Aumenta exponencialmente el poder y la accesibilidad convirtiendo tus visualizaciones de datos en un dashboard basado en la web con Plotly Dash."Frase de alguien" - Bejamin FranklinNo sé tú, pero yo a veces encuentro un poco intimidante tener que codificar algo. Esto es doblemente peor cuando estoy construyendo algo parecido al desarrollo web en lugar de hacer algún análisis de datos locales con visualización. Soy un programador de Python competente, pero no me llamaría a mí mismo un desarrollador web en absoluto, incluso después de haber más que chapoteado con Django y Flask.Puedes leer más artículos de Data Science en español aquí Aún así, convertir los datos de salida en una aplicación web conlleva algunas mejoras no triviales para tu proyecto.Es mucho más fácil incorporar una verdadera y poderosa interactividad en una aplicación web. También significa que puedes controlar exactamente cómo se presentan los datos, ya que la aplicación web puede convertirse en el informe de facto, así como en el punto de acceso a tus datos. Por último, y lo más importante, puedes escalar exponencialmente la accesibilidad a tus resultados; haciéndolos disponibles en cualquier lugar y en cualquier momento. Siempre hay un navegador web al alcance de la mano de un usuario.Build a web data dashboard — in just a few lines of Python codeAsí que, empecé a hacer esto con algunos de mis proyectos de ciencia de datos recientemente, con una velocidad y eficiencia sorprendentemente rápida. Convertí uno de mis resultados de este artículo en una aplicación web (que puedes encontrar aqui) en sólo un par de horas.My NBA analytics web app (link)Pensé que esto era bastante divertido, y quería compartir cómo esto se unió en sólo unas pocas líneas de código.Como siempre, incluyo todo lo que necesitas para replicar mis pasos (datos y código), y el artículo no es realmente sobre baloncesto. Así que no os preocupéis si no estáis familiarizados con él, y pongámonos en marcha.Antes de que empecemosDataIncluyo el código y los datos en mi repositorio GitLab aquí (directorio dash_simple_nba). Así que por favor, siéntete libre de jugar con él / mejorarlo.PaquetesAsumo que estás familiarizado con Python. Aunque seas relativamente nuevo, este tutorial no debería ser muy difícil.Necesitarás pandas, plotly y dash. Instala cada uno (en tu entorno virtual) con una simple instalación de pip [NOMBRE_PAQUETE].Anteriormente, en Python...Para este tutorial, simplemente voy a saltarme *la mayoría* de los pasos dados para crear la versión local de nuestra visualización. Si estáis interesados en lo que está pasando, echad un vistazo a este artículoTendremos una sesión de recapitulación, para que puedan ver lo que sucede entre el trazado del gráfico localmente con Plotly, y cómo portarlo a una aplicación web con Plotly Dash.Cargar datosHe preprocesado los datos y los he guardado como un archivo CSV. Es una colección de datos de los jugadores de la actual temporada de la NBA (a partir del 26/Feb/2020), que muestra:Qué parte de los tiros de su equipo están tomando, yCuán eficientes / eficaces son en hacerlo.Para esta parte, abra el local_plot.py de mi repositorio.Cargue los datos con:all_teams_df = pd.read_csv(‘srcdata/shot_dist_compiled_data_2019_20.csv’)Inspecciona los datos con all_teams_df.head(), y deberías ver:>>> all_teams_df.head()
player pl_acc pl_pps min_start min_mid min_end shots_count shots_made shots_freq shots_acc group
0 Jahlil Okafor 65.1 132.6 1 0.5 1 3 1 3.7 33.3 NOP
1 Jaxson Hayes 77.8 155.6 1 0.5 1 3 2 3.7 66.7 NOP
2 Nicolo Melli 36.4 88.6 1 0.5 1 1 1 1.2 100.0 NOP
3 Zion Williamson 54.3 111.4 1 0.5 1 2 1 2.5 50.0 NOP
4 Frank Jackson 44.7 105.3 1 0.5 1 0 0 0.0 0.0 NOPLos datos de cada jugador han sido compilados para cada minuto del juego (excluyendo las horas extras), siendo las estadísticas pl_acc y pl_pps la única excepción, ya que han sido compiladas por cuarto del juego (para cada período de 12 minutos).El marco de datos contiene todos los jugadores de la NBA, así que vamos a desglosarlo hasta un tamaño manejable, filtrando por equipo. Por ejemplo, los jugadores de los Pelícanos de Nueva Orleans pueden ser elegidos con:all_teams_df[all_teams_df.group == 'NOP']Entonces, nuestros datos pueden ser visualizados en Plotly, como sigue:import plotly.express as px
fig = px.scatter(all_teams_df[all_teams_df.group == 'NOP'], x='min_mid', y='player', size='shots_freq', color='pl_pps')
fig.show()Visualised player data for New Orlean PelicansA riesgo de hacer esto:How to Draw a Horse — Van Oktop (Tweet)Añadi algunos pequeños detalles a mi gráfico, para producir esta versión del mismo gráfico.Same chart, with a few ‘small details’ added (& different team).Este es el código que usé para hacerlo.Puedes leer más artículos de Data Science en español aquí Ahora, aunque es un montón de código de formato, pensé que era útil mostrarles cómo lo hice, porque vamos a reutilizar estas funciones en nuestra versión Dash del código.def clean_chart_format(fig):
import plotly.graph_objects as go
fig.update_layout(
paper_bgcolor="white",
plot_bgcolor="white",
annotations=[
go.layout.Annotation(
x=0.9,
y=1.02,
showarrow=False,
text="Twitter: @_jphwang",
xref="paper",
yref="paper",
textangle=0
),
],
font=dict(
family="Arial, Tahoma, Helvetica",
size=10,
color="#404040"
),
margin=dict(
t=20
)
)
fig.update_traces(marker=dict(line=dict(width=1, color='Navy')),
selector=dict(mode='markers'))
fig.update_coloraxes(
colorbar=dict(
thicknessmode="pixels", thickness=15,
outlinewidth=1,
outlinecolor='#909090',
lenmode="pixels", len=300,
yanchor="top",
y=1,
))
fig.update_yaxes(showgrid=True, gridwidth=1, tickson='boundaries', gridcolor='LightGray', fixedrange=True)
fig.update_xaxes(showgrid=True, gridwidth=1, gridcolor='LightGray', fixedrange=True)
return True
def make_shot_dist_chart(input_df, color_continuous_scale=None, size_col='shots_count', col_col='pl_acc', range_color=None):
max_bubble_size = 15
if color_continuous_scale is None:
color_continuous_scale = px.colors.diverging.RdYlBu_r
if range_color is None:
range_color = [min(input_df[col_col]), max(input_df[col_col])]
fig = px.scatter(
input_df, x='min_mid', y='player', size=size_col,
color=col_col,
color_continuous_scale=color_continuous_scale,
range_color=range_color,
range_x=[0, 49],
range_y=[-1, len(input_df.player.unique())],
hover_name='player', hover_data=['min_start', 'min_end', 'shots_count', 'shots_made', 'shots_freq', 'shots_acc', ],
render_mode='svg'
)
fig.update_coloraxes(colorbar=dict(title='Points per<BR>100 shots'))
fig.update_traces(marker=dict(sizeref=2. * 30 / (max_bubble_size ** 2)))
fig.update_yaxes(title="Player")
fig.update_xaxes(title='Minute', tickvals=list(range(0, 54, 6)))
return fig
fig = make_shot_dist_chart(
all_teams_df[all_teams_df.group == 'SAS'], col_col='pl_pps', range_color=[90, 120], size_col='shots_freq')
clean_chart_format(fig)
fig.update_layout(height=500, width=1250)
fig.show()Ahora, vayamos al evento principal: cómo crear una aplicación web a partir de estos graficos.En la World Wide WebPuedes leer más sobre Plotly Dash aquí, pero por ahora todo lo que necesitas saber es que es un paquete de software de código abierto desarrollado para abstraer las dificultades de poner tus visualizaciones en la web.Funciona con Flask under the hood, y puedes reutilizar felizmente la mayor parte del código que usaste para desarrollar los gráficos en plotly.py.Esta es la versión simple que he armado:import pandas as pd
import dash
import dash_core_components as dcc
import dash_html_components as html
from dash.dependencies import Input, Output
all_teams_df = pd.read_csv('srcdata/shot_dist_compiled_data_2019_20.csv')
app = dash.Dash(__name__)
server = app.server
team_names = all_teams_df.group.unique()
team_names.sort()
app.layout = html.Div([
html.Div([dcc.Dropdown(id='group-select', options=[{'label': i, 'value': i} for i in team_names],
value='TOR', style={'width': '140px'})]),
dcc.Graph('shot-dist-graph', config={'displayModeBar': False})])
@app.callback(
Output('shot-dist-graph', 'figure'),
[Input('group-select', 'value')]
)
def update_graph(grpname):
import plotly.express as px
return px.scatter(all_teams_df[all_teams_df.group == grpname], x='min_mid', y='player', size='shots_freq', color='pl_pps')
if __name__ == '__main__':
app.run_server(debug=False)¡Pruébalo! Debería abrir este grafico en tu navegador.Our first Dash app!¿Cuál es el tema de todo esto? Bueno, para empezar, es una aplicación web en vivo, en menos de 25 líneas de código. ¿Y notan el menú desplegable en la parte superior izquierda? Intenta cambiar los valores en él, y mira el gráfico cambiar *mágicamente*.Puedes leer más artículos de Data Science en español aquí Adelante, esperaré.¿De acuerdo? Hecho.Repasemos brevemente el código.En un nivel alto, lo que estoy haciendo aquí es:Iniciar una aplicación Dash;Obtener una lista de nombres de equipos disponibles, y proporcionarla a un menú desplegable (con DOM id group-select) con un valor por defecto o 'TOR';Instanciar un objeto Graph como el identificador shot-dist-graph dentro de Dash; yCrear una función de devolución de llamada en la que, si se modifica alguno de los valores, llamará a la función update_graph y pasará el objeto devuelto a la salida.Si echas un vistazo al código, muchas de las cosas que probablemente son triviales para los desarrolladores web pero molestas para mí se abstraen.dcc.Graph envuelve el objeto figurativo de plotly.py en mi aplicación web y los componentes HTML como divs pueden ser llamados y configurados convenientemente con los objetos html.Div.Lo más gratificante para mí, personalmente, es que los objetos de entrada y las llamadas de esas entradas están configuradas de forma declarativa, y puedo evitar tener que lidiar con cosas como formularios HTML o JavaScript.Y la aplicación resultante sigue funcionando maravillosamente. El gráfico se actualiza en el momento en que el menú desplegable se utiliza para seleccionar otro valor.Y hemos hecho todo eso en menos de 25 líneas de código.¿Por qué Dash?En este punto, podrías estarte preguntando - ¿por qué Dash? Podemos hacer todo esto con un framework de JS, y Flask, o cualquier otra de las innumerables combinaciones.Para alguien como yo, que prefiere la comodidad de Python que tratar nativamente con HTML y CSS, el uso de Dash abstrae muchas cosas que no agregan mucho valor al producto final.Tomemos, por ejemplo, una versión de esta aplicación que incluye más formato y notas para la audiencia:(Es simple_dash_w_format.py en el git repo)def clean_chart_format(fig):
fig.update_layout(
paper_bgcolor="white",
plot_bgcolor="white",
annotations=[
go.layout.Annotation(
x=0.9,
y=1.02,
showarrow=False,
text="Twitter: @_jphwang",
xref="paper",
yref="paper",
textangle=0
),
],
font=dict(
family="Arial, Tahoma, Helvetica",
size=10,
color="#404040"
),
margin=dict(
t=20
)
)
fig.update_traces(marker=dict(line=dict(width=1, color='Navy')),
selector=dict(mode='markers'))
fig.update_coloraxes(
colorbar=dict(
thicknessmode="pixels", thickness=15,
outlinewidth=1,
outlinecolor='#909090',
lenmode="pixels", len=300,
yanchor="top",
y=1,
))
fig.update_yaxes(showgrid=True, gridwidth=1, tickson='boundaries', gridcolor='LightGray', fixedrange=True)
fig.update_xaxes(showgrid=True, gridwidth=1, gridcolor='LightGray', fixedrange=True)
return True
def make_shot_dist_chart(input_df, color_continuous_scale=None, size_col='shots_count', col_col='pl_acc', range_color=None):
max_bubble_size = 15
if color_continuous_scale is None:
color_continuous_scale = px.colors.diverging.RdYlBu_r
if range_color is None:
range_color = [min(input_df[col_col]), max(input_df[col_col])]
fig = px.scatter(
input_df, x='min_mid', y='player', size=size_col,
color=col_col,
color_continuous_scale=color_continuous_scale,
range_color=range_color,
range_x=[0, 49],
range_y=[-1, len(input_df.player.unique())],
hover_name='player', hover_data=['min_start', 'min_end', 'shots_count', 'shots_made', 'shots_freq', 'shots_acc', ],
render_mode='svg'
)
fig.update_coloraxes(colorbar=dict(title='Points per<BR>100 shots'))
fig.update_traces(marker=dict(sizeref=2. * 30 / (max_bubble_size ** 2)))
fig.update_yaxes(title="Player")
fig.update_xaxes(title='Minute', tickvals=list(range(0, 54, 6)))
return fig
app.title = 'Dash Demo - NBA'
team_names = all_teams_df.group.unique()
team_names.sort()
app.layout = html.Div([
html.Div([
dcc.Markdown(
"""
#### Shot Frequencies & Efficiencies (2019-20 NBA Season)
This page compares players based on shot *frequency* and *efficiency*,
divided up into minutes of regulation time for each team.
Use the pulldown to select a team, or select 'Leaders' to see leaders from each team.
*Notes*:
* **Frequency**: A team's shots a player is taking, indicated by **size**.
* **Efficiency**: Points scored per 100 shots, indicated by **colour** (red == better, blue == worse).
* Players with <1% of team shots are shown under 'Others'
"""
),
html.P([html.Small("See more data / NBA analytics content, find me on "), html.A(html.Small("twitter"), href="https://twitter.com/_jphwang", title="twitter"), html.Small("!")]),
]),
html.Div([
dcc.Dropdown(
id='group-select',
options=[{'label': i, 'value': i} for i in team_names],
value='TOR',
style={'width': '140px'}
)
]),
dcc.Graph(
'shot-dist-graph',
config={'displayModeBar': False}
)
])
@app.callback(
Output('shot-dist-graph', 'figure'),
[Input('group-select', 'value')]
)
def update_graph(grpname):
fig = make_shot_dist_chart(
all_teams_df[all_teams_df.group == grpname], col_col='pl_pps', range_color=[90, 120], size_col='shots_freq')
clean_chart_format(fig)
if len(grpname) > 3:
fig.update_layout(height=850, width=1250)
else:
fig.update_layout(height=500, width=1250)
return figPuedes leer más artículos de Data Science en español aquí La mayoría de los cambios son cosméticos, pero notará que aquí, sólo escribo el texto del cuerpo en Markdown, y simplemente llevo mis funciones de formato de Plotly para ser usadas en el formato de los gráficos en Dash.Esto me ahorra una tremenda cantidad de tiempo entre el análisis de datos y la visualización hasta el despliegue a las vistas de los clientes.Con todo, desde que empecé con mi gráfico inicial, creo que probablemente llevó menos de una hora desplegarlo en Heroku. Lo cual es bastante sorprendente.Me adentraré en las características más avanzadas de Dash, y en realidad haciendo algunas cosas geniales con él en cuanto a funcionalidad, pero estoy muy contento con este resultado en términos de facilidad y velocidad.Pruébalo tú mismo, creo que te impresionará. La próxima vez, pienso escribir sobre algunas cosas realmente geniales que puedes hacer con Dash, y construir dashboards verdaderamente interactivos.Si te gustó esto, di 👋 / follow en twitter, o sigueme para las actualizaciones. Este es el artículo en el que se basan los datos
Data Science
Deployment
Machine Learning
No Aprendas Machine Learning
No Aprendas Machine Learning. En vez de ello, Aprende a construir software con modelos de Machine Learning.Si eres un desarrollador de software (web o mobile), probablemente tengas algo de curiosidad o al menos un poco de interés en Machine Learning. El concepto de algoritmos que predicen y que pueden enseñarse a sí mismos es algo... genial.Sin embargo, si decides estudiar Machine Learning y seguir las recomendaciones canónicas para empezar, hay una buena posibilidad de que pases dos semanas aprendiendo álgebra lineal y cálculo multivariable antes de rendirte.La razón es que la mayoría del material de introducción al aprendizaje automático no está dirigido a los desarrolladores de software, sino a los investigadores de Machine Learning, y éste es un post para desarrolladores de software que sólo quieren construir productos de machine learning.Source: Pexels¿Quieres construir productos o investigar?Antes de finales de la década del 2000, el aprendizaje automático era más o menos exclusivamente un problema de investigación. Simplemente no había muchas empresas que utilizaran el aprendizaje automático en producción de forma significativa.Por lo tanto, gran parte del material introductorio disponible para el aprendizaje automático se enfoca desde esta perspectiva de investigación. Comienza explicando las redes neuronales desde una perspectiva matemática, explicando toda la teoría que hay detrás del Machine Learning, cosas como el back propagation y el adversarial networks.Incluso el material no afiliado a una universidad sigue este patrón hasta cierto punto. Por ejemplo, esto se toma directamente de "Quickstart for Beginners" de TensorFlow:Source: TensorFlowSi crees que estoy eligiendo un lenguaje confuso, te invito a que lo leas todo.Si ya estás familiarizado con las matemáticas que hay detrás del aprendizaje automático, o estás entusiasmado por aprenderlas, este enfoque te funcionará. Sin embargo, si lo que quieres es construir cosas con machine learning, puede que no sea exactamente lo que estás buscando.Para usar la programación como corolario, este enfoque es como aprender a escribir código aprendiendo primero assembly. Prácticamente ningún desarrollador aprende así.Nota: Si de alguna manera aprendiste a programar en assembly, acepto tus enojados comentarios, y estoy impresionado de que hayas conseguido un navegador para instalar en cualquier oscura distro de Linux que estés ejecutando.Cuando aprendiste a codificar, probablemente lo hiciste escribiendo "hola mundo" en un lenguaje de alto nivel. Luego, a medida que introdujiste pequeños trozos de complejidad en tus proyectos, aprendiste más y más programación de bajo nivel según lo necesitabas.Este patrón de aprendizaje tiene éxito entre las personas que construyen software porque da prioridad a la construcción de cosas, y si estás más interesado en construir un motor de recomendación que en publicar un artículo, así es como deberías enfocar el aprendizaje del ML.Cómo aprender Machine Learning construyendo software?Si eres el tipo de persona que aprende mejor tomando cursos, el mejor recurso, y probablemente el defensor más vocal de este enfoque de arriba hacia abajo, aprender haciendo, para aprender Machine Learning, es el curso de fastai Practical Deep Learning For Coders.El objetivo de este artículo no es hacer publicidad para fastai, basta con decir que sus fundadores (Jeremy Howard y Rachel Thomas) han creado varios cursos que enseñan a los desarrolladores deep learning haciendo que realmente construyan cosas, sumergiéndose en la teoría subyacente en lo que respecta a los proyectos que se están construyendo. Para tener una idea de su estilo de enseñanza, mira esta charla de Rachel Thomascharla de Rachel ThomasPor otra parte, si eres el tipo de persona que aprende mejor sumergiéndose y construyendo cosas por sí mismo, empezar a aprender machine learning es lo mismo que cualquier otro nicho de programación. Elija un proyecto que le parezca interesante, he reunido una lista gigante de proyectos de NLP para principiantes, entre en ella aqui.Un buen enfoque para familiarizarse con lo que es construir con NLP, suponiendo que aprendas de esta manera, sería:Identificar un objetivo, como construir un autocompletador de texto o un identificador de matrícula.Encontrar un modelo pre-entrenado que se ajuste a tu proyecto -GPT-2 o YOLOv3 funcionaría para los proyectos mencionados anteriormente, respectivamente.Si te apetece, puedes incluso utilizar una biblioteca como gpt-2-simple para afinar (personalizar con tus propios datos) tu modelo.Finalmente, despliega tu modelo como un microservicio.Una vez que tenga un modelo desplegado como una API, puede consultarlo como lo haría con cualquier otro servicio web y construir su aplicación alrededor de él.En realidad, puedes ver una aplicación real de este proceso en este proyecto, creada por un ingeniero que se dedica al Machine Learning:https://www.youtube.com/watch?v=gsYEZtecXlA&feature=emb_titleCon este enfoque, puede aprender sobre las diferentes arquitecturas de modelos populares y enfoques de aprendizaje de máquinas, y para qué aplicaciones son adecuadas. Igualmente importante, aprenderá sobre la infraestructura de Machine Learning, que es vital para construir productos reales a partir de modelos.Una vez que puedas construir algo con machine learning, entonces aprenderás la teoríaSi eres ingeniero, probablemente ya has implementado alguna forma de autenticación antes, lo que significa que (con suerte) has hecho contraseñas.Cuando configuraste el hash de las contraseñas, ¿escribiste un algoritmo de hash personalizado? ¿Pasó semanas estudiando criptografía? ¿O simplemente usaste bcrypt?Del mismo modo, cuando construyó su primera aplicación web, ¿pasó semanas aprendiendo sobre bases de datos? ¿Escribió la suya propia desde cero? ¿O usaste cualquier ORM que viniera con tu framework favorito?Esta misma lógica se aplica también al aprendizaje automático. Si eres el tipo de persona a la que le gusta construir software, empieza por construir software con aprendizaje automático, y deja que las herramientas, los modelos pre-entrenados y los frameworks de machine learning abstraiga la teoría Machine Learning subyacente. Luego, si tienes curiosidad o si tu proyecto exige más complejidad, profundiza más en el tema para ver cómo funciona todo.Thanks to Omer Spillinger, David Eliahu, and Vishal Bollu. Disclaimer: Lo siguiente está basado en mis observaciones de los equipos de machine learning - no sobre una encuesta académica de la industria. Para el contexto, soy un colaborador de Cortex, una plataforma de código abierto para el despliegue de modelos en producción.
Deployment
Data Science
Ciencia De Datos Para Startups: Data Pipelines - Parte 2
Una tubería escalableSiguiendo el hilo anterior sobre data pipeline, en esta ocasión construiremos una tubería de datos que reciba los eventos usando el PuSub de Google como endpoint, y guardaremos los eventos en un lago de datos y una base de datos. El enfoque presentado aquí guardará los eventos como datos en bruto (raw data), pero también discutiré las formas de transformar los eventos en datos procesados.La tubería de datos que realiza toda esta funcionalidad es relativamente simple. El pipeline lee los mensajes de PubSub y luego transforma los eventos para su persistencia: la porción de BigQuery del pipeline convierte los mensajes en objetos de TableRow y los transmite directamente a BigQuery, mientras que la porción de AVRO del pipeline agrupa los eventos en ventanas discretas y luego guarda los eventos en Google Storage. El gráfico de operaciones se muestra en la siguiente figura.El canal de transmisión desplegado en Google CloudEstablecer el Environment...El primer paso para construir una tubería de datos es establecer las dependencias necesarias para compilar y desplegar el proyecto. Utilicé las siguientes dependencias para configurar los entornos de la API de rastreo que envía los eventos a la tubería, y la tubería de datos que procesa los eventos.<!-- Dependencies for the Tracking API ->
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-pubsub</artifactId>
<version>0.32.0-beta</version>
</dependency>
</dependencies>
<!-- Dependencies for the data pipeline ->
<dependency>
<groupId>com.google.cloud.dataflow</groupId>
<artifactId>google-cloud-dataflow-java-sdk-all</artifactId>
<version>2.2.0</version>
</dependency>Usé Eclipse para crear y compilar el código de este tutorial, ya que es de código abierto. Sin embargo, otros IDEs como IntelliJ proporcionan características adicionales para desplegar y monitorear las tareas de DataFlow. Antes de poder implementar las tareas en Google Cloud, deberá configurar una cuenta de servicio tanto para PubSub como para DataFlow. La configuración de estas credenciales está fuera del alcance de este artículo, y hay más detalles disponibles en la documentación de Google.Un requisito previo adicional para ejecutar este flujo de datos es la creación de un topic de PubSub en GCP. Definí un topic de eventos en bruto que se utiliza para publicar y consumir los mensajes para la tubería de datos. Puede encontrar más detalles sobre la creación de un topic PubSub aquí.Para implementar este canal de datos, necesitarás configurar un entorno java con las dependencias maven mencionadas anteriormente, configurar un proyecto de Google Cloud y habilitar la facturación, habilitar la facturación en los servicios de almacenamiento y BigQuery, y crear un tema PubSub para el envío y la recepción de mensajes. Todos estos servicios gestionados cuestan dinero, pero hay un nivel gratuito que puede utilizarse para crear un prototipo de una tubería de datos.Sending events from a server to a PubSub topicEventos de publicaciónPara construir una tubería de datos utilizable, es útil construir APIs que encapsulen los detalles del envío de datos de eventos. La clase de API de rastreo proporciona esta funcionalidad, y puede utilizarse para enviar datos de eventos generados al conducto de datos. El código que se muestra a continuación muestra la firma del método para el envío de eventos, y muestra cómo generar datos de muestra./** Event Signature for the Tracking API
public void sendEvent(String eventType, String eventVersion, HashMap<String, String> attributes);
*/
// send a batch of events
for (int i=0; i<10000; i++) {
// generate event names
String eventType = Math.random() < 0.5 ?
"Session" : (Math.random() < 0.5 ? "Login" : "MatchStart");
// create attributes to send
HashMap<String, String> attributes = new HashMap<String,String>();
attributes.put("userID", "" + (int)(Math.random()*10000));
attributes.put("deviceType", Math.random() < 0.5 ?
"Android" : (Math.random() < 0.5 ? "iOS" : "Web"));
// send the event
tracking.sendEvent(eventType, "V1", attributes);
}La API de rastreo establece una conexión con un topic PubSub, pasa los eventos como un formato JSON, e implementa una llamada de retorno para la notificación de fallas en la entrega. El código utilizado para enviar eventos se proporciona a continuación, y se basa en el ejemplo de PubSub de Google que se proporciona aquí.// Setup a PubSub connection
TopicName topicName = TopicName.of(projectID, topicID);
Publisher publisher = Publisher.newBuilder(topicName).build();
// Specify an event to send
String event = {\"eventType\":\"session\",\"eventVersion\":\"1\"}";
// Convert the event to bytes
ByteString data = ByteString.copyFromUtf8(event.toString());
//schedule a message to be published
PubsubMessage pubsubMessage =
PubsubMessage.newBuilder().setData(data).build();
// publish the message, and add this class as a callback listener
ApiFuture<String> future = publisher.publish(pubsubMessage); ApiFutures.addCallback(future, this);El código de arriba permite a las aplicaciones enviar eventos a un tema de PubSub. El siguiente paso es procesar estos eventos en un entorno totalmente gestionado que puede escalar según sea necesario para satisfacer la demanda.Almacenamiento de eventosUna de las funciones clave de una tubería de datos es poner los eventos instrumentados a disposición de los equipos de ciencia y análisis de datos para su análisis. Las fuentes de datos utilizadas como endpoints deben tener una baja latencia y ser capaces de escalar hasta un volumen masivo de eventos. El conducto de datos definido en este tutorial muestra cómo producir eventos tanto para BigQuery como para un lago de datos que puede utilizarse para dar soporte a un gran número de usuarios de empresas de análisis.Streaming event data from PubSub to DataFlowEl primer paso en esta tubería de datos es leer los eventos de un topic PubSub y pasar los mensajes ingeridos al proceso de DataFlow. DataFlow proporciona un conector PubSub que permite la transmisión de mensajes PubSub a otros componentes del DataFlow. El código que se muestra a continuación muestra cómo instanciar el conducto de datos, especificar el modo de transmisión y consumir los mensajes de un topic PubSub específico. El resultado de este proceso es una colección de mensajes PubSub que se pueden almacenar para su posterior análisis.// set up pipeline options
Options options = PipelineOptionsFactory.fromArgs(args)
.withValidation().as(Options.class);
options.setStreaming(true);
Pipeline pipeline = Pipeline.create(options);
// read game events from PubSub
PCollection<PubsubMessage> events = pipeline
.apply(PubsubIO.readMessages().fromTopic(topic));La primera forma en que queremos almacenar los eventos es en un formato de columnas que puede ser usado para construir un lago de datos. Aunque este post no muestra cómo utilizar estos archivos en ETLs río abajo, tener un lago de datos es una gran manera de mantener una copia de su conjunto de datos en caso de que necesite hacer cambios en su base de datos. El lago de datos proporciona una manera de volver a cargar sus datos si es necesario debido a cambios en los esquemas o problemas de ingestión de datos. A continuación se muestra la parte del lago de datos asignada a este proceso.Batching events to AVRO format and saving to Google StoragePara la AVRO, no podemos usar un enfoque de transmisión directa. Necesitamos agrupar los eventos en lotes antes de poder guardarlos en archivos planos. La forma en que esto se puede lograr en DataFlow es aplicando una función de ventanas que agrupa los eventos en lotes fijos. El código que se muestra a continuación aplica transformaciones que convierten los mensajes PubSub en objetos String, agrupa los mensajes en intervalos de 5 minutos y envía los lotes resultantes a archivos AVRO en Google Storage.// AVRO output portion of the pipeline
events
.apply("To String", ParDo.of(new DoFn<PubsubMessage, String>() {
@ProcessElement
public void processElement(ProcessContext c) throws Exception {
String message = new String(c.element().getPayload());
c.output(message);
}
}))
// Batch events into 5 minute windows
.apply("Batch Events", Window.<String>into(
FixedWindows.of(Duration.standardMinutes(5)))
.triggering(AfterWatermark.pastEndOfWindow())
.discardingFiredPanes()
.withAllowedLateness(Duration.standardMinutes(5)))
// Save the events in ARVO format
.apply("To AVRO", AvroIO.write(String.class)
.to("gs://your_gs_bucket/avro/raw-events.avro")
.withWindowedWrites()
.withNumShards(8)
.withSuffix(".avro"));Para resumir, el código anterior agrupa los eventos en ventanas de 5 minutos y luego exporta los eventos a archivos AVRO en Google Storage.El resultado de esta porción de la tubería de datos es una colección de archivos AVRO en el almacenamiento de Google que puede ser usada para construir un lago de datos. Cada 5 minutos se genera una nueva salida de AVRO, y los ETL pueden analizar los eventos en bruto en esquemas de tablas específicas de eventos procesados. La imagen de abajo muestra una salida de los archivos de AVRO.AVRO files saved to Google StorageAdemás de crear un lago de datos, queremos que los eventos sean accesibles inmediatamente en un entorno de consulta. DataFlow proporciona un conector BigQuery que sirve esta funcionalidad, y los datos enviados a este endpoint están disponibles para su análisis después de una corta duración. Esta porción de la tubería de datos se muestra en la siguiente figura.Streaming events from DataFlow to BigQueryLa tubería de datos convierte los mensajes PubSub en objetos TableRow, que pueden ser insertados directamente en BigQuery. El código de abajo consiste en dos métodos de aplicación: una transformación de datos y un escritor IO. El paso de transformación lee las cargas útiles de los mensajes de PubSub, analiza el mensaje como un objeto JSON, extrae los atributos eventType y eventVersion, y crea un objeto TableRow con estos atributos además de una marca de tiempo y la carga útil del mensaje. El segundo método de aplicación le dice al pipeline que escriba los registros en BigQuery y que añada los eventos a una tabla existente.// parse the PubSub events and create rows to insert into BigQuery events.apply("To Table Rows", new
PTransform<PCollection<PubsubMessage>, PCollection<TableRow>>() {
public PCollection<TableRow> expand(
PCollection<PubsubMessage> input) {
return input.apply("To Predictions", ParDo.of(new
DoFn<PubsubMessage, TableRow>() {
@ProcessElement
public void processElement(ProcessContext c) throws Exception {
String message = new String(c.element().getPayload());
// parse the json message for attributes
JsonObject jsonObject =
new JsonParser().parse(message).getAsJsonObject();
String eventType = jsonObject.get("eventType").getAsString();
String eventVersion = jsonObject.
get("eventVersion").getAsString();
String serverTime = dateFormat.format(new Date());
// create and output the table row
TableRow record = new TableRow();
record.set("eventType", eventType);
record.set("eventVersion", eventVersion);
record.set("serverTime", serverTime);
record.set("message", message);
c.output(record);
}}));
}})
//stream the events to Big Query
.apply("To BigQuery",BigQueryIO.writeTableRows()
.to(table)
.withSchema(schema)
.withCreateDisposition(CreateDisposition.CREATE_IF_NEEDED)
.withWriteDisposition(WriteDisposition.WRITE_APPEND));Para resumir el código anterior, cada mensaje que se consume de PubSub se convierte en un objeto de TableRow con una marca de tiempo y luego se transmite a BigQuery para su almacenamiento.El resultado de esta porción de la tubería de datos es que los eventos serán transmitidos a BigQuery y estarán disponibles para su análisis en la tabla de salida especificada por la tarea de DataFlow. Para utilizar eficazmente estos eventos para las consultas, necesitará construir ETLs adicionales para crear tablas de eventos procesados con registros esquematizados, pero ahora tiene un mecanismo de recolección de datos para almacenar eventos de seguimiento.Game event records queried from the raw-events table in BigQueryDespliegue y escalado automáticoCon DataFlow puede probar la tubería de datos localmente o desplegarla en la nube. Si ejecuta los ejemplos de código sin especificar atributos adicionales, entonces la tubería de datos se ejecutará en su máquina local. Para poder realizar el despliegue en la nube y aprovechar las capacidades de escalado automático de este conducto de datos, debe especificar una nueva clase de Runner como parte de sus argumentos de tiempo de ejecución. Para ejecutar el conducto de datos, utilicé los siguientes argumentos de tiempo de ejecución:--runner=org.apache.beam.runners.dataflow.DataflowRunner
--jobName=game-analytics
--project=your_project_id
--tempLocation=gs://temp-bucketUna vez que el trabajo se despliega, deberías ver un mensaje de que el trabajo ha sido enviado. Entonces puede hacer clic en la consola de DataFlow para ver la tarea:The steaming data pipeline running on Google CloudLa configuración de tiempo de ejecución especificada anteriormente no se predeterminará en una configuración de escalado automático. Para implementar un trabajo que se escalará según la demanda, deberá especificar atributos adicionales, como por ejemplo:--autoscalingAlgorithm=THROUGHPUT_BASED
--maxNumWorkers=30Detalles adicionales sobre la configuración de una tarea de DataFlow para escalar a condiciones de gran carga de trabajo están disponibles en este artículo de Google y en esta entrada de Spotify. La imagen de abajo muestra cómo DataFlow puede escalar para satisfacer la demanda según sea necesario.An example of Dataflow auto scaling. The pipeline will scale up and down as necessary to match demand.De los datos en bruto a eventos procesados.El conducto presentado hasta ahora guarda los eventos de rastreo como datos en bruto. Para traducir estos eventos a datos procesados, necesitaremos aplicar esquemas específicos de eventos. Hay algunos enfoques diferentes que podemos tomar con esta tubería:Aplicar los esquemas en el conducto actual de DataFlow y guardar en BigQueryAplicar los esquemas en la tubería actual y enviar a un nuevo PubSubAplicar atributos adicionales a los eventos en bruto y enviar a un nuevo PubSubUsar los ETLs posteriores para aplicar los esquemasEl primer enfoque es el más sencillo, pero no ofrece una buena solución para actualizar las definiciones de los eventos si es necesario. Este enfoque puede ser implementado como se muestra en el siguiente código, que muestra cómo filtrar y analizar los eventos MatchStart para su entrada en BigQuery.events.apply("To MatchStart Events", ParDo.of(
new DoFn<PubsubMessage, TableRow>() {
@ProcessElement
public void processElement(ProcessContext c) throws Exception {
String message = new String(c.element().getPayload());
JsonObject jsonObject = new
JsonParser().parse(message).getAsJsonObject();
String eventType = jsonObject.get("eventType").getAsString();
String version = jsonObject.get("eventVersion").getAsString();
String serverTime = dateFormat.format(new Date());
// Filter for MatchStart events
if (eventType.equals("MatchStart")) {
TableRow record = new TableRow();
record.set("eventType", eventType);
record.set("eventVersion", version);
record.set("server_time", serverTime);
// event specifc attributes
record.set("userID", jsonObject.get("userID").getAsString());
record.set("type", jsonObject.get("deviceType").getAsString());
c.output(record);
}
}}))
.apply("To BigQuery",BigQueryIO.writeTableRows()Para implementar este enfoque, necesitaría crear una nueva implementación de DoFn para cada tipo de evento. El segundo enfoque es similar al primero, pero en lugar de pasar los eventos analizados a BigQuery, se pasan a un nuevo topic de PubSub. Es posible enviar varios tipos de eventos a un solo tema o crear un tema por evento. El inconveniente de utilizar los dos primeros enfoques es que la lógica de análisis de mensajes forma parte de la cadena de eventos en bruto. Esto significa que cambiar las definiciones de los eventos implica reiniciar la tubería.The streaming pipeline with an additional output:Un tercer enfoque que puede utilizarse es el envío de eventos sin procesar con atributos adicionales a otro topic del PubSub. Un segundo trabajo de flujo de datos puede ser configurado para analizar los eventos según sea necesario. El código que se muestra a continuación muestra cómo analizar los eventos sin procesar, agregar atributos adicionales al mensaje PubSub para filtrarlos y publicar los eventos en un segundo topic. Este enfoque permite cambiar las definiciones de los eventos sin necesidad de reiniciar el flujo de eventos sin procesar.# topic for raw events with additional attributes
private static String processed =
"projects/your_project_id/topics/processed-events";
events.apply("PubSub Processed",
ParDo.of(new DoFn<PubsubMessage, PubsubMessage>() {
@ProcessElement
public void processElement(ProcessContext c) throws Exception {
String message = new String(c.element().getPayload());
// parse the JSON message for attributes
JsonObject jsonObject = new
JsonParser().parse(message).getAsJsonObject();
String eventType = jsonObject.get("eventType").getAsString();
// Add additional attributes for filtering
HashMap<String, String> atts = new HashMap();
atts.put("EventType", eventType);
PubsubMessage out = new PubsubMessage(message.getBytes(), atts);
c.output(out);
}
}))
.apply(PubsubIO.writeMessages().to(processed));Un cuarto enfoque que puede utilizarse es hacer que los procesos de ETL posteriores apliquen esquemas a los sucesos sin procesar y separen la tabla de sucesos sin procesar en tablas de sucesos específicos. Cubriremos este enfoque en el próximo artículo.ConclusiónEste post ha proporcionado una introducción a la construcción de una tubería de datos para una startup. Hemos cubierto los tipos de datos en una tubería, las propiedades deseadas de una tubería de datos de alto funcionamiento, la evolución de las tuberías de datos, y una tubería de muestra construida sobre GCP (Google Cloud Platform).Ahora hay una variedad de herramientas disponibles que hacen posible establecer una tubería de análisis para una aplicación con un esfuerzo mínimo. El uso de recursos gestionados permite a los equipos pequeños aprovechar la infraestructura sin servidores y de escalado automático para escalar a volúmenes de eventos masivos con una gestión de infraestructura mínima. En lugar de utilizar la solución estándar de un proveedor de datos para recopilar datos, puede registrar todos los datos relevantes para su aplicación. Si bien el enfoque que se presenta aquí no es directamente portable a otras nubes, la biblioteca Apache Beam que se utiliza para implementar la funcionalidad principal de este conducto de datos es portable y herramientas similares pueden aprovecharse para construir conductos de datos escalables en otros proveedores de nubes.El código fuente completo de este pipeline de muestra está disponible en Github.
Data Science
Deployment
Ciencia De Datos Para Startups: Data Pipelines - Parte 1
Source: TheDigitalArtist at pixabay.comLa tercera parte de mi serie en curso sobre la construcción de una disciplina de ciencia de datos en una startup. Puedes encontrar enlaces a todas las publicaciones en la introducción, y un libro basado en esta serie en Amazon.La construcción de pipelines (tuberias) de datos es un componente básico de la ciencia de datos en una startup. Para poder construir productos basados en datos, es necesario ser capaz de recolectar puntos de datos de millones de usuarios y procesar los resultados casi en tiempo real. Mientras que mi anterior entrada en el blog hablaba de qué tipo de datos hay que recolectar y cómo enviar los datos a un endpoint de una API, esta entrada tratará de cómo procesar los datos que se han recolectado, permitiendo a los científicos de datos trabajar con los datos. La próxima entrada del blog sobre la producción de modelos discutirá cómo desplegar modelos en esta plataforma de datos.Típicamente, el destino de una tubería de datos es un lago de datos (data lake), como Hadoop o archivos de parquetes en S3, o una base de datos relacional, como Redshift. Un conducto de datos ideal debería tener las siguientes propiedades:Baja latencia de eventos: Los científicos de datos deberían ser capaces de consultar los datos de eventos recientes en la tubería, en cuestión de minutos o segundos después de que el evento sea enviado al punto final de recolección de datos. Esto es útil para fines de testing y para construir productos de datos que necesitan actualizarse casi en tiempo real.Escalabilidad: Una tubería de datos debería poder escalar a miles de millones de puntos de datos, y potencialmente a trillones a medida que el producto se va escalando. Un sistema de alto rendimiento no sólo debería poder almacenar estos datos, sino también poner a disposición el conjunto completo de datos para su consulta.Consulta interactiva: Un sistema de datos de alto rendimiento debería permitir tanto consultas por lotes de larga duración como consultas interactivas más pequeñas que permitan a los científicos de los datos explorar tablas y comprender el esquema sin tener que esperar minutos u horas al tomar muestras de los datos.Versiones: Debería ser capaz de hacer cambios en su tubería de datos y en las definiciones de los eventos sin que la tubería se caiga y se pierdan los datos. En este post se discutirá cómo construir una tubería que soporte con diferentes definiciones de eventos, en el caso de cambiar un esquema de eventos.Monitoreo: Si un evento ya no se recibe, o si ya no se reciben datos de seguimiento para una región en particular, entonces el conducto de datos debería generar alertas a través de herramientas como PagerDuty.Testing: Debería poder probar su tubería de datos con eventos de prueba que no terminen en su lago de datos o base de datos, pero que sí prueben los componentes en la tubería.Hay una serie de otras propiedades útiles que un conducto de datos debe tener, pero este es un buen punto de partida para una startup. A medida que comience a construir componentes adicionales que dependen de su tubería de datos, querrá configurar herramientas para la tolerancia a las fallas y la automatización de tareas.Este artículo mostrará cómo configurar un conducto de datos escalable que envíe datos de seguimiento a un lago de datos, una base de datos y un servicio de suscripción para su uso en productos de datos. Discutiré los diferentes tipos de datos en un conducto, la evolución de los conductos de datos, y recorreré un ejemplo de conducto implementado en GCP con PubSub, DataFlow y BigQuery.Antes de desplegar una tubería de datos, querrá responder a las siguientes preguntas, que se asemejan a nuestras preguntas sobre las especificaciones de rastreo o tracking:¿Quién es el propietario del conducto de datos?¿Qué equipos consumirán los datos?¿Quién controlará la tubería?En una organización pequeña, un científico de datos puede ser el responsable del conducto, mientras que las organizaciones más grandes suelen tener un equipo de infraestructura que se encarga de mantener el conducto en funcionamiento. También es útil saber qué equipos consumirán los datos, de modo que se puedan transmitir los datos a los equipos apropiados. Por ejemplo, es posible que el departamento de marketing necesite datos en tiempo real de las visitas a una landing page para realizar la atribución de las campañas de marketing. Y, por último, la calidad de los datos de los eventos pasados al conducto debe ser inspeccionada minuciosamente de manera regular. A veces, la actualización de un producto hará que un evento de tracking deje caer datos relevantes, por lo que se debe establecer un proceso para capturar estos tipos de cambios en los datos.Tipos de datosLos datos en una tuberia suelen denominarse con diferentes nombres en función de la cantidad de modificación que se haya realizado. Los datos se clasifican típicamente con las siguientes etiquetas:Datos en bruto (Raw data): Es el seguimiento de datos sin procesamiento aplicado. Son datos almacenados en el formato de codificación de mensajes utilizado para enviar eventos de rastreo, como JSON. Los datos brutos no tienen todavía un esquema aplicado. Es común enviar todos los eventos de rastreo como eventos sin procesar, porque todos los eventos pueden ser enviados a un solo endpoint y los esquemas pueden ser aplicados más tarde en la tubería.Datos procesados (Proceseed Data): Los datos procesados son datos sin procesar que han sido decodificados en formatos específicos de eventos, con un esquema aplicado. Por ejemplo, los eventos de seguimiento JSON que se han traducido en eventos de inicio de sesión con un esquema fijo se consideran datos procesados. Los eventos procesados suelen almacenarse en diferentes tablas de eventos/destinos en un conducto de datos.Datos cocinados (Cooked Data): Los datos procesados que han sido agregados o resumidos se denominan datos cocinados. Por ejemplo, los datos procesados podrían incluir eventos de inicio y fin de sesión y utilizarse como entrada de datos cocinados que resumen la actividad diaria de un usuario, como el número de sesiones y el tiempo total de permanencia en el sitio para una página web.Los científicos de los datos trabajarán normalmente con datos procesados y utilizarán herramientas para crear datos cocinados para otros equipos. En este post se discutirá cómo construir un pipeline de datos que produzca datos procesados, mientras que en el post de Inteligencia de Negocios se discutirá cómo agregar datos cocinados a su pipeline.La evolución de los data pipelinesEn las últimas dos décadas el paisaje para la recolección y análisis de datos ha cambiado significativamente. En lugar de almacenar datos localmente a través de archivos de registro, los sistemas modernos pueden rastrear la actividad y aplicar machine learning casi en tiempo real. Las startups podrían querer utilizar uno de los enfoques anteriores para los testing iniciales, pero realmente deberían buscar enfoques más recientes para construir tuberías de datos. Basándome en mi experiencia, he observado cuatro enfoques diferentes para las tuberías:La era de archivo plano: Los datos se guardan localmente en servidoresLa era la base de datos: Los datos se ponen en escena en archivos planos y luego se cargan en una base de datosLa era del Data Lake: Los datos se almacenan en Hadoop/S3 y luego se cargan en un DBLa era sin servidores (Serverless): Los servicios administrados se utilizan para el almacenamiento y la consultaCada uno de los pasos de esta evolución apoya la recopilación de conjuntos de datos más grandes, pero puede introducir una complejidad operacional adicional. Para una startup, el objetivo es ser capaz de escalar la recolección de datos sin escalar los recursos operacionales, y la progresión hacia los servicios administrados proporciona una buena solución para el crecimiento.La tubería de datos por la que caminaremos en la siguiente sección de este post se basa en la era más reciente de tuberías de datos, pero es útil caminar a través de diferentes enfoques porque los requisitos para diferentes empresas pueden encajar mejor con diferentes arquitecturas.La era de los archivos planosComponents in a pre-database Analytics ArchitectureNota: Hablaremos sobre "Game" servers debido a que el autor trabaja en ZyngaMe inicié en la ciencia de los datos en Electronic Arts en 2010, antes de que EA tuviera una organización construida alrededor de los datos. Mientras que muchas compañías de juegos ya estaban recolectando cantidades masivas de datos sobre la jugabilidad, la mayoría de la telemetría se almacenaba en forma de archivos de registro u otros formatos de archivos planos que se almacenaban localmente en los servidores. Nada podía ser consultado directamente, y calcular las métricas básicas como los usuarios activos mensuales (MAU) requería un esfuerzo considerable.En Electronic Arts, se incorporó un feature de "replay" en el Madden NFL 11 que proporcionó una fuente inesperada de telemetría del juego. Después de cada juego, se enviaba un resumen del mismo en formato XML a un servidor de juegos que enumeraba cada jugada llamada, los movimientos realizados durante el juego y el resultado de la caída. Esto resultó en millones de archivos que podían ser analizados para aprender más sobre cómo los jugadores interactuaban con el videojuego de fútbol de Madden en la vida real.Almacenar los datos localmente es, con mucho, el enfoque más fácil de tomar cuando se recogen datos de juego. Por ejemplo, el enfoque PHP presentado en el último post es útil para establecer un endpoint de análisis ligero. Pero este enfoque tiene inconvenientes significativos.Este enfoque es simple y permite a los equipos guardar los datos en cualquier formato que se necesite, pero no tiene tolerancia a fallos, no almacena los datos en una ubicación central, tiene una latencia significativa en la disponibilidad de los datos, y tiene herramientas estándar para construir un ecosistema para el análisis. Los archivos planos pueden funcionar bien si sólo tienes unos pocos servidores, pero no es realmente una tubería de análisis a menos que muevas los archivos a una ubicación central. Puedes escribir scripts para llevar los datos de los servidores de registro a una ubicación central, pero generalmente no es un enfoque escalable.La era de las bases de datosComponentes de una arquitectura analítica basada en ETLMientras estaba en Sony Online Entertainment, teníamos servidores de juegos que guardaban archivos de eventos en un servidor de archivos central cada dos minutos. El servidor de archivos luego ejecutaba un proceso ETL una vez por hora que cargaba rápidamente estos archivos de eventos en nuestra base de datos de análisis, que era Vertica en ese momento. Este proceso tenía una latencia razonable, alrededor de una hora desde que un cliente de un videojuego enviaba un evento a los datos que se podían consultar en nuestra base de datos analítica. También se escaló a un gran volumen de datos, pero requirió el uso de un esquema fijo para los datos de evento.Cuando era empleado en Twitch, usábamos un proceso similar para una de nuestras bases de datos analíticas. La principal diferencia con el enfoque de Sony era que en lugar de tener los archivos scp de los servidores de juegos en una ubicación central, usábamos Amazon Kinesis para transmitir eventos de los servidores a un área de montaje en el S3. Luego usamos un proceso ETL para cargar rápidamente los datos en Redshift para su análisis. Desde entonces, Twitch ha cambiado a un enfoque de lago de datos, con el fin de escalar a un mayor volumen de datos y proporcionar más opciones para la consulta de los conjuntos de datos.Las bases de datos utilizadas en Sony y Twitch eran inmensamente valiosas para ambas compañías, pero nos encontramos con desafíos a medida que escalábamos la cantidad de datos almacenados. A medida que recogíamos información más detallada sobre el juego, ya no podíamos mantener un historial completo de eventos en nuestras tablas y necesitábamos truncar los datos más antiguos de unos pocos meses. Esto está bien si se pueden crear tablas de resumen que mantengan los detalles más importantes sobre estos eventos, pero no es una situación ideal.Uno de los problemas de este enfoque es que el servidor staging se convierte en un punto central de fracaso. También es posible que surjan cuellos de botella cuando un juego envía demasiados eventos, haciendo que los eventos se eliminen en todos los títulos. Otro problema es el rendimiento de las consultas al aumentar el número de analistas que trabajan con la base de datos. Un equipo de unos pocos analistas que trabajen con unos pocos meses de datos de juego puede funcionar bien, pero después de recopilar años de datos y aumentar el número de analistas, el rendimiento de las consultas puede ser un problema importante, lo que hace que algunas consultas tarden horas en completarse.Los principales beneficios de este enfoque son que todos los datos de los eventos están disponibles en un solo lugar que puede ser consultado con SQL y que se dispone de grandes herramientas, como Tableau y DataGrip, para trabajar con bases de datos relacionales. Las desventajas son que es costoso mantener todos los datos cargados en una base de datos como Vertica o Redshift, los eventos deben tener un esquema fijo, y puede ser necesario truncar las tablas para mantener el rendimiento de los servidores.Otro problema de la utilización de una base de datos como interfaz principal para los datos es que las herramientas de machine learning, como MLlib de Spark, no pueden utilizarse eficazmente, ya que los datos pertinentes deben descargarse de la base de datos antes de que se puedan utilizar. Una de las formas de superar esta limitación es almacenar los datos de juego en un formato y una capa de almacenamiento que funcionen bien con las herramientas de Big Data, como por ejemplo, guardar eventos como archivos de parquete en S3. Este tipo de configuración se hizo más poblada en la siguiente era, y evita las limitaciones de tener que truncar las tablas y reduce el costo de mantener todos los datos.La era del Data LakeComponents in a Data Lake Analytics ArchitectureEl patrón de almacenamiento de datos que era más común mientras trabajaba como científico de datos en la industria de los videojuegos era un lago de datos. El patrón general es almacenar datos semiestructurados en una base de datos distribuida, y ejecutar procesos ETL para extraer los datos más relevantes a bases de datos analíticas. Para la base de datos distribuida se pueden utilizar diferentes herramientas: en Electronic Arts usamos Hadoop, en Microsoft Studios usamos Cosmos, y en Twitch usamos S3.Este enfoque permite a los equipos escalar a volúmenes masivos de datos, y proporciona una tolerancia adicional a las fallas. El principal inconveniente es que introduce una complejidad adicional, y puede dar lugar a que los analistas tengan acceso a menos datos que si se utilizara un enfoque de base de datos tradicional, debido a la falta de herramientas o políticas de acceso. La mayoría de los analistas interactuarán con los datos de la misma manera en este modelo, utilizando una base de datos analítica poblada de ETLs de lago de datos.Una de las ventajas de este enfoque es que admite una variedad de esquemas de eventos diferentes, y puede cambiar los atributos de un evento sin afectar a la base de datos analítica. Otra ventaja es que los equipos de análisis pueden utilizar herramientas como Spark SQL para trabajar directamente con el lago de datos. Sin embargo, en la mayoría de los lugares en los que trabajé se restringió el acceso al lago de datos, eliminando muchos de los beneficios de este modelo.Este enfoque se escala a una cantidad masiva de datos, soporta esquemas de eventos flexibles, y proporciona una buena solución para consultas por lotes de larga duración. La desventaja es que puede implicar una sobrecarga operacional significativa, puede introducir grandes latencias de eventos, y puede carecer de herramientas maduras para los usuarios finales del lago de datos. Un inconveniente adicional de este enfoque es que normalmente se necesita un equipo completo sólo para mantener el sistema operativo. Esto tiene sentido para las grandes organizaciones, pero puede ser exagerado para las empresas más pequeñas. Una de las formas de aprovechar la utilización del lago de datos sin el costo de los gastos generales de funcionamiento es utilizar servicios gestionados.Era sin servidoresComponents in a managed Analytics Architecture (GCP)En la era actual, las plataformas analíticas incorporan una serie de servicios gestionados, que permiten a los equipos trabajar con los datos casi en tiempo real, ampliar los sistemas según sea necesario y reducir los gastos de mantenimiento de los servidores. Nunca experimenté esta era mientras trabajaba en la industria de los videojuegos, pero vi señales de que esta transición estaba ocurriendo. Riot Games está usando Spark para los procesos de ETL y el machine learning, y necesitaba hacer girar la infraestructura según la demanda. Algunos equipos están usando métodos de computación elástica para los servicios de juegos, y tiene sentido utilizar este enfoque para el análisis también.Este enfoque tiene muchos de los mismos beneficios que el uso de un lago de datos, auto-escalas basadas en las necesidades de consulta y almacenamiento, y tiene un mínimo de gastos operativos. Las principales desventajas son que los servicios gestionados pueden ser costosos, y la adopción de este enfoque probablemente dará lugar a la utilización de herramientas específicas de la plataforma que no son portables a otros proveedores de nubes.En mi carrera tuve el mayor éxito trabajando con el enfoque de la era de la base de datos, ya que proporcionaba al equipo de análisis acceso a todos los datos relevantes. Sin embargo, no fue una configuración que continuara escalando y la mayoría de los equipos en los que trabajé se han trasladado desde entonces a entornos de lago de datos. Para que un entorno de lago de datos tenga éxito, los equipos de análisis necesitan acceso a los datos subyacentes, y herramientas maduras para apoyar sus procesos. Para una startup, el enfoque sin servidores suele ser la mejor manera de empezar a construir un conducto de datos, porque puede escalarse para ajustarse a la demanda y requiere un mínimo de personal para mantener el conducto de datos. En la siguiente post se explicará cómo construir un conducto de muestra con servicios gestionados.Continua con la segunda parte de este post aqui.
Deployment
Data Science
Creación De Una Infraestructura De Data Science Desde Cero Para Una App De Recomendaciones En Una Startup
Librerias de machine learning para diferentes tipos de entorno de datos (Fuente: Kosyakov (2016))Continuando con el anterior post sobre la gestion de datos que todo cientifico de datos debe saber, en este post continuaremos con un caso de estudio.Construir un producto viable de Data Science implica mucho más que construir un modelo de machine learning con scikit-learn, encurtirlo (pickling) y cargarlo en un servidor. Requiere una comprensión de cómo todas las partes del ecosistema de la empresa trabajan juntas, comenzando con dónde/cómo los datos fluyen en el equipo de datos, el ambiente donde los datos son procesados/transformados, las convenciones de la empresa para visualizar/presentar datos, y cómo la salida del modelo será convertida como entrada para algunas otras aplicaciones de la empresa. Los principales objetivos consisten en crear un proceso que sea fácil de mantener; en el que los modelos se puedan iterar y el rendimiento sea reproducible; y en que el resultado del modelo se pueda comprender y visualizar fácilmente para otros interesados a fin de que puedan adoptar decisiones empresariales mejor fundamentadas. Para alcanzar esos objetivos es necesario seleccionar los instrumentos adecuados, así como comprender lo que hacen los demás integrantes de la industria y las mejores prácticas.Ilustrémoslo con un escenario: supongamos que usted acaba de ser contratado como data scientist para una startup que está construyendo una aplicación que recomienda vacaciones a sus usuarios y se espera que recoja cientos de gigabytes de datos tanto estructurados (perfiles de clientes, climas, precios y registros de transacciones) como no estructurados (mensajes/comentarios de los clientes y archivos de imágenes) de los usuarios diariamente. Sus modelos de predicción tendrán que ser reentrenados con nuevos datos semanalmente y hacer recomendaciones instantáneas cada vez que se solicite. Dado que usted espera que su aplicación sea un gran éxito, su capacidad de recolección, almacenamiento y análisis de datos tendría que ser extremadamente escalable. ¿Cómo diseñaría el proceso de data science y dejaría listos para producción sus modelos? ¿Cuáles son las herramientas que necesitaría para hacer el trabajo? Dado que se trata de una startup y que usted es el principal (senior) - y tal vez el único - científico de datos, está en usted la responsabilidad de tomar estas decisiones.En primer lugar, habría que averiguar cómo configurar la tubería de datos (data pipeline) que toma los datos en bruto de las fuentes de datos, procesa los datos y alimenta los datos procesados a las bases de datos. El conducto de datos ideal tiene una baja latencia de eventos (capacidad de consultar los datos tan pronto como se recogen); escalabilidad (capaz de manejar una gran cantidad de datos a medida que el producto se va escalando); consultas interactivas (admite tanto consultas por lotes como consultas interactivas más pequeñas que permiten a los científicos de datos explorar las tablas y los esquemas); creación de versiones (capacidad de realizar cambios en el conducto sin que éste se caiga y se pierdan datos); supervisión (el conducto debe generar alertas cuando los datos dejen de llegar); y pruebas (capacidad de probar el conducto sin interrupciones). Tal vez lo más importante es que no interfiera con las operaciones comerciales diarias - por ejemplo, rodarán cabezas si el nuevo modelo que está probando hace que su base de datos operativa se detenga. La construcción y el mantenimiento del conducto de datos suele ser responsabilidad de un ingeniero de datos (para más detalles, este artículo tiene una excelente visión general sobre la construcción del conducto de datos para startups), pero un científico de datos debe estar al menos familiarizado con el proceso, sus limitaciones y las herramientas necesarias para acceder a los datos procesados para su análisis.A continuación, tendrá que decidir si desea establecer una infraestructura en las instalaciones de la empresa o utilizar servicios en la nube. Para una startup, la prioridad principal es escalar la recolección de datos sin escalar los recursos operacionales. Como se mencionó anteriormente, la infraestructura en las instalaciones requiere enormes costos iniciales y de mantenimiento, por lo que los servicios en la nube tienden a ser una mejor opción para las startups. Los servicios en la nube permiten una escalabilidad que satisface la demanda y requieren un mínimo de esfuerzos de mantenimiento, de modo que su pequeño equipo de personal podría centrarse en el producto y el análisis en lugar de la gestión de la infraestructura.Ejemplos de proveedores que ofrecen soluciones basadas en Hadoop (Fuente: WikiCommons)Para elegir un proveedor de servicios en la nube, primero tendría que establecer los datos que necesitaría para el análisis, y las bases de datos y la infraestructura analítica más adecuada para esos tipos de datos. Dado que habría tanto datos estructurados como no estructurados en su pipeline de análisis, es posible que desee establecer un Data Warehouse y un Data Lake. Una cosa importante a considerar para los científicos de datos es si la capa de almacenamiento soporta las grandes herramientas de datos que se necesitan para construir los modelos, y si la base de datos proporciona un efectivo análisis dentro de la base de datos. Por ejemplo, algunas bibliotecas de ML como la MLlib de Spark no pueden utilizarse eficazmente con bases de datos como interfaz principal para los datos - los datos tendrían que ser descargados de la base de datos antes de que se pueda operar en ella, lo que podría ser extremadamente lento a medida que el volumen de datos crece y podría convertirse en un cuello de botella cuando se tiene que volver a entrenar los modelos regularmente (causando así otra situación de "rodar cabezas").En cuanto a la ciencia de datos en la nube, la mayoría de los proveedores de nubes están trabajando arduamente para desarrollar sus capacidades nativas de aprendizaje automático que permitan a los científicos de datos construir y desplegar modelos de aprendizaje automático fácilmente con datos almacenados en su propia plataforma (Amazon tiene SageMaker, Google tiene BigQuery ML, Microsoft tiene Azure Machine Learning). Pero el conjunto de herramientas todavía está en desarrollo y a menudo incompleto: por ejemplo, BigQuery ML actualmente sólo admite la regresión lineal, la regresión logística binaria y multiclase, K-means clustering y la importación de modelos de TensorFlow. Si usted decide utilizar estas herramientas, tendría que probar sus capacidades a fondo para asegurarse de que hacen lo que usted necesita que hagan.Otro aspecto importante a tener en cuenta al elegir un proveedor en la nube es el bloqueo del proveedor. Si elige una solución de base de datos en la nube de propiedad exclusiva, lo más probable es que no pueda acceder al software o a los datos en su entorno local, y cambiar de proveedor requeriría migrar a una base de datos diferente, lo cual podría ser costoso. Una forma de abordar este problema es elegir proveedores que apoyen las tecnologías de código abierto (aquí está Netflix explicando por qué utilizan software de código abierto). Otra ventaja de utilizar tecnologías de código abierto es que tienden a atraer a una comunidad más amplia de usuarios, lo que significa que le resultaría más fácil contratar a alguien que tenga la experiencia y los conocimientos necesarios para trabajar dentro de su infraestructura. Otra forma de abordar el problema es elegir proveedores externos (como Pivotal Greenplum y Snowflake) que ofrezcan soluciones de bases de datos en la nube utilizando otros grandes proveedores en la nube como backend de almacenamiento, lo que también le permite almacenar sus datos en múltiples nubes si eso se ajusta a las necesidades de su startup.Por último, como se espera que la empresa crezca, habría que poner en práctica una práctica robusta de gestión de la nube para asegurar su nube y evitar la pérdida y fugas de datos, como la gestión del acceso a los datos y la seguridad de las interfaces y las API. También usted querrá implementar las mejores prácticas de gobierno de datos para mantener la calidad de los datos y asegurar que su Data Lake no se convierta en un Data Swamp.Como puede ver, hay mucho más en un proyecto de ciencia de datos empresariales que ajustar los hiperparámetros de sus modelos de machine learning. Esperamos que esta visión general de alto nivel le haya entusiasmado para aprender más sobre la gestión de datos, y tal vez aprender algunas cosas para impresionar a los ingenieros de datos de su oficina.
