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.
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.
Para CDP 2.0, deciden introducir una solución unificada para limpiar el desorden. En la capa de cálculo de CDP 2.0, Apache Doris realiza cálculo y almacenamiento de datos tanto en tiempo real como fuera de línea.
Para ingerir datos sin conexión , utilizan el método Stream Load . Su prueba de ingesta de 30 subprocesos muestra que puede realizar más de 300.000 upserts por segundo. Para cargar datos en tiempo real , utilizan una combinación de Flink-Doris-Connector 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 de catálogo múltiple para 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.
¿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.
Este CDP contiene información de 500 millones de clientes , que provienen de más de 500 tablas de origen y están adjuntas a más de 2000 etiquetas en total.
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 INSERT INTO SELECT de Apache Doris y habilitan la actualización parcial de la columna . Esto reducirá significativamente el consumo de memoria y mantendrá la estabilidad del sistema durante la carga de datos.
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 partial_columns
en 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 declaración preparada 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 el caché de filas como complemento del Apache Doris orientado a columnas.
be.conf
: disable_storage_row_cache = false storage_page_cache_limit=40%
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 de grupo de colocación en Doris.
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 50 segundos en Impala en finalizar ahora solo necesita 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: BITMAP_CONTAINS
es una forma rápida de verificar si un cliente es parte de un grupo determinado, y BITMAP_OR
, BITMAP_INTERSECT
y BITMAP_XOR
son las opciones para el análisis cruzado.
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 comunidad Apache Doris y el equipo de VeloDB seguirán siendo socios de apoyo durante esta actualización.
También publicado aquí .