迁移了几十家企业之后，我们总结了如何在云中构建成功的现代数据分析平台

我曾与数十家企业合作，帮助他们将旧有数据仓库或者分析数据库迁移至云端。通过亲身经历，我体会到整体式思维与设计在本质上，很难与现代云架构带来的种种优势相兼容。在本文中，我们将具体探讨如何在AWS云当中建立起可扩展、灵活且经济高效的数据分析平台模式，同时回顾这种模式在企业当中的成功表现。

内容摘要：我们设计出一套三层架构的数据平台，L1包含原始文件数据，L2包含经过优化的文件数据，L3则充当缓存。数据会首先被归入L1当中，而后将各个用例独立转换为L2，接下来再根据特定的访问模式将其中部分数据缓存至专用数据存储之内。

错误一：“一种数据存储机制即可通吃一切。”

企业在对现有数据分析平台进行现代化时，面临的主要问题就是需要放弃遗留系统中使用的各独立数据库。考虑到构建与运营方面已经投入的海量资金，企业往往很难下决心将其淘汰。我遇到过不少企业，他们投入了数百万美元与多年时间来构建自己的数据仓库，包括其中的各类ETL流程、存储流程以及报告工具。同样的，熟悉了原有系统的企业也很难放弃单一工具带来的助益，例如“单一瓶颈”或者“明确的待分析数据位置”等等。

几天之前，Amazon.com宣布他们正式关闭了零售业务中的最后一套Oracle数据库。这是个漫长的转型过程，前后持续了四年多时间。作为Amazon.com解决方案架构师，我的第一项任务就是帮助设计一套由常规关系数据库（特别是Oracle）向云数据库的迁移流程。我与企业中的数十个团队开展合作，对遗留系统进行重新设计，努力从传统的关系数据库转换为更具可扩展性与灵活性的新型数据存储架构。我们的目标是迁移至NoSQL（主要是DynamoDB）数据库或者分析（当时主要以Amazon Redshift为目标）数据库。对于这些团队来说，放弃以往的舒适区绝非易事：他们能够对每个列进行查询（或者用他们的话来说，进行列搜索）、使用SQL作为标准查询语言满足其全部数据需求，同时全程使用早已熟悉到不能再熟悉的工具方案。但是，Amazon.com决定从长远出发，必须投资建立起几乎拥有无限可扩展空间的基础设施。他们希望技术元素永远不再成为制约业务发展的瓶颈。

几年当中，Amazon.com以“简化加发明”为基本理念，打造出多种工具以简化整个迁移流程。他们还利用AWWS构建起一系列新型目标数据库，主要包括Amazon Aurora（PostgreSQL风格的Oracle数据库替代方案）以及Amazon Athena。关于这两套方案，我们将在后文中具体探讨。

对于大多数企业而言，单一工具在发挥云环境中灵活性、规模化、成本、敏捷性以及其他现代架构优势方面也都有着显而易见的局限性。但与此同时，企业也无法容忍系统整体发生崩溃或者卡顿，因此多数客户希望利用云服务（例如Amazon Redshift数据仓库服务）或者Amazon Athena（托管Presto服务）、Azure Databricks（托管Spark服务）或者谷歌BigQuery替代不可扩展且成本高昂的本地数据库——例如Oracle或者MS-SQL。这种一项云服务代替一种整体式本地数据库的方法，在直观上更加简单易行。但遗憾的是，实际情况往往没这么简单，因为之前提到的局限性来自工具的独立性，而不仅仅是其到底运行在哪里。

错误二：“Hadoop已死，Spark才是未来。”

每隔大约五年，就传代出现一种足以颠覆整个现代架构的新兴技术。十年之前，Hadoop开创了可扩展数据处理的新时代，让用户得以通过Hive、Pig、HBase等工具打理自己的大数据资源。五年之前，Spark拿出了远超Hadoop的大数据处理速度，比Hive更好的SQL，更具功能现代性的Scala与Python编程语言（替代Hadoop的Java）以及一系列高人气新功能，并再次改变了游戏规则。

Spark还拥有良好的工具成熟度，以及在大数据开发人员群体内的广泛认可度与高人气。将Spark SQL、Spark Streaming乃至机器学习同Spark MLlib结合起来，能够带来极具吸引力的强大功能，也让众多企业将Spark视为大数据处理的客观标准。然而，人气的快速飙升以及对数据分析与机器学习的大量需求，令Spark的局限性同样暴露无遗。作为Spark专家，同事们经常要求我审查并修改那些随着体量增长而变得太复杂或者运行速度太慢的Spark代码。另外，我也看到不少企业开始尝试利用Spark库构建机器学习模型，Databricks在这方面就做出了不少努力与贡献。

我个人的建议是，现在大家最好利用基于PrestoDB的SQL编写数据转移逻辑。与Scala或者Spark的Python相比，SQL仍然具有多种优势，特别是简洁的形式、更少的代码潜在错误，以及为编写者预留的逻辑发挥空间。当然，负面因素主要来自当前开发人员们的抵触情绪，对他们来说Scala或者Python更加熟悉好用，而SQL则显得比较难上手。

