1. 需求先行数仓项目到底在解决什么问题先说点实在的。我每次接手数仓项目第一件事不是打开浏览器查组件版本而是把项目需求按人话复述一遍。因为数仓这玩意儿本质上没有标准答案你选的每一套框架、每一台服务器、每一个版本都是被需求倒逼出来的。需求搞错了后面整个技术选型就是空中楼阁砸钱砸时间最后产出一堆谁也说不清楚能不能信的报表。这个项目我参与的时候业务侧的核心诉求其实很朴素把散落在多个业务系统里的订单、用户、商品、营销、渠道数据统一收口做出一套能支撑日常经营分析、用户画像、精细化运营的指标体系。听起来不复杂吧但往细了拆就有几个关键约束冒出来了。第一是数据量级。业务方给了一个相对模糊的数字说每天大概几千万条订单流水加上埋点日志、曝光点击日志日增量大约是2到3个TB。我当时专门去确认了这个估算的逻辑——它是按业务的峰值预估的不只是当前日均值。这个点很关键数仓建设一定按峰值和年增长去规划而不是按当下的平均值。按我过往的经验日增量给一个数半年后翻倍是常态所以我直接按日均增量5TB去留了容量余量。第二是时效性要求。最开始业务方说我要T1报表就行但深入聊下来发现运营侧对用户实时画像、实时营销触达有很强的诉求只是他们自己也说不清具体要实时到什么程度。所以这个项目最终定的是离线为主、实时为辅的混合架构——离线数仓处理99%的核心报表和分析需求预留一个实时计算模块处理实时大屏、实时风控、高价值用户的实时特征更新。这个决策直接影响了后续在存储选型、计算引擎选型上的取舍。第三是下游使用方的复杂度。数仓不只是给报表开发用的。数据产品经理要看指标口径算法团队要取特征宽表运营要自助做多维分析财务要做成本分摊核算。不同角色的使用习惯和查询特征差异极大这意味着数仓的底层表结构设计、数据服务层DWS/ADS的表粒度设计必须留出足够的灵活度不能一股脑做成大宽表或者单表走天下。把这些需求翻译成技术语言其实就是几条硬性指标日增量5TB级别年增长按100%预估整体存储规划至少按3倍冗余做。核心离线任务要在每天上午8点前全部产出完成留给计算引擎的作业调度时间和容错空间必须充足。支持多引擎接入查询Hive、Spark、Presto/Trino底层存储要能兼容这些引擎的并发访问。数据生命周期管理要配套冷热分层、过期清理、成本控制得在一开始就设计进去。我个人的经验是数仓需求阶段最忌讳的就是业务方说什么就是什么。你要做的不是记录需求而是帮业务方把需求量化、边界化甚至帮他们看到自己没说出来但实际存在的需求。比如这个项目的实时需求就是在反复追问你们每天什么时候最需要看到最新数据之后才浮出水面的。需求弄清楚了后面的技术选型才不会跑偏。2. 技术选型每个组件背后都是一道取舍题技术选型这块是数仓项目里最容易引发争论也最容易踩坑的环节。很多人选型只看哪个技术最火或者哪个组件我熟但成熟的做法是列一张矩阵表格把约束条件、团队能力、运维成本、生态兼容性全部摆上去再一项项打分。这个项目我当时列的核心候选组件大概有这些组件层候选方案A候选方案B候选方案C决策结果存储层HDFS物理机自建云上对象存储OSS/S3CephHDFS计算引擎SparkHive on TezFlink离线模式Spark为主Hive为辅调度系统DolphinSchedulerApache AirflowAzkabanDolphinSchedulerOLAP引擎ClickHouseDorisPresto/TrinoPresto为主ClickHouse局部使用元数据管理AtlasDataHub自研Atlas数据质量Great ExpectationsDeequ自研规则引擎Deequ 自研规则为什么最终定了这套组合我逐个说下当时的思考逻辑。2.1 存储层为什么坚持用HDFS而不是云对象存储其实这个项目是可以选择上云对象存储的尤其是在当时云资源采购有折扣的情况下对象存储的成本看起来比自建HDFS要低。但我最终还是选了HDFS物理机自建。原因有三第一这个项目的核心计算场景是高频的Shuffle、Join、聚合数据本地性对Spark作业的提速效果非常明显。虽然现在对象存储配合Shuffle Service也能解决一部分问题但运维复杂度反而上去了。第二HDFS的权限管控和NameNode的元数据服务可以做到非常精细的目录级管控这对于数仓这种多团队共享数据的场景更友好。第三我们团队对HDFS的调优、故障处理经验足够自建能最大化控制运维风险。当然这个选型有一个前提就是公司已经具备机房资源、服务器采购渠道和基础运维能力。如果是一个从零开始的小团队没有专职运维那我可能会劝你选云上对象存储加托管Hadoop生态省心得多。这个判断完全取决于团队现状没有绝对的对错。2.2 计算引擎Spark是主线Hive当兜底离线计算引擎的选择我基本没怎么纠结就定了Spark为主。原因很直接Spark SQL的成熟度、生态兼容性、以及我们对Spark性能调优的掌控力都是最优解。MapReduce时代已经过去了Hive on Tez虽然在某些纯ETL场景下表现稳定但复杂计算、多表关联、数据倾斜处理上Spark还是更好用。但是我把Hive保留了下来作为一个兜底引擎。这不是多余的动作而是出于两个考虑第一数仓里有一批非常成熟的Hive SQL脚本和UDF是历史沉淀下来的直接迁移到Spark上需要测试和改造没必要一上来就搞大迁移第二Hive Metastore是整个数仓的元数据中枢保留Hive的会话入口方便排查元数据相关问题时多一个直接的验证手段。所以这个项目的实际运行状态是Spark跑99%的离线任务Hive作为查询兜底和元数据管理侧写验证。2.3 调度系统DolphinScheduler胜出的核心理由调度系统这一票竞标很激烈。Airflow在行业内声望很高社区活跃Python编写DAG对数据工程师来说也友好。但最终我们选了DolphinScheduler因为它的几个特性太契合国内数仓场景了中文生态完善社区答疑响应快毕竟数仓团队日常值班的同事还是更习惯中文文档和中文问题排查路径。原生支持可视化DAG编排、定时调度、依赖传递、失败重试对于数仓这种日结任务依赖链很长的场景直接在界面上就能看清上下游关系排障时效率极高。内置的告警通知模块对接企业微信、钉钉都很方便无需额外开发。Airflow当然也好但我们的实际情况是团队里Python功底扎实的人占比不高而Java/Scala是主流技能栈。让团队用自己最熟的技能去维护调度系统比盲目追求社区热度更重要。这个道理很多选型讨论里都被忽略了。2.4 OLAP引擎Presto为主ClickHouse局部使用OLAP选型是讨论最激烈的一块。ClickHouse的查询性能确实惊人单表聚合能达到秒级甚至毫秒级响应非常适合即席查询和固定报表场景。但ClickHouse的短板也很明显多表关联能力弱精确去重受限于内存数据更新代价高对于灵活多变的BI分析场景支持不够自由。而Doris虽然兼顾了查询性能和实时更新但当时我们团队对其运维经验不足不敢贸然作为核心引擎上生产。所以最终方案是Presto作为统一OLAP查询引擎对接Hive Metastore直接查询HDFS上的数仓表。这样业务侧的即席SQL、BI工具比如某款开源可视化平台都能通过Presto快速访问数仓数据。同时在部分高并发、固定报表场景比如销售日报、渠道趋势引入ClickHouse把数仓的ADS层结果表同步进去用于支撑对响应时间要求极高的查询。这个组合既保障了灵活性又兼顾了性能代价是多运维一个集群但对于我们已经成熟的团队来说完全可控。2.5 数据治理与质量控制最后简单说一下元数据管理和数据质量这两块。元数据管理选了Atlas主要是看重它对Hive、Spark、HDFS的原生血缘解析能力可以自动捕获表级和字段级血缘。数据血缘这东西平时感觉不到价值一旦业务方问这个字段到底怎么算出来的或者你要做表变更影响分析的时候就是最重要的基础设施。数据质量上我们用Deequ来做数据集的完整性、唯一性、波动性校验同时自研了一套轻量级的规则引擎用于在数仓各层任务跑完后自动执行预先配置的断言规则比如当日分区无空值指标日环比波动不超过10%校验不通过就阻断下游任务并告警。这一块在后续的项目推进中节省了不计其数的排查时间。技术选型这块我最后想强调的一点是不要被组件的新版本功能牵着走。有些组件出新版本了社区一片叫好但实际生产环境的稳定性和兼容性未必跟得上。选型的时候一定要考虑我们的团队能不能在三天内排掉这个组件在生产环境出的问题答案是否再新再热也别轻易上。3. 框架版本稳定压倒一切但也不能老掉牙框架版本选型是这个项目总结里我认为最值得仔细记录的一节因为版本问题带来的坑往往比功能问题更隐蔽、更致命。数仓项目里任何一个核心组件的版本升级都可能引发SQL兼容性、性能退化、甚至集群不可用的连锁反应。所以版本选型的原则我总结成一句话主力框架用成熟稳定版周边组件用生态匹配版所有版本组合必须先做兼容性验证再上生产。3.1 Hadoop版本3.x是唯一选择吗项目启动时Hadoop 2.x已经进入维护末期社区主流已经迁移到3.x。Hadoop 3.x带来的特性里对我们最有价值的是支持了更灵活的纠删码策略EC、YARN的资源精细化调度、以及多NameNode的联邦机制。这些特性对于数仓这种大规模数据存储和共享集群的场景实用价值很高。所以我们选择了Hadoop 3.3.x系列。具体版本是3.3.4当时是这个分支里bug修复较多、社区反响较稳的一个版本。需要特别提醒的是Hadoop 3.x相比2.x在默认端口、权限模型、部分API上有不兼容变更如果是从2.x直接迁移需要做一次全面的兼容性测试。这个项目是全新搭建不存在迁移负担所以直接拥抱3.x是个正确决定。如果你们是存量集群升级那要单独评估。3.2 Hive版本和Spark的协作是核心约束Hive的版本选择最核心的约束条件不是Hive自己的功能而是它和Spark的协作方式。Hive 3.x的Metastore独立成了一个服务Hive Metastore Service这让我们在数仓架构设计上可以解耦元数据层和计算层。而Spark SQL访问Hive表是通过Spark内置的Hive支持来连接Metastore并不需要HiveServer2常驻。我们选的Hive版本是3.1.3。之所以不追高版本是因为Hive 4.x在当时的生态配套还不够成熟很多外围工具和UDF的兼容性没验证过没必要冒险。3.1.3是3.x里最稳定、社区反馈最好的一个版本。3.3 Spark版本3.3.x是当时的最优解Spark的版本选择我直接定了3.3.x。为什么不是3.1.x或者更早的版本因为3.2之后Spark在SQL引擎的优化器尤其是自适应查询执行AQE上做了大量增强对于数仓里常见的数据倾斜、join优化、动态分区裁剪都有显著的提升。3.3.x则进一步修复了3.2里的一些性能和稳定性问题。我当时安装的是Spark 3.3.1。这里要提醒一个细节Spark版本和Hive版本的兼容性是通过Metastore的JAR包来桥接的所以安装时需要把对应版本的hive-exec等依赖放到Spark的classpath里做一次Metastore connectivity的专门测试否则会出现在Spark里查不到Hive表结构、或者元数据操作超时这些诡异问题。3.4 其他组件的版本矩阵为了方便复盘我把这个项目最终确定的版本矩阵整理成了下面这张表。这张表建议后续再做同类项目时直接拿来对照参考虽然版本会迭代但选型思路是通用的。组件最终版本核心选型理由Hadoop3.3.4稳定成熟支持EC和YARN精细调度Hive3.1.3元数据服务稳定生态兼容广社区通行版本Spark3.3.1AQE成熟与Hive Metastore兼容性好Flink1.16.x实时模块使用状态后端和Checkpoint机制稳定Presto/Trino380查询引擎对Hive Metastore支持良好ClickHouse22.8.x稳定版本ADS层报表秒级查询DolphinScheduler3.1.x可视化DAG、完善的告警和重试机制Atlas2.3.0血缘解析稳定Hive/Spark支持完善Deequ2.0.x官方维护的数据质量库Spark集成性好JDK1.8更新到最新小版本与Hadoop/Spark生态兼容性最保险这里面我想特别说一下JDK的选型。经常有人问能不能直接用JDK 11或者JDK 17我的建议是在大数据生态里不要让JDK版本成为你最先吃螃蟹的地方。Spark 3.3虽然理论上支持JDK 8/11/17但很多UDF写的时候未必按JDK 11的模块化约束去做跑起来就会出现各种莫名其妙的NoClassDefFoundError。我们当时的做法是JDK 8走到底所有组件都用同一个JDK版本消除跨组件运行时差异。这个选择看起来保守但换来了极低的环境类故障率。版本这块最想说的一句经验是不要做版本组合的想象派要做验证派。框架之间所谓的官方兼容性矩阵只能作为参考不能作为结论。真正可靠的方式是把所有核心组件装在独立环境里做一轮端到端的冒烟测试用一张典型的事实表维度表跑一套完整的ETL查询流程确认没问题了再铺到生产集群。这一步省不了省了就等着上线后和版本兼容性搏斗吧。4. 服务器规划与集群规模把每一台机器的资源都算明白服务器规划和集群规模设计是这个项目里最体现工程经验的部分。很多数仓集群建起来性能不行不是因为组件选型错而是资源规划和实际负载完全不匹配。要么CPU配多了内存不够要么数据盘RAID级别选错导致写入瓶颈要么NameNode的堆内存设置小于上亿文件的元数据需求各种问题。这部分我详细说下我们的规划过程和计算方法。4.1 集群总体规模先估算再打折再加冗余按照第一节里提到的需求约束——日增量5TB、年增长100%、核心任务早8点前完成、支持多引擎并发——我们可以做一个粗略的资源估算。存储方面日增量5TB保留3个副本HDFS默认副本数加上临时文件、中间结果、日志等开销实际写入放大系数大约在4左右所以每天的存储增量约为5TB乘以3再乘以1.3写放大和临时空间近似等于20TB。按年增长100%算如果项目按3年生命周期规划那么需要支撑的存储容量就是第1年20TB/天 * 365天 ≈ 7.3PB第2年约14.6PB第3年约29.2PB这个体量如果全用物理机按照单台数据节点配12块16TB HDD盘去掉系统盘、元数据盘可用容量约为单机120TB左右那么数据节点规模大约在200~300台的量级。就本项目而言由于业务预估存在不确定性且公司对一次性采购成本有控制要求最终采用了分阶段扩容的方式首期先建一个约80台数据节点的集群预留扩展能力第二年再根据实际数据增量扩容。计算方面核心离线任务要在早8点前完成意味着从凌晨到早上7点这个窗口大约7个小时是计算高峰。日均任务总量我们预估的Spark作业数量是每日约4000个作业包括数仓各层加工、指标计算、数据质量校验、数据同步等按照每个作业平均消耗约10万CPU秒这是一个经验值来估算一天的作业总计算量约为400亿CPU秒。换算到7小时高峰窗口25200秒需要的平均CPU核数约为400亿CPU秒 / 25200秒 ≈ 158万核这个数字显然不是首期规模能覆盖的。但这里要理解并不是所有作业都集中在高峰窗口跑大部分同步任务和部分非核心任务是可以错峰执行的。我们通过调度系统的优先级和队列配置把核心链路任务集中在高峰窗口非核心任务分散到白天空闲时段。最终首期集群的CPU规划是每台数据节点配置64线程对应一颗32核物理CPU开超线程80台节点提供约5000核的计算容量再辅以队列调度和弹性伸缩策略可以满足首期业务需求。4.2 服务器配置Master节点和数据节点分开设计在服务器选型上我们严格区分了Master节点管理节点和数据节点存储计算节点的配置规格。很多人图省事所有节点一个配置最后要么管理节点资源浪费要么数据节点内存不够用。Master节点规划了3台跑NameNodeHA、ResourceManagerHA、Hive Metastore、DolphinScheduler、Atlas等管理服务。配置上CPU不需要太多16线程足够但内存要给足因为NameNode的JVM堆要承载整个集群文件的元数据Atlas的图数据库也很吃内存。具体配置是CPU2 * 8核心超线程后32线程内存128GBNameNode堆内存分配64GB其余给Atlas和调度系统系统盘2 * 480GB SSDRAID1元数据盘NameNode的edits和fsimage2 * 1.92TB NVMe SSDRAID1这里用NVMe是因为NameNode的日志写入是同步的磁盘延迟直接影响所有元数据操作的响应时间数据节点用的是均衡型配置。因为数仓场景里数据节点既要做HDFS的存储又要跑Spark的Executor属于典型的存储计算耦合模式。具体配置是CPU1 * 32核心不开超线程时就是32线程我偏向开超线程对Spark这种多线程任务有正向收益内存512GB系统盘2 * 480GB SSDRAID1数据盘12 * 16TB HDD采用JBOD直通模式不组RAID这里为什么数据盘不做RAID这是一个很容易被喷但实际很有道理的决定。HDFS本身通过3副本机制保证了数据冗余所以底层磁盘不需要做RAID5或者RAID10。JBOD模式下单盘故障只影响一部分数据块HDFS会自动从其他副本恢复反而比RAID模式更灵活。同时JBOD节省了RAID控制器开销和磁盘阵列重建的漫长过程。唯一的代价是如果一块盘坏了上面所有数据块都要从其他节点拉取重新复制但这对数仓场景来说完全可接受。4.3 集群规模的分布设计最终我们首期集群的节点分布如下节点角色数量配置说明Master节点3台管理服务、NameNode/ResourceManager HA数据节点80台存储与计算通用节点OLAP节点ClickHouse5台独立部署减少对HDFS集群的并发影响实时计算节点Flink Kafka5台独立于离线集群承载实时链路边缘节点提交机/网关2台用于Yarn Job提交、运维工具安装、数据服务API整体规模90多台物理机加上虚拟机和网络设备是一个中型偏上的数仓集群。和那些几百台节点的大厂数仓比不了但对于支撑日增5TB级别的业务这个规模是匹配的。4.4 容量模型怎么算出来的一个可以抄的公式为了照顾正在规划数仓集群的读者我把我用的容量估算原则直接写成公式可以按自己项目的数据套进去存储容量按天 日增量 * 副本数 * 写放大系数 * 保留天数 * 增长系数数据节点数 存储容量 / 单节点可用存储容量CPU总量 高峰窗口期内任务总CPU秒 / 高峰窗口秒数单节点CPU核数按超线程 CPU总量 / 数据节点数 * 1 20%的管理开销系数这里面最容易被忽略的是写放大系数。数仓里的中间表、Shuffle文件、临时结果经常会占用大量的瞬时存储如果不把写放大算进去容量规划一定低估。我们的经验是写放大系数至少取1.3到1.5。4.5 网络规划万兆是底线最后说下网络。这个规划方案里数据节点之间的数据传输Spark Shuffle、HDFS复制是最大的流量压力。当时我们做了一个简单的测算单个Spark作业做一次大表JoinShuffle数据量动辄几十GB到上百GB如果网络是千兆一个Shuffle阶段的时间就会从分钟级膨胀到小时级完全不可接受。所以数据节点之间的网络用了万兆10GbE互联Master节点和数据节点之间同样万兆管理网独立千兆。机架划分上80个数据节点分布在4个机柜每个机柜20台这样HDFS副本的机架感知策略可以保证数据冗余分布在不同机柜提升容灾性。我自己在服务器规划上踩过最大的坑是低估了NameNode内存需求。当时一个几十亿文件的集群NameNode堆内存给了32GB结果文件数增长到一定量级之后频繁Full GC整个集群的元数据操作从毫秒级变成秒级所有作业都在等待元数据锁。那次之后我对需要管理海量小文件的集群NameNode堆内存都是按每100万个文件块约占用1GB内存这个量级来预估宁多勿少。5. 踩坑实录那些没有写在文档里的教训技术选型和集群规划做得再周密到了真正落地的时候还是会有一堆意想不到的问题。这节我把这个项目从搭建到稳定运行期间遇到的几个典型问题和排查过程记录下来算是给同样在做数仓项目的朋友一个提前预警。5.1 HDFS小文件问题还没有跑业务先被小文件卡住了问题描述数仓还没正式接入业务数据在做环境压力测试的时候往HDFS里灌了一批测试数据结果发现集群的元数据操作明显变慢NameNode响应不流畅。排查过程看NameNode的日志发现大量Block报告处理的耗时异常GC频率显著上升。进一步看指标发现测试数据产生的文件块数量远高于预期——因为我们直接用了一个同步工具从业务库抽取数据这个工具默认按记录数切分文件导致产生了大量几十KB到几百KB的小文件。解决方案第一对同步工具的切分策略做了配置调整按目标文件大小128MB来控制输出文件数第二写了一个小文件合并的定时任务把历史遗留的小文件按分区合并成大文件第三在后续的ETL开发规范里明确要求所有写入HDFS的表单文件大小不得低于64MB否则视为异常。这个经历让我意识到数仓项目里小文件问题不是遇到了再解决的问题而是一开始就要在技术选型和开发规范里做硬性约束的。否则随着增量数据涌入小文件只会越积越多最后拖垮整个集群。5.2 Spark和Hive的元数据连接配置问题SQL查不到表问题描述Spark部署完成后在Spark SQL里能正常创建临时表但访问Hive已有的表时报错提示找不到表或者表结构为空。排查过程先确认了Hive Metastore服务本身正常因为通过Hive CLI能查到表。然后检查Spark的配置文件发现hive-site.xml没有完整地分发到Spark的conf目录下导致Spark没有连接正确的Metastore地址而是起了一个内置的Derby元数据库。解决方案把Hive的hive-site.xml复制到Spark的$SPARK_HOME/conf目录并确保其中javax.jdo.option.ConnectionURL和hive.metastore.uris指向正确的Metastore服务地址。重启Spark之后问题解决。这个问题单独看很幼稚但在复杂的组件环境里这类配置文件没有同步到位的问题非常容易发生。所以我后来定了一条规矩所有组件涉及跨服务连接的配置文件统一由配置管理工具比如Ansible下发禁止手工拷贝从流程上杜绝漏配错配。5.3 DolphinScheduler任务积压调度线程池被打满问题描述上线初期业务方集中补录了大量历史数据DolphinScheduler的工作流数量暴增出现任务排队时间过长、部分任务超时未执行的情况。排查过程查看DolphinScheduler的Master和Worker日志发现任务队列深度很高Worker的线程池已经打满。看监控面板发现Worker所在服务器的CPU使用率并不高说明瓶颈不在计算资源而是调度系统本身的任务分发能力。解决方案调整DolphinScheduler的Worker线程池配置增大worker.exec.threads参数同时把部分非核心工作流分配到独立的Worker租户里做解耦避免一个工作流的任务风暴拖垮全部作业。经验总结调度系统也是集群的一部分它的容量规划要和业务任务量匹配不能只盯着计算引擎的资源。尤其是数仓项目里会有大量补数据、重跑、数据修复的场景这些临时任务会一下子涌入调度系统一定要预留足够的调度并发能力。5.4 ClickHouse和HDFS的数据同步链路延迟波动问题描述ADS层的报表数据由Presto从HDFS查出来再由同步任务写入ClickHouse但是每天凌晨的同步都会出现延迟导致早上个别报表没有及时刷出来。排查过程先看同步任务耗时发现大部分时间花在ClickHouse的本地表写入上。进一步查ClickHouse的MergeTree分区写入merge过程发现某些大分区在写入时触发了大量的merge占用了CPU和磁盘IO。同时检查源端的数据发现Presto查询HDFS大表的耗时本身就不稳定尤其是当表存在数据倾斜或者小文件较多的时候Presto的查询时间直接翻倍。解决方案第一把ClickHouse的写入策略改成批量写、减少写入频率降低merge触发次数第二对同步到ClickHouse的结果表做预先分区设计保证每个分区的大小相对均匀避免某个分区过大第三优化Presto侧的表文件布局减少小文件稳定查询耗时。5.5 数据质量规则误报率过高规则阈值需要动态调整问题描述Deequ的数据质量规则上线后监控报警频繁但大部分报警经过人工核查后发现是伪劣数据即数据本身没问题是规则阈值设置得太死板。排查过程检查规则配置发现很多规则都用了固定的绝对阈值例如某字段为空值数量不能超过1000条某指标日环比波动不能超过5%。但实际上数仓里的数据天然存在波动比如节假日、大促期间的日活和订单量会大幅跳变固定阈值很容易误报。解决方案把规则阈值改成动态策略支持按历史均值、按周同比、按月环比综合计算警戒线并且为不同业务板块配置独立的阈值模板。上线之后误报率从最初的40%降到5%以内。这个问题的背后逻辑是数据质量工具只是一个执行平台真正有效的规则设计需要对业务数据的波动模式有深刻理解。算法同学和数据产品经理在这个环节的深度参与比任何技术方案都重要。6. 项目落地后的一些真实感受数仓项目做到这个阶段框架搭起来了、集群跑起来了、数据链路通了这只是万里长征的第一步。后面还有大量的ETL开发、指标体系建设、数据治理、性能调优等着去做。但回顾需求梳理、技术选型、版本规划、服务器设计这几个环节我最大的感受是数仓项目的成功在最初的规划阶段就已经决定了六七成。一个清晰的需求边界、一套贴合团队和场景的技术选型、一份经过验证的版本矩阵、一个留足余量的集群规模后面所有环节的推进都会顺畅很多。我个人在实际操作中最深的体会是不要在选型的时候被最优解绑架而要在可行解里做选择。所谓的最优是要把团队运维能力、业务成长速度、成本约束、甚至公司采购流程的周期都放进考量。有些方案在纸面上非常完美却因为采购周期太长导致项目延迟三个月这同样是最差的选择。集群规模宁大勿小但也不能盲目堆机器一定要用容量模型去算清楚每个阶段的资源边界在哪里扩到什么规模需要重新审视架构。最后再分享一个我屡试不爽的小技巧如果你第一次在一个项目里引入某套技术栈先别急着搞生产级的高可用而是先搭一个极简的验证环境把核心链路用最小数据集跑通再逐步加高可用、加监控、加外围组件。这个验证环境的存在可以让你在正式投产前发现大量想当然的坑把问题留在验证阶段而不是生产环境。这个数仓项目的启动阶段总结基本就到这里了。需求梳理、技术选型、框架版本、服务器规划和集群规模每一项都是后面所有工作的地基。下一篇我打算重点写数仓的分层架构设计和ETL规范那部分内容实操性更强踩的坑也更细。如果有朋友正在规划类似项目欢迎在评论里交流你们的选型思路和踩过的坑互相借鉴。