Cómo aprender sobre S3 puede ayudarlo a diseñar un datalake ideal en AWS
Si ha tenido alguna conexión con el mundo de los datos, probablemente haya escuchado alguna frase memorable, a menudo peculiar, sobre cuán valiosos son los datos.
Estoy pensando en frases como …
- “Los datos son el nuevo petróleo”.
- “Sin grandes datos, eres sordo y ciego en medio de una autopista”.
- “¡Los datos son el nuevo tocino! “1965
Y, sinceramente, la exageración es merecida. (Excepto que no estoy seguro de estar de acuerdo con eso sobre el tocino …).
Desde una perspectiva analítica, los datos nos ayudan a tomar decisiones informadas sobre los próximos pasos que debemos tomar en nuestros negocios.
Esto puede manifestarse en forma de informes tabulares a los paneles de datos de esta nueva cosa que recibe mucha publicidad llamada aprendizaje automático.
Donde las personas en los “viejos tiempos” se quedaron en la oscuridad sobre cómo tomar las mejores decisiones comerciales, hoy tenemos MUCHOS recursos de datos a nuestra disposición para ayudar.
Utilizando mi catálogo de iconos que he creado para publicaciones de blog anteriores (😃), no exagero cuando digo que todas las cosas en la imagen a continuación pueden producir datos valiosos.
Entonces, dado que todo esto es creando datos, la siguiente pregunta lógica es … ¿cómo hacemos un mejor uso de ellos?
Aquí es donde viene a la mente el concepto de un datalake. Dicho básicamente, un datalake es un espacio unificado para colocar todos sus datos, tanto estructurados como no estructurados. Para construir soluciones analíticas.
Aquí hay una imagen simple que ilustra eso.
Por supuesto, desea administrar este datalake para asegurarse de que no se convierta en un vertedero de datos. La gobernanza de datos es muy importante.
Por lo que querrá asegurarse de administrar cosas como los metadatos, la calidad de los datos y más con las cosas que coloca en este datalake. Eso está fuera del alcance de esta publicación, ¡pero te estaría perjudicando si al menos no lo mencionara!
Para esta publicación en particular, quiero centrarme en lo que significa construir un datalake dentro de Amazon Web Services (AWS).
Dado que las soluciones en la nube están de moda en estos días. Tiene sentido que las personas quieran construir su propio datalake dentro de AWS.
Más específicamente, tendría sentido que la gente quisiera usar el Servicio de almacenamiento simple (S3) de AWS como base para el datalake.
Aquí está el problema … sin ofender a AWS. Pero no creo que hagan un gran trabajo en explicar cómo S3 difiere de los conceptos del “viejo mundo”.
Tengo cuatro certificaciones de AWS, incluida la especialidad de Big Data. Y ninguno de los materiales de estudio que encontré estudiando para esas certificaciones realmente explica muy bien lo que voy a explicar en esta publicación.
Lo que voy a compartir en esta publicación probablemente cambiará radicalmente su pensamiento sobre cómo diseñar adecuadamente su datalake de AWS en S3.
Pero ANTES de entrar en eso, hablemos de esos conceptos del “viejo mundo” …
El mundo local de aislamiento de datos físicos
Antes de la era de AWS y la computación en la nube en general, una empresa realmente tenía la carga de asegurarse de que podían soportar todas sus necesidades de bases de datos con la infraestructura física adecuada.
Literalmente, estoy hablando de comprar estas máquinas gigantes y gigantescas que alguien tendría que conectar para la conectividad de red y mantener con parches de servidor y demás.
No fue fácil (y aún no lo es si actualmente mantiene una infraestructura local) y, por supuesto, fue limitado en el sentido de que una pieza de hardware solo puede contener una cantidad finita de datos. Si deseaba tener más datos, tenía que activar un nuevo hardware.
Si deseaba separar cosas como los datos de prueba de los datos de producción, probablemente también tenía que configurar un nuevo hardware.
Por lo tanto, si tenía datos en un entorno físico que tenían que usarse para fines analíticos en otro entorno físico, probablemente tuvo que copiar esos datos en el nuevo entorno de réplica.
Por supuesto, probablemente también mantuvo un vínculo con el entorno de origen para asegurarse de que las cosas en el entorno de la réplica todavía estén actualizadas.
Esa pequeña imagen de arriba representa la copia de datos de una fuente operativa a una réplica analítica. Por supuesto, sus datos fuente operativos probablemente no se encuentren en un solo entorno.
Es probable que tenga decenas, si no cientos, de esas fuentes operativas donde recopila datos. ¡Eso es mucho movimiento de datos!.
Pero debido a limitaciones físicas literales, esa copia debe hacerse. Los datos no pueden estar literalmente en dos lugares al mismo tiempo, ¿verdad?
Bueno, aquí es donde las cosas se ponen diferentes con AWS y sus cubos S3 …
Cómo los cubos S3 cambian el juego
Recuerda cuando dije que no creo que AWS haga un gran trabajo al explicar todo acerca de cómo se segmentan los cubos S3?.
Si ha tomado alguna de las certificaciones de AWS, incluido Cloud Practitioner, es posible que recuerde que S3 usa un espacio de nombres compartido para los depósitos en todas las cuentas.
Por ejemplo, si creo un depósito en mi cuenta de AWS con el nombre “dkhundley”, usted en su cuenta NO PUEDE crear un depósito llamado “dkhundley”.
Desafortunadamente, eso es todo lo que explican en la mayoría de los materiales de estudio.
¿Pero sabes por qué ese es el caso? ¡No te preocupes si no lo haces! Tal vez una imagen simple ayude a ilustrar esto …
En cierto sentido, ¡no es injusto pensar que AWS en general ya es un datalake GIGANTE! La razón por la que no puedes crear un cubo llamado “dkhundley” es porque ya hay uno presente en este “datalake” masivo que llamamos S3.
La infraestructura física ha sido extraída de nosotros, por lo que, lógicamente hablando, es como si los datos de cada compañía fueran una gran familia feliz.
¡Ahora, no me dejen asustarlos! Con esta lógica, puede llegar a la conclusión natural de que la empresa de otra persona y sus respectivas cuentas de AWS pueden acceder fácilmente a los datos de sus cubos S3.
Afortunadamente, esto NO es cierto. AWS ha sido muy intencional al poner la seguridad adecuada alrededor de todo en AWS, incluidos los depósitos de S3. Por lo que solo puede acceder a los depósitos de S3 si tiene las credenciales adecuadas para hacerlo.
Aquí está el verdadero truco y por qué S3 es tan diferente de infraestructura local (esto es MUY importante): no necesariamente tiene que estar dentro de la misma cuenta que produjo los datos en el depósito S3 para tener acceso a esos datos .
Por ejemplo, si me configura con las credenciales correctas. Puedo ver el contenido de los cubos S3 de su empresa directamente desde mi cuenta personal de AWS, NO SE REQUIERE COPIA FÍSICA .
Así es, amigos. Este es un ENORME cambio de mentalidad de cómo hacemos las cosas en el mundo local.
Cuando enfocamos nuestro tiempo en aislar datos con infraestructura física. Los cambios en la computación en la nube se centran en aislar los datos mediante políticas de seguridad.
Dado que AWS adopta un modelo de pago por uso, desea diseñar cosas de tal manera que maximiza el rendimiento y minimiza los costos.
Teniendo en cuenta que tanto el almacenamiento como el movimiento de datos tienen sus costos asociados, la replicación de datos de un segmento S3 a otro es prohibitiva en cuanto a costos e ineficiente en cuanto al rendimiento.
Del mismo modo, en el contexto de S3, las cuentas de AWS NO aíslan los recursos. ¡No cometas el error de pensar que tienes que copiar datos de un bucket de S3 a otro solo porque es posible que no compartas la misma cuenta que otra en tu empresa!.
Todavía habrá casos de uso específicos en los que desee mover datos entre depósitos S3. Pero si sus datos analíticos ya son buenos para ir en un depósito S3. Es probable que copiarlos físicamente en otro depósito S3 “cuenta de datalake” no es necesario.
Consideraciones de diseño para su datalake de AWS en S3
Espero que lo que hemos cubierto tenga sentido hasta ahora. ¡Vuelve y revísalo varias veces si es necesario!.
Espero que mis ilustraciones simples lo hagan bastante fácil de entender.
Con esta nueva mentalidad a la vista, finalicemos esta publicación con algunas consideraciones de diseño para que tenga en cuenta al establecer su datalake de AWS en S3:
- Prueba frente a datos de producción : Cuando crea un nuevo Solución de TI que realiza cambios en los datos. Es natural querer proteger sus datos de nivel de producción para que no se vean afectados negativamente por esa nueva solución. En la mayoría de las infraestructuras locales. Eso significa aislar físicamente los entornos entre prueba y producción. Es necesario considerar cómo aislar los datos de prueba frente a producción en S3, y se puede hacer de varias maneras. La forma más segura y fácil es aislar completamente los datos en sus propios cubos respectivos. Y puede administrar la organización mediante el uso de estándares de nombres de cubos o etiquetas de AWS. (¡O ambos!) Pero si no desea replicar todo. Hay formas de aislar ciertas cosas dentro de cada cubo. Eso requerirá más trabajo de su parte. Pero si la administración de costos es un factor importante para usted, podría valer la pena.
- Protección de datos confidenciales : Esto se parece mucho a la prueba de aislamiento vs. producción que acabamos de discutir en el punto anterior. Lo más fácil nuevamente es aislar datos confidenciales en su propio depósito y realmente bloquearlo con muchas medidas de seguridad. Pero nuevamente, es posible bloquear datos confidenciales con datos no confidenciales en el mismo depósito. Probablemente no me gustaría meterme con la molestia de eso, pero ustedes, amigos.
- Data Lake vs. Data Warehouse : Seamos claros aquí … un datalake NO es sinónimo de un almacén de datos. Un almacén de datos generalmente contiene solo datos estructurados o semiestructurados. Mientras que un datalake contiene todo el shebang: estructurado, semiestructurado y no estructurado. Los datalakes a menudo coexisten con los depósitos de datos, donde los depósitos de datos a menudo se construyen sobre los datalakes. En términos de AWS, la implementación más común de esto es usar S3 como el datalake y Redshift como el almacén de datos. Por supuesto, hay más de una forma de desollar a un gato en AWS, así que no piense que solo está limitado a Redshift para sus necesidades de almacenamiento.
- Gestión y gobierno de datos : Ya pasé por alto esta vez en esta publicación. Pero creo que vale la pena mencionarlo nuevamente. Un datalake puede convertirse en un volcado de datos MUY rápidamente sin una gestión y gestión de datos adecuada. Cuando diseña su datalake de AWS en S3. AWS ofrece servicios como AWS Glue para ayudarlo a administrar cosas como un Catálogo de datos. Pero le exige mucho descubrir esas cosas por sí mismo. Si realmente desea ayuda adicional en este espacio. También hay muchos proveedores de terceros que proporcionarán una gran cantidad de oomph aquí. (Oomph es un término técnico. 😂) Dependiendo de las necesidades de su empresa. Podría valer la pena esa inversión adicional para traer un proveedor externo que lo ayude a organizar su datalake. (No estoy demasiado familiarizado con él, pero AWS también ofrece un servicio llamado Formación de lake que también vale la pena considerar).
- Consumo de lake: Las cosas pueden obtener un poco complicado cuando quieres construir soluciones analíticas sobre tu datalake. Mientras que las cuentas de AWS no necesariamente importan al poner datos en un datalake, sí importan más para sus soluciones de consumo. Se pueden extraer varias cuentas del mismo datalake. Pero debe asegurarse de que todas tengan las credenciales de seguridad adecuadas para acceder a los depósitos de S3 subyacentes. Y lo más probable es que no desee dar acceso general a todos por cada segmento S3 en su datalake. Una vez más, aquí es donde la gestión de datos y la gobernanza son extremadamente importantes. Por lo que nuevamente puede valer la pena aprovechar esas mismas herramientas de gobernanza de terceros para ayudar a dividir las credenciales de seguridad de manera apropiada.
¡Muy bien, eso cierra esta publicación! Este era un concepto bastante extraño para mí hasta hace poco, así que no te desanimes si no lo entendiste por completo, incluso si tienes una certificación AWS.