错误三：“所以，Presto才代表着未来。”

“现代云架构”这个术语是指基于微服务、无服务器以及按需计费（而非按配置计费）的新型架构。这种现代架构的典型代表就是AWS Lambda（或者Azure Functions/Google Cloud Functions）。用户只需要编写业务逻辑，其他工作都由云端统一负责打理——告别以年为单位的漫长产品发布周期，无需无数次重复启动及终止服务器或虚拟机，也用不着考虑“生产环境中必须仅代表和Java”之类的限制。未来，将有成千上万种功能可根据需求随时开发并在必要时执行，业务逻辑网格相互之间完美调用，并根据负载强度随时进行规模伸缩。

在数据方面，Amazon Athena就是一种无服务器选项。这项服务当前运行在托管PrestoDB引擎之上。之所以要加“当前”这个定语，是因为亚马逊方面正在着手为S3升级最佳引擎选项SQL。由Hive、Impala、SparkSQL到现在的Presto，一路演变已经反复证明，我们总能迎来更好更强大的引擎方案。亚马逊也希望避免他们在命名EMR（此前的Elastic Map Reduce）服务时犯的错误，这套号称能够简化分布计算的解决方案如今在复杂程度上甚至反超了当初的MapReduce。

在Amazon Athena当中，大家可以使用SQL语言编写业务逻辑，而后将查询发送至经过优化以满足数据及查询复杂性要求的一组工作节点。在大多数情况下，只需要等待几秒钟，用户就能够通过S3中的CSV文件获取查询结果。无需管理服务器，用不着等待服务器启动，也不再为闲置计算设备付费——这，才叫真正的无服务器模式。

但是，也有不少人向我抱怨说Amazon Athena太贵了，特别是在运行大量系统管理的分析查询时，其使用成本确实比较夸张。AWS Lambda也面临着类似的评价。由一次性资源采购（Presto集群或者用于业务逻辑的应用程序服务器）转向按使用量计费，确实是一场令人心生顾虑的冒险。但完成冒险的秘诀，就是弄清楚该如何优化资源使用量，不过这会加大资源管理难度并吓退不少运营人员。

由于Amazon Athena的使用成本直接由查询请求所扫描的数据量决定，因此控制数据体积能够显著降低每一次查询的执行成本。在Athena使用方面，最常见的错误就是利用它查询大量原始数据与原始格式（例如JSON或者CSV），并大量依赖它提供的查询功能。

那么，该如何解决？

让我们总结一下到目前为止，我们都探讨了哪些内容。我们了解到，不应使用单一数据存储机制，这会限制我们提升数据使用量的能力。我们了解到，在新兴技术发展到一定的成熟度之后，我们就应该积极了解并学习、测试以及采用这些新的工具与技术。在设计技术系统时，我们应该具有长远的眼光，确保企业业务能够摆脱架构束缚实现无限增长。

有了这样的背景与前瞻性，我们就可以更好地解释为什么有必要在接下来的几个数据层身上投入大量精力，而不只是将所有内容都放进同一套超级数据库（无论您具体选择的是哪一种数据库方案）。

现在来看我推荐的这套架构模式。

第一层（L1）——利用低成本存储容纳原始数据（例如S3）

所有数据都应以原始格式人各个来源获取，无需进行任何修改或者过滤。数据可以来自物联网设备，Kafka或者Kinesis等流媒体源，文本日志文件，NoSQL，或者Web服务中的JSON、图像、视频、文本注释，合作伙伴提供的Excel或者CSV文件，或者是需要进行处理及分析的任何其他来源。

数据很难以外部键的形式在不同表之间进行良好组织，我们也无法要求一切地址或者产品ID都采取相同的格式。第一层不关心协调工作，也只有这样才能保证系统拥有充分的规模扩展灵活性。很多数据项目之所以遭遇失败，就是因为人们投入了太多时间进行数据组织，却不知道自己组织的大多数数据根本就无法带来任何重要的商业价值。与此同时，这部分浪费的资源自然无法被用于对数据分析平台自身的设计与构建。

第二层（L2）——低成本存储中的多种优化后衍生数据

进入第一层的数据接下来逐步构建起第二层。在首个文件到达第一层后，第二层立即产生，并随着第一层接收数据量的增长而逐步发展。发展的方向以数据可用性为基础，同时配合企业的业务使用情况。输出结果将接受分析，例如进行机器学习预测或者分析报告。下面，我们简要论述小标题描述中的各部分内容。

多种—每种分析用例都都应具有自己的专用独立数据流，当然这也意味着数据将被复制数十次以进行不同方式的计算。需要注意的是，每项分析都会从不同的角度以及不同的业务需求出发审视数据内容。而得出的结果，最终也将服务于不同的业务团队。例如，销售分析、市场营销分析以及物流分析的侧重点就有所区别。

