BIG DATA... ¿Qué es?

 

Últimamente escucho muy a menudo en el trabajo a la gente hablar  sobre "Big Data", pero ¿Qué es Big Data y porqué se ha vuelto tan importante? debido a la tendencia en el avance de la tecnología que ha abierto las puertas hacia un nuevo enfoque de entendimiento y toma de decisiones, la cual es utilizada para describir enormes cantidades de datos que tomaría demasiado tiempo y sería muy costoso cargarlos a un base de datos relacional para su análisis. De tal manera que, el concepto de Big Data aplica para toda aquella información que no puede ser procesada o analizada utilizando procesos o herramientas tradicionales.

Es importante entender que las bases de datos convencionales son una parte importante y relevante para una solución analítica. De hecho, se vuelve mucho más vital cuando se usa en conjunto con la plataforma de Big Data.

¿Generamos tanta información?

Los seres humanos estamos creando y almacenando información constantemente y cada vez más en cantidades astronómicas, imaginemos la cantidad de información que genera un banco en un solo día, transacciones, clientes nuevos, prestamos, etc.

 

 Y..¿Qué información es la que se debe analizar?, en este caso la mejor pregunta sería ¿Qué problema intentamos o queremos resolver?.

Si bien sabemos que existe una amplia variedad de tipos de datos a analizar, una buena clasificación nos ayudaría a entender mejor, Big Data tiene  tipos de información, los muestro a continuación:

 

En cuanto a la utilidad, he leído muchos post en los que indican que Big Data es muy útil en el entorno empresarial, de manufactura, retails, educación e incluso investigación.

Para finalizar este post quiero concluir lo siguiente , como todos los que trabajamos en sistemas podemos notar que la naturaleza de la información actualmente es diferente a la información en el pasado. Ahora abundan los sensores, micrófonos, cámaras, escáneres médicos, imágenes, etc. en nuestras vidas, los datos generados a partir de estos elementos serán dentro de poco el segmento más grande de toda la información disponible.
El uso de Big Data ha ayudado a los investigadores a descubrir cosas que les podrían haber tomado años en descubrir por si mismos sin el uso de estas herramientas, debido a la velocidad del análisis. La importancia del dato para el negocio, saber que datos son los que se deben analizar, es fundamental. Tanto que ya se empieza a hablar del científico de datos, un profesional con perfil científico, tecnológico...y visión de negocio.

Les recomiendo investigar del tema, es súper interesante.

Saludos

Referencias:
https://es.wikipedia.org/wiki/Big_data
http://www.sas.com/en_th/insights/big-data/what-is-big-data.HTML
http://www.eleconomista.es/tecnologia/noticias/5578707/02/14/La-moda-del-Big-Data-En-que-consiste-en-realidad.html
http://thinking.netezza.com/blog/big-data-data-velocity-discussion
 

¿Por qué servicios web basados en SOAP o REST?

 

No es mi intención hacer una comparativa entre SOAP y REST, lo que intento es destacar los objetivos y características comunes del desarrollo de servicios web basados en SOAP o REST.

SOAP y REST son siglas asociadas a estándares para el diseño y desarrollo de web services o servicios RESTful. El uso más común que se suele dar a estos servicios es el de integrar diferentes sistemas o componentes de una o varias plataformas. La interacción se consigue mediante el intercambio de mensajes entre sistemas.

Es muy común ver cómo se emplean tanto SOAP como REST para exponer parte de la funcionalidad (o recursos) de diferentes aplicativos. En este caso exponen recursos a través de un API REST (imagino que por sencillez y porque los requisitos lo permiten) para que otros sistemas puedan interoperar con ellos. Esta misma filosofía es aplicable dentro de una plataforma empresarial.

 

Puede ser bastante común crear un web service cuya lógica funcionalidad sea requerida por distintos aplicativos o componentes dentro de una plataforma. Además, podríamos tener un servicio de más alto nivel para ser consumido desde diferentes frontales: ejemplo, una aplicación web y una aplicación móvil.

 

 

Y un ejemplo clásico en el uso de servicios web es el de integrar diferentes sistemas o plataformas como puede ser el caso de diferentes departamentos dentro de una organización o diferentes organizaciones.

 

