El día de hoy leí el siguiente artículo "Cómo acelerar el flujo de datos entre Databricks y SAS" y deseo compartir un resumen del mismo. El artículo explora cómo mejorar la eficiencia del flujo de datos entre Databricks y SAS. Enumera varios métodos para lograrlo: 1. **Optimización de Datos en Databricks:** - Utiliza las capacidades de Spark en Databricks para procesar y transformar los datos antes de enviarlos a SAS. - Recomienda usar las funciones de Spark para filtrar, agregar y transformar datos antes de pasarlos a SAS. 2. **Reducción de la sobrecarga en SAS:** - Se sugiere minimizar el procesamiento en SAS para evitar sobrecargas. - Aplica las transformaciones y cálculos complejos en Databricks antes de enviar los datos a SAS. 3. **Uso de múltiples conexiones y conjuntos de datos:** - Para procesos intensivos de E/S, se aconseja utilizar múltiples conexiones y dividir los datos en conjuntos más pequeños. - Esto puede acelerar el tiempo de procesamiento al paralelizar la lectura y escritura de datos entre Databricks y SAS. 4. **Mejoras en la eficiencia de los algoritmos:** - Aconseja evaluar y ajustar los algoritmos utilizados en SAS para mejorar la eficiencia. - Puede ser útil utilizar algoritmos optimizados para grandes volúmenes de datos. En general, el artículo enfatiza la importancia de aprovechar las capacidades de procesamiento distribuido de Spark en Databricks para preparar y optimizar los datos antes de enviarlos a SAS, lo que puede mejorar significativamente el rendimiento y la eficiencia del flujo de datos entre estas dos plataformas. **Fuente:** [How to Speed Up Data Flow Between Databricks and SAS](https://lnkd.in/eRWpjqck)
Publicación de Jorge Rodríguez M.
Más publicaciones relevantes
-
Un Lakehouse es una arquitectura de datos que combina elementos de un data warehouse (almacén de datos) y un data lake (lago de datos). Su objetivo es aprovechar lo mejor de ambos mundos: la estructura y el rendimiento de los almacenes de datos con la flexibilidad y la escalabilidad de los lagos de datos. Características principales de un Lakehouse: 1. Almacenamiento de datos estructurados y no estructurados: Un Lakehouse puede manejar datos tabulares como un data warehouse, así como datos no estructurados como videos, imágenes, archivos de texto, etc. 2. Motor de consulta unificado: Permite ejecutar consultas SQL tanto sobre datos estructurados como no estructurados. 3. Optimización de rendimiento: Utiliza técnicas como el almacenamiento en caché, la optimización de consultas y el almacenamiento columnar para mejorar el rendimiento de las consultas. 4. Escalabilidad: Al igual que un data lake, puede escalar horizontalmente para manejar grandes volúmenes de datos. 5. Mantenimiento de transacciones y consistencia: Implementa características ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad), permitiendo transacciones seguras y consistencia de los datos. 6. Compatibilidad con herramientas de análisis y machine learning: Facilita la integración con herramientas de análisis de datos y aprendizaje automático, permitiendo una fácil explotación de los datos almacenados. En resumen, un Lakehouse busca proporcionar una plataforma única y coherente para el almacenamiento y análisis de datos, reduciendo la necesidad de mover los datos entre diferentes sistemas y simplificando la arquitectura de datos.
Announcing General Availability of Lakehouse Federation
databricks.com
Inicia sesión para ver o añadir un comentario.
-
Interesante comparación aunque un DAG no puede compararse con ETL. Lo que me parece más interesante es como D.bricks continúa evolucionando para unir el OPS (data & ML) https://lnkd.in/dsXScWqs
What is the best tool: Apache Airflow, Azure Data Factory, or Databricks Workflows?
medium.com
Inicia sesión para ver o añadir un comentario.
-
DatabricksIQ impulsado por Liquid Clustering sintoniza inteligentemente y determina el diseño de datos adecuado para ti, garantizando que tus datos estén siempre optimizados tanto para el rendimiento de lectura como de escritura. Elimina las molestias de la partición estilo Hive, escala automáticamente y reduce la sobrecarga de mantenimiento de tablas. #DeltaLake #LiquidClustering
Announcing General Availability of Liquid Clustering
databricks.com
Inicia sesión para ver o añadir un comentario.
-
Este es un tema que nos va a perseguir durante todo este año. Es una buena nota para tener un parametro para aquellos que evaluan mover synapse a fabric. Igualmente esto es resolucion de consultas y potencia. hay todo un cambio de procesos y modo de trabajo que tambien va a requerir una alta dosis de ajustes para que operen de forma correcta, sobre todo que la mayoria de las implementaciones de sypase con SQL dedicado no tienen estructuras medalion. https://lnkd.in/dQ5CJ2gq
Mapping Azure Synapse dedicated SQL pools to Fabric data warehouse compute | Microsoft Fabric Blog | Microsoft Fabric
blog.fabric.microsoft.com
Inicia sesión para ver o añadir un comentario.
-
Arquitectura de Big Data La arquitectura de Big Data define cómo se recopilan, almacenan, procesan y analizan los datos. A continuación, se describen los componentes de una arquitectura típica de Big Data: 1. Fuentes de Datos: 1.1. Datos Estructurados: Datos provenientes de bases de datos, hojas de cálculo o API. 1.2. Datos No Estructurados: Publicaciones en redes sociales, imágenes, archivos de video y datos de sensores IoT. 1.3. Datos Semiestructurados: Correos electrónicos, archivos XML y JSON. 2. Almacenamiento de Datos: 2.1. Hadoop Distributed File System (HDFS): Componente central de Hadoop para almacenar grandes volúmenes de datos. 2.2. Bases de Datos NoSQL: Ejemplos incluyen Cassandra, MongoDB y HBase, usadas para datos no estructurados y semiestructurados. 2.3. Data Lakes: Repositorios centrales donde se pueden almacenar datos estructurados y no estructurados, a menudo en su formato original. 3. Procesamiento de Datos: 3.1. Procesamiento por Lotes: Utilizado para procesar grandes volúmenes de datos periódicamente. Herramientas: Apache Hadoop MapReduce y Apache Spark. 3.2. Procesamiento en Tiempo Real: Procesamiento continuo de datos en tiempo real o casi en tiempo real. Herramientas: Apache Kafka, Apache Flink y Apache Storm. 4. Análisis de Datos: 4.1. Análisis Descriptivo: Describe lo que ha ocurrido. 4.2. Análisis Predictivo: Predice eventos futuros en base a datos históricos. 4.3. Análisis Prescriptivo: Recomienda acciones basadas en modelos predictivos. 5. Visualización de Datos: Herramientas como Tableau, Power BI y D3.js ayudan a transformar datos en bruto en insights visuales que facilitan la toma de decisiones. Para conocer más acerca de estas tecnologías habilitantes puedes seguir nuestras publicaciones Big Data | Arquitectura Big Data | Industrias que aprovechan Big Data | Casos de uso de Big Data | Big Data Cheat Sheet https://lnkd.in/edaV8awG https://lnkd.in/eQing5M2 https://lnkd.in/eXPG4Fec https://lnkd.in/eYVCH3mC Nicolas Gutierrez Larraguibel
Inicia sesión para ver o añadir un comentario.
-
🔄💡 Procesos ETL: La columna vertebral del Data Engineering 💡🔄 ¿Quieres saber cómo manejar grandes volúmenes de datos de manera eficiente? 🚀 Los procesos ETL (Extract, Transform, Load) son esenciales para garantizar que los datos se integren correctamente en un entorno analítico. 1️⃣ Extract (Extracción): 🛠️ En esta etapa, los datos se extraen de múltiples fuentes heterogéneas como bases de datos relacionales (SQL), APIs, archivos CSV o incluso plataformas en la nube. La clave es obtener los datos de manera eficiente, minimizando la carga en los sistemas fuente. 2️⃣ Transform (Transformación): 🔄 Aquí es donde ocurre la "magia" ✨. Los datos crudos pasan por una serie de transformaciones: limpieza (eliminación de duplicados y valores faltantes), agregación, estandarización de formatos y enriquecimiento con otros conjuntos de datos. Este paso garantiza que los datos sean consistentes y útiles para el análisis. 3️⃣ Load (Carga): 📥 Finalmente, los datos transformados se cargan en su destino final, que suele ser un Data Warehouse 🏢 o un Data Lake 🌊. En esta etapa, es crucial garantizar que la carga sea rápida y escalable, especialmente cuando trabajamos con grandes volúmenes de datos en tiempo real. 🔑 Tip técnico: Para optimizar un proceso ETL, herramientas como Apache Nifi, Talend o Airflow permiten la automatización y monitorización de pipelines, asegurando un flujo de datos eficiente y sin errores. 💼 ¿Estás implementando ETL en tus proyectos? Comparte tus experiencias y retos con la comunidad. 🚀💡 #ETL #DataEngineering #BigData #DataPipelines
Inicia sesión para ver o añadir un comentario.
-
Interesante resumen de la evolución de los lakehouse + toolkits + cómo mezclarlo con modern data stack. Muy recomendable para ver cómo acelerar tu Arq de datos para entregar valor (qué en el fondo, de eso se trata). https://lnkd.in/dRRXAsc8
Data Lakehouses, Post-Modern Data Stacks and Enabling Gen AI: The Rittman Analytics Guide to…
blog.rittmananalytics.com
Inicia sesión para ver o añadir un comentario.
-
🚀 Unifying Parameters Across Databricks 🚀 #Databricks anunció el 17 de septiembre el soporte para marcadores de parámetros nombrados en el editor SQL. 🎉 Esta potente función te permite escribir código SQL parametrizado que puedes copiar y ejecutar directamente en dashboards o notebooks, sin cambios de sintaxis. 💡 Este es un hito importante hacia la unificación de parámetros en consultas, notebooks y dashboards, facilitando más que nunca la optimización de los flujos de trabajo en SQL. ¿Cómo funciona?🤔 Los marcadores de parámetros nombrados te permiten sustituir valores en tus consultas en tiempo de ejecución, ideal para filtrar datos por fechas, categorías de productos, y más. ✅ Tipado fuerte y seguro: Separar los valores de las declaraciones SQL ayuda a prevenir ataques de inyección SQL. ✅ Fácil de usar: Solo necesitas agregar dos puntos (:) antes del nombre del parámetro (por ejemplo, :nombre_parametro). ✅ Flexible: Úsalo en consultas, dashboards, flujos de trabajo y APIs. 📢 Requiere: Databricks Runtime 13.3 y versiones posteriores 👉 Casos de uso comunes: 🔸 Agregar un rango de fechas a tu consulta: ✏️ SELECT * FROM samples.nyctaxi.trips WHERE tpep_pickup_datetime BETWEEN :start_date AND :end_date 🔸 Seleccionar o crear un catálogo, esquema y tabla de manera dinámica: ✏️ SELECT * FROM IDENTIFIER(:catalog || '.' || :schema || '.' || :table) 🔸 Parametrizar cadenas para formatear salidas como números de teléfono: ✏️ SELECT format_string("(%d) %d", :area_code, :phone_number) As phone_number 🔸Define dos marcadores de parámetros: descuento: Un valor de tipo INTEGER con valor 10. precio: Un valor de tipo DOUBLE con valor 50.0. En este caso, se usa precio varias veces, mientras que descuento se usa una vez. ✏️ DECLARE consulta ='SELECT :precio - :precio * :descuento / 100 AS precio_con_descuento'; ✏️ EXECUTE IMMEDIATE consulta USING10 AS descuento, 50.0 AS precio; Más info en: https://lnkd.in/dfAytq_b
Inicia sesión para ver o añadir un comentario.
-
Los data lakes … Siguiendo con la línea de los patterns de Erich Gamma, el data lake es uno muy común que voy a resumir en base a mi experiencia de hacer proyectos de ML donde hubo (o debería haber habido) data lakes. Para hacerla corta, son necesarios en general. Las empresas suelen tener mucha data, y a veces juntarla es primordial para lograr un dataset consolidado con info de varias fuentes. Si encima la empresa tiene la idea de hacer 20 proyectos de ML, tener un DL pasa a ser estratégico. Aclaremos un poco que quiero decir con un data lake. Me gusta el enfoque de Fowler. Véanlo en: https://lnkd.in/dXrpPBpx . Se popularizó mucho cuando llegó el Hadoop, antes de la consolidación de Amazon y Google como Clouds. En conclusión, un data lake es un repositorio barato de data cruda. Cuando las palabras se ponen de moda, a veces cuesta distinguirlas, como pasa ahora con AI y ML. En el caso del data lake, creo que conviene separarlo del concepto de data warehouse así evitamos confusiones. A medida que "intervenimos" en un data lake nos alejamos de su concepto. Les paso unas recetas de rápida aplicación para estar atentos a cuando nuestro data lake va perdiendo identidad: * Si tiene elaborados permisos de seguridad y controles de acceso. * Si es MUY caro. * Si tiene muchas capas de procesamiento y/o ETLs complicados. * Si está excesivamente ordenado. * Si tiene muy pocas tablas y con pocos registros. * Si los índices están optimizados para acceso. * Si solo tiene info estructurada (tablas) * Si tiene info solamente una fuente. * etc. El data lake debería ser más un punto de partida que destino para empezar a lidiar con los issues de gobernanza, calidad y modelado de forma ágil. En estos años vi muchos clientes que hicieron esfuerzos tremendos en armar un data lake para sacarle muy poco provecho. Por ahí hay que tratar de buscar un punto medio en el dilema explore-exploit. Por último y para no aburrir más, Fowler acuñó el concepto: Datensparsamkeit, que básicamente es la tensión opuesta. Para darles una idea ... tiene que ver con poner en el data lake lo que necesitás siendo austero, y en consecuencia minimizar los issues que arriba mencione. Para pensar, no? Esta contradicción la veo positiva (como todas) ya que nos anima a pensar en nuestro data lake. Remate, si no es un data lake, no le digamos data lake. 😀
bliki: DataLake
martinfowler.com
Inicia sesión para ver o añadir un comentario.
-
🚀 PySpark para ETL: Potencia tus Procesos de Datos 🔄📊 En IA-Solutions, creemos en el poder de PySpark para transformar tus procesos de ETL (Extract, Transform, Load). 🛠️ Con la capacidad de manejar grandes volúmenes de datos y proporcionar pipelines robustos y escalables, PySpark es la herramienta ideal para tu estrategia de Data Engineering. 1. Procesamiento de Datos a Gran Escala: PySpark maneja conjuntos de datos masivos distribuidos a través de clústeres, permitiendo una escalabilidad horizontal sin precedentes. Utilizamos Apache Spark en conjunto con Hadoop para almacenamiento distribuido, lo que nos permite procesar terabytes de datos en minutos en lugar de horas. ⚡ 2. Optimización del Rendimiento: Utilizamos las capacidades de paralelismo y optimización de PySpark para mejorar el rendimiento de tus pipelines. Con PySpark SQL, optimizamos las consultas y el manejo de datos estructurados, reduciendo los tiempos de procesamiento en un 50% comparado con soluciones tradicionales. 🚀 3. Integración con Herramientas Modernas: Integramos PySpark con herramientas como Apache Kafka para la ingestión en tiempo real y Apache Airflow para la orquestación de workflows. Esto proporciona pipelines de datos en tiempo real con orquestación automática, utilizando Apache Kafka y Apache Airflow. 🔄 4. Flexibilidad en la Transformación de Datos: PySpark permite la transformación compleja de datos utilizando su API de DataFrame, que ofrece simplicidad y eficiencia. Realizamos transformaciones complejas y limpiezas de datos de manera eficiente con la API de DataFrame de PySpark. 📊 5. Manejo de Diferentes Fuentes de Datos: Con PySpark, conectamos múltiples fuentes de datos, como bases de datos SQL, NoSQL, y sistemas de archivos distribuidos. Utilizamos conectores nativos de PySpark para diversas fuentes de datos, simplificando la consolidación de datos de múltiples orígenes en una sola pipeline. 🌐 En IA-Solutions, estamos listos para ayudarte a construir y optimizar tus pipelines de datos con PySpark. Desde la ingesta de datos hasta la entrega, nuestra experiencia te asegura un proceso eficiente y escalable. #dataengineering #etl #pyspark #bigdata #datapipelines #apachespark #realtimedata #datatransformation #ia-solutions #techinnovation #chile #mexico #colombia #brasil 🌐🔄📈📊🛠️⚙️💡📉🔍🚀
Inicia sesión para ver o añadir un comentario.