前言
当第一次进入大数据的世界时,我仿佛置身于软件开发的美国西部荒原。许多人放弃了关系型数据库,转而选择带有高度受限模型的NoSQL数据库,主要是因为其使用体验良好、熟悉度较高且这种数据库可以扩展到成千上万台机器上。NoSQL数据库的数量巨大,堪称铺天盖地,这些数据库中很多都只有细微的差别。一个名为“Hadoop”的新项目开始崭露头角,它宣称具备基于海量数据进行数据深度分析的能力。但弄清楚如何使用这些新工具很令人困惑。
当时,我正试图处理所在公司面临的扩展性问题。系统架构非常复杂—该Web系统包含共享关系型数据库、队列、工作节点、主节点和从节点。数据损坏渗透至数据库,为了处理这些损坏,我们使用了应用程序中的特殊代码,但从节点的操作总是落后于其他节点。我决定探索其他大数据技术,看看是否有比我们的数据架构更好的设计。
早期的软件工程职业生涯的经历,深刻影响了我对“系统该如何架构”的观点。我的一位同事花了几个星期将来自互联网的数据收集到一个共享文件系统。他在等待收集足够的数据,以便能在其上进行数据分析。有一天,在做一些日常维护时,我不小心删除了他的所有数据,导致他的项目延期了好几周。
我知道自己犯了一个大错,但作为一个软件工程师新手,我并不知道这会导致什么样的后果。我会不会因为粗心被解雇呢?我发了一封电子邮件向团队诚挚地道歉—让我惊喜的是,大家对此都表示非常同情。我永远不会忘记那个时刻—一个同事来到我的办公桌旁,拍着我的背说:“恭喜你!你现在是一个专业的软件工程师了!”
他玩笑式的表述道出了软件开发中不言而喻的“真理”—我们不知道如何创造完美的软件。软件可能有bug而且会被部署到生产中。如果应用程序可以写入数据库中,那么bug也可能写入数据库中。当着手重新设计我们的数据架构时,这样的经历深深地影响了我。我知道,新架构不但必须是可扩展的、对机器故障是可容错的,并且要易于推断故障原因—但对人为错误也可容错。
重构那套系统的经验,促使我走上了一条“在数据库和数据管理方面怀疑一切我认为是正确的”道路。我想出了一个基于不可变数据和批量计算的架构,令我很惊讶的是,与仅仅基于增量计算的系统相比,新系统要简单得多。一切都变得更容易,包括操作、不断发展的系统以支持新的功能、从人为错误中恢复和性能优化等方面。该方法很通用,似乎可以用于任何数据系统。
但有些事情困扰着我。当观察其他行业时,我发现几乎没有人使用类似的技术。相反,在使用基于增量更新数据库的庞大集群架构中,令人生畏的复杂性是为人所接受的。这些架构的许多复杂性已经通过我所开发的方法完全避免或大大缓减了。
在接下来的几年中,我扩展了该方法,并使之正式成为我戏称的Lambda架构。在初创公司BackType工作时,我们的5人团队构建了一个社会化媒体分析产品,该产品支持在超过100TB的数据上进行多样化实时分析。我们的小团队还负责拥有数百台机器的集群的管理部署、运营和系统监控。当我们向别人展示自己的产品时,他们对这个团队只有5个人感到非常惊讶。他们经常会问“这么几个人做了这么多事情?怎么可能!?”我的回答很简单:“不是我们在做什么,而是我们没有做什么。”通过使用Lambda架构,我们避免了困扰传统架构的复杂性。通过避免这些复杂性,我们大大提高了工作效率。
大数据运动只是放大了已经存在了几十年的数据架构的复杂性。主要基于增量更新的大型数据库架构将遭受这些复杂性的折磨,从而导致错误、繁重的操作,并阻碍了生产力。尽管SQL和NoSQL数据库通常被描述成对立或相互对偶的关系,但从最基本的方面来说,它们实际上是一样的。它们都鼓励使用这种相同的架构—该架构具有不可避免的复杂性。复杂性是一个邪恶的野兽,无论你承认与否,它都会“咬”你。
为了传播Lambda架构以及它如何避免传统架构的复杂性等知识,我写了本书。它是我开始从事大数据工作时就希望有的。我希望你把这本书作为一个旅程—挑战你以为自己已经知道的关于数据系统的知识,并发现从事大数据工作也可以优雅、简单和有趣。
出版在【华章出版社】 作者:
南森·马茨(Nathan Marz)
[美] 詹姆斯·沃伦(James Warren)
-------------------------
-------------------------
感谢分享!
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。