La gran ventaja que ofrecen estas alternativas es la flexibilidad a la hora de elegir la tecnología con la que queremos implementar la lógica de negocio que queremos exponer. De esta forma, podemos comunicar diferentes sistemas o componentes independientemente de la tecnología con la que están implementados.

 

Saludos

 

 

Referencias:

https://es.wikipedia.org/wiki/Representational_State_Transfer

http://www.advogato.org/article/464.HTML

http://careerride.com/SOAP-What-is-SOAP.aspx

https://es.wikipedia.org/wiki/Simple_Object_Access_Protocol

 

 

10 Mejores Prácticas de RESTful API

Me llamó la atención el estándar RESTful hace poco cuando leí la presentación "RESTful API Design", por lo que investigué acerca de las mejores prácticas que quiero compartir...

 

1. Utilizar sustantivos, no verbos

 

Para una fácil comprensión utilizaré esta estructura para cada recurso:

Resource	GET read	POST create	PUT update	DELETE
/cars	Returns a list of cars	Create a new ticket	Bulk update of cars	Delete all cars
/cars/711	Returns a specific car	Method not allowed (405)	Updates a specific ticket	Deletes a specific ticket

 

No usar verbos como:

/getAllCars
/createNewCar
/deleteAllRedCars

 

2. El método GET y los parámetros de consulta no deben alterar el estado

 

Usar los métodos PUT, POST y DELETE en lugar del método GET para alterar el estado.

No usar GET para cambios de estado:
GET /users/711?activate
GET /users/711/activate

 

3. Usar sustantivos en plural

 

No hacer un mix de estos. Sólo utilizar sustantivos en plural para todos los recursos.

/cars en vez de /car
/users en vez de /user
/products en vez de /product
/settings en vez de /setting

 

4. Usar sub-recursos para las relaciones

 

Si un recurso está relacionado con otro, usar sub-recursos.

 

GET /cars/711/drivers/ Retorna una lista de conductores para el carro 711
GET /cars/711/drivers/4 Retorna el conductor #4 para el carro 711

 

5. Usar los encabezados HTTP para los formatos de serialización

 

Ambos, cliente y servidor, necesitan saber qué formato se utiliza para la comunicación. El formato tiene que ser especificado en el encabezado HTTP.

Content-Type define el formato de solicitud.
Accept define una lista de formatos de respuesta aceptables.

 

6. Usar HATEOAS

 

Hypermedia as the Engine of Application State es un principio que los enlaces de hipertexto se deben utilizar para crear una mejor navegación a través del API.

 

 7. Proporcionar filtrado, clasificación, selección de campos y de paginación para colecciones

8. Versiona tu API

La versión de la API obligatoria. Utilice un número ordinal simple y evitar la notación de puntos tales como 2.5.

Para el ejemplo, estamos utilizando la dirección URL de la API de control de versiones que empiecen con la letra "v"

/blog/api/v1

9. Controlar errores con códigos de estado HTTP

El estándar HTTP proporciona más de 70 códigos de estado para describir los valores de retorno. No todos  los necesitamos, perose debe utilizar al menos la cantidad de 10.

10. Habilitar  el overriding HTTP method

Algunos servidores proxy sólo admiten métodos POST y GET. Para soportar una API REST con estas limitaciones, la API necesita una forma de reemplazar el método HTT

Se debe usarla personalización del encabezado HTTP X-HTTP-Method-Override en el método POST.


Espero les  sirva...

 

Referencias
http://www.slideshare.net/apigee/restful-api-design-second-edition
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
http://www.tutorialspoint.com/restful/restful_introduction.htm
https://es.wikipedia.org/wiki/Representational_State_Transfer
 

¿CUÁLES SON LAS VENTAJAS Y DESVENTAJAS DE FILE TRANSFER?

Hace unos días en el curso de Desarrollo de Sistemas Distribuidos nos encargaron investigar acerca de los estilos de integración del Enterprise Integration Patterns, decidí investigar sobre el File Transfer ya que por muchos años trabajé en el área de DWH de un banco muy conocido aquí. Siempre nos llegaban requerimientos donde cierto aplicativo requería que se almacene en DWH un dato nuevo, esto significaba la modificación del proceso en COBOL que obtenía la broad del aplicativo y la cargaba, y el o los procesos que obtenían este archivo, transformaban la data y lo cargaban a DWH.

 

