数据库一体机这个词放到今天听起来已经有点古董味了。但在2010年前后它是数据仓库圈子里最硬核的一条赛道而Teradata和SAP HANA就是在这条赛道上正面相撞打了一场长达八年的官司最终以一笔接近4.8亿美元的赔偿金收场。作为一名长期在企业级数据平台里摸爬滚打的人我一直觉得这场诉讼的看点不在吃瓜而在于它把数据库一体机的核心矛盾完整地撕开给人看软硬一体到底值多少钱内存计算究竟动了谁的蛋糕以及当一家公司把“一体机”作为护城河时它最怕的对手是什么。这篇内容适合正在做数据仓库选型的人、搞过Teradata或HANA迁移的架构师以及所有对数据库行业“大事件”背后逻辑感兴趣的读者。我会把这场8年诉讼的来龙去脉、技术争议的实质、4.8亿美元赔偿的来由讲清楚也会结合今天FineReport连接HANA、S/4 HANA SD模块业务伙伴配置这些实际操作场景聊一聊这场“历史大战”留给我们的真实遗产。1. 数据库一体机一个被云时代半路截胡的“铁盒子”1.1 一体机到底是个什么东西数据库一体机英文叫Database Appliance本质上就是把“服务器硬件 存储 数据库软件 管理运维工具”打包成一个整体以一台高度集成的设备形态交付给客户。用最朴素的话说就是你买回去一个“铁盒子”插上电、配上网络它就是一个可用的数据仓库不需要你再费劲地去选服务器、配存储、调操作系统、装数据库。这个模式在2010年前后特别吃香。原因很简单传统数据仓库的部署太折磨人了。你买了一堆通用服务器装好Linux再装数据库软件然后要花大量时间去调存储的IO、配置RAID、规划表空间、调并行度。更麻烦的是数据库的扩展性往往跟不上业务增长今天扩容要加内存明天加CPU后天才发现存储带宽根本不够。一体机把这些事情全部收敛掉硬件和软件在出厂前就已经调优过扩容基本上就是“再加一台节点”整个集群的节点间通信、数据分布、负载均衡全部由软件控制。Teradata就是这种模式的先驱。早在1984年Teradata就推出了第一代数据库计算机DBC/1012这是行业里最早的“专业数据仓库硬件”之一。它采用的架构被称为Shared Nothing也就是无共享架构每个节点拥有独立的CPU、内存和磁盘节点之间通过高速网络通信数据按照某个分布键散列到不同节点上。这种设计的好处是扩展就是增加节点查询可以在节点间并行跑数据量越大、节点越多性能优势越明显。HANA则走了另一条路。SAP HANA的核心卖点是“内存计算”把数据全部放在内存里配合列式存储和强大的压缩算法把传统磁盘数据库要跑几分钟甚至几小时的报表压缩到几秒甚至亚秒级。但内存再大也是有上限的所以HANA也采用了一体机形态SAP提供数据库软件IBM、Dell、HPE、富士通等硬件厂商提供经过认证的服务器内存和CPU配置提前选好软件硬件打包交付。客户不用管底层怎么分区、怎么分布交给一体机就行。1.2 为什么当年的架构师会为“软硬一体”买单我现在回头看当年国内很多银行、电信、零售企业上数据仓库一体机核心驱动力就三条省心、性能、可控。省心这一点最好理解。传统的企业采购流程是先选数据库厂商再选服务器厂商然后自己做集成。这中间的坑太多了最常见的是“配置冲突”数据库厂商说需要至少128GB内存服务器厂商说你买的机型最大只支持96GB或者存储厂商说他们的磁盘阵列能提供12GB/s的吞吐结果实际跑到6GB/s就开始告警。一体机把这些集成工作提前做完了厂商给你一套经过验证的“标准答案”实施周期可以缩短一半以上。性能则是另一个故事。通用的服务器加存储组合很难针对特定数据库做深度优化。比如Teradata的一体机存储层会针对它的并行扫描做预读和IO调度优化HANA的一体机会特别关注内存带宽和多核CPU的NUMA亲和性。这些优化不是简单堆硬件就能实现的必须软件和硬件协同工作一体机把这个协同做到了出厂级。可控性也值得说。企业用一体机本质上是在买“一个产品”而不是买“一堆零件”。出了问题一个电话打给厂商不需要在服务器厂商和数据库厂商之间来回踢皮球。对于IOE架构盛行的时代这是非常实际的考量。但一体机的悖论也在这里它太“整装”了客户被绑定在特定厂商的软硬件组合上价格高、升级路径单一、技术路线受限。当云数据库和分布式数据库兴起之后一体机的灵活性短板就被无限放大。这为后来Teradata和HANA的缠斗以及整个行业的风向转变埋下了伏笔。2. Teradata的黄金时代与HANA的入场2.1 Teradata如何成为数据仓库的代名词2000年代到2010年代Teradata在全球数据仓库市场的地位基本等同于我们今天说“字节跳动做短视频”的认知度。它的客户集中在金融、电信、零售、航空这些数据量大、报表复杂度高、对性能要求苛刻的行业。一个典型的场景是一家大型银行每天产生数亿条交易数据月底要对全行几十个维度做汇总分析Teradata能在这张大表上用并行扫描和哈希连接快速跑完这是当时通用关系型数据库很难做到的。Teradata的技术护城河其实不是某单一技术点而是整个“大规模并行处理”的工程能力。它有一个非常成熟的查询优化器能根据统计信息把SQL拆分成多个子任务分配到不同节点上并行执行。再加上它的数据分布策略按照主键哈希分布和工作负载管理Workload Management控制不同部门、不同优先级查询的资源分配让一个几百个节点的集群可以同时服务数千个分析用户。今天很多分布式数仓做的事情Teradata在20年前就做过了。但Teradata也有它的软肋贵。这种贵体现在硬件、许可、维保、实施、人员培训的方方面面。很多客户买得起硬件却养不起一支懂Teradata的运维团队。这种“高门槛”让Teradata在金字塔尖活得很好但也在金字塔中下部留出了巨大的市场空间后面SAP HANA、Oracle Exadata、以及后来的云数仓实际上都从这个空间里找到过机会。2.2 SAP弃Teradata自研HANA合作伙伴反目SAP和Teradata本来是合作关系。2000年代中后期SAP的BW/BO业务信息仓库/商务智能产品线在数据仓库硬件层面长期依赖Teradata作为底层扩展平台。很多SAP客户跑BW报表底下接的数据库就是Teradata。你可以这么理解SAP负责业务数据和模型Teradata负责海量数据存储和分析加速两家各赚各的钱。但这个合作关系并不稳固。SAP很快就受够了“数据库握在别人手里”的状态。SAP的核心资产是ERP业务数据模型如果底层数据库性能不好ERP再复杂也跑不快而如果底层数据库是别人的SAP就等于把发动机交给了外人。2009年前后SAP开始秘密投入研发自己的列式内存数据库也就是后来的HANA。2010年SAP公开HANA原型2011年正式发布产品。转折点出现在这里SAP推HANA的时候并没有像传统数据库厂商那样“软件先行硬件随便”而是非常聪明地打出了一体机牌。SAP联合HPE、IBM、Dell、富士通等硬件厂商推出“SAP HANA Appliance”也就是内嵌HANA数据库的一体机。这个产品直接对标的就是Teradata的数据仓库一体机。与此同时SAP开始引导客户把BW从Teradata迁移到HANA而且迁移速度很快因为HANA是列式存储BW的星型模型正好适配列式压缩迁移后查询性能往往能提升一个数量级客户体验非常直观。Teradata眼睁睁看着自己的“最大盟友”变成了“最大对手”而且对手还把自己最赚钱的模式学了个遍。商业上的反目只是一个开始真正把矛盾推向白热化的是接下来的法律战场。2.3 HANA的一体机打法用内存换磁盘HANA能在一体机这个品类里后来居上技术路线上确实打了差异化。Teradata的优势是海量数据并行处理但它的底层存储依旧是磁盘介质虽然也有闪存加速数据加载到内存之前要经过一层“落盘-扫描”的IO环节。HANA则把数据的“家”直接搬到了内存里磁盘只是用来做持久化和日志备份。这个差异带来一个非常明显的用户体验变化查询速度。传统的磁盘数仓跑一个复杂的星型模型关联可能要几十秒甚至几分钟HANA内存计算把“磁盘IO找数据”变成了“内存指针跳转”同样的关联查询在基准测试里可以快到几秒甚至几百毫秒。对于SAP客户来说这种速度提升是革命性的之前可能要跑到夜里两点的月度报表白天点一下就跑出来了。但内存计算的成本也摆在明面上内存很贵。HANA一体机的机器配置通常要几百GB甚至几TB内存整套设备的价格非常可观。所以HANA在早期并没有直接去抢Teradata的老客户而是先从SAP自身生态里切入反正你要跑BW/ERP反正你在SAP体系内用HANA就是“最顺的路”。这种生态绑定加上一体机的交付形态构成了HANA在商业上快速渗透的逻辑。3. 八年诉讼查什么、争什么、输了什么3.1 第一回合Teradata起诉SAP盗取商业机密时间回到2016年Teradata正式在美国加州北区联邦法院起诉SAP指控SAP窃取其商业机密。Teradata在诉状里讲的核心内容用大白话说是这样的SAP在跟我们合作期间通过“联合开发”“技术互访”“共同客户支持”这些正常合作动作接触到了Teradata的查询优化、工作负载管理、数据分布、并发控制等核心技术细节。然后SAP掉过头来把这套技术用到了HANA的开发上。Teradata之所以这么愤怒是因为它认为这不是“正常的行业借鉴”而是利用了合作伙伴的信任。当时的公开报道里提到Teradata指控的内容涉及“SAP工程师在合作项目中有针对性地获取Teradata技术方案”还包括SAP内部邮件中“研究Teradata优化器”之类的证据。这个官司的走向一度非常胶着SAP当然全盘否认说HANA是自主研发技术路线完全不同内存计算 vs 分布式磁盘架构不存在剽窃。从行业观察者的角度看这场诉讼最精彩的地方在于它跳出了“谁抄谁”的罗生门逼着法庭去对“数据库核心技术”做一次公开解剖。比如查询优化器的代价模型是怎么写的、数据压缩算法是否有相似实现、并发控制机制是不是同一套路。这些平时躺在源代码库里的东西突然成了法庭证据这在整个数据库行业历史上都很少见。3.2 技术争议的实质优化器、压缩、工作负载管理很多技术圈的朋友喜欢把这场官司简单说成“大厂互撕”但如果你真去研究庭审披露的技术细节会发现双方争的根本不是“内存”这个概念——内存计算不是SAP发明的列式存储也不是。真正争的是三项工程实现层面的事查询优化、数据压缩、工作负载管理。查询优化这块是Teradata几十年的家底。优化器要解决的核心问题是一条SQL来了是走哈希连接还是嵌套循环哪张表做驱动表数据是分布在10个节点还是100个节点不同执行计划之间的性能差异可能高达几个数量级。Teradata的优化器在分布式场景里迭代了三十年积累了海量关于“数据分布并行执行”的代价模型经验。SAP HANA要在分布式集群上高效跑SQL同样绕不开这套问题。数据压缩也是关键。HANA的卖点之一是“内存里放更多数据”怎么放更多靠压缩。列式存储天然对压缩友好但压缩算法的选择、压缩后如何做向量化计算、如何保证数据读取时的解压开销足够低这些都是硬骨头。Teradata当年在其列式存储和压缩技术上也做了多年投入双方在这一带的专利和商业机密分布相当密集。工作负载管理则是一个典型的万亿级运维问题几十个部门共用一台数据仓库一体机有人跑报表有人跑数据抽取有人做即席查询如何保证不彼此挤死Teradata在内存分配、并发队列、优先级调度上有一套成熟的机制。HANA想在企业级市场站住脚也必须做到这一点。法庭审理的焦点正是这些工程机制之间的相似性。3.3 4.8亿美元赔偿的判决与后续到了2018年8月陪审团做出了裁决。根据当时公开的媒体报道法院认定SAP确实存在盗用商业机密的行为裁定SAP向Teradata支付赔偿最初裁定的赔偿金大约为3.98亿美元再加上利息和部分惩罚性赔偿最终接近4.8亿美元。这个金额拿到今天看也是个大数目在当时更是数据库领域诉讼的一个标志性结果。SAP当然不服之后提起了上诉和后续法律动作。最后的结局严格来说没有“戏剧性反转”双方后来围绕赔偿金额继续打了好几年官司期间还有过部分裁决被撤销或减少的插曲。但“SAP要为盗用商业机密付出巨额代价”这个整体判断在陪审团裁决那一步其实就已经定了调。直到今天你在搜索“Teradata SAP lawsuit”时看到的大多数结果讲的还是这起接近4.8亿美元赔偿的历史案件。值得一提的是这笔赔偿对两家公司后来的战略都产生了实质影响。Teradata拿到判决后并没有因此“躺赢”因为行业已经悄悄变了——云数仓来了。SAP则在继续上诉的同时加速推动HANA向云上转型把“HANA一体机”逐渐软化成了“HANA Cloud”以应对云数据库的竞争。如果用一句话总结这个阶段官司赢了但战争输了赢家是趋势。4. 诉讼尘埃落定后HANA真赢了吗4.1 从一体机到云HANA的路线调整熟悉数据库行业的人应该能感觉到最近几年“数据库一体机”这个词已经很少被主动提起了。原因很现实云数据库和分布式数据库把“软硬一体”的逻辑打穿了。在云上计算和存储可以独立扩展资源和资源之间通过网络连接你不再需要购买一台动辄百万、千万级的铁盒子而是可以在控制台上点几下就创建一组数据库实例。这种灵活性是一体机完全给不了的。SAP也敏锐地调整了船头。HANA Cloud、BTPBusiness Technology Platform这些新产品路线图本质上都是把HANA从“软件与硬件强绑定的设备”变成“可以跑在任何云基础设施上的软件服务”。今天的HANA对于新客户来说更多是一套“数据库软件数据平台方案”而不是当年那个人人谈“一体机配置”的硬件时代。但老一代SAP ECC/BW客户不是这样。他们当时买的是一体机硬件在里面迁移成本极高所以一大批企业到现在还在本地机房跑着HANA一体机尤其是制造业、能源、大型零售这些对数据主权敏感的行业。这也是为什么你看招聘市场上还有大量“SAP HANA 系统管理员”“HANA DBA”的岗位需求。历史在这里并没有“一键清空”而是以另一种形式滞留在生产系统里。4.2 FineReport等外部工具连接HANA的常见坑我在实际项目里发现今天真正高频接触HANA的人很多并不直接操作HANA Studio或者SAP HANA cockpit而是通过报表工具、BI平台去连HANA。比如国内用得比较多的FineReport几乎每个S/4 HANA项目里都会遇到“FineReport连接HANA”的配置问题。最常见的坑可以总结成以下几类第一JDBC驱动不匹配。连接HANA必须用SAP官方的ngdbc.jar驱动这个驱动一般在安装HANA Client后位于hdbclient目录下。很多人图省事从网上下一个老版本驱动结果连不上或者明明连上了执行复杂SQL时报奇怪异常。建议直接去SAP官方下载HANA Client驱动版本尽量和数据库小版本对齐至少大版本不能差太多。第二JDBC URL格式。HANA的JDBC URL长这样jdbc:sap://192.168.1.100:30015。端口号是“3 实例号 15”比如实例号00就是30015实例号01就是30115。如果FineReport里填错端口连接会直接超时。这个细节看起来简单但在现场我已经帮人排查过不下五次。第三时区和十进制字段类型问题。HANA的时区默认和服务器系统时间相关FineReport如果连接后时间数据差8小时多半是连接参数里没配客户端时区。还有一种情况是HANA的DECIMAL字段在JDBC下返回为BigDecimalFineReport某些版本对这类字段的汇总计算会报“不支持的类”需要在数据集里先用CAST转成DOUBLE或者VARCHAR再处理。第四SQL语法兼容性。HANA虽然基本兼容ANSI SQL但和MySQL、SQL Server这类数据库的差异还是很明显的。比如字符串拼接用||分页用LIMIT OFFSET公共表表达式支持不错但过深的递归查询性能会变差。从别的数据库迁移过来的SQL常常要先在HANA Studio里跑一遍确认语法。我给一个相对稳妥的操作顺序先在HANA Studio里验证SQL能跑通然后到FineReport的“服务器数据集”或“数据集管理”里配置ngdbc.jar之后在连接串中加上useSSLfalse如果HANA側没有强制SSL最后测试连接并跑一条最简单的SELECT * FROM ... LIMIT 10。这四步走完之后再去调报表模板出现连接层问题的概率会小很多。4.3 落不了地的业务伙伴配置SD模块的达因锁与校验除了报表工具连库另一个HANA落地中的高频实战场景是S/4 HANA的SD销售与分销模块里的业务伙伴确定。这个功能的名字听着有点绕但本质上就一句话销售订单上的“售达方”“送达方”“收票方”“付款方”这些角色系统怎么根据客户主数据自动带出来、怎么校验合法性、怎么在异常情况下给出提示。S/4 HANA和传统ECC最大的变化之一就是全面启用了“业务伙伴”Business Partner简称BP模型。老ECC里的客户主数据分散在KNA1客户基本数据、KNB1公司代码数据、KNVV销售范围数据等表里S/4 HANA全部归集到BP模型底层的表变成了BUT000、BUT001、CVI_CUST_TYPE等。字段位置变了很多老顾问第一周就会懵以前在客户主数据里维护“售达方”现在要去BP的销售视图里找。这里最容易踩的坑是业务伙伴确定不生效。典型的症状是手工创建销售订单时售达方明明填了客户代码订单保存后“送达方”一片空白也不报错。排查思路要从三个地方展开。第一检查销售订单的类型对应的“合作伙伴确定程序”Partner Determination Procedure。这个在SPRO里配置路径大致是“销售和分销 - 基本功能 - 业务伙伴确定”。如果销售订单类型调的确定程序里没有给“送达方”配置伙伴功能WE那无论你怎么维护主数据订单都带不出来送达方。第二检查客户主数据销售视图里的“客户层级”和“销售伙伴功能”。在BP事务代码里如果销售视图下没有维护“送达方”相关的伙伴功能记录系统无从带出。很多人BP基本数据维护好了忘了点销售范围视图结果订单关联时怎么也匹配不上。第三检查BP字段的校验。如果业务伙伴的状态不是“已完成”或者销售范围的数据不完整系统在确定伙伴时会静默跳过只在日志里写一条“合作伙伴缺失”的警告。你如果不打开“业务伙伴检查”这个事务的详细日志根本不知道发生了什么。经验之谈先查“合作伙伴确定程序”再查BP销售视图最后查BP状态。十个“带不出来”的问题至少有八个能在前两步定位。这是我在S/4项目里反复验证过的顺序。5. 这段历史留给数据库选型的经验账5.1 一体机选型时的真实考量如果你今天还在考虑上一套数据库一体机不管是用在数据仓库还是交易型系统我建议你先问自己三个问题。第一个问题你们的增长速度是可预期的吗如果业务增长是线性的明年的数据量、并发量大致能算出来那一体机的“整装交付”确实省心。但如果业务增长根本就不可预测今天100GB下个月可能跳到10TB一体机的扩展模式就是灾难因为每次扩容都是换机头和加节点预算和周期的弹性都很差。第二个问题团队是真的想省心还是怕麻烦一体机最大的价值是“少踩集成坑”但代价是你接受了厂商的强约束。硬件升级要看厂商路线图软件补丁要看厂商认证矩阵甚至连换硬盘都要走厂商流程。这跟云上的“随时换规格”完全是两种体验。第三个问题你真的需要“这台机器”吗还是需要“这个数据库的能力”很多时候客户的诉求本质是“我要一个能跑大数据量分析的数据库”而并不关心它长在什么硬件上。如果是这样不如直接评估开源分布式数据库或者云数据仓库用软件能力替代硬件绑定灵活性要高得多。这套思考框架不仅适用于Teradata和HANA的对比也适用于今天任何软硬一体的数据库方案选型。历史没有给出一劳永逸的答案但至少留下了一条清晰的经验数据库选型的天平正在从“买硬件”倒向“买能力”。5.2 从诉讼看专利与兼容性之争Teradata和HANA这起案子给整个行业带来的另一层影响是对“知识产权”的再度审视。过去很多技术团队觉得数据库底层的优化器、压缩、并行调度这些能力“大家不都是那么做的吗”但这起诉讼用4.8亿美元说明做是可以做但如果你是借了别人的“内部方法”做的那是要付出代价的。这件事连锁影响了后来的行业生态。你看今天几乎每家大数据库厂商都更谨慎地对待“合作访问”和“技术互鉴”源代码级别的东西更加严密。同时开源项目之间的兼容与借鉴变得空前重要因为大家都明白如果全靠闭门造车技术进步一定会慢下来。而开源社区的机制至少把“借鉴”放在了一个可以被审计、被透明的环境里。对于普通选型人员这里有一个很实在的建议在评估HANA或者其他商业数据库时别只看功能和性能Benchmark多考察一下它的“技术独立性”。这家公司的核心技术到底是原创的还是从哪家合作方拿来的它的知识产权风险会不会传导给下游客户这类问题虽然冷门但在关键决策时往往比性能数字更值钱。5.3 项目级避坑跨平台迁移和成本控制回到实际项目里我见过很多企业还在做“Teradata迁移到HANA”或者“其他数仓迁移到HANA”的事情。这中间的坑比想象中多。首先是SQL方言差异。Teradata用的是大家熟悉的Teradata SQLHANA的SQL方言更接近ANSI但在字符串函数、日期函数、分页语法上有区别。比如Teradata里常用DATE 2024-01-01HANA支持但Teradata的QUALIFY行过滤语法HANA完全没有。迁移大批量旧SQL之前建议先做一个“语法扫描”凡是带QUALIFY、MACRO、HASH JOIN这类特有语法的都要单独改造。其次是数据类型和精度差异。Teradata支持DECIMAL(38,0)的大范围小数HANA也不是所有精度都顺手。字段类型一旦转换不当跑报表时会出现精度丢失或者类型转换错误这个问题在跨数据库迁移里几乎必现。最后是性能调优策略完全不一样。Teradata老司机习惯用“收集统计信息 查看Explain计划 调整表的分布键”这套方法调优HANA则更多依赖内存中执行、列存的物化视图、参数化SQL。很多团队把老经验带过来结果发现同样的SQL在HANA上跑得非常别扭。成本控制上也要有清醒认识。HANA的许可费用按内存和CPU计算一体机的内存尽量一步到位。如果前期为了压预算选了“足够用”的配置半年后被业务增长打脸再升级硬件的成本远超当初省下的那点费用。我现在做方案一般都会建议客户把HANA的内存按业务规划的2到3倍去规划宁可前期看起来“浪费”也不要中期为了扩容跟厂商反复扯皮。我个人的体会是数据库技术的历史往往不是线性的那些曾经被市场追捧的架构后来可能变成包袱那些当年赔了巨款的对手反而在新的赛道上活得不错。Teradata和HANA的八年诉讼表面上是一场知识产权大战实际上是“软硬一体”模式从盛到衰的缩影。而对每一个正在选型或迁移的人来说真正能从中得到的不是谈资而是这些被验证过的取舍逻辑关注能力而不是设备重视可拆分性而不是绑定感尊重知识产权也要保持技术甄别力。今天如果让我给同行一个最直接的建议那就是当有一个厂商跟你说“我们的一体机可以帮你省掉所有麻烦”时先问一句“那如果行业变了我还能跟着变吗”。这个问题比那个4.8亿美元的赔偿数字更值得每一个做数据平台的人记在心里。
