云上数据仓库选型指南：Redshift、BigQuery还是自建？
上个月，一个做跨境电商的朋友问我：“我们用户数据越来越多，MySQL扛不住了，想搞个数据仓库做分析。AWS、Google、阿里云都有产品，该选哪个？自己搭个Hadoop是不是更便宜？”
我问：“你们数据量多大？”
“每天几千万条，存了两年，大概几十TB。”
“分析场景呢？”
“主要是BI报表、用户行为分析、运营看板，偶尔跑点复杂的SQL。”
“团队呢？”
“两个后端，一个兼职数据分析，没人专门搞大数据。”
我说：“你这种情况，千万别自己搭。”
这是很多公司转型数据驱动时会遇到的灵魂拷问：业务数据爆炸了，原来的OLTP数据库撑不住分析查询，是时候上个正经的数据仓库了。但市面上选项太多，Redshift、BigQuery、Snowflake、自建Hadoop……到底怎么选？
今天聊聊云上数据仓库选型。不是那种“各有优劣”的废话，而是帮你理清楚：你的数据量、团队能力、查询模式，到底该匹配哪个方案。
01 先搞明白：数据仓库不是“更大的数据库”
很多人误以为数据仓库就是把MySQL的配置调高一点、磁盘换大一点。这是第一个坑。
OLTP数据库（MySQL、PostgreSQL）是为事务设计的——高并发、小查询、强一致性。跑几个分析查询，可能就把在线业务拖垮了。
数据仓库是为分析设计的——低并发、大查询、海量数据扫描。它能在秒级跑完一个扫描几十亿行的SQL，这是OLTP数据库做不到的。
所以第一个决策点：如果你的分析查询已经开始影响线上业务，或者跑个报表要等半小时，是时候上数据仓库了。
02 三大云数据仓库速览
先快速过一遍主流选项。
AWS Redshift
Redshift是云数据仓库里的老牌选手，2013年就推出了。它是基于PostgreSQL改造的列式存储数据库，用MPP（大规模并行处理）架构，把数据分片到多个节点上并行计算。
优点：和AWS生态深度集成，能从S3、RDS、Kinesis等无缝导数据。预留实例定价，稳定负载下成本可控。
缺点：配置复杂，需要根据数据量选节点类型和数量，扩缩容没那么灵活。不是真正的存算分离，存储和计算绑在一起。
Google BigQuery
BigQuery是云原生数据仓库的代表，2010年就推出了（比Redshift还早）。它是真正的存算分离架构——存储和计算独立计费，查询时才拉起计算资源。
优点：零运维，不需要选节点、调参数。按量付费，适合不确定的查询负载。查询速度快得惊人，尤其擅长扫描大表。
缺点：和Google生态绑定深，虽然支持AWS/Azure数据源，但跨云有网络成本。持续高负载下，按量付费可能比预留实例贵。
自建方案（Hadoop/Spark）
自建数据湖/数据仓库，比如用EMR搭Hive、Spark SQL、Presto。
优点：完全掌控，可以混搭不同组件。开源生态，不绑定厂商。
缺点：运维成本高，要自己调优、监控、扩容、处理故障。团队需要有人懂大数据技术栈。
03 反常识视角：Redshift比BigQuery便宜？不一定
很多人有一个刻板印象：Redshift是“传统”数仓，便宜；BigQuery是“云原生”数仓，贵。
这个印象在特定场景下对，但换个场景就反过来了。
场景一：稳定负载，持续查询
比如你每天跑固定报表，查询量稳定。Redshift买预留实例，月成本固定。假设需要10个节点，每月约2000-3000美元。BigQuery按量付费，同样负载可能每月4000-5000美元。这时候Redshift更便宜。
场景二：波动负载，临时分析
比如运营经常临时跑一些Ad-hoc查询，数据工程师偶尔做探索性分析。BigQuery按扫描数据量收费，没查询时不花钱。Redshift即使没查询，节点也在跑着，钱照付。这时候BigQuery更便宜。
一个真实数据：某SaaS公司从Redshift迁移到BigQuery后，月成本从8000美元降到3000美元，因为他们的查询模式是“白天密集、晚上几乎为零”，BigQuery的按量付费完美匹配。
反常识结论：选哪个更便宜，取决于你的查询模式，而不是产品本身。
04 再说说自建：真的省钱吗？
很多公司觉得自建开源方案省钱。但算算账：
硬件成本：EMR集群的实例费用，和Redshift节点费用差不多。
人力成本：需要有人搭集群、调优、修故障、升级版本。一个大数据工程师月薪至少2-3万。按0.5个人算，每月1-1.5万。
时间成本：搭个能用的Hive数仓，少说一周；调优到生产级别，可能一个月。这还是假设团队已经熟悉这套技术栈。
我一个朋友的公司，老板觉得“开源免费”，让后端团队自建Hadoop。结果花了三个月，勉强跑起来，查询慢得一塌糊涂，最后全组加班两周才迁移到Redshift。算下来，自建花的钱够用三年Redshift。
什么时候自建划算？
数据量巨大（PB级），云厂商的节点成本太高
有成熟的、经验丰富的大数据团队
需要混合云或私有化部署，数据不能出机房
对开源生态有硬性依赖，比如必须用特定组件
否则，云数据仓库是更省心的选择。
05 决策框架：三步走
第一步：看团队
没有专职大数据工程师 → 选BigQuery（零运维）或Snowflake（也是零运维）。有DBA或数据工程师 → Redshift可考虑，但需要人花时间调优。
第二步：看查询模式
稳定负载、持续查询 → Redshift预留实例更划算
波动负载、临时分析 → BigQuery按量付费更省
混合模式 → 可考虑Redshift Spectrum（存查分离）或Snowflake
第三步：看生态
全在AWS上（S3、RDS、Kinesis） → Redshift集成最顺
多云或Google生态（GA、GCS） → BigQuery天然优势
已经有Snowflake或考虑多云 → Snowflake是专门为多云设计的
06 一个真实案例：从自建Hive到BigQuery
去年帮一个游戏公司做咨询。他们的用户行为数据每天几亿条，存在HDFS上，用Hive跑分析。结果Hive越来越慢，运维越来越重，专职大数据工程师从1个招到3个，还是扛不住。
我们评估后，建议他们迁到BigQuery。
迁移过程：用Dataflow把数据从HDFS流到GCS，然后直接挂到BigQuery。查询从原来平均20秒降到3秒，运维几乎为零，大数据团队从3人减到1人（剩下的人转去做数据建模和业务分析）。
成本呢？原来自建Hadoop每月2万美金（包括实例和人力），现在BigQuery每月1.2万美金。省了40%。
写在最后
回到开头那个朋友。他的数据量几十TB，团队没有专职大数据工程师，查询以运营看板和临时分析为主。我给他的建议是：先用BigQuery。
为什么？因为他这种情况，最怕的是“搭起来没人管”。Redshift需要选节点、调参数、监控资源，他团队没这个精力。自建更不可能，那是给自己挖坑。BigQuery零运维，按量付费，用多少付多少，起步门槛最低。
三个月后他发消息说：“BI报表从原来的5分钟变成5秒，运营同事以为我换了一套系统。”
选数据仓库这件事，最怕的不是选错，而是拖着不选。业务数据不会等你，分析需求不会停。早一天上数仓，早一天让数据驱动决策。
你的数据，现在谁在管？