Me pregunto, cómo podría un banco, sabiendo que en muchos casos la información que se transfería era crítica y confidencial, tener algunas falencias en sus procesos donde tienen la necesidad de transferir un archivo de una aplicación a otra, luego de analizar las ventajas y desventajas de este estilo de integración que voy a compartir con ustedes, intentaré identificar las mejoras en los procesos mencionas de este banco en DWH.

A  continuación, vamos a empezar mencionando las desventajas de la transferencia de archivos en la integración de aplicaciones empresariales:

Desventajas:

Escalabilidad

Cuando hablamos de escalabilidad a la capacidad de un sistema para adaptarse a los cambios sin perder calidad, entonces ¿Qué pasa si el volumen de datos crece sustancialmente después de que los desarrolladores pasen a producción un proceso para la transferencia de archivos? Esto ocasionaría que la transferencia del archivo tome más tiempo que el esperado (en el mejor de los casos) o que la transferencia falle. Y ¿Qué pasa si la información era necesaria para generar un reporte regulatorio? Esto haría mucho más crítico este problema. En cualquiera de los dos casos, se requerirá un replanteamiento de la solución para el manejo del aumento de las cargas de datos.

Adaptabilidad

¿Qué decir adaptabilidad? Los usuarios solicitarán modificaciones después de implementar un proceso para la transferencia de archivos, ¿Qué tan sensible será nuestro proceso para realizar estos cambios? en muchos casos esta flexibilidad insuficiente ya que estos procesos suelen ser muy personalizados.

Seguridad

Cuando hablamos de seguridad, en especial si la información confidencial es deseable o incluso necesario usar procedimientos para la encriptación o cifrado de la información para asegurar la el cumplimiento de la seguridad de información. Si los desarrolladores no toman en cuenta que se requieren esas medidas o tiene problemas para su aplicación, sus procesos podrían no cumplir con los protocolos de seguridad de la empresa.

Ventajas:

Integración

Esto significa que el sistema receptor no necesita saber si el sistema de envío es un mainframe, aplicaciones cliente-servidor o aplicación web. La transferencia de archivos proporciona un método simple pero potente para lograr integración de aplicaciones.

Estandarización

Hoy en día, todos los lenguajes de programación proporcionan APIs para abrir archivos, procesarlos y cargarlos. No se requiere dispositivos o programas especiales para recuperar datos de archivos. Actualmente, los formatos más de moda son XML y JSON, estos pueden requerir componentes adicionales de software para procesar las información.

 

 

Como mencioné anteriormente, iba a comentar acerca de las falencias y porque no, las cosas buenas, que luego de la investigación que realice pude identificar en el banco en el que trabajé. En primer lugar, en cuanto a la escalabilidad, para aquellos procesos nuevos, se reservaban campos adicionales sin uso para que en caso se necesiten, la modificación sea menor y con esto su costo se reduciría, sin embargo, los procesos antiguos para la transferencia de archivos no tenían escalabilidad, por lo que los cambios por mas mínimos suponían la revisión de todo su proceso de transferencia. Por otro lado, hablando de seguridad, no vi procesos de encriptamiento o cifrado, podría suponer que tienen otros mecanismos de seguridad, pero no podría asegurarlo. Por ultimo, acerca de la estandarización, todos sus procesos tienen un estándar de construcción, que usar, como usarlo, etc; esto también supone que los desarrolladores conocen y hay documentación del flujo a seguir para transferencia de archivos entre aplicaciones.

 

 Referencias:
http://www.enterpriseintegrationpatterns.com/patterns/messaging/FileTransferIntegration.HTML
https://technicalmumbojumbo.wordpress.com/2012/10/04/enterprise-integration-pattern-file-transfer-eai/
https://en.wikipedia.org/wiki/Enterprise_Integration_Patterns#Integration_Styles
https://www.attachmate.com/blogs/datainmotion/pros-and-cons-file-transfer-enterprise-application-integration/