El problema de los silos de datos es como la artritis para las empresas en línea porque casi todo el mundo la contrae a medida que envejece. Las empresas interactúan con los clientes a través de sitios web, aplicaciones móviles, páginas H5 y dispositivos finales. Por una razón u otra, resulta complicado integrar los datos de todas estas fuentes. Los datos permanecen donde están y no pueden interrelacionarse para análisis posteriores. Así es como se forman los silos de datos. Cuanto más crezca su negocio, más fuentes de datos de clientes diversificadas tendrá y más probabilidades habrá de quedar atrapado en silos de datos. Esto es exactamente lo que le pasa a la compañía de seguros de la que voy a hablar en este post. En 2023, ya habrán atendido a más de 500 millones de clientes y firmado 57 mil millones de contratos de seguros. Cuando comenzaron a construir una plataforma de datos de clientes (CDP) para acomodar ese tamaño de datos, utilizaron múltiples componentes. Silos de datos en CDP Como la mayoría de las plataformas de datos, su CDP 1.0 tenía un canal de procesamiento por lotes y un canal de transmisión en tiempo real. Los datos sin conexión se cargaron a través de trabajos de Spark en Impala, donde se etiquetaron y dividieron en grupos. Mientras tanto, Spark también lo envió a NebulaGraph para el cálculo de OneID (elaborado más adelante en esta publicación). Por otro lado, Flink etiquetó los datos en tiempo real y luego los almacenó en HBase, listos para ser consultados. Eso llevó a una capa de cálculo con muchos componentes en el CDP: Impala, Spark, NebulaGraph y HBase. Como resultado, las etiquetas fuera de línea, las etiquetas en tiempo real y los datos de gráficos se dispersaron en varios componentes. Integrarlos para servicios de datos adicionales resultó costoso debido al almacenamiento redundante y la transferencia de datos voluminosa. Es más, debido a discrepancias en el almacenamiento, tuvieron que ampliar el tamaño del clúster CDH y del clúster NebulaGraph, lo que aumentó los costos de recursos y mantenimiento. CDP basado en Apache Doris Para CDP 2.0, deciden introducir una solución unificada para limpiar el desorden. En la capa de cálculo de CDP 2.0, realiza cálculo y almacenamiento de datos tanto en tiempo real como fuera de línea. Apache Doris Para ingerir , utilizan el método . Su prueba de ingesta de 30 subprocesos muestra que puede realizar más de 300.000 upserts por segundo. Para cargar , utilizan una combinación de y Stream Load. Además, en los informes en tiempo real, donde necesitan extraer datos de múltiples fuentes de datos externas, aprovechan la función para . datos sin conexión Stream Load datos en tiempo real Flink-Doris-Connector de catálogo múltiple consultas federadas Los flujos de trabajo analíticos del cliente en este CDP son así. Primero, clasifican la información del cliente; luego colocan etiquetas a cada cliente. Según las etiquetas, dividen a los clientes en grupos para un análisis y una operación más específicos. A continuación, profundizaré en estas cargas de trabajo y le mostraré cómo Apache Doris las acelera. Una identificación ¿Te ha pasado esto alguna vez cuando tienes diferentes sistemas de registro de usuarios para tus productos y servicios? Puede recopilar el correo electrónico del ID de usuario A de la página web de un producto y luego el número de seguro social del ID de usuario B de otra. Luego descubre que el ID de usuario A y el ID de usuario B en realidad pertenecen a la misma persona porque tienen el mismo número de teléfono. Por eso surge OneID como idea. Se trata de agrupar la información de registro de usuarios de todas las líneas comerciales en una tabla grande en Apache Doris, ordenarla y asegurarse de que un usuario tenga un OneID único. Así descubren qué datos de registro pertenecen a un mismo usuario, aprovechando las funciones de Apache Doris. Servicios de etiquetado Este CDP contiene información de , que provienen de más de y están adjuntas a más de en total. 500 millones de clientes 500 tablas de origen 2000 etiquetas Por puntualidad, las etiquetas se pueden dividir en etiquetas en tiempo real y etiquetas fuera de línea. Apache Flink calcula las etiquetas en tiempo real y las escribe en la tabla plana de Apache Doris, mientras que Apache Doris calcula las etiquetas fuera de línea a medida que se derivan de la tabla de atributos del usuario, la tabla de negocios y la tabla de comportamiento del usuario en Doris. Estas son las mejores prácticas de la empresa en etiquetado de datos: 1. Etiquetas sin conexión: Durante los picos de escritura de datos, una actualización completa podría fácilmente provocar un error de OOM, dada la enorme escala de datos. Para evitar eso, utilizan la función de Apache Doris y habilitan . Esto reducirá significativamente el consumo de memoria y mantendrá la estabilidad del sistema durante la carga de datos. INSERT INTO SELECT la actualización parcial de la columna set enable_unique_key_partial_update=true; insert into tb_label_result(one_id, labelxx) select one_id, label_value as labelxx from ..... 2. Etiquetas en tiempo real: Las actualizaciones de columnas parciales también están disponibles para etiquetas en tiempo real, ya que las etiquetas en tiempo real se actualizan a diferentes ritmos. Todo lo que se necesita es establecer en . partial_columns true curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load 3. Consultas puntuales de alta concurrencia: Con su tamaño comercial actual, la empresa recibe solicitudes de consulta de etiquetas a un nivel de simultaneidad de más de 5000 QPS. Utilizan una combinación de estrategias para garantizar un alto rendimiento. En primer lugar, adoptan una para la precompilación y ejecución previa de SQL. En segundo lugar, ajustan los parámetros de Doris Backend y las tablas para optimizar el almacenamiento y la ejecución. Por último, habilitan como complemento del Apache Doris orientado a columnas. declaración preparada el caché de filas Ajuste los parámetros de Doris Backend en : be.conf disable_storage_row_cache = false storage_page_cache_limit=40% Ajuste los parámetros de la tabla al crearla: enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true 4. Cálculo de etiquetas (unirse): En la práctica, muchos servicios de etiquetado se implementan mediante uniones de varias tablas en la base de datos. A menudo se trata de más de diez mesas. Para un rendimiento informático óptimo, adoptan la estrategia en Doris. de grupo de colocación Agrupación de clientes El proceso de agrupación de clientes en CDP 2.0 es el siguiente: Apache Doris recibe SQL del servicio de atención al cliente, ejecuta el cálculo y envía el conjunto de resultados al almacenamiento de objetos S3 mediante SELECT INTO OUTFILE. La empresa ha dividido a sus clientes en 1 millón de grupos. La tarea de agrupación de clientes que solía tardar en finalizar ahora solo necesita . 50 segundos en Impala 10 segundos en Doris Además de agrupar a los clientes para un análisis más detallado, a veces realizan análisis en dirección inversa. Es decir, dirigirse a un determinado cliente y saber a qué grupos pertenece. Esto ayuda a los analistas a comprender las características de los clientes y cómo se superponen los diferentes grupos de clientes. En Apache Doris, esto se implementa mediante las funciones BITMAP: es una forma rápida de verificar si un cliente es parte de un grupo determinado, y , y son las opciones para el análisis cruzado. BITMAP_CONTAINS BITMAP_OR BITMAP_INTERSECT BITMAP_XOR Conclusión De CDP 1.0 a CDP 2.0, la compañía de seguros adopta Apache Doris, un almacén de datos unificado, para reemplazar Spark+Impala+HBase+NebulaGraph. Esto aumenta su eficiencia en el procesamiento de datos al romper los silos de datos y optimizar los procesos de procesamiento de datos. En el futuro CDP 3.0, quieren agrupar a sus clientes combinando etiquetas en tiempo real y etiquetas fuera de línea para un análisis más diversificado y flexible. La y el equipo seguirán siendo socios de apoyo durante esta actualización. comunidad Apache Doris de VeloDB También publicado . aquí

This story contains new, firsthand information uncovered by the writer.

Find the Apache Doris community on Slack

Read My Stories

Este audio es producido en el idioma original de la historia!

Rompiendo silos de datos: cómo Apache Doris agiliza la integración de datos de clientes

Demasiado Largo; Para Leer

People Mentioned

Frank Z

STORY’S CREDIBILITY

Original Reporting

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...