我曾与数十家企业合作，帮助他们将旧有数据仓库或者分析数据库迁移至云端。通过亲身经历，我体会到整体式思维与设计在本质上，很难与现代云架构带来的种种优势相兼容。在本文中，我们将具体探讨如何在AWS云当中建立起可扩展、灵活且经济高效的数据分析平台模式，同时回顾这种模式在企业当中的成功表现。
内容摘要：我们设计出一套三层架构的数据平台，L1包含原始文件数据，L2包含经过优化的文件数据，L3则充当缓存。数据会首先被归入L1当中，而后将各个用例独立转换为L2，接下来再根据特定的访问模式将其中部分数据缓存至专用数据存储之内。
错误一：“一种数据存储机制即可通吃一切。”
企业在对现有数据分析平台进行现代化时，面临的主要问题就是需要放弃遗留系统中使用的各独立数据库。考虑到构建与运营方面已经投入的海量资金，企业往往很难下决心将其淘汰。我遇到过不少企业，他们投入了数百万美元与多年时间来构建自己的数据仓库，包括其中的各类ETL流程、存储流程以及报告工具。同样的，熟悉了原有系统的企业也很难放弃单一工具带来的助益，例如“单一瓶颈”或者“明确的待分析数据位置”等等。
几天之前，Amazon.com宣布他们正式关闭了零售业务中的最后一套Oracle数据库。这是个漫长的转型过程，前后持续了四年多时间。作为Amazon.com解决方案架构师，我的第一项任务就是帮助设计一套由常规关系数据库（特别是Oracle）向云数据库的迁移流程。我与企业中的数十个团队开展合作，对遗留系统进行重新设计，努力从传统的关系数据库转换为更具可扩展性与灵活性的新型数据存储架构。我们的目标是迁移至NoSQL（主要是DynamoDB）数据库或者分析（当时主要以Amazon Redshift为目标）数据库。对于这些团队来说，放弃以往的舒适区绝非易事：他们能够对每个列进行查询（或者用他们的话来说，进行列搜索）、使用SQL作为标准查询语言满足其全部数据需求，同时全程使用早已熟悉到不能再熟悉的工具方案。但是，Amazon.com决定从长远出发，必须投资建立起几乎拥有无限可扩展空间的基础设施。他们希望技术元素永远不再成为制约业务发展的瓶颈。