国产替代导致多库并存
十年前，很多大一点的企业架构图长这样：前端系统 → ESB、中间件 → Oracle → 一堆报表
业务线想多开几个环境、做点新系统，IT 一算：“这又得多几套 License…”于是，本来该做的拆库、优化、压测，全被一句“我们先顶一顶”压了下去。
数据库太贵、太关键，没人敢乱调。于是遇到性能问题的标准动作是：“先加点内存、加点磁盘，看能不能顶过去。”
业务要数据，流程是：提报工单 → 等 DBA 抽空写 SQL → 导出来扔个 Excel → 业务自己二次处理。周期长、成本高，大家慢慢也就放弃了“好好用数据”这件事。
后来用 MySQL / 开源数据库 替代昂贵的 Oracle，降低成本、拥抱互联网架构。
从 Oracle 换到 MySQL，业务没重构，表结构不重设计
读写分离、分库分表、容灾备份，边做边学
最后成了一句：“反正先跑起来，有问题再说。”
产品那边功能“敏捷”地加，SQL 越写越重；DBA 那边每天看监控心惊胆战：“这不是 OLAP 查询吗？你咋给我扔到 OLTP 库上来了？”
订单在一个库，用户在一个库，日志又在别的地方。老板一句：“我想看下从拉新到复购的完整链路。”大家沉默 3 秒钟，开始画数据血缘图。
硬从 Oracle 时代的“单体大库”挪到 MySQL“多实例拼起来”，没有配套的监控、预警、容量规划，出问题就一锅乱炖。
最近几年，新的组合出现了：
线上交易用 MySQL / PolarDB / RDS
分析用 ClickHouse / Doris / Hive
国产数据库（比如国产 OLTP、OLAP）在不同系统里试点
外加一堆日志库、时序库、搜索引擎…
结果：
数据散落在 N 个数据库里
每个库都有自己的客户端、权限体系、方言 SQL
每条业务线都有自己的一套“报表体系”
同一个指标，在不同系统里不一样
A 系统里的“活跃用户”是 7 天；B 系统定义成 30 天；老板开会问：“为什么两个 DAU 差这么多？”所有人都在解释概念，没人敢说谁是对的。
云上算力很便宜，错用也很贵
有人用在线库跑大查询，有人一次性拉全库做分析，有人每天定时导出全量数据再丢 Excel。算力费刷刷往上冒，大家又开始怀念“当年一台 Oracle”——至少，成本是清晰的，问题也是集中暴露的。
数据分析需求越来越多，但分析能力没跟上
数据库层越搞越复杂，业务问题却越来越简单直接：
某个渠道的投放到底赚不赚钱？
今年库存周转是不是变慢了？
哪几条产品线在拖后腿？
页:
[1]