 OK, let's get started. Hello, everyone. I'm so excited to see some of you here. And I will show you my presentation named Hyperd Telemetry Data Backend. Firstly, let me introduce myself. My name is Xu Yuzhan, and I come from the Huawei Cloud Database Innovation Library. And there was a co-speaker with me whose name is Xiaotun Yang. And she is a professor of the Northeast University in China. And she has been engaged in teaching and researching in the field of data manager and analysis. But I have to announce that she can't be here due to some scheduling conflict. So I will step in to show her part for you. OK, in my team, there is an open source project named Open Gemini, which aimed to processing the monitoring data on Huawei Cloud. And my presentation will depart in four parts. The first is a challenge of the processing of observability data on Huawei Cloud. And the second is Open Gemini as a backend storage solution of Open Telemetry. And the third, I will show you some key design of the backend storage for logs and metrics. And last, I will show you some evaluation of our system. OK, there are two types of telemetry data on Huawei Cloud. First is a metric data which describes the status of the hardware and the software. And there is about 10 million per second. And the total size is about 20 per beta per day. And another is a log data is about 18.5 terabeta per day. So this data is used for some real-time analysis for monitoring, such as alert, anonymous detection, time-serving sites, and some troubleshooting. And for these goals, we introduce a lot of data engine into our system, such as Spark for processing the streaming and the treat for the overlap and some time-assist database to store the metrics data. And for the logs data, we introduce some search engine for full-time searching and the log storage. It seems that it can solve some of the problems. But the disadvantages is also apparent. Firstly, the metrics data is redundantly stored in the different storage engine. So the cost of the storage must be sensitive. And the second different data engine has different agent and different collector. So we have a lot of cluster, a lot of software to update, and a lot of cluster to scale out or scale in. The operation cost is so expensive. And last, when we want to do some correlation analysis, such as joining the same trace ID of the logs and the trace, it's necessary to pull the whole data out of the data engine and computer them. And the cost of the transformation is so expensive, and that's not efficient. So we want to exploring a simple data stack of the data generated and the data collecting and want to unify storage engine to process all of this data. In the next part, I will explain the solution of OpenJMNI compatible with the OpenTelemetry. For the years, OpenTelemetry has become the standard rate of visibility. And it provides a unified access protocol and standard rate data models for metrics, trace, metrics, trace, and logs. And it provides various SDK, such as C++ and Golang. And it's absolutely open source. So that gave us a big opportunity to unify our agent and the collector. And there are three ways for us to comfortable with OpenTelemetry. First, we call it agent to agent. Some of the search engines choose this way. And the two agents are deployed on the same data source end. And the data is transferred from the OpenTelemetry agent to the search engine backend. And the second, we call the collector to collector. The data is transferred from the OpenTelemetry collector to the time series backend. And the third, this is what OpenTelemetry choose is we call the collector to the backend. We think this is mostly the native way, because there are just two times of the protocol conversion and passing. In order to further understanding the OpenTelemetry format, we have abstracted it into three fields, three types of fields. Firstly is tags, which description will the data come from, such as the host name, the host IP, the trace ID, and the span ID. The next is a time step which describes the data when the data is generated. And the rest is columns, which contains the metric value, the log content, and the trace tags. And Open Gemini provides such a schema to match them. The next part, I will explain how Open Gemini is working for stores, logs, and metrics. Starting with the metric store, first let me show you about the data partition. The metric data is sharding by two types of property. First is a partition key, which is equal to the tag sets by default. And the second is a time range. After this, the data from the same data source end is sharding to the same partition. And there are and is convenience for the query that specific the tag set and the time range. And there are two types of storage in the shard. The first is a tag storage, which is implemented by the inventory tags. The term of the index is key value of the tags. And the position list is pointing to the data in the metric store. And the metric store is implemented by a column layout. And there is some disadvantage of this system with some when it can handle the log state for searching. And when the text value is the continuity is high, the performance value is poor. When it comes to the log store, we introduce a new type of for-text index called the airway index. When the log state ingestion into our system, we tokenize it and sharding it to the shard. And the tag set is used to build the tag index. And the token from the logs content is used to build the airway index. And the log is the same column store layout. So it's the same that we can store both the metrics and log data in one system. And I'll show you how it's running. For the for-text search, we provide a unified circle engine for all of the queries. When the circle come into the system, we separated the log searching and the tag filtering by the circle optimizer in the index gain stage. If you want a wrong log query, such as exactly query for a keywords, the keywords is searching from the airway index. And when it comes to the tag filtering, the result is searching from the tag index. And the result of them is composed to the position set, which point to the column, the data in the column store. The traditional implement of the for-text index is always inverted list. And there is a problem of it. When the words with the high frequency, the linked list of the term will be longer. And with the lower frequency, it will be shorter. And this result in this imbalance of linked list result in a problem of the fluctuation of the query performance. So our theory index is aimed to balance the linked list and reduce the total size of it. For the right image, it is constructed by the theory index. And you can see where it sacrificed the number of keys and reduce the total size of the linked list. Even the high frequency words get have a shorter linked list. This work has published in well-db and sig mode. If you want to know the detail of it, I will send the paper name in the Slack channel. And last, I will show you some evaluation of our system. Starting from the metric store, our Open Gemini has replaced the orange system, which contains HBase, Dread, Elastic Search, and OpenTSDB. And we replace the orange system and reduce the CPU cost by 16%. But unfortunately, we observe that when the tag value, the cardinality of the card value reaches 10 million per node, Open Gemini ingestion performance starts to degrade. That was the next phase where we must tackle the problem. For the log store evaluation, we compared with a search engine with 1 billion data set. And the result is that the index size reduced by 16% and the index pure time reduced by 16%. And for the performance of the query, the exact query latency reduced by 75% and the further query latency reduced by 16%. And the regress query latency reduced by 16% 3%. The man of optimization is due to the theory index and our circular engine. And let's review the roadmap of Open Gemini. Firstly, in the first phase, we position it as a metric store. And we reference a lot of time series, time series DB, database design, such as the inward index and the storage layout and the compression algorithm. So the metric store, we can support the unit and the float and the string types and provide a circular-like syntax and can manage a pair of beta data. And the next phase, we position it as a log store. There are more data types such as JSON and the text is supported. And we introduce the tokenizer text indexing and text retrieval in our system. And we connect to the open telemetry. And the next phase, we want to be as a observability backend storage. Firstly, we must support the tracing data storage and the tanker with a high cardinality problem and support the metrics and log and tracing correlation analysis. If you want to give some feedback, if you want to learn more about the Open Gemini, welcome to the BOSS D7. OK, that's all. Thank you.