MicroStrategy 的本地产品已发布支持终止日期。 我们探讨这对无法迁移到云端的企业意味着什么——以及TURBOARD的架构如何回答供应商不会提出的问题。
企业商业智能市场内部正在发生一种悄然的转变,而供应商在主题演讲中却并未提及这一点。 在人工智能发布和“代理分析”发布的持续鼓点之下,那些在大量本地部署中建立声誉的平台正逐渐退出这一领域。 撤资很少被视为一种退出。 它被描绘成一种过渡、现代化和一段旅程。 但对于在过去十五年里在这些平台上构建关键任务报告的客户而言,实际效果是一样的:你购买的产品版本已不再是供应商所投资的版本。
这并非关于云计算的抱怨。 对许多工作负载而言,云计算确实更好。 问题更加具体。 很大一部分大型企业——银行、电信运营商、保险公司、公共部门机构、各种行业均受到监管——无法将其分析工作负载转移到超大规模企业,甚至无法将其转移到超大规模企业,甚至某些方面甚至将来如此。 数据驻留法、部门法规、针对本地操作系统的延迟要求、下沉的基础设施成本以及内部安全态势,均密谋将某些工作负载控制在客户自身的铁杆上。
供应商的路线图所假设与客户实际实际情况之间的这一差距,正是当前有趣的架构对话正在发生的地方。
初程中断,具体细节
全保市内微策略(第一级)支持计划
- 主流支持: 至2026年12月31日
- 延长生命周期支持 (关键安全补丁+基本技术援助):至2028年12月31日
- 2028年12月之后: 生命的终结,由供应商自身定义
MicroStrategy 内部部署平台正式更名为 MicroStrategy 企业平台,现已采用更广泛的“Strategy One”品牌,其发布的支持终端计划值得仔细阅读。 过渡期期间的路线图信号至少与结束日期相当。 工作站本地模式——允许用户在本地数据集上构建和保存仪表板的功能——在2026年3月版本中终止支持;后续版本无法打开这些文件。 在新品牌下引入的多种基于人工智能的功能——Auto Answer、Auto SQL、Auto Bot、Auto Dashboards——仅在云版中提供。 新的创新是通过刻意设计,向云端产品推广。 内部产品正在维护,而非先进。
这些都没有隐藏。 供应商自己的文档明确描述了方向,而从MicroStrategy到Strategy的重新品牌化本身就是一个信号,表明公司正在围绕不同的产品进行重新定位。
对于能够迁移到 AWS、Azure 或 GCP 上托管云环境的客户而言,这是一个有序的过渡。 对于无法被追问的客户而言,这种挤压是真实存在的,而用一个简单的“迁移到云”来回应它的原因,理应被点名:
为什么“迁移到云端”并不总是一个答案
- 数据居住法。 在土耳其,个人数据的跨境传输仍受KVKK第9条的约束,该条款要求明确同意或采取充分保护机制。 在欧盟,欧洲经济区以外的转移需要根据《通用数据保护条例》(GDPR)提供特定的保障措施。 海湾地区各自拥有数据保护制度,每一项都为任何跨国架构增加一层法律审查。
- 工程重力。 大型Oracle版块并非被动存储。 它们是经过调校的系统,包含分区策略、实体化视图、工作负载管理计划、统计机制以及多年来构建的临时表格模式。 将BI层级从它们上移开需要重新验证性能、安全性、身份、网络拓扑结构、灾难恢复以及操作所有权。
- 延迟和平。 当BI计算层位于数据仓库旁边时,针对十亿行事实表的查询是可处理的。 将计算层移动到由供应商管理的云端,同时将仓库留在本地,相同的查询则跨越广域网,从而扩大了延迟预算和安全范围。
对这些客户而言,真正的问题不在于他们目前的平台能否持续运行到2028年。 它会的。 问题在于,他们的分析策略在此后的十年中是什么样子,当时本地版本甚至不再收到安全补丁,而供应商的产品团队已花费五年时间优化客户无法采用的架构。
值得重新审视的“开箱即用”假设
另一个更具技术性的假设值得与战略因素一并审视。 长期运营的MicroStrategy客户——尤其是那些与Oracle数据仓库竞争的客户——通常将该平台描述为一站式服务,因为它与数据库的集成程度非常深入。 最常被引用的示例是能够将中间查询结果推送到 Oracle 全局临时表中,使带有强制筛选器的仪表板能够针对任意大小的事实表运行,而不会将数十亿行拖入 BI 层级。
这种模式值得精确描述,因为精确性就是重点。 仪表板位于一张非常大的事实表上。 在进行任何可视化渲染之前,用户必须选择一个强制筛选项——客户细分、投资组合、分支机构、报告期、授权人员。 BI引擎将所选标识符写入数据库内的会话范围临时表中。 后续的仪表板查询会将大型事实表与这个小型工作组结合。 优化器在靠近数据的地方完成繁重的任务。 BI层级从未看到未过滤的种群数量。 BI服务器的内存压力保持有边界;网络传输保持边界;数据库执行数据库的良好功能。
Oracle 全球临时表 — 标准 DDL
该声明每个环境执行一次,是整个模式的基础。 从那时起,任何会话都可以自行将行写入 filter_population仅查看其行,并在事实表上加入。
错误归因在下一步中: 假设该模式属于MicroStrategy。 全局临时表是Oracle功能。 它由数据库定义,由数据库管理,并通过标准DDL进行泄露。 MicroStrategy 的作用是自动生成该 SQL 的变体,作为其多通查询策略的一部分,该策略由 VLDB 属性(如中间表类型)设置为“True 临时表”控制。 这是复杂的SQL生成技术,但使模式快速运行的工作由Oracle完成,而不是由MicroStrategy完成。
建筑含义: 任何能够针对Oracle会话生成正确多通码DDL的BI平台都可以使用GTT。 该功能不受BI供应商的限制。 它取决于BI供应商的查询生成器是否设计为利用数据库原生临时对象,以及连接层是否保留了GTT语义所需的会话亲和性。
这改变了评估问题。 而不是问“哪款产品已经具备MicroStrategy的精确Oracle集成功能? 企业应该提出这样的要求哪个平台能够重现我们Oracle资产实际需要的工作负载模式? 问题听起来相似。 它们导致了截然不同的候选名单。
更换项目通常会展示什么
另一种观察,即较少架构但更难反驳,往往出现在TURBOARD已取代企业环境中现有MicroStrategy装置的项目中:MicroStrategy前端,与企业用户在现代仪表盘体验中所期望的水平相评估,显示出其时代性。
可视化库的局限性在于较新的平台所没有。 开箱即用的图表种类比现代消费者所期望的要窄。 自定义可视化是可以实现的,但需要使用 SDK 或原始 JavaScript——在围绕可扩展性设计的工具中,其开销比同等水平更高。 交互模式源于早期商业智能时代。
前端创新成本高昂,而供应商正在将其投资用于战略产品的运营。 对于本地客户而言,他们拥有的前端总体上是他们将保持的前端。
更广泛的原生可视化库;与MicroStrategy的SDK依赖方法相比,自定义开销更低。 交互模式——滤波层叠、钻孔路径、全视图构建——专为当前一代企业型仪表盘消费者设计。
企业级后端行为——受管理的元数据、具有数据库感知的SQL生成、强制筛选的自律——无需牺牲现代前端的灵活性。
这是之前描述的本地/云分叉的可预见结果。 这正是许多微策略替代讨论所困惑的地方:团队认为必须在企业级后端行为和现代前端灵活性之间做出选择。 这一假设值得被挑战。
不同的建筑答案
这就是引入TURBOARD的有用之处——它并非类似于对MicroStrategy的替代,而是作为基于一组不同假设的BI架构的示例,该假设涉及数据应在何处以及BI层级应如何与数据库产生关联。
TURBOARD 的架构采用混合设计。 数据可以通过使用原生数据库驱动程序(而非通用的ODBC)进行优化的实时连接,保留具有会话感知和下行功能的特性,从而实现Oracle GTT等模式。 或者,数据可以导入到 MariaDB 柱子商店、ClickHouse 或 Vertica 等高性能列库存储中,其中分析查询可从列压缩和柱状修读功能中获益,而不能将数据集保存在内存中。 常用的查询结果在 Redis 中被缓存,其缓存触发机制用于检查指定的触发字段(例如最后更新的时间戳),以判断缓存的答案是否仍然有效,或该源需要重新查询。
每次查看报告时，TURBOARD 都会在 Redis Sorted Set 中提高相应内容的热度分数，从而持续识别真正有需求的仪表板。当内存紧张时，企业实际使用的仪表板会优先受到保护；一次性查询则会被路由到列式存储或实时数据源。该机制已获得专利，申请于 2022 年并于 2025 年获批，涵盖基于使用情况的缓存评分、基于触发器的时效检测和智能缓存刷新。
对于GTT的应用场景,该架构自然地构成。 原生Oracle驱动程序保留了GTT所需的会话语义。 强制过滤仪表板针对非常大的事实表,使其过滤和聚合工作完全依赖于Oracle,就像在任何经过良好调整的BI层级下一样,在GTT中实现了中间结果,从而产生更完善的计划。 对于Oracle并非正确执行引擎的工作负载——高并发运行仪表板,对历史数据进行临时探索——列式存储和Redis加速层则取用负载。 这种架构并不强制在实时查询和记忆中做出选择,而是让每个工作负载都满足适合它的引擎。
为了进行架构上的讨论,探讨为何这与纯粹的内存平台相关, TURBOARD与Qlik Sense记忆模型的对比 值得完整阅读。
建筑决策,并排
本地版“微策略”版块与混合式TURBOARD部署之间的架构差异,最好不是作为特征比较,而是作为对比 每个架构假设的是什么.
| 建筑决策 | 微策略(第一策略,初稿) | TURBOARD |
|---|---|---|
| 按需供应商路线图 | 主流支持至2026年12月;延期(仅限安全)至2028年12月;EOL之后 | On-prem 是一个一流的持续部署模式 |
| 新创新走向何方(人工智能等) | 仅限云版(自动回答、自动SQL、自动机器人、自动仪表盘) | 本地和云端都具备相同的功能 |
| Oracle GTT / 强制筛选模式 | 通过 VLDB 属性和 SQL 生成支持 | 通过具有会话亲和力的原生Oracle驱动程序提供支持 |
| 运行时默认数据驻留 | 服务器端缓存;DB 中的中间结果 | 柱子商店 + 智能Redis缓存;居住在合适的位置 |
| 缓存驱逐政策 | 以年龄和尺码为主 | 使用率(专利),行为感知 |
| 前端可扩展性 | SDK / JavaScript 用于非标准视觉效果 | 更广泛的原生可视化库;更低的自定义开销 |
| 部署拓扑假设 | 云优先;主页被视为过渡 | 拓扑无关;入门级、云级或混合模式 |
| 数据主权立场 | 客户跟随供应商走向托管云 | 客户选择数据和计算的实时位置 |
这张桌子并非详尽无遗,任何单个单元格都值得进行一场比一排更深刻的对话。 但对比的形状是关键。 这是两种不同的架构理念,根据企业实际管理的制约因素进行评估。
未来十年
十年后仍将具有重要意义的平台,是尊重客户实际拥有的数据基础设施的平台,而非供应商所期望的数据基础设施。 这并非对本地计算的浪漫偏好;而是认识到企业在监管、财务、架构、组织等限制条件下运营,而供应商的路线图往往过于薄弱。
对于那些对2028年问题提出“我们仍将在自己的基础设施上运行大量分析工作负载”的组织而言,选择范围正在缩小。 现有平台正按其公开记录的时间表进行推进。 可行的替代方案是从一开始就设计的,旨在将数据库原生执行、柱状存储和智能缓存视为单一架构的可组合部分,而不是作为内存下注停止支付时的回落。
TURBOARD是否是任何特定环境的正确答案,恰恰是一个概念验证的问题。 更广泛的观点是,答案是存在的——而“迁移到云端或接受生命终结”并非唯一可行的途径。
准备好看到区别了吗?
如果你正在评估 MicroStrategy 的替代方案——或者已经运行它,并开始感受到路线图日益缩小的压力——我们很乐意向您展示 TURBOARDD 架构如何在您自身基础设施上处理相同的工作负载。
与我们的团队一起预约演讲,并使用您自己的数据查看平台的实际运行情况。 无需施加压力——我们更希望您找到最适合您特定需求的合适人选。
您也可以探索我们的 完整商业信息对比 页面,查看我们如何在更多企业场景中叠加。
带来一个真实的业务问题，看看 TURBOARD 如何回答。
我们在您的报表、您的定义和您的安全上下文中演示 JAS —— 而不是在通用示例数据库上。