★ FEATURED ARTICLE 1. 从双轨制到统一底座城商行大数据平台的破局思路1.1 传统架构的尴尬处境不少城商行前些年的数据架构基本脱不开这样一个套路数仓用CDH来做离线批处理和Hive数仓与此同时再单独部署一套Elasticsearch集群把明细数据同步过去扛即席查询、日志检索、风控指标等在线场景。表面上看各有分工但真正跑起来之后问题一个接一个浮出水面。先看CDH这边。Cloudera在CDH 6.x之后就宣布不再提供开源免费版本商业版转向CDPLicense费用对城商行这种体量来说并不是一笔小数目。更要命的是CDH本身组件版本相对陈旧HDFS、YARN、Hive、Spark这些核心组件的版本多年不更新新版本生态里的很多特性用不上一旦遇到Bug社区资料也少得可怜。再看Elasticsearch这边。ES本身是个好产品全文检索、倒排索引、聚合分析都非常能打但问题在于它和数据平台主链路是割裂的。数据从业务库同步到数仓再从数仓同步到ES同一份数据存了两遍甚至三遍存储成本成倍上升。而且ES集群的运维复杂度不低——分片规划、JVM堆内存调优、索引生命周期管理、主分片恢复策略每一项都是需要专人盯着的活。城商行的科技团队本来人手就紧同时维护CDH和ES两套技术栈长期下来运维压力非常大。1.2 场景驱动的替换诉求真正推动替换的往往是几个非常具体的业务痛点而不是架构洁癖。第一个痛点是数据一致性。数据从Hive同步到ES的过程中一旦同步任务出问题两边数据就对不上了。业务部门拿着数仓的口径和ES查询的结果对账对不上就质疑平台数据有问题技术团队疲于解释和修复。第二个痛点是资源利用率。ES集群的节点规模通常按峰值流量规划但日常大部分时间的负载并不高计算资源大量闲置。而数仓集群这边跑大任务的时候又常常资源紧张两边一松一紧就是没法互通。第三个痛点是信创和合规要求。城商行作为持牌金融机构在基础软件国产化替代方面有明确的政策要求。CDH和Elasticsearch都是国外开源产品虽然在金融行业用了很多年但面向未来的合规压力越来越大早点动手替换后面的主动权就更大。1.3 统一底座的设计目标综合这些背景替换方案的核心目标可以概括为三条一套存储、一套计算、一套权限。一套存储指的是不再让数据碎片化地散落在多个独立系统里而是用统一的表格式Table Format管理数仓数据、明细数据、日志数据让一份数据支撑多个场景。一套计算指的是OLAP查询、离线批处理、实时计算都跑在同一套资源调度框架上可以动态调配资源不再各管各的。一套权限指的是行级、列级权限、数据脱敏策略统一下沉到存储层不管是哪个引擎来查数据都走同一个权限校验逻辑。坦白讲这三条目标对任何一家中型金融机构来说都不是一蹴而就的工程。城商行的优势在于数据体量相对可控——通常就是几十TB到几百TB的规模远没有互联网大厂那种动辄PB级的压力——所以方案选择的余地反而更大有机会用更现代化的架构一步到位。2. 方案选型用什么替代CDH和Elasticsearch2.1 计算引擎与存储格式的重新选型替代CDH首先要解决的是数仓底座的问题。核心矛盾在于既要保留Hive数仓的成熟生态和SQL习惯又要解决Hive在事务支持、增量处理、小文件治理上的老毛病。我实操下来比较顺手的路径是采用Spark Hudi/Iceberg StarRocks的组合。具体来说离线批处理继续用Spark SQL但底层表格式换成Hudi或者Iceberg它们支持ACID事务、upsert、时间旅行和增量读取能解决传统Hive表更新数据必须全表覆盖的痛点。报表和即席查询引擎换成StarRocks它有极速的MPP查询能力还自带全文检索功能可以部分替代Elasticsearch的检索场景。这个组合对比CDHES的优势非常明显对比维度CDH ElasticsearchSpark Hudi StarRocks数据存储HDFS ES索引多副本双份存储HDFS/对象存储统一一份StarRocks可建物化视图数据一致性同步链路割裂需自行保障Hudi统一管理表引擎直读权限管理两套独立权限体系统一走Ranger行级列级统一下沉运维成本两套集群两套监控一套资源池运维面大幅收窄信创适配国外商业发行版License成本高开源组件为主可按需替换2.2 Elasticsearch的替代思路Elasticsearch最核心的能力是全文检索和倒排索引替代它之前要先想清楚业务到底在用ES的什么能力我接触过的城商行ES场景大概能分成三类。第一类是日志检索比如应用日志、操作日志的统一检索特征是全文本扫描、时间范围过滤、按关键字查。第二类是业务明细的即席查询比如在几十亿条交易明细里按客户ID、时间、渠道组合条件筛选特点是高并发、多维过滤、分页排序。第三类是风控规则的实时匹配比如实时流里做特征命中对延迟要求极高。这三类场景里第一类和第二类StarRocks都能接得住。StarRocks从3.0版本开始支持全文检索虽然倒排索引的实现深度和ES还有差距但对绝大多数金融业务场景已经够用。第三类实时风控匹配通常已经在用Flink做流式计算特征和规则本身就维护在状态后端里也不依赖ES的检索能力。我建议走一步看一步不要一开始就追求对ES功能的全量覆盖。先把数据同步链路断掉把即席查询和日志检索切到StarRocks跑顺一个季度再评估是否还有必要保留ES集群。实操中大部分场景切过来之后ES集群就可以逐步缩容下线了。2.3 资源调度和集群部署策略统一底座的落点最终是资源的统一调度。CDH时代用的是YARNES独立集群自己管资源替换之后要让所有计算引擎跑在一套YARN或K8s资源池上。这里有个关键决策到底用YARN还是用K8s。坦白说城商行科技团队对K8s的掌握程度普遍不如对YARN熟而且现有Spark、Hive、Flink的任务调度体系和YARN的整合已经非常成熟迁移成本低。所以我的建议是初期保留YARN作为统一资源调度器计算引擎全部跑在YARN上后续再逐步演进到K8s。集群规模规划上给一个参考总数据量在100TB以内的城商行Master节点3台Core节点5到8台存储用HDD加SSD分层计算和存储不强制分离。单节点配置建议32核128G起步配4块以上的NVMe SSD做热数据缓存这样StarRocks的查询性能才能发挥出来。3. 核心架构设计与落地实现3.1 整体架构分层整个统一底座架构我把它分成五层来看每一层的职责都非常明确存储层HDFS或兼容S3协议的对象存储统一承载所有数据文件。Hudi/Iceberg表格式在这一层管理数据的文件布局、事务和增量。计算层Spark负责离线批处理和ETLFlink负责实时计算Presto/StarRocks负责即席查询。所有引擎都通过统一的资源调度器获取资源。服务层StarRocks作为统一查询入口对外提供标准SQL接口、全文检索能力和高并发点查能力。数据服务API统一从这里出。治理层Apache Ranger统一权限控制Atlas或DataHub做元数据管理数据质量校验规则在这里配置。调度层DolphinScheduler或Apache Airflow统一编排所有数据任务替代原来分散在多个系统里的定时脚本。这个架构的核心思想是把“存储”和“计算”解耦再让“权限”成为所有引擎的共同底座。业务方访问数据不再关心数据存在哪、由哪个引擎计算只面对一套标准的SQL接口和统一的数据权限。3.2 统一权限体系的设计与落地权限统一是替换过程中最容易被低估的工作量也是我最想强调的一个环节。CDH时代可以靠Hive的库表权限糊弄过去ES则是完全独立的一套用户体系和索引级权限两套之间没有打通同一个用户在两边的权限可能不一致安全审计非常被动。统一权限体系我推荐直接上Apache Ranger Hudi/StarRocks插件的组合。Ranger负责定义和管理权限策略支持行级过滤、列级脱敏、标签式授权这些高级功能然后通过插件下发到各个计算引擎。具体设计上分三步走第一步把用户和用户组理清楚。城商行通常就是零售、公司、风险、财务、运营这几大条线每个条线下挂对应的应用账号和人工账号不要搞太细的粒度否则后面策略维护成本受不了。第二步定义数据分级的标签体系。比如客户信息、账户信息、交易流水属于敏感数据配置列级脱敏策略特定机构的数据只允许本机构用户访问配置行级过滤策略。第三步把Ranger的插件装到Spark、StarRocks、Flink上让所有引擎都强制走Ranger的鉴权逻辑。这个步骤要放到数据迁移之前做否则数据迁完了新平台权限还没控住业务根本不敢放量接入。3.3 数据同步与迁移路径从CDHES迁移到新底座最核心的工作是数据迁移这里最忌讳的就是“全量割接”。我的经验是分批次迁移、双跑验证、逐步切换流量。第一批迁移的是离线数仓的核心层数据。从Hive里把建表语句导出来转换成Hudi表的DDL然后用Spark任务做全量数据回放。这一批的目标是把数仓底座的“骨架”搭起来Hive任务先不迁移新旧平台并行跑。第二批迁移的是ES里的业务明细数据。把ES索引映射转成StarRocks表的Schema用同步工具从ES里全量抽取数据写入StarRocks。注意ES里的数据是扁平化的文档结构嵌套字段、数组字段转StarRocks的建表方式要提前设计好不要简单地照搬字段类型。第三批迁移的是ETL任务和调度。把Hive SQL、Spark任务从旧平台迁到新平台优先迁移日批任务再迁移小时级和实时任务。调度统一收到DolphinScheduler里做好依赖关系梳理和告警配置。3.4 数据回放过程中的一致性保障数据迁移过程中的数据一致性是让很多团队栽跟头的地方。我提供两个基本原则第一全量数据做校验不做抽样。每次迁移一批表之后用校验工具对源和目标做全字段、全量行的比对主键、字段值、记录数都要一致。城商行的数据量级完全撑得住全量校验不要图省事只做count字段值不对才是最隐蔽的问题。第二增量链路先跑通再切流量。全量数据迁移完成后立刻启动增量同步任务让新旧平台的数据保持准实时一致。在这个阶段业务查询可以继续打旧平台新平台只做数据同步和比对跑一个星期不出差异再考虑切流量。4. 实操过程与关键环节的踩坑实录4.1 Hive表到Hudi表的DDL转换Hive迁移到Hudi看起来只是把表格式换一下实际操作里有一堆细节。首先是主键设计。Hudi表必须要有主键但Hive表通常没有。选择主键的时候要格外小心不能随便拿一个业务字段当主键——如果这个字段在业务上存在更新覆盖的情况主键冲突会导致数据丢失。我建议优先用“业务主键数据日期”的组合主键既能保证幂等写入又方便按天做增量管理。其次是分区策略。Hudi支持Hive风格的分区字段但要注意分区字段的基数。城市商业银行的数据通常按“日期机构号渠道”分区是合理的但要避免把客户ID这类高基数字段作为分区字段否则会产生大量小文件。还有一个容易踩的坑是文件大小。Hudi默认的文件大小是128MB迁移初期如果数据量不大会产生大量几十KB的小文件后续查询性能会很差。建议调大文件大小参数到256MB同时开启小文件自动合并功能。我们实测算下来这个参数调整可以让后续查询性能提升40%以上。4.2 ES索引迁移到StarRocks的字段映射ES里的字段类型和StarRocks不是一一对应的迁移时要逐字段梳理映射关系。ES的keyword类型通常映射为StarRocks的STRING或VARCHARtext类型在StarRocks里可以建STRING配合全文索引来使用。但这里有个重要区别ES的text字段会自动做分词和倒排索引StarRocks需要显式地为字段创建NGram或倒排索引否则查询性能会打折扣。我建议迁移时先把索引需求列清楚哪些字段必须支持模糊匹配哪些只需要精确匹配再针对性地建索引。嵌套字段是另一个麻烦。ES文档支持任意深度的嵌套StarRocks在3.x版本虽然支持了嵌套类型但查询语法和ES差异较大。实操上我建议能拍平就拍平把嵌套的对象字段转成多个平铺字段或者JSON字符串查询时用JSON函数解析。确实需要保留嵌套结构的再考虑StarRocks的Array和JSON类型。数据同步方式可以用Flink CDC从ES全量抽取到StarRocks也可以用DataX之类的离线工具。ES数据量不大、又不要求实时性的场景我倾向用DataX简单稳定需要准实时同步的用Flink任务处理更合适。4.3 存量SQL任务改造的方言兼容存量任务迁移到新平台最现实的问题是SQL方言差异。Hive SQL和Spark SQL之间其实兼容性不错毕竟同源但涉及UDF和特定语法时还是会出问题。我这里分享一个经验先做静态扫描再做动态测试。把所有存量Hive SQL脚本收上来用脚本扫描Hive和Spark的方言差异点——比如LATERAL VIEW和EXPLODE的写法差异、INSERT OVERWRITE的行为差异、自定义UDF的注册方式等等。先用工具扫一遍能提前发现八九成的问题。剩余的问题用动态测试来兜底在测试环境把任务全部跑一遍对比新旧两个平台的执行结果。最保险的做法是拿生产数据的一个分区做全量跑批然后逐表对比结果。这一轮往往能发现静态扫描发现不了的问题比如UDF里依赖了Hive的隐式类型转换规则Spark下结果不一致。另外存量任务迁移的时候不要图省事把所有任务一次性迁完。按数据域分批迁移每批次包含关联度较高的表迁移完跑一个星期确认没問题再迁下一批。分配好迁移窗口给业务留出足够的验证时间。4.4 元数据打标和数据质量规则的配置统一底座建好之后如果没有元数据管理用不了多久又会变成新的混沌。这块我的做法是在上线第一批数据迁移的同时就把元数据打标的底子打好。用Atlas或DataHub把表、字段、分区、任务的元数据全部采集上来然后做三件事。第一给表和字段打业务标签比如“客户信息”“交易流水”“手机号”“身份证号”后续所有权限策略和脱敏策略都基于标签来配置而不是基于表名硬编码。第二配置数据质量规则包括非空校验、主键唯一性校验、枚举值范围校验、表行数波动监控规则统一在数据质量平台上配置跑批任务完成后自动触发校验。第三建立血缘关系让业务人员能追踪“这个报表的数据从哪几张表来、经过了哪些加工逻辑”解决数据信任问题。因为权限模型和标签体系已经挂钩后续新增表的时候只要打上标签权限策略就自动生效了。这也是我在实操中感受到的最有价值的收益——它让“权限管理”从一次性的配置工作变成了可持续运转的机制。5. 常见问题与排查技巧实录5.1 Hudi表小文件问题现象数据入湖之后HDFS上产生了大量小于50MB的碎片文件查询任务变慢NameNode压力增大。排查思路先看Hudi表的FileGroup数量和每个FileGroup下的FileSlice数量。如果FileGroup特别多说明写入并发度太高或者分区字段基数太大如果FileGroup数量正常但每组的文件多说明Clustering没有及时触发。解决办法第一合理设置写入任务的并发度和目标文件大小让Spark写入阶段的输出文件尽量接近256MB的设定值第二开启Hudi的Clustering服务设置周期性的小文件合并计划比如每天凌晨执行一次第三对于已经产生的碎片文件跑一次手动Clustering把它们合并掉。5.2 StarRocks全文检索与ES查询语义的差距现象ES迁移过来的检索场景部分查询在StarRocks上结果不对比如分词方式不一样查询“北京银行”在ES里能匹配到“北京”和“银行”的任意组合StarRocks默认的全文索引却按NGram分词需要重新调参。排查思路先确认StarRocks的全文索引配置里NGram的gram_num参数。中文字符场景2元分词是比较合理的默认选择但如果业务经常做单字匹配或者短语匹配就要调整gram_num或者改用CHAR_NGRAM分词。解决办法我建议提前对需要支持全文检索的字段做一个“检索需求清单”。把每个字段期望支持的查询模式列出来——是精确匹配、前缀匹配、还是包含匹配然后针对性地设计索引。StarRocks的全文检索能力在持续增强但现阶段它更擅长的是“关键词结构化条件”的组合过滤大批量的全文扫描性能还是不如ES这个预期要管理好。5.3 权限策略不生效的排查现象Ranger的权限策略配置好了但通过某个引擎查询还是能读到不该读的数据。排查思路先确认Ranger插件是否已经正确安装到对应的引擎上。Spark和StarRocks的Ranger插件需要在引擎配置里显式启用很多情况下是插件根本没装上。再确认权限策略的作用范围对不对Ranger的权限策略可以按库、表、列、行来配置如果策略里没配置列级脱敏那查询默认是不会脱敏的。解决办法配置完成后一定要用权限测试账号实际跑一遍查询验证效果不要只看Ranger界面上的策略列表。我这里踩过的一个很深的坑是Spark SQL的Hive Metastore直连不走Ranger数据通过Metastore接口被绕过。后来强制所有引擎都走统一的Catalog接口才彻底封住了这个洞。5.4 Flink实时任务的checkpoint恢复现象实时同步任务在运行过程中频繁重启重启后数据重复或丢失。排查思路先确认checkpoint目录的配置和文件系统的权限。城商行如果没有专门的存储checkpoint目录很可能直接配在本地磁盘或临时目录里一旦任务重启checkpoint数据就丢了。解决办法把checkpoint目录配置到HDFS或对象存储上并且开启checkpoint的自动清理策略避免历史checkpoint文件无限堆积。实操上我会把Flink的checkpoint间隔设为60秒同时配置最多保留5份checkpoint这样既能保证恢复点不会太旧也不会占太多存储。6. 运维保障与团队能力建设6.1 监控告警体系的建设统一底座上线后监控体系要覆盖三层基础设施层、大数据组件层、数据链路层。基础设施层管机器指标比如CPU、内存、磁盘IO、网络流量大数据组件层管HDFS健康状态、YARN资源使用率、StarRocks的BE节点状态、Hudi表的提交时间数据链路层管数据任务的执行状态、同步延迟、数据质量校验结果。我去过不少城商行的机房里看过监控平台搭了不少但告警阈值设得过于保守等告警发出来的时候事故已经发生了。这里我的建议是核心链路指标必须设三级告警。比如同步任务的延迟超过10分钟告警超过30分钟PagerDuty级别告警超过1小时直接通知运维负责人。宁可多收告警也不能漏告警。6.2 团队技能转型的培养路径从CDHES迁移到新架构不只是技术栈的替换更是团队技能的升级。原来维护CDH的工程师要学Spark、Hudi和StarRocks维护ES的工程师要学StarRocks和Flink这对团队来说是不小的挑战。我的建议是分三步走。第一步挑一两个核心成员派到开源社区或者靠谱的技术培训机构做深度培训回来后做内部知识分享形成“核心带骨干骨干带全员”的传帮带模式。第二步选择一个非核心业务场景作为试点全程由内部团队动手实施在真实业务中积累经验。第三步试点跑通之后再逐步扩大覆盖范围把核心数仓和检索场景都迁过来。还有一个切身体会不要只靠手工排查问题要在迁移过程中顺手把问题复盘沉淀成文档。每次踩坑都记下一两页的排查笔记半年之后就是一份非常宝贵的团队知识库。这个习惯比任何培训都管用。6.3 数据链路健康度巡检统一底座上线之后我建议每周做一次数据链路健康度巡检。巡检的核心内容有四项第一检查所有数据同步任务的延迟和成功率找出连续失败超过3次的任务第二检查Hudi表的提交时间和小文件情况确认没有出现长时间未提交或者碎片严重膨胀的分区第三检查StarRocks的查询性能统计慢查询数量分析Top N慢查询的SQL模式第四检查Ranger的权限策略变更记录和审计日志确认没有异常授权。这个巡检制度看着简单但坚持下来效果很显著。它能让团队在业务方发现问题之前就主动发现和解决平台的问题是平台稳定性最重要的一道防线。7. 最后一点实践体会回到最初的话题替代CDH和Elasticsearch、构建统一的企业级大数据底座对城商行来说真正难的不是技术选型也不是集群搭建而是“统一”这两个字的落地。统一存储、统一计算、统一权限、统一运维每一项都需要动到存量系统的奶酪每一项都需要业务部门的配合与信任。我在实操中的一个深刻体会是不要试图用一次大工程解决所有问题。先定一个半年期的目标把架构的骨架搭好把最核心的离线数仓和明细检索切过来跑稳了再逐步扩大范围。数据的迁移、任务的改造、权限的梳理每一项都是脏活累活但每一步走扎实了后面替换的成本就会越来越低。过程中我还想多说一句用StarRocks替代Elasticsearch的检索场景并不代表ES一无是处。ES在全文检索的深度上依然有优势但城商行的业务场景并不需要那么强的全文搜索能力。先把重复存储的链路断掉把权限统一起来把运维复杂度降下来这才是统一底座要解决的核心问题。如果你们也正在经历类似的架构替换过程务必先抓两件事一是统一权限尽早做二是数据校验全程做。这两件事做好了其他问题大概率都能在可控范围内化解。希望这篇实操记录对你们有参考价值。
阅读完成 · 觉得有帮助？
