前两天在技术社群里看到有人提问HBase到底算不算列式存储底下吵了几十楼有人搬出“列式数据库鼻祖”的说法也有人坚持HBase是NoSQL行存跟分析型列存没半毛钱关系。说实话这个问题值得认真回答因为答案里藏着大数据存储这十几年演进的一条主线从在线服务的列族模型到分析场景的列式文件格式再到把文件组织成一张真正“表”的表格式。我这些年做过实时存储、也迁过数据湖今天就用一篇偏实战的文章把HBase到Iceberg这条路上的原理、选型和坑一次讲清楚。这篇文章主要适合两类人一类是做数据平台、数仓研发正在调研要不要引入Iceberg另一类是手上有HBase存量数据想把它搬到分析型存储上又不知道从何下手的同学。读完你至少能回答三个问题为什么HBase当时会被误解为列式存储、Parquet和ORC这类真列式格式到底解决了什么、Iceberg在更高一层又补齐了什么以及一次从HBase到Iceberg的迁移具体该怎么做。1. HBase被叫“列式存储”的底气与误会来源1.1 先回到HBase的数据模型RowKey、列族与版本HBase的设计出处是很多年前一篇分布式系统方向的经典论文它的目标是解决海量、稀疏、高并发写入的数据如何在线服务的问题。表里的数据按RowKey排序整个表按RowKey范围切成若干个Region分散到集群不同的节点上。每个Region内部每一行并不是一个扁平的宽表结构而是由一到多个列族组成列族是逻辑和物理上的基本边界每个列族内部有任意多的列列名不需要预先定义写入时动态加上去就行。每个单元格可以保留多个时间版本查询时能拿到某个时间点的值。这个模型的几个特点值得划重点第一行是主维度数据始终按行键有序所以最擅长的是RowKey点查和范围扫描第二列是稀疏的行里没有的列不占物理空间第三schema是活的加列不用改表结构在业务字段频繁变化的年代简直是救命稻草。当时很多团队把HBase叫“列式数据库”很大程度上就是因为“列族”这三个字带来的直觉——既然按列组织了那肯定是列式存储吧但物理存储根本不是这么回事。1.2 LSM树解决的是写放大不是分析查询HBase在存储引擎层面走的是LSM这套路新写入先进内存里的MemStore同时在WAL里记日志内存攒到一定阈值就flush成HFile文件写到HDFS上。文件越来越多之后通过后台minor compaction和major compaction合并整理。整个设计的目标非常明确把随机写变成顺序写用内存排序抵消磁盘随机IO换来的是一般场景下非常好的写入吞吐。需要说明的是每个Region下面的每一个列族都会独立维护一个MemStore所以列族数量不是越多越好列族多了内存压力会成倍放大flush和compaction的节奏也会互相干扰这是HBase表设计里一个非常经典的约束。这套设计解决的是“写放大”和在线服务延迟它从来就不是为“扫描几TB数据做聚合”设计的。后果就是一旦你让HBase去跑分析型SQL会发现处处别扭。点查RowKey时它可以通过布隆过滤器快速跳过大部分HFile速度很快可一旦是全表扫描它只能把一行一行的KeyValue从文件里读出来再把需要的字段逐个筛出来。你想做列裁剪对不起同一个列族内的数据虽然按列名排过序但物理上仍然是以单元格为单位存的行式组织扫描时依然要把整行的KV都遍历一遍才能拿到需要的列。想用min/max统计信息跳过无关数据HFile的block index和布隆过滤器是为点查设计的对范围聚合的帮助非常有限。1.3 一个类比部门档案柜与一沓卡片我给新同学讲这个区别时常用一个类比。HBase像一个按部门划分的档案柜每个柜子里是员工档案袋一个袋子装一个人的全部材料。你要统计全公司所有人的薪资只能一个个档案袋打开把薪资那一页翻出来再自己汇总。这个过程不是不能做但很慢而且你明明只需要一列数据却把每个档案袋整个过了一遍。真正的列式存储则是反过来的它把所有档案袋里的“薪资”这一页抽出来装订成厚厚一沓卡片卡片按顺序排好、整体压缩、只在这沓卡片上做运算。这一沓卡片就是Parquet或ORC里的一个列块。所以对“HBase算不算列式”这个问题我的答案是它借鉴了列族的思想但物理组织仍然是行式KeyValue它解决的是在线读写问题不是分析扫描问题。真实世界里的“列式存储技术演进”第一站其实是后面要讲的Parquet和ORC。2. 分析型负载逼出的真列式Parquet/ORC改变的不只是格式2.1 列式格式到底赢在哪里当数据平台的重心从“支撑在线业务”转向“支撑离线分析、数据仓库、机器学习取样”文件存储的诉求彻底变了。分析任务通常只关注几百个字段里的三五个而且要求快速吞吐整列数据去做过滤、聚合、join。列式格式就是为这个场景量身的列裁剪让你只读用到的列同一列的数值类型统一、重复率高压缩率能轻松做到行式存储的三到五倍每个列块自带min/max等统计信息查询引擎可以据此跳过大量无关文件列数据在磁盘上连续存放加载到内存后天然适合SIMD向量化执行。这些优势叠加下来同样一份数据用列式格式做全表扫描的IO量往往只有行式的十分之一甚至更低。2.2 Parquet文件里到底有什么Parquet这类列式格式本质上还是文件格式它的核心设计是把一个数据文件按“行组-列块-页”三层组织。写入时把一批行攒成一个行组行组内部按列切出一个个列块每个列块再切成若干个页页才是压缩和编码的基本单位。文件末尾的footer里集中存放了整个文件的元数据每个行组、每个列块的统计信息、编码方式、偏移量、字典页位置。查询引擎读文件时先拿footer再根据过滤条件决定哪些行组可以整个跳过哪些列块根本不用打开。这套“先看目录再动手”的机制让列式格式第一次把“读之前先删减”变成了现实也把文件级的数据跳过能力下放给了所有计算引擎。Parquet在嵌套结构上还引入了一套来自经典大规模嵌套数据存储论文的方法用重复层级和定义层级两个附加信息把任意复杂的嵌套对象拍平成列式存储同时又能完整还原出原来的JSON或对象结构。这一点对互联网场景格外重要因为业务数据几乎都是多层嵌套的日志、订单、行为事件纯平铺的表格很难表达。很多团队只盯着Parquet的压缩率忽略了这套嵌套表示能力其实它才是Parquet在日志类数据上不可替代的关键。2.3 ORC的同与异Stripe、三级索引与Hive生态ORC是另一个主流列式格式思路和Parquet类似但细节上有自己的坚持。它把文件切成Stripe每个Stripe里按列存块文件底部有footer元数据。ORC更早地把“索引”做进了格式内部文件级、Stripe级、行组级三层统计信息都有还内置布隆过滤器让Spark、Presto这类引擎可以用很小的代价判断一个Stripe是否需要读取。早期ORC和Hive生态绑定得更深Hive的ACID能力也是建立在ORC之上的后来逐步开放给Spark、Flink。选择哪个更多取决于团队生态如果你整条链路围绕SparkParquet更通用如果你对Hive数仓有历史包袱ORC也能很好工作。但无论Parquet还是ORC它们解决的问题都集中在“单个文件怎么存、怎么读”。一个分析任务往往涉及几十万个文件谁来保证这批文件的schema是一致的谁来保证同一时刻所有读者看到的是同一份数据谁来做修改表结构、修改分区策略时不重写数据文件格式回答不了这些问题于是演进到了下一层——表格式。3. Iceberg不是存储格式是“表格式”三层元数据解锁快照与ACID3.1 Iceberg站在哪一层很多人第一次接触Iceberg时会问它和Parquet是什么关系答案是上下层关系。Iceberg自己并不存数据数据的物理载体仍然是Parquet或ORC文件它管的是“这些文件如何组织成一张有schema、有分区、有版本、有一致性语义的表”。在计算引擎和文件系统之间它塞进来一层元数据管理层Catalog里保存表当前元数据文件的指针元数据文件是一份份JSON里面记录了这张表的所有快照每个快照通过Manifest List列出一串Manifest每个Manifest文件里记录了一组数据文件的路径、分区信息、列统计、文件大小。查一次数据的路径大致是这样引擎先到Catalog拿到最新的元数据指针读取元数据JSON拿到快照和Manifest List再读Manifest最后得到一批精确的数据文件路径按需打开Parquet文件读取。因为所有“文件清单”都是先统一拿到的引擎看到的是一致快照不会出现读到一半发现某个文件被另一个提交删掉的尴尬。这个设计和HBase从MemStore到HFile的路径完全是两个维度——HBase管的是单个Region内的文件组织Iceberg管的是整个表所有目录下的文件集合。3.2 快照隔离、时间旅行与乐观并发Iceberg把“每一次成功提交”定义成一个新快照。任何写入、删除、改schema的操作都会在旧元数据基础上生成一份新的元数据文件并原子地把Catalog指针切到新版本。老的快照不会立刻被删所以任何一个读者只要持有了某个快照的文件清单就可以不受影响地继续读。这就是表级快照隔离。时间旅行也因此变成一件很自然的事情只要指定一个历史快照ID或时间戳就能看到那张表当时的完整状态这在数据回滚、审计、复现bug时非常有用。需要注意的是快照保留是成本每多留一个快照就多一份manifest开销所以“能查多久之前”和“元数据多大”需要专门做权衡。并发控制也很有意思。Iceberg没有用全局锁而是采用乐观并发几个write各自基于同一份元数据写自己的文件提交时通过Compare-And-Swap尝试把自己生成的新元数据指针写回Catalog如果发现Catalog里已经不是自己看到的那一版就重新读、重新计算、再试。这套机制在多流同时写同一张表时仍然能保持数据库级的隔离性比“Hive表加个分区互斥”的粗放做法精细得多。我在实际环境里见过Flink Kafka链路和Spark批任务同时写一张Iceberg表两边都没加锁跑了好几个月没有出现数据错乱靠的就是这一层乐观控制。3.3 Schema演进和分区演进为什么不需要重写数据传统Hive表改schema尤其是改列名、调整列顺序、改分区字段通常意味着刷一遍全量数据。Iceberg的核心技巧是给每个字段分配了永久的字段ID改名、加列、删列、调整顺序这些操作记录在元数据里底层数据文件完全不用动读取时靠字段ID而不是列名来对应所以历史文件虽然用旧名字写的也能被新schema正确解析。分区演进同样如此你可以在某个时间点把分区策略从“按天”改成“按月”Iceberg允许同一张表的不同快照使用不同分区布局新数据按新策略写旧数据保持原样查询时按需匹配不用全量重写。还有一个容易被忽略的设计是隐藏分区。传统表如果按时间字段做分区得先在业务表里冗余存一个“日期”分区列还要保证应用层写对Iceberg允许直接声明“按ts字段的天做分区”分区值由引擎推导业务不用管物理目录这样既避免了分区列和业务列不一致的问题也让分区裁剪变得可靠。在Iceberg v2里还能看到另一层进步更新和删除不再是“重写整个分区文件”一种解法而是引入了delete file机制支持position delete和equality delete做UPSERT时可以走merge-on-read控制住写放大。这让我很明确地说Iceberg要解决的不只是“读的效率”还有“数据变了之后表怎么维护”。4. 业务选型什么场景留在HBase什么场景迁向Iceberg4.1 一张对比表先看清边界维度HBaseHive传统表Iceberg核心定位在线服务、高效点查离线批量分析湖仓分析、批流一体物理存储行式KeyValue列族Parquet/ORC等列式文件列式文件表级元数据单位操作单行、行范围扫描全表/分区扫描全表/分区/快照扫描查询延迟毫秒级点查秒到分钟级秒到分钟级事务能力单行原子无多行事务基本无表级快照隔离、ACIDSchema演进动态列无需预定义多数要重建不重写数据在线演进历史追溯单元格多版本行级无快照级时间旅行适合场景用户状态、订单详情、推荐KV传统数仓ETL数据湖、流批一体、特征存储这张表最想传达的一点是HBase和Iceberg不是同一种东西的替代关系前者是数据库式的在线服务引擎后者是数据湖里的表组织方式。拿“HBase能不能换成Iceberg”这种问题来问本身就说明没把定位分开。Iceberg的扫描延迟和它底层的列式文件绑定做不了毫秒级在线点查这一点无论怎么调优都改变不了。4.2 现实中的混合架构HBase继续服务在线Iceberg接管分析我在实际项目里见过的最常见形态不是二选一而是各干各的。在线服务链路继续用HBase它依然是点查之王读路径经过布隆过滤器能在几十毫秒内拿到一个用户的最新状态或一笔订单的完整明细LSM的写入特性也让高并发打点没有压力。与此同时分析链路单独建一条数据湖业务消息进KafkaFlink做实时清洗并写入Iceberg表Spark或Presto跑报表和特征任务。HBase里积累的宝贵历史数据可以定时以快照形式导出到Iceberg和实时链路的数据合并供分析使用。这样HBase的在线延迟优势没有被破坏分析查询也不再受HBase扫描能力的拖累。这种架构还有一个好处Iceberg天然支持流批一体。Flink用CDC或消息流持续写IcebergSpark批任务又在同一张表上跑T1报表两者通过快照隔离互不干扰。这在几年前几乎是不可想象的——以前要么实时一套、离线一套两套数据还经常对不上要么把分析强压在HBase上SQL跑起来又慢又耗资源。所以我一直建议团队把HBase当作“状态存储”而不是“分析数仓”分析的事交给湖上那一层。4.3 迁移前的成本和风险评估清单决定迁移之前建议先填一遍下面这个清单第一你的查询模式是点查为主还是聚合扫描为主如果业务99%是RowKey点查那留在HBase是正确答案别折腾。第二分析任务当前跑得慢的瓶颈到底是存储格式、文件数量还是下游计算资源不足有时候单纯给Spark加资源、把Hive表换成Parquet分区表就好了不需要全套上Iceberg。第三数据一致性要求如果需要跨表、跨分区的原子提交和回滚Iceberg优势明显如果只是“每天覆盖一次分区数据”传统分区表也能凑合。第四团队维护能力Iceberg引入后快照过期、孤儿文件清理、manifest合并、小文件治理都是新增日常任务没有专人盯的话半年后可能比HBase更乱。5. 一次真实的迁移复盘从HBase导出到Iceberg的完整过程5.1 背景与方案选型为了把抽象的东西落到地上我讲一个做过的模拟项目某运营分析平台近三年订单明细存在HBase里每天凌晨用一个批量任务全表扫描导出到HDFS再挂Hive分区表跑报表。随着单量增长每天全表扫描越来越慢而且Hive表schema调整频繁分区字段还改过一次。当时决定把历史订单迁到Iceberg底座还是Parquet查询引擎用Spark。迁移方案先过了几轮纯HBase工具导出再手工转换太绕用ExportSnapshot把HBase快照导成文件再用Spark读适合停机迁移最终选了在线迁移——Spark通过HBase的Connector直接并发扫描转成DataFrame再写Iceberg表。好处是迁移期间HBase完全不用停可以多次增量同步。这份经验想说明的是迁移方案不是选“最先进的”而是选“对当前业务影响最小的”在线迁移能用多轮增量把风险摊薄通常比一次性停机切换稳妥得多。5.2 最容易翻车的三个细节第一个坑是RowKey。早期为了均衡写入RowKey前缀加了散列盐值导出后才发现盐值字符串混在业务键里。解决方式是单独做一层解析函数把盐值剥离后再按规范拆分成订单ID、用户ID、创建时间等字段。如果表里原先就把多个维度拼在RowKey里迁移前务必梳理一份“RowKey解析规范”否则后面每张表都踩一遍。这个工作看起来简单实际做起来远比想象中烦因为历史数据里会有各种奇奇怪怪的写入习惯解析函数要兼容老格式和新格式。第二个坑是版本。HBase的Cell保留了多个历史版本直接搬会让数据量翻几倍而且分析场景几乎永远只用最新值。所以读取时把扫描限定在最近的时间范围并且只取最新版本这样导出数据量才和业务行数一致。如果确实需要历史版本分析那得单独设计一张version表而不是原样搬。当时我们有一张表因为没过滤版本导出后数据量是业务行的四倍跑完发现对不上排查了半天才定位到是版本问题。第三个坑是列映射和空值。HBase是稀疏存储某一行没有的列在物理上不存在Iceberg的字段默认允许null但Spark读出来的DataFrame可能把缺失列变成null而不是0或空串下游聚合时很容易出现“以前HBase这个字段默认是0现在变成null”的隐性问题。建表时要把默认值和nullable语义提前对齐别等报表数据对不上了再找。5.3 写入调优与数据校验写Iceberg时我用Spark任务按用户ID做了一次重分区再按订单时间排序这样落到Iceberg表后文件天然和分区策略匹配避免了一次写入产生大量跨分区小文件。文件大小目标控制在单文件两三百MB左右通过write.target-file-size-bytes参数调整不过这个值受集群内存和任务并发数影响别贪大一般先试跑一天数据看文件数和查询耗时再定。文件太大后续重写和裁剪的粒度都会变粗文件太小NameNode和查询引擎都难受这个度要在自己的集群上实测。数据校验我做了三层第一层是行数Spark统一从HBase和从Iceberg各跑一次count两边的计数必须一致第二层是主键集合抽样对比订单ID的哈希值集合是否一致防止漏行或重复行第三层是字段值按时间分区抽样对金额、状态几个关键字段做sum和count比较误差必须为零。校验通过后再把增量链路切过去而不是一次性全量切换。这套校验顺序很重要行数错了直接打回别急着看字段主键集合不一致说明有重复得先查写入去重逻辑。5.4 迁移后的小文件治理与分区规划迁移完成后最常被忽视的是小文件。如果在HBase侧导出时每个Region产出一个文件写进Iceberg可能直接散成几千个小文件查询时打开文件的开销甚至大过读数据本身。我用rewrite_data_files把分区内小文件合并成大文件并且顺手对订单时间做了排序排序后的文件配合分区统计信息让Spark在做时间范围过滤时能跳过大量文件。这一步不要只在迁移时做之后每跑一轮增量写入都得定期检查文件数。另外记得及时清理历史快照。迁移测试过程会留下非常多的历史快照不清理的话元数据会越来越大Catalog读写都会变慢。数据文件的物理删除和元数据清理是有时间差的清理快照时千万确认还有没有长任务在引用旧快照否则可能把正在用的文件标记成可删。我在生产里吃过这个亏后来不管是在测试环境还是生产环境清理前都会先跑dryRun看一遍清单再确认执行。6. 运维视角Iceberg的日常维护与新手最容易踩的误区6.1 快照、孤儿文件与元数据维护节奏Iceberg每次写入、删除、更新都会生成新快照长期不治理Catalog里会堆积大量无用的manifest和快照元数据。我一般按环境不同设置维护周期测试环境每天跑一次快照过期和孤儿文件清理生产环境每周跑一次大维护同时根据表写入频率做manifest合并。下面这段Spark SQL式的调用基本是每次维护都要跑的动作-- 快照过期只保留最近3个快照并清理早于指定时间的快照 CALL demo.system.expire_snapshots( table ods.order_detail, older_than TIMESTAMP 2024-12-31 00:00:00, retain_last 3 ); -- 文件重写把小文件按binpack策略合并可附带排序 CALL demo.system.rewrite_data_files( table ods.order_detail, options map(rewrite-all, true) );删除孤儿文件前同样要先看dryRun结果。尤其当多个任务共享同一份文件系统目录时误删公共目录文件是真实发生过的生产事故。我的原则是凡是涉及删除的操作先只读、再小范围、最后全量每一步都有日志和快照兜底。6.2 几个常见的认知误区第一个误区是“用了Iceberg就自动变快”。提速的真正来源是列裁剪、分区裁剪、文件级统计信息跳过这些的前提是表设计合理分区粒度合适、写入文件不小、排序有序。Iceberg只是把“文件级别的优化”提升到了“表级别”它不替你设计数据布局。同一份数据分区乱、小文件多在Iceberg上跑和在Hive上跑一样慢。第二个误区是“既然支持并发写我就可以无脑开几十个任务同时写一张表”。乐观并发虽然避免脏写但冲突严重时重试会浪费大量资源设计上还是要尽量按分区或按主键范围划分写入责任把冲突控制在低频。尤其是高频的Flink流式写入和低频的Spark批写入混在一起时批任务提交瞬间的冲突会很集中最好把批任务调度到流量低谷。第三个误区是“Catalog随便选个就好了”。Catalog是表元数据一致性的关键用共享的Hive Metastore可行但要注意把Iceberg和Hive表的命名空间隔离避免版本冲突项目规模大了之后托管的Table服务或自建REST Catalog更容易做好权限和审计。Catalog一旦出问题不是某张表读不了而是整条分析链路都瘫痪所以它的高可用和备份策略要按核心组件来对待。6.3 从存储演进看到的方向回看这条线索在线时代需要点查和写吞吐于是有了LSM和列族分析时代需要扫描效率和压缩于是有了列式文件格式再往后数据湖需要把一堆文件变成一张有事务语义的表于是有了表格式。这个趋势背后其实只有一个主题存储层不断把管理职责从应用层上移让上层引擎可以把更多精力放在计算本身。未来我看到的方向是元数据服务化和自动化维护Catalog变成独立服务快照清理、文件合并、分区优化变成平台自动完成的动作而HBase和Iceberg这类组件将各自守住在线和分析的边界长期共存。最后说点个人体会。我见过不少团队在HBase和Iceberg之间反复横跳本质都是没有先想清楚自己的查询模式和数据生命周期。如果你还在犹豫我的建议是先挑一两个月的历史数据做迁移验证跑通上面说的完整校验链路再决定要不要全量推进千万别一上来就把整套生产数据搬到新存储上等发现文件布局不合理时回退的成本远高于当初慢慢验证的时间。存储选型这条路没有银弹但把每个组件到底解决什么问题想清楚了你就不会走太多弯路。