数据平台搭建，为什么先谈架构选型？

政务系统和企业软件定制的痛点，往往不在“写代码”本身，而在于数据从分散到汇聚、从脏乱到可用、从离线到实时的链路是否稳固。成都迪吉信息技术有限公司在承接数据平台搭建项目时，第一件事从来不是急着部署组件，而是和客户一起厘清业务场景的吞吐量、时效性要求与未来三年的数据增长预期。这决定了选型的方向，也决定了平台是“能用三年”还是“要推倒重来”。

从Lambda到Kappa：实时与批处理的博弈

很多团队纠结于Lambda架构的“双链路”复杂度，又担心Kappa架构在纯实时场景下的回溯能力不足。我们的实操经验是：如果业务对数据延迟容忍度在分钟级以内，且历史数据重放需求频繁，优先考虑Kappa架构的流批一体方案——比如基于Flink + Iceberg的组合，既保留流处理的低延迟，又通过数据湖的ACID能力弥补批处理短板。反之，若报表体系庞大且对成本敏感，再退回到Lambda，但务必用统一SQL引擎（如Trino）掩盖底层两套引擎的差异。

存储选型：不能只看“快不快”

数据平台搭建中，存储层的坑最多。我们曾遇到一个政务项目，初期选用纯HDFS存储，结果半年后小文件数量超过2000万，NameNode内存直接打满。后来切到JuiceFS + 对象存储的组合，把元数据压力下沉到Redis和数据库，整体读写性能反而提升约40%。这不是说HDFS不行，而是说选型必须匹配文件规模特征。对于中小规模数据（TB级以内），ClickHouse+对象存储的轻量组合往往比重型Hadoop生态更划算——运维成本降低至少50%，查询性能却快一个数量级。

计算引擎：CPU换时间，还是内存换效率？

这个问题的答案取决于预算和数据量级。我们做过对比测试：在同等100GB数据量的聚合查询场景下，Presto/Trino的响应时间约为Spark SQL的1/3，但内存消耗高出2倍。如果客户的数据量在PB级以下，且查询并发不高，我们强烈建议直接用Trino，省去Spark集群的调优成本。反之，如果涉及复杂的机器学习特征工程或大规模ETL，Spark的稳定性优势就体现出来了。成都迪吉信息技术有限公司在信息化运维服务中，通常会在同一平台内混用两种引擎——用Trino跑即席查询，用Spark跑定时批任务，两者通过统一的Catalog（如Hive Metastore）共享元数据。

选型落地时的三个“反直觉”建议

• 别盲目上K8s：如果运维团队小于3人，用Docker Compose或裸机部署反而更可靠。我们见过太多小团队被K8s的证书轮换和网络策略拖垮。
• 优先考虑“带存储的计算”：像StarRocks或Doris这样的MPP数据库，集存储与计算于一体，对于10亿行以内的明细查询，比“HDFS+Spark”的方案简单十倍。
• 监控先行：在架构图上画好Prometheus/Grafana的监控指标（如背压率、Flink Checkpoint时长），比事后调优省力得多。

数据平台搭建没有银弹，但成都迪吉信息技术有限公司的实践表明，架构选型80%的工作在于梳理业务约束，而非对比技术参数。我们提供企业软件定制、政务系统开发、数据平台搭建、信息化运维服务，核心价值就是帮客户避开那些“看起来很美”的复杂方案。如果您的团队正在纠结于某个组件版本或架构决策，不妨让我们用过往十几个项目的踩坑记录，帮您少走一段弯路。