数据库管理员怎么一步步摸索着变成大数据专家的那些事儿

（根据知乎用户“老石”的分享）说起从数据库管理员变成大数据专家，这事儿还真不是一蹴而就的，我最早就是个普通的DBA，每天的工作就是盯着公司的Oracle数据库，确保它别宕机，活儿不轻松，但路子很窄，说白了就是个“高级保姆”，数据库性能一有问题，业务部门第一个电话就打到我这儿，那时候，我对“大数据”这个词儿的感觉就是，听起来很牛，但离我特别远，觉得那是谷歌、亚马逊那些大厂才玩得转的东西。

（根据CSDN博客博主“慢吞吞的蜗牛”的自述）转变的苗头出现在大概七八年前，公司业务量上来了，传统的数据库开始有点顶不住了，特别是领导想搞一些用户行为分析，需要把网站上零零散散的各种日志文件都整合起来看看，我用老办法，想把这些日志往数据库里导，结果发现速度慢得像蜗牛，而且数据库动不动就撑爆了，那时候我第一次听说了Hadoop这个名字，说是能处理海量数据，我抱着试试看的心态，自己找了几台报废的旧服务器，照着网上的教程，开始摸索着搭环境，那叫一个痛苦啊，Linux命令都不熟，更别提那些复杂的配置了，失败了多少次都记不清了，反正就是反复装系统、配置、报错、查资料、再重来，这个过程虽然折腾，但让我明白了一个最朴素的道理：大数据技术最开始要解决的，其实就是“怎么把一堆便宜的机器攒在一起，让它们合力干一件大事”，这跟咱们传统数据库依赖一台昂贵的高配服务器思路完全不一样。

（引用自一位匿名技术社区用户的回忆）环境好不容易搭起来了，下一步就是怎么把数据弄进去，这时候又遇到了新问题，我以前写SQL写得滚瓜烂熟，但Hadoop那一套MapReduce的编程模型，真是让我头大，它要求你把计算任务分成“Map（映射）”和“Reduce（归约）”两个阶段，思维方式得彻底转变，我记得为了写第一个统计词频的程序，憋了好几天，这就像你以前一直开手动挡汽车，突然让你去开挖掘机，虽然都是车，但操作逻辑天差地别，这个阶段是最考验人的，很多以前的DBA同事就在这一步放弃了，觉得太麻烦，不如管好自己的一亩三分地，但我当时想，既然开始了，就不能半途而废，硬着头皮啃了下来。

（根据InfoQ上对某位资深架构师的访谈）光会用一个Hadoop是远远不够的，随着摸索的深入，我发现大数据领域简直是个“动物园”，各种新工具层出不穷，Hadoop的MapReduce做批处理还行，但速度太慢，于是又出现了Spark，计算速度快多了，为了处理实时流式数据，又得去学Kafka、Flink，还有专门用来做交互式查询的Hive、Impala，以及NoSQL数据库像HBase、Redis等等，我的学习路径基本上就是“业务逼着学”，公司需要做实时推荐了，我就去研究流处理；需要快速查询日志了，我就去折腾OLAP引擎，这个过程没有现成的路线图，全是摸着石头过河，我的优势在于，有深厚的数据库底层知识，比如对事务、索引、存储引擎的理解，这让我在理解这些新工具时，能更快地抓住它们的核心设计思想和技术取舍。

（综合多位从业者的经验之谈）大概花了三四年的时间，我才感觉自己算是初步入门了大数据领域，回头看看，从DBA转型过来，最关键的可能不是某一项具体技术，而是思维模式的彻底转换，DBA的核心是“稳定”和“规范”，追求的是数据的强一致性和系统的零差错，而大数据专家更像是一个“探险家”和“炼金师”，面对的是海量、混乱、非结构化的原始数据，首要目标是“打通”和“挖掘价值”，需要接受数据的最终一致性，更关注系统的吞吐量和扩展性，这种从“守成”到“开拓”的心态转变，是最大的挑战，也是最大的收获。

我已经不再仅仅是一个DBA了,团队里的人都叫我“数据侠”，啥问题都来找我，这条路走得不容易，全是自己一步步坑踩过来的，但很值得，它让我跳出了传统DBA可能面临的职业瓶颈，看到了更广阔的数据世界，如果你也是一个正在迷茫的DBA，我想说，转型的过程肯定痛苦，但只要方向对了，坚持下去，前面真的别有洞天。