To improve data sorting for push notifications, Alibaba’s Xianyu team reworked its approach to database structure, enabling its service to better target user populations. As Alibaba’s second-hand trading platform Xianyu(闲鱼) has grown and developed, the amount of data it has to sort through has risen astronomically. With hundreds of millions of users, each with over one hundred dimensions for data indicators, user data presents a technological challenge for Alibaba: How can you quickly screen for a targeted population to carry out targeted customer operations using push notifications? Pushing is the quickest way for Xianyu to get information to users. The most common pushing method for Xianyu is to first calculate the push population offline, prepare the corresponding push message, and then push messages at a specified time on the next day. Generally, pushing is a periodic task. However, for pushing tasks that need to be sent immediately, BI personnel must manually intervene. Each push task occupies half of a day on average for BI personnel to develop, and the operation can be troublesome due to the difficulty of identifying user populations to push to from the user data. Many existing solutions in the industry take minutes or even hours to generate query results when handling large amounts of data. This article explores Xianyu’s solution for high-efficiency data screening, statistics and analysis in big data scenarios, enabling its BI personnel to use any combination of query conditions to screen data that can be used to form pushing strategies within milliseconds. Identifying the Solution Looking at the challenges its platform faces, the Xianyu team realized that sorting data related to pushing is a typical OLAP scenario. A simple comparison of OLTP and OLAP is as follows: Specifically, it involves querying large databases with millions, or even billions, of rows of data, for which the high read/write concurrency or the transaction support of OLTP is unnecessary. Based on this conclusion, the team further realized that a column storage database presented the best approach — specifically, Alibaba Cloud’s HybridDB for MySQL. Columns beat rows Row storage databases commonly used for OLTP such as MySQL and Oracle are poor solutions for Xianyu’s needs. Row storage is suitable for nearline data analysis, for example, in scenarios that require querying all the fields of a certain number of eligible records in the table. It does not scale well if you have a large number of rows and only need to query a small number of fields. A simple comparison of the characteristics of row storage and columnar storage is as follows: For example, consider a scenario where you have a table with 20 fields and you need to calculate the average user’s age. If the table uses row storage, the database needs to scan the whole table and traverse all the rows. A separate index or composite index can mitigate this, but only for commonly used conditional queries. As soon as you need to query a non-indexed field, the database needs to scan the entire table. When you have hundreds of millions of rows, scanning the whole table can take a significant amount of time. Columnar storage is much better in this scenario. The database only needs to locate the age column, scan the data from this column to get all the ages, and then calculate the average value. Theoretically, the performance is 20 times faster than row storage since you only need to read one column of data. Which columnar storage is best? Xianyu comprehensively reviewed Alibaba Group’s various columnar storage DB products (ADS/PostgreSQL/HBase/HybridDB), and evaluated their respective read/write performance, stability, syntax comprehensiveness, and development and deployment costs. The most commonly used columnar storage database is HBase. However, its design makes it unsuitable for Xianyu’s requirements. It uses a rowkey as the core part of its design. Common filtering conditions are combined and integrated into the rowkey, and queries are done through the Rowkey’s get (single record) or scan (range) functions. It is designed for unstructured data that has a limited number of filtering conditions. For Xianyu, since all fields need to be used as filtering conditions, structured storage is still needed, and low latency is required for queries. Of the remaining solutions offered by the Alibaba Group, HybridDB for MySQL made the best choice. For Xianyu, HybridDB for MySQL provides the following features that allow to it provide millisecond response times to multi-dimensional queries in big data scenarios: · A high-performance columnar storage engine and its predicate computing capabilities with built-in storage, which can use a variety of statistical information to quickly skip data blocks for fast screening. · Smart indexing technology, which automatically creates indexes for a table and can combine multiple predicate conditions based on the indexes for screening. (Xianyu does not need to build its own indexes.) · A high-performance MPP+DAG fused computing engine that combines high-concurrency and high-throughput modes to achieve high-performance vector computing, this allows the computational engine and storage to work closely together to speed up computation. · Support for a variety of data modeling techniques such as star modeling, snowflake modeling, and aggregation sorting. Business moderate data modeling enables better performance indicators. In addition to performance, Hybrid DB for MySQL was also ideal for Xianyu because MySQL and BI are compatible with each other with complete SQL support. Further, it included support for spatial search, full-text search, and complex data types (multi-value columns and JSON). Pushing on HybridDB Xianyu implemented HybridDB for MySQL for its population selection system, and integrated the population selection system with its original Push system. This greatly improved the preparation data and transmission efficiency of pushing and freed up development resources. HybridDB for MySQL not only provides strong underlying support for Xianyu’s targeted user operations, but can also be applied to other business scenarios, such as targeted pushing of home page pictures and other scenarios that require hierarchical user operations, thus increasing the optimization space for the Xianyu service. System architecture In the following image you can see the three-layer system architecture used by Xianyu for its population selection system used with Push, consisting of an offline data layer, a real-time computing layer (HybridDB), and an application system. In the , user dimension data is distributed in the offline tables for each business system. The offline T+1 timing task is used to aggregate and import the data into the user wide table at the real-time computing layer. offline data layer The , according to the screening conditions of the population, will query the eligible number of users and list of user IDs from the user wide table to provide services to the application system. real-time computing layer The forms the first part of the application system layer, and provides a visual interface for operational personnel to select and save screening conditions as a population for analysis or pushing. Each population corresponds to a SQL store, which resembles: population selection front-end system select count(*) from user_big_table where column1> 1 and column2 in (‘a’,’b’) and (column31=1 or column32=2) SQL supports multiple layers and/or nested combinations of any fields for querying. With SQL saving a population, when the data in the user table changes, running SQL can retrieve the latest users in the population and update it accordingly. _Xianyu’s PUSH syste_m forms the second part of the application system layer. It obtains the corresponding “where” condition of the population from the population selection front-end system, obtains the user list in a paging manner from the real-time computing layer, and pushes messages to the user. During its implementation process, the performance of paging queries was a key focus. Optimizing paging performance When paging, if the size of the population is large (> 10 million), the query performance significantly reduces as the number of queried pages increases. To improve performance, row numbers were added to the population data and they were exported to MySQL. The following table shows that structure. Each time the population is exported, a new batch number is added, and is time stamped and incremented. The row number automatically increments from 1 for each batch number. The structure uses a composite index made up of “Population ID” + “Batch No.” + “Row No.”. This allows the PUSH system to use an index query to replace paging and improve the efficiency and performance of querying large-number pages. HybridDB’s powerful data export capability more than compensates for the extra cost of exporting data, with millions of data points taking only seconds to export. Looking to The Future Xianyu’s model ensures that the results of combined queries are returned within seconds from massive multi-dimensional data stores. As a generic technology implementation solution in OLAP scenarios, this technique can be used to transform other original service systems to improve service results and as a reference for similar scenarios. User data in the population selection engine is currently imported at T+1. The reason is that population-related indicators do not change frequently, and many indicators (such as user tags) are computed offline at T+1, such that the data update frequency of T+1 is acceptable. Later on, a more powerful commodity selection engine based on HybridDB was built. Xianyu commodity data changes faster than user data. On the one hand, users update their own merchandise at any time they wish. On the other hand, due to Xianyu’s single-stock feature (such that goods are removed from their shelves as soon as they are sold) and various other reasons, the statuses of goods can change at any time. Therefore, our selection engine should be able to recognize these changes in data as soon as possible and make real-time adjustments at the delivery layer. Based on HybridDB (storage) and real-time computing engines, the Xianyu team has recently built a more powerful real-time selection system called Mach, which readers can look forward to exploring in future articles covering developments at Xianyu. Alibaba Tech First hand and in-depth information about Alibaba’s latest technology → Facebook: . Twitter: . “Alibaba Tech” “AlibabaTech”

Facebook

Oracle

Target

Twitter

Staying Relevant in the Age of AI: An Alibaba Guide for Algorithm Engineers

Prediction in Three Dimensions: Alibaba Launches Its Live CFD-Based Sandbox

Follow us on Facebook!

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

A Push in the Right Direction: Improving Notification Targeting

A Push in the Right Direction: Improving Notification Targeting

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Brief History of Flink: Tracing the Big Data Engine’s Open-source Development

The Noonification: Feature Optimization for Price Prediction (11/26/2023)

10 Ways to Optimize Your Database

10 Essential Computer Skills for Data Mining

10 Most Evolving Big Data Technologies to Catch Up on in 2022

A Brief History of Flink: Tracing the Big Data Engine’s Open-source Development

The Noonification: Feature Optimization for Price Prediction (11/26/2023)

10 Ways to Optimize Your Database

10 Essential Computer Skills for Data Mining

10 Most Evolving Big Data Technologies to Catch Up on in 2022

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps