业务需求
随着可观测理念逐渐深入人心，人们越来越意识到通过多层次、多维度、多视角的数据来观测应用系统，以提升故障的定位效率以及业务分析能力。然而，在真正尝试落地实践构建可观测平台时，会遇到各种问题。观测云的核心需求是建立一站式数据门户，为架构减负，统一业务系统查询与分析。
业务挑战
01. 数据来源不一
客户端需要观测包括 Native、Webview、Hybrid、小程序等多种 App 环境；应用后端需要关注 Java、Python、PHP、Go 等程序语言；也需要从不同的中间件和基础系统如 Redis、MySQL、Doris、Kubernetes、Linux 等系统中采集不同维度的数据。还存在部分基础数据在托管的云厂商上，持续跟进和完善整个采集链路的成本和难度非常高。
02. 各存储系统导致查询语言与界面设计不统一
- 报表分析系统：指标结果多轮计算会导致数据处理链路过长、各类成本的叠加。
- 即席查询系统：资源浪费、查询响应延迟、高并发等难题。
- 多维分析系统：Druid 架构下无法保证业务稳定性。
- 人群圈选系统：HBase、ClickHouse、Kylin 架构下高并发能力弱，灵活度不足。
03. 原架构维护成本较高、易用性较低
- ES 资源开销高：内存和 CPU 开销高，同时历史数据存储的成本高；当前 ES 的冷数据存储设计还存在查询准确性问题。
- ES 维护成本高：在高负载下集群稳定性不高，频繁遇到分片数据量限制，需要经常手动调整索引分片数量。
- ES Mapping 动态映射字段易用性差：在长期使用过程中，一些字段会被淘汰、另一些字段新增，经常遇到总字段数的限制；字段创建后不能更新，时常遇到字段类型的冲突。
解决方案
观测云选择使用 SelectDB Enterprise 企业版替换 Elasticsearch，充分发挥 SelectDB 在日志存储以及半结构化数据方面的优势。观测云与 SelectDB 借助简化语法元素，在此基础上设计出了新的查询语言 DQL，并且增强了在可观测场景下的常见计算函数，通过 DQL 即可查询指标、日志、链路追踪、对象等所有的可观测数据。
客户收益
基于 SelectDB 成功构建起一站式数据门户，统一了指标标签计算存储，支持报表分析、即席查询、营销机构人群圈选系统以及多维分析的应用，并已上线了管理层的报表应用系统、总部与一线运营人员的可视化分析系统。
01. 开发效率提升
实现更高吞吐的数据实时写入，峰值写入速率达 1GB 每秒，写入后即可提供查询；摆脱了 ES 的索引分片数据量限制，SelectDB 可以根据数据量自动伸缩 Bucket，每天可以根据前一天的数据量动态伸缩 Bucket，保证写入和查询的高效。
02. 存储成本大幅度降低
使用了冷热数据分层降低存储成本，成本仅需要 ES 的 20%~30%；观测云引入 SelectDB 极大降低了数据的存储成本，也极大提升了存储运维的效率，后续也将持续关注最近技术动态，进一步降低成本并提升系统架构的稳定性。
03. 提升存储运维效率，加强索引字段灵活性
摆脱了 ES 的索引字段数量和类型的限制，SelectDB 提供强大的半结构化数据支持，Variant 字段可以根据写入数据类型来动态调整，能写入任意 JSON 动态数据，无需再担心数据类型冲突的问题。