优化 — 从原始格式到分析见解的数据转换过程，也将带来巨大的优化空间。目前最典型的作法就是提取JSON数据并将其保存为Parquet格式。这种格式既保留列式元素（对单一列的查询仅扫描该列数据），同时也经过了压缩。在利用Athena中的“Create Table As Select（CTAS）”处理大部分此类转换结果时，我们都能获得高达1000甚至10000倍的资源成本改善。我们可以将音频及视频转录为文本，将图像分析为类，或者是对面部表情或者人脸图像进行转换。总而言之，此类分析及查询应当尽可能简单且成本低廉，只有这样分析功能才会真正成为业务人员的日常工作利器。

衍生数据 — 第二层中的数据主要源自原始格式的汇总、过滤或者转换结果，用以匹配特定的业务需求。举例来说，我们可能需要预测品牌商品的每日销售额，但无需单独列出每一款具体产品的销售量。当然，我们也不用担心衍生数据太过粗略，毕竟原始数据还好好地待在第一层里呢。对于其他业务用例，我们可以整理出其他特定的衍生数据。到这一步，可以看到“相同”数据开始呈现出多种不同形式，这是因为数据本身并不真的相同，衍生出的结果可能五花八门。

低成本存储 — 如果大家希望为业务大数据保留几十套“副本”，那么每一套副本的存储成本都必须非常低廉。我发现很多企业都在尝试直接使用原始数据或者不加筛选地将其一股脑塞进计算与内存成本高昂的数据库当中。请记住，如果没有第二层的加持，这种作法很快就会带来我们难以承担的恐怖成本。

第三层（L3）——选择性缓存数据存储

为了帮助用户与数据分析结果进行交互，我们通常需要缓存这些结果，从而提供真正具备可用性的访问速度与查询功能。

下面来看几种我个人比较推荐的方案选项（当然不够全面，每种选项也都对应不同的应用场景）：

• DynamoDB，用于对客户端应用程序的GraphQL访问；
• ElasticSearch，用于文本查询；
• Redis ，用于对内存内数据集（例如Sorted-Sets）进行快速操作；
• Neptune，用于图查询（请不要与GraphQL混淆）。

另外，把分析结果缓存到关系数据库（例如MySQL或者Aurora PostgreSQL）也是种常见操作，比较适合那些体积相对较小的数据集及可视化工具、或者只能支持关系数据库的商务智能工具。

最重要的是，现在咱们聊的可是缓存，缓存的成本比前两层高得多得多。因此，请务必斟酌用户的实际使用情况，并随时根据需求进行创建或者删除。如此一来，我们就能在组织之内建立起始终符合灵活性与成本效益要求的分析用例。虽然难度较高，但这一步能让你的企业在智能水平方面更上一层楼、节约使用数据时的时间周期，并有效规划产品发布过程中的敏捷性、成本、规模以及简单性等因素。

运营：编排与监控

要想运行这样一套多层、多用例、多业务线外加多数据存储机制的复杂系统，单独一位数据库管理员甚至是数据库管理团队都不可能胜任。换言之，从项目的起步阶段，我们就必须将自动化考虑进来。

在不少企业中，DevOps实践已经开始发展，并围绕着微服务、容器、持续集成与部署（CI/CD）衍生出多种新功能。另外，面向云端的迁移工作也越来越引起人们的关注。这一切，都为IT架构的现代化升级与能力增强奠定了坚实的基础。但是，对于大多数组织而言，DataOps仍是一项复杂且难以克服的挑战。新架构与敏捷性的持续发展，对技术人员的能力提出了全方位要求，同时也让企业不得不精心选择合适的工具以全面实现流程自动化。

目前比较常见的编排选项主要分AWS原生（Step Functions）、开源工具（主要是Apache AirFlow）以及托管服务（例如Upsolver）这几种。我个人对这几种选项都很熟悉，大家需要结合自己的特定用例、数据源、预算以及技术能力等因素决定采用哪种方法。

总结部分

在第一次接触时，下面这副图可能会吓退不少人，因此我才把它留到最后。希望大家在阅读本文并理解了具体原因之后，能够更好地参考并剖析这样一份总结性资料。

云环境中的多层数据流

此图所示为某家客户所使用的实际项目，当然大家可以根据自己的喜好利用其他工具（例如AirFlow、Grafana以及Jenkins）替换其中的编排方案，使用DataDog进行监控或者选择Terraform实现部署。云的基本概念，就是实现架构模块化并确保在业务需要时随时对其中任意部分进行添加、替换、扩展以及删除。只要大家拥有旺盛的好奇心并愿意学习新兴技术，就完全能够在技术快速进步这一时代背景之下建立并运营起一套强大的现代化数据平台。更重要的是，这样一套数据平台已经成为如今任何一家希望良好生存并提升自身竞争力的企业所不可或缺的数字化与AI转型基础。

原文链接：

Building a successful modern data analytics platform in the cloud