BAT的大数据架构网上随处可查，技术栈也琳琅满目，但那个机制、那个人才池、那个薪酬体系，传统企业真抄不来。技术终究是为业务服务的，没必要盲目追求先进性——适合自己的，才是好架构。
本文不聊纯技术选型，而是从业务价值出发，回答一个核心问题：为什么要用这个架构？它能带来什么？最终结果怎样？这套思路未必通用，但可能比BAT的方案更贴近大多数企业的现实——毕竟多数企业数据量没那么夸张，也不可能全自研，商业+开源混搭才是正解。
这里把大数据平台划分为 “五横一纵” ，五层自底向上：
数据采集层：离线用Hadoop生态（Sqoop等），实时用Flume+Kafka，还可引入OGG做Oracle日志采集。建议升级为数据交换平台，兼顾双向流动，统一管理接口。爬虫中心也值得建，但别小看它——还需要分词、索引、文本挖掘，全套下来挑战不小。
数据处理层：典型“混搭”格局。Hive适合离线海量清洗，但复杂关联慢；MPP（如Gbase）是传统数仓的优质替代，性价比高；流处理（推荐IBM Streams，性能远超Storm）让实时反欺诈等场景变得简单。
数据分析层：R和Python各有所长，分布式挖掘可走Spark+Scala，传统业务人员可用SPSS，深度学习往TensorFlow靠。工具只是手段，核心还是建模师的能力。
数据开放层：查询场景多样，HBase适合百亿级详单查询，Redis做高速缓存，Kylin是多维分析的利器，各司其职。
数据应用层：越往上变化越快，按企业实际规划即可，没有标准答案。
一纵贯穿：数据管理层，涵盖调度、元数据、质量、安全，需靠平台固化流程，从事前到事后全程管控。
最后提醒：大数据平台正从集中走向分布式，技术组件繁多，商业版易遇服务瓶颈，开源版考验运维能力。人才争夺激烈，但对真正想做数据的人来说，数据量大、场景丰富的传统企业，反而是不错的战场。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70051142/viewspace-3181509/ ，如需转载，请注明出处，否则将追究法律责任。
