01 优秀数据架构师成长之路
盖国强：「数据工匠」这是一个非常有意思的话题，在我的理解里，工匠首先意味着“精深”，钻研一个领域达到精深的境界才能称之为工匠。
第二可能意味着“持久”，只有在一个行业持续不断的钻研，才能达到精深的状态。
第三应该还包含了“痴迷”，当我们谈到某一个人在某一方向达到了工匠的境界，在我看来他对这个技艺是痴迷的，可能为此废寝忘食。
从我的个人经历来看，我在这个行业里已经坚持了20年。20年前很多人还意识不到数据会有这么重要，今天所有的企业数据都成为了宝贵资产，数据成为智能时代的驱动力，我们每个人每天都在和海量的数据打交道。
其实我们在最初进入一个行业的时候不太会有那么清晰的认知，当你进入一个行业或者一个新领域的时候，最重要的是低下头来、扎下根来，把你手上的事情做到最好。
最好能够在这个过程中找到兴趣，通过兴趣来驱动你持之以恒的投入。或者是发现你并不热爱它，然后再找到另外一个你热爱的方向。 我当年就是一开始扎下头来，努力去理解、学习、然后找到乐趣并且坚持下来。虽然这些年金融、电商都发展得非常快速，但我没有中途转换方向，一直坚持下来，才有了现在这样的局面。
这就是我个人所理解的“工匠”精神，就是要精深、持久、达到痴迷的境界。
分享一个小故事，当年我们在学习数据库技术的时候，整个互联网才刚刚兴起，还找不到特别多的分享资源与学习资料。那我们是怎么做的呢？我们聚集了一群热爱技术的朋友创建了论坛，叫做 ITPUB 技术社区，我们共同分享一起成长。
记得那个时候，社区里每一个帖子我都要去回，至今我在论坛上的积分还是第一位的。为了回答一个问题可以忘记吃饭，我现在也很怀念那段时光。最初的学习和积累，让我获得了最宝贵的经验。后来我在互联网上结识了志同道合的朋友，创建了今天的公司，这是我的一点小感想，分享给大家。 林晓斌：如果我们想要对数据库有更深入的了解以至于到达工匠水平，很重要的一点就是要保持好奇心。我们在网上会看到很多最佳实践，好奇心会引发我们深入思考：为什么这样就是最佳实践，而那样做就不是？
第二要勤动手，对于数据库领域，当有一个想法时就要设计一个方案去验证它，不能只是纸上谈兵，用动手得到的结论来印证自己的理论，这样做可以提升自己的技术深度。
第三点，就像国强老师说的那样，多多分享，把自己理解的东西写出来。在分享的过程中能够重新梳理自己的知识框架，查缺补漏，形成新的知识体系。
好奇心、勤动手、多分享，可以让我们快速来积累技术。
我也分享一个自己的故事。我是怎么进到这个领域呢？我刚毕业的时候是做应用工程师写服务器程序的，那时候是 MySQL 的一个用户。2008 年时我发现一个情况，平常正常的读写都是一毫秒或两毫秒，但一天跑下来偶尔一两次会出现100毫秒，对于一个性能很敏感的业务来说，这100毫秒会突然间抖动一下，我就想：为什么会这样？然后自己去分析，才知道原来是刷脏页导致的。
了解这个原理后，就容易复现了。我先做大量的更新，然后再去测试查询，十几分钟就能复现这个现象。当你有理论基础做指引，再动手验证自己的推论，问题就不难解决了。 虽然我当年还没有圆满解决问题的能力，最后的解法也是通过应用层的缓存来规避这个问题。但这个状态跟我一开始不知道是什么原因而选择绕过是完全不同的，慢慢的追求真相的过程是非常有趣的。 杨振涛：其实每一个人因为专业背景和职业生涯的发展状况不一样，所以发展路线也并不完全一样。就我自己而言，我一开始并不是立志于要做一名程序员，其实我最早的理想是研究人类生命的奥秘，看起来会是一个很宏大的命题。
那我是怎么从人类生命奥秘的研究，走到了互联网领域，并且每天跟数据打交道的呢？我们知道生命科学和生物科学是非常年轻的学科，到上世纪中叶才慢慢成熟。更早之前大家都是学医学的，完全没有人会去学比如生态学那些东西，大家也不理解为什么需要保护野生动物，多元能给我们带来什么好处等。
十年前我在研究怎么测人类的基因，把由ATCG组成的基因序列从实验数据里解读出来，彼时生物学也经历了从实验生物学到计算生物学的过渡。虽然每天研究的基因序列数据看起来是在研究人类生命的奥秘，但更多还是在做数据分析：从生物生化实验获得数据，然后挖掘出跟人类性状表现相关联的片段或位点。
比如癌症病人的某个组织可能发生了一些变化，那么他的数据跟健康人的数据会有什么区别？经过比对最后会找到一些关联的位点，可能会对制药公司有一些参考价值，让制药公司去做下游。
通过这样的过程我就进入了数据相关的行业，所以大概十多年前，就已经在使用今天互联网广泛应用的一些所谓人工智能相关的分析方法。比如我们最常见的需要做主成分分析、归因分析和数据聚类分类，这是数据分析里最基本的方法，而这些基础反而是我此前在另外一个领域所奠定的。 后来随着成长，我发现对人类生命探究的道路过于遥远，于是转行到了消费互联网。虽然我在 Nature/Science 顶级期刊的论文上也挂了一些名字，但学术离我已经很遥远了，我更加期望关注消费互联网给大家创造的直接价值。
比如我做的手机上的搜索功能，有三亿多用户每天在使用，它哪里不好用我也可以通过行为数据来发现和改进，这就是我们能通过数据所创造的价值。
在数据这条路上首先我们要保持好奇心，不管是对业务的好奇心还是对技术关键点的好奇心，它都会驱动着我们在数据这条路上发展得更好，走得更远。
02 数据库技术发展现状及未来趋势
盖国强：对于数据库领域，今天就是最好的时代。为什么这样讲？大家可以看到，在过去数据库发展的四十多年里，一直是国外的产品占据了主流，并且直到今天它们仍然是市场上的主要产品，大家可能最熟悉的数据库就是Oracle。
但今天国产数据库正在崛起，持续渗入到各种各样形态的应用里。尤其在今天这样的国际国内发展形态之下，我认为所有在这个领域学习就业的朋友们，我们遇到了一个发展的最好时机，可以将过去所学到的知识和技术，在国产化大背景之下，发挥更重要的作用。
数据库自身有什么样的发展新形态呢？我个人认为主要有三点：
第一点在数据库产品本身，分布式渐渐成为一个趋势。而分布式数据库，其实也是国产数据库有可能进行弯道超车获得领先优势的一个方向，因为中国有最庞大的用户群体。
第二点，云数据库成为一种趋势和潮流。今天各个云厂商在云上不管是基于商业数据库还是开源数据库构建新的数据库形态，这种大势已经确定了。今天的企业用户也在用云的模式构建数据中心和数据环境，这是云的大势。
第三点就是数据库走向自治。我认为很不幸，未来可能不太需要传统意义上的 DBA 了，数据库一定会越来越自动化和智能化。就像腾讯的数据库智能管家 DBbrain ，把过去靠人工完成的工作变成智能和自动化的，这显然是一个趋势，Oracle 数据库也在引领这个趋势，它提出来自治数据库叫做 Autonomous DB。
我认为当今数据库已经完整的出现分布式、云化和自治这三大趋势，今后会在这样的趋势下滚滚向前发展。
林晓斌：根据我对 DBA 的理解，我认为未来 DBA 还会存在，但是形态会发生改变，很可能返回 DBA 最初的能力。什么时候是 DBA 最黄金的时期呢？就是国强老师那一代，那时候 Oracle 功能非常强，数据库可以做很多的工作，DBA 了解数据库的业务架构，对业务有很强的主导性，很多业务架构设计也都需要 DBA 的审核。
等到数据库云化以后，各种功能的实现通过在线的一个按键就能解决，DBA 需要基于现有产品的情况来评估这些能力。数据库自治后对 DBA 的要求也会更高，DBA 又会变回最初的时代，这时候数据系统已经很强了，它智能以后又变成了一个挺完备的“Oracle”了，这时候 DBA 的价值又回去了，会成长出更多国强老师这样的大神，他们不仅了解数据库还了解业务并对业务主导，这点我觉得才是 DBA 真正发挥价值的部分。 杨振涛：我依然保持朴素的观点来看，诸多事物是合久必分，分久必合。业务系统对数据的读写要求，从早期的我们都指望一个数据库搞定，到后来出现不同业务对数据读取的差异化要求，促进了不同存储产品的演化，进入了一个百家争鸣的时代。
从 Elasticsearch（下文简称 ES ）角度来说，我们现在已经不再纠结它是搜索引擎还是存储了，有人认为它就是一个数据库。所以在一些平台我的 ES 产品是放到大数据还是数据库还是哪个菜单里呢？按照目前ES的演化趋势，只要你有数据存进去，我就能帮你自动做异常检测，所以这种发展的趋势，都让我们看到现在是一个“分”的时代。
包括国产数据库的崛起，持续的让这个数据时代更加多元化。从系统论来讲，当多元化越强，系统蕴含的熵就越大，进化的能力也越强。 如果永远是三巨头占领市场，就可能不是一个健康的行业发展态势。
03 数据工匠有哪些特质
盖国强：我想起民国大家辜鸿铭讲过一句话，他说中国人是“博大的、精深的、淳朴的、灵敏的”。他用这四个词来概括中国人的特性，说中国人超过了西方，他本人也是一名坚定的中国支持者。
我之所以想到这四个词，是因为我觉得它恰好也符合对我们技术人的要求。我们搞数据的人首先要深沉，要能沉下心来十数年如一日。
首先这个行业不是那么容易出成果的。进入这个行业要能耐得住寂寞，要投入很长时间，所以你要印证自己是不是适合或者热爱这个行业。我一直跟小伙伴讲要努力的去学，用最快的速度发现自己适不适合这个行业？如果你适合，那就用十年时间来成为这个行业里的专家，也即是数据工匠。
第二个词博大。今天我说万物皆数，一切事情都可以被数据化。这个世界上的数据库有多少种呢？400种数据库，国产数据库也有将近200种。我们要抬起头来从架构上看清楚大的格局，理解不同的产品都解决什么样的问题，然后想好自己要在哪一个方向上钻研下去。需要从架构上看才有感觉，才能够有开阔的视野。
其它两个词我不展开了，对于我们技术人来说要能够博大，要能够深入的去钻研，我认为这是做技术的特质。
很多时候如果你非常容易接受新生事物，这种情况要沉下心来把板凳坐实，要投入长时间持之以恒的去探索。
第二个问题有没有捷径？世界上没有捷径，一万小时定律就是最好的答案，你必须花那么长时间才能够看清楚一个行业，才能成为工匠。我们团队就有位杨老师号称“百科全书”，他二十年如一日去读文档，把官方文档看很多遍，了解一个数据库的所有的特性，他甚至可以告诉你一段描述在哪本书的哪一页上。
有了这个基础后，再加上我们个人的思考就可以灵活的运用一个数据库自身的技术，帮助用户解决各种复杂问题的挑战。很多人看到别人分享的实践，觉得怎么会有这样巧妙的方案？
其实运用之妙存乎一心。运用之妙首先需要你对技术有深刻的理解，我的方法是由点及面，由浅入深来学习。当我们遇到一个问题的时候，我会从那个问题出发追溯到内核级，因为 Oracle 不是一个开源的数据。
把这条线完全吃透有什么好处呢？这个过程能够证明你具有深入的能力，能够建立你自己的方法并建立丰富的体系。我可以非常自豪的讲，在二十年前刚入行的时，我研究一个问题写出的一篇文章，今天去看同样还是非常精彩，因为它没有纰漏，是我花了一个月甚至更长时间把一个问题彻底洞悉了以后的展示成果。由浅入深、由点及面，从而变成了一个知识面。
如果想求捷径就去看看前辈们走过的路，他们会非常乐于分享，写得非常详细。你去看看哪条路更适合你，如果你找到适合你的，就去尝试复制一下，不要怕苦怕累，花两三年的时间，就可能做到前辈们当年要花十年做到的成果。你用两三年达到一定的境界，这时候就可以看清楚这个行业并自由作出自己的选择。
林晓斌：我的方法也是从点到面。从点开始的好处是更容易有点滴的成就感，当你弄明白一个问题，成就感会来得更快一点。
经常有同行问我是不是应该去看一下 Oracle 的手册？我觉得应该要看，但是也要看时间点。至少先把骨架弄明白后再去啃，那几百万字的英文文档没有背景看到中间可能就忘了前面，但如果你心里记住了一个骨架，看手册就是一个查缺补漏的过程。
谈到技术深度，我觉得现在每个数据库都有它各自的技术优势和应用场景，对于一个数据从业者，具有框架视野也特别重要，我经常跟刚毕业的同学说数据库的缓存机制你搞明白后，再翻回你读书时的课本就会发现 cp 的内核也是这么做的。
再往下硬件系统也差不多，其实数据库是一个综合系统，把这块搞明白，再看别的技术就会有触类旁通的感觉。
另外，现在有很多技术解决方案，当我们碰到需求的时候，第一步并不是上来就使用现在特别熟的技术来满足需求，而是要跳出来先评估这个方案的改造成本，以及了解业界其它的产品，它们能否满足这个需求，是不是可以直接用？如果没有的话，它们的改造成本是多少？需要有成本方面的意识。
最后说到架构师，当每个数据库都很成熟的时候，专家需要做的事情是什么呢？就是基于他对各种数据库的了解、解决方案的了解和业务的了解来进行评估，给出一个成本最低最能够满足需求的方案。这就是专家的价值，而这一定是用技术视野来支撑的。 杨振涛：我分享的第一点是专业主义，对专业主义的追求决定了你能把这个事儿做到哪一步，刚才国强老师提到了一万小时定律，可能有些行业实行起来不只一万小时，要好几万小时。
当然专业主义我们也要辩证的去看。你愿意在这个事情上去坚持，你知道正在做正确的事情，那就尽全力去做，在这个道路一直坚持走到底，会有所收获的，这是专业主义的一个方面。
另外一个方面，从反面的角度去看，在坚持专业主义的时候，它对我们最终用户需求的满足以及对业务问题解决程度是什么样的？如果它最终创造的价值已经开始出现变化的时候，我们就需要及时的作出调整，不然可能在已经不产生价值或者产生价值越来越少的道路上坚持。
这是我个人对专业主义两边辩证的分享，也是我作为数据技术人觉得需要关注的一点。
其次我们要有利他并成就他人的意识。很多技术人会写博客，其实就是一个利他的思想。这个分享的过程，会让你得到一些反馈，可以重构你的知识体系和框架，甚至让你的收获新的认知。分享是个软技能，对学习来说会带来放大的效果，是非常值得投入的。
最后，我们做技术方案时可能经常会有“我是不是要用最新的技术、最酷炫的技术”的想法。其实这不是最重要的方面，我们要更多的关注效率和成本，因为技术最终是要产生真正的价值的，如果不产生价值就可能叫“炫技”，“炫技”是临时性的，我们最终还是要产生真正的“价值”。 盖国强：听了两位的分享我很有感触。两位都在说作为一个技术人要把我们的宝贵经验和知识分享出去，这种理念我特别同意。我认为正是因为分享才让我们获得了最大的鼓舞和成长。
我本身是个性格非常内向的人。在参加工作后因为互联网社区建设，我需要做线下培训、知识的授课、写博客和写技术书籍，在这些不同形态的分享的过程中对我自身的成长影响特别大，所以我也希望大家要不断的锻炼自己的分享能力，比如演讲、视频和讲课等。
其实我们把自己的一个观点清晰的表达出来是挺难的，可能自己认为表达挺清晰，但别人听起来就很混乱。如果你能够用文字和语言把事情描述清楚，这样对你的帮助会很大，所以我特别鼓励大家都能够参与到技术分享里面去。
今天技术领域的变化其实是倒逼我们去成长去进步的，未来没有普通的 DBA 了，以前 DBA 做的是安装部署、监控和优化等简单的工作，这些以后一定是自动化完成的，现在互联网上出现了云模式，一切将变为自动。
所以传统意义上的低附加值的工作要被替代掉了，我们从业人员的未来在什么价值上？我认为越是基础的工作，将来越是重要。
如果我们多了解算法、原理和数据架构，并把这些基础真正掌握了，我们就能够为行业贡献更多的力量，帮助中国的数据库领域上一个台阶。
未来的世界是智能世界，但一定是数据驱动的，所以从事数据这个行业前景是无限的。 杨振涛：我个人对数据工匠这个词比较欣赏。现在我们现在处于数据时代，我相信随着国产技术的提升，我们能看到数据世界、数字化基建方面不但能成就一些工匠、大师、数字化世界的缔造者，也能产出一批数字化世界的“大国重器”。
我相信数字化的方向一定是正确的，而且这个方向一定是要靠我们这些从业者一步一个脚印走过来的。
中国有这么大的舞台有这么多的用户和需求场景，数据从业者们可以快速验证技术方案的有效性，这是非常好的机会。对于数据世界来说，相较于传统的时代我们面对的是一个非常好的充满机遇的时代。 林晓斌：对于数据从业者的成长建议，我觉得重要的是培养性能意识。比如我有一个表，我应该建什么样的索引来验证这种场景？在这个场景里面，业务要求我们数据存一周跟存两个月可能完全不同，再大一点是要考虑整个的解决方案，比如数据要分几片才可以满足性能需求。
有一种解决方法是实践出真知，慢慢试总能找到正确的方案。举个例子，有10个参数每个参数有两个选项，那就有1024种可能性，这么多选项不能都测一遍吧？
如果我们有性能意识，有一套很完备的系统做剪枝、就可以避免无意义的测试，大大提高效率，还可以有效的节约成本，体现专业性。 另外一点，我认为数据从业者要有安全意识。不论是我们一线的操作人员还是团队的负责人都需要有安全意识。
一线操作的同学要留有后手，我这个操作如果做错了，可以快速的恢复到安全状态。团队的负责人要制订一些规范让大家遵守，比如说如何规避损失，或者说避免信息泄漏，这些规范都是主管需要去思考制定的。 术业有专攻，一个人不可能什么事都懂。但拥有安全意识是很重要的，一旦你有这个意识，即使你不知道具体怎么实施，也可以请教安全专家，寻找到有效的解决方案。 杨振涛：性能和安全不只对于某个数据库，我觉得对于整个行业都是需要大家关注的。性能跟容量规划也是密切相关的，比如我们做 ES，容量的规划不只影响性能，甚至影响整个系统的扩展性。
容量规划在实践中是个技术活，它对技巧性要求也是非常高的。有时候很小的一些策略会给你的系统带来很多益处。而安全问题的负面案例就太多了，拿 ES 来说，不时出现在科技媒体的头条上，每过一段时间就爆出 ES 安全问题。部分问题就相当于家里有一个保险箱，虽然很结实，但是它是放在大马路上，而且钥匙就放在旁边，这是非常危险的一个行为。
当然每个产品它处于发展的不同阶段，对开发人员而言，它的安全性的成本和体验都是不一样的。
我相信 Oracle 今天发展得已经足够成熟，肯定不存在像现在 ES 这样看起来容易造成数据泄露这样的风险。但在其他方面，可能会有一些因为复杂性而导致的不可预测的风险和安全性问题。
再次重申安全性不只对数据库，对整个软件世界来说都是非常重要。现在对数字世界基础设施的安全威胁已经越来越多了，随着物联网以及智能电动汽车的发展，你的电动汽车看起来很酷炫很好用，但有可能它就是一个后门注入点，存在很大的安全隐患。
盖国强：我最后补充一下，把我20年的经历，总结一个公式送给大家。
其实学习任何一门技术都适用4个词，第一是兴趣，第二是勤奋，第三是坚持，第四是方法。
兴趣就是找到一个你能够自得其乐的方向。如果你对这个技术毫不感兴趣怎么去坚持，那它就是苦难，所以你一定要找到一个感兴趣的方向。爱因斯坦说兴趣是最好的老师，我非常认同。
第二是说勤奋，今天可能是大家不得不勤奋，因为单位会逼着你勤奋。但我们当年入行的时候不是这样，那时候是很宽松的一个工作环境，但我们对自己要求非常高。我记得我那时候虽然不是996，但都是在客户现场做开发，每天晚上10:00才离场，但是我自己学习也会经常到2点，早晨还会起来去跑步，保持一个健康的体魄。
第三是坚持，我觉得年轻人不能过于频繁的调整方向。我有时候看到年轻同事的简历，可能一年就换一个工作，我说你怎么能知道你到底要做什么？你可能自己也不知道，这是个坏事。所以要能够坚持，在坚持的过程中你要获得学习的能力。掌握了学习的能力，把技术和知识吃透，然后可以把它复制到新的方向上去，不惧怕挑战。
第四点就是方法，你可以借鉴一些他人的成功经验。兴趣、勤奋、坚持加上方法，每个人都能做出来优秀的成绩。后来我有个朋友为我这四个词又加上了一个词——健康，健康是第一位的，如果你身体不好，就会变成三天打鱼两天晒网，加了三天班养两天病。
04 Q&A
Q：以前 Oracle 都喜欢把业务逻辑在库里做，现在其他数据库都要轻，不要重，业务都放在应用程序做，还要 redis 这些缓存，这是趋势吗？盖国强：首先这是一个现状，那么这个现状是不是一种最佳的状态？我认为不是。任何事情都是过犹不及，相信我这句话。
以前 Oracle 的发展历程是什么呢？最早所有的数据库都是一个单纯的存储。MySQL 最初是这样，ES 也是，只是说 Oracle 在过去发展的特别成熟，它尽可能的去拓展了它的外延，然后它把大量应用在做的事情放到了数据库里，让数据库变成了一个不再纯粹的存储系统。所以我说 Oracle 其实应该是一个具有应用属性的数据库系统。
让大家可以在数据库上做开发工作，这些工作对于一个数据库厂商来说好不好？当然好。它让你的应用对它产生依赖了。为什么今天的新的数据库都不要在数据库里做应用逻辑？而要在应用上做呢？
你想去革别人的命，你自然要唱出新的曲调从而去取代它。一个新的数据库成长起来，当它逐渐强大之后，它还是会走向这条路，这是想都不要想的。而今天如果一个人或者一个产品过分偏激的去攻击一个技术或成果，我觉得它一定是片面的。
过去 Oracle 发展的特别快，把各种东西全都放到数据库里，比方它以前把 LOB 大对象、XML、JSON 和区块链等什么都放在数据库里了。
肯定有一些它不擅长的事情，所以不同的数据库涌现出来，来解构它过去的一站式方案形态，搜索的拿出来，大对象的图片、非结构化的数据被拿出来独立成新产品，这些其实是倒逼着数据库回归到它本源的状态中去。
所以这个问题挺复杂的，但是我总结起来就是过犹不及，任何一个技术都是过犹不及。把应用逻辑从数据库里完全挪掉，也是过的，因为你把这些东西都放在应用端了，当应用端跟数据库与网络之间产生大量的交互，其实也会带来大量的额外的负担，你会发现可能服务器的资源又不能够被充分利用，慢慢的可能新兴的数据库又会将关系的逻辑放在数据库里，这是发展演进的一个过程。
但我相信这是个螺旋上升的过程。如果我们能看清楚这个状态，我们还能发现这些变化是上升的，是前进的，它就是正确的。但是一切偏激的言论、观点我认为都要怀疑它。
林晓斌：我特别认同国强老师的这个观点。如果你把所有的数据库当 kv 来用，你会浪费很多的能力。有的团队会规定，这也不能用那也不能用，那可能是因为我们对它还不够了解，这东西我们真的去了解内部。
一个 join 语句在数据库里执行逻辑，如果我们在应用程序实现，你会发现写法是差不多的，但是在数据库里面做有它的好处，因为它本地计算减少交互。
有的团队会规定不允许使用存储过程。可能是之前被乱用了，因此认为这样代码就不好维护，实际上它是一个代码没有维护好的锅，不是存储过程的锅。 如果你把存储过程也认为是代码的一部分，把它放到你的 git 里面去，你存储过程的所有变更也都必须走代码发布流程，它就是你代码的一部分。
不是说所有东西都要放在存储过程，而是你现在多了一种选择，并不一定是在所有的条件都必须在应用层做，而是多了一种选项。
Q：数据方面有哪些好的社区？杨振涛：我对这里的“数据”有两种理解，一种是数据存储系统，有一些特定的数据产品，另一个我理解是大数据相关的。其实对于一个特定的数据产品来说，每一个都有两种类型的渠道。
第一个是官方渠道的，一定是最权威一手的信息。我觉得作为一个软件开发人员或者作为一个技术人员，一定要具备掌握一手信息的能力。只有当你的英语成为一个障碍，而想要快速去了解它的时候，看二手信息也是没有问题的，但真正想了解权威专业的知识，一定要去看一手的信息。
特别是 ES 这种，迭代速度非常快，最关键的是认识它的原理，可以直接去看它的代码，Github 上打开后定位到具体的某一行去研究。
我曾经仔细去研究过 ES 为什么会有那么多的线程池，最后发现它所有的线程池都是一个自己写的工具类。它对线程池的理解就是不需要你再去经常调试那些参数，它已经先天给你配到最佳状态了，这个产品设计就是这样子，你调了之后可能只会影响它的均衡性。
第二个，基本上所有流行的开源项目在国内都发展有本地化的开源社区，比如我所参与的 ES 、Redis 和 Jenkins 社区，我们不止帮大家把原版的英文文档翻译成开发人员更喜欢看的中文，而且还提供线上的交流平台，社区和论坛随时可以提问和解答。
曾经有些同学说做程序开发就是依赖于搜索引擎，你遇到的任何问题，都可以在网上搜索到，很少会遇到一个全世界人都没遇到过的问题。其实这里有一个正面的含义，就是这样丰富的社区给你提供了很好的经验学习方向。
像 ES 的中国社区算是非常活跃了，不但有线上的问答社区，而且线下也有非常火爆的 Meetup 活动开展。
Q：数据库新人要成为一名数据工匠的话要选择深入哪些数据库呢，业务中用了 7、8 种数据库，但都是停留在使用层面，哪些开源的数据库适合新人深入学习呢？杨振涛：我把这个问题拆解一下，对业务系统来说它可能永远只是使用数据库，比如我所经历的一个业务系统中，虽然 ES 有很强大的插件模式，但业务系统不愿意绑定在这个上面，假如说我的业务系统因为某种原因需要做技术方案重构的时候，如果绑定在这个产品上，另外一个核心产品它如果没有支持这个特性，那就很为难。
这就是业务系统为什么不绑定特定产品的原因，所以大概率是对这些数据产品只停留在使用的层面。
如果你希望更熟练的使用它，作为一个开发人员很好的支撑业务需求，那主流的这些产品，每一类型至少选一个。
比如 Redis 最主要的一定要知道它的典型应用场景、主要特性和基本的使用方法，掌握所使用语言有哪些驱动，它的特性是什么样子？支不支持集群？兼容性是什么样子的？有时候可能会发现有的驱动很好用，或者是用其他第三方的，但最后发现支持的特性不全，这个是需要去权衡的。
另一个方面就是对于你所选择的这些数据库，像 ES 这种新的类型，其实后面还有很多这种全新的类型的，可以从某一个单点突破，比如从搜索引擎单点突破；现在有很多人对 ES 的驾驭能力很强，就用它来做存储。包括 Redis 最早所有的业务系统只用作缓存一种方式，不敢让它的数据落盘等各种各样的风险。
现在这种方案已经很成熟了，Redis 无论是单节点还是集群方案都非常成熟，大家可以大胆去使用。所以关系型、key-value、分析型等每一种类型建议至少学一个。
另外新人从哪一种数据库入手？我的建议是实践出真知，实践才是检验真理的唯一标准。具体哪一个数据库好，哪一种适合新手，我觉得比较难定，因为判断的标准不明确。需要根据你从事的行业，面临的业务领域的问题综合分析。
掌握最需要、最能匹配需求的才是首选，哪怕你是一个新人。当然对于在校的学生，建议首先拥抱开源，学习开源的知识。
盖国强：今天的数据库的种类确实非常多，我到底应该学那个？大家注意去看那些在每个领域里的专家，比如像今天我们这三位“老”专家。为什么大家会知道我们？因为我们入行早。所以选择恰当的时机去投入到一个恰当的方向里是很重要的。
所以关于你今天要做的选择，你需要预判哪一个数据库可能会快速成长起来，哪些数据库是非常新兴的，如果你能够尽早的在这个方向上提前处理，掌握深入，那你就可能会获得先入者的技术红利，获得回报。
比如说今年很多企业会选择MySQL作为支撑的数据库，为什么很多人要这么选？因为生态比较好。 如果你判断出一个可能有价值的方向，就提早去投入，这个方向的人才是非常有限的，你一定能够在这个方向上获得回报。所以如果你有志在一个方向去发展，找到一个非常有潜质的方向，越早投入越好，能获得先入者的优势。
Q：丁奇老师能推荐 MySQL 相关的1-3本入门书吗？林晓斌：只要一本就行，推荐《高性能MySQL》第三版，反复看会有很大收获。
Q：数据库最重要就是数据安全不丢数据，其次才是性能等等，现在各种各样的新硬件，及新的框架作为底层存储有一定的不可控的风险，怎么看待现在云原生数据库这些很激进的技术及迭代现象？林晓斌：你不用担心，因为我相信所有在做新技术的时候都是有保底方案的，比如说我们要替换一个成熟的系统，一定会拿成熟系统做保底的，这边要是出什么问题能快速切回去。
对于技术迭代，其实技术迭代一定是激进的，否则就不迭代了。比如用了新的硬件，为了开发出硬件的极致性能对软硬件进行优化，可能会引入新的 bug，可能会只局限在特定场景里发挥好的效果，但我觉得这就是技术迭代的正常过程。 Q：如何进行自我剖析，制定学习路线呢？盖国强：你一定要学会给自己设问，然后自己来寻找答案，通过不断挑战自我去获得成长，这个能力特别好。
我们当年在论坛上也会给自己提问，去思考，并且找答案。我觉得这就是一个自我剖析的方式。如果经常做自我反思、自我设问、自我解题，我觉得你就是一个具有探索型性格的人。
在面试的时候，我最喜欢问别人的一个问题就是：你自己做过深入思考的的技术话题是什么？你思考的有多深，得出了什么结论？很多人会回答说好像没有做过什么，反正就在看书，其实是没有把书本上的东西变成自己的。
如果你不能够特别深入的去做自我自我探究，那你就学会包容别人的成果，看看别人是怎么做的。就熟读唐诗三百首，不会作诗也会吟。
所有如果你能够经常自我设问倒逼成长，那么就选择一个你感兴趣的数据库，自己去探究找到适合自己的方法，你可以借鉴别人，最后形成自己的风格，最终获得自信。
Q：如果从 Oracle DBA 转型到 MySQL 或者其他数据库，没有生产经验怎么办？盖国强：我的建议是由点及面，由浅入深，我要把任何一个我能够抓到的问题追究到内核层和源码层。如果你研究 MySQL，你可以在社区里看看别人遇到了什么问题，你也可以上去跟别人探讨，找到一些问题，去验证自己到底能不能具备一种解题能力。
如果你现在没有，就要有意识培养这种解题能力，找到10~20个问题点，在每个问题上花一个星期去探究它，跟自己死磕，一个星期不行就两个星期。如果能在10~20个典型的问题上，进行非常深入的探究，你会得到所有懂行的人的尊重，你的努力会让别人知道。
如果自己找不到问题，就去技术社区，墨天轮的小程序上也有很多人提问。回答问题是提升你自己的最好方法。我当年最开始入门的时候，别人提的问题我没有遇到过，就自己整了两台服务器去搭了个环境来验证，花了很长时间但是把这个问题研究出来了，帮助了别人的同时，让我自己也对该问题有了通透的了解。
林晓斌：我认识一位小伙伴，他就是从 Oracle 转的 MySQL，其实是非常有优势的。
在 2010 年左右，有一天我的导师问我：“MySQL还有改进空间吗”？我想了想回答：“人家都做了二十几年，应该已经极致了，没什么改进空间了”。
后来我才发现不是这样。从10年到现在，MySQL 也在不停迭代，离极致还有很远的距离。那个小伙伴说，以前他熟悉 Oracle，但 Oracle 是闭源，只能接触到原理，现在突然之间有一个机会让他从代码级去看它是怎么实现的。
其实 MySQL 跟 Oracle 很像，Oracle 工程师转行到 MySQL工程师还是有天然优势的。但是核心还是跟所有跨行学习人的品质要求一样，就是有很强的学习能力，要敢于接受挑战。
Q：数据库和分布式系统有什么可畅想的未来?杨振涛：现在的很多分布式数据库其实它就是一个分布式系统，分布式系统是一个概念，主要包括应用、存储、计算等类型，比如现在的应用程序很多是分布式的，各种微服务还涉及很多节点之间的协同，服务的治理，甚至有自己的命名服务，需要有服务的注册机制等等，还有流量的调度，服务的无损切换和上下线，这些都是分布式应用系统。
另外从存储和计算来讲，数据库是典型的分布式存储系统的一个范畴。从 ES 到大数据这些都有自己的分布式存储特性支持。从大数据的离线、在线实时分析系统到 AI 训练的平台这些属于分布式计算系统。
分布式系统未来的畅想是什么样子呢？第一，现在存储计算大部分基本上是分离的，所以未来这个方向有可能会去融合，会有更好的解决方案。
另外一方面，从应用层角度来看，分布式应用系统可能会跟分布式存储系统，有更密切的交互关系。
我举个例子，一个几亿用户量级的大型系统，一个用户请求过来的时候，前端有统一接入，然后路由到某个应用程序的某个节点去处理，这个时候可能已经知道了我对数据层的访问需求，只要到特定的存储层的某一个节点去就可以了，而不需要整个系统感知到，或者不需要到某一个集中的节点去，利用分布式存储系统的路由能力路由到指定的节点，因此它的路径就可能会大大的缩短。
我们知道现在很多微服务治理平台有调用链功能，它希望知道一个请求从底层的处理到最后返回的整个调用链上涉及到哪些服务，中间的数据传递以及每一个服务的健康状况，还可以用来做监控中的健康检查，以及用来做性能调优。
如果未来分布式应用系统和分布式存储系统能融合到更上层密切协作的话，调用链上的时间会大大的缩短，因为不再需要让层与层之间的隔离这么强了。
总之相比于各层都有一个中心的节点去路由，如果说我有一种协同的机制，让调用链路极大地缩短，既减少了网络请求的时间，也做到了整个请求响应，我觉得这也是一个比较重要的方向。
当然现在已经有一些这种激进的微服务治理平台，在往前后分别去延伸，在最前端希望跟边缘计算结合，所以有些东西已经开始融合了。
最下层的存储层，甚至我们现在有的这种系统，有些激进的做法已经做到了应用程序的访问日志不再需要落盘了，数据来到内存直接写走，流式地直接到大数据系统去处理。用户的访问行为可能在秒级这个级别，在后端的数据分析系统已经可以看到，在后端经过 AI 模型预测已经能反馈到用户端上了。在你下次点击的时候，反馈效果已经在应用程序层去体现了，这也是未来的一个发展的趋势。所以这种实时的多层之间多个分布式系统跨层的协作，一定会越来越密切。
当然更长远的未来，我还是坚持合久必分，分久必合这样一个观点。像现在云原生生态这种服务网格，它其实就是一个分和合的关系，以前我们希望应用程序里面把很多事情解决了，现在希望就是说应用程序只有一个唯一的重要职责，那就是业务逻辑的实现，剩下的所有网络流量的处理交给下层去处理。
