（原标题：数据新时代：深入了解摩根大通如何在AWS云上运行数据网格）
一个新的数据时代即将来临。
技术行业普遍处于转型期，数据业务尤甚。即使是我们的语言也反映出了这一点。例如，我们很少再使用“大数据”这个词了。相反，我们现在谈论的是数字化转型和数据驱动型企业。
许多人终于意识到了数据不是新的石油——因为相同的数据可以反复地被用于不同的目的，这一点和石油可不一样。但是我们的语言仍然非常令人困惑。我们会说“数据是我们最宝贵的资产”之类的话，但是在同一句话中，我们谈论的又是民主化访问和数据共享。你想想，你什么时候想过要和你的同事、合作伙伴和客户分享你的金融资产？
在本期的突破性分析中，我们想分享一下我们对数据业务状况的评估。我们将介绍一下数据网格的概念，并以一个领先的金融机构——摩根大通的一个部门为例，介绍他们是如何运用这种相对比较新的理念，面向下一个十年调整其数据架构的。
什么是数据网格（data mesh）？
正如我们之前报道的那样，数据网格（data mesh）是ThoughtWorks公司的技术总监 Zhamak Dehghani在2018年提出的一系列概念和原则。她发起这项运动是因为她的客户——一些世界领先的公司——已经在占据主导地位的数据架构上投入了巨资，可是这些架构并没有带来期待中的回报。
在工作中，她深入了解了为什么她的客户的投资没有产生预期中的效果。她的主要结论是，试图将我们的数据强制转换为单一单体架构的流行做法从根本上来说其实是一种限制。
数据网格背后最深刻的思想之一是数据架构应该围绕着具备领域情境的业务线来组织。跨职能的集中式团队扮演了高度技术化并且高度专业化的角色，而这是阻碍我们实现数据理想的关键障碍。
下面是数据网格最重要的四个原则：
上述的第三条是最重要，但也是最难理解的一条。在过去十年里，关于数据价值的绝大多数讨论都集中在使用数据创建可操作的见解方面：数据知会人类，帮助他们做出更好的决策。我们认为，对于二十一世纪20年代来说，这是数据成功转换的必要但不充分条件。换句话说，如果终极游戏是获得更好的洞察力，我们会将其视为报告的一种重要的延伸，但是这种延伸只是一种进化。相反，我们相信构建能够货币化的数据产品是一个更为有趣（而且是现在就可以实现）的目标。这些产品可能可以直接降低成本，或者是能够产生新的收入——这一点更为重要。
数据网格的概念还有很多，如果你想了解更多的信息，网络上这方面的资源非常多，还有围绕着数据网格形成的整个社区。但是我们想在这里帮助你了解一些基础概念。
数据网格与工具无关
另一个值得注意的点是，在观察 Zhamak 的工作时，她会有意避开围绕特定工具进行的讨论，对于有些人来说，这有点令人沮丧。这种情绪很好理解，因为我们都喜欢有具体的产品和公司作为参考。这是一把双刃剑，一方面，这种做法很好，因为数据网格设计的初衷就是要独立于所选择的工具取得成功。可是另一方面，一些人则会随意歪曲数据网格的概念，大肆推销他们的解决方案，并且声称这些解决方案可以“完成任务”，但实际上，这只是营销的噱头，而不是现实。
摩根大通和数据网格之旅
上周，我们饶有兴趣地观察到一个来自摩根大通的团队举办了一个会议，会议的议题是“通过数据网格架构的数据湖战略”。我们看到了这个标题，然后想，“这个题目真的很奇怪”。我们想知道他们是不是只是使用了旧有的数据湖，然后宣称自己现在已经转变成数据网格了？
但是在我们听了演讲之后，发现答案是明确的——“不，完全不是这样。”一位名为Scott Hirleman的绅士组织了这场会议，有三位摩根大通的发言人进行了发言，如上图所示，他们是：部门首席信息官James Reid、技术专家及架构师Arup Nanda以及信息架构师Sarita Bakst。
这是我们见过的最详细也是最实用的关于数据网格实现的讨论。而且这是摩根大通。我们知道该公司是Hadoop早期采用者，这是一家非常精通技术的公司，这家巨无霸级别的公司在过去的十年里，在全公司范围内为了数据投资了大约数十亿美元。我们很高兴地看到，这家公司并没有纠结于过去在大数据方面的得失，而是在努力地寻找方法进行改进，并且拥抱了数据网格的新思想。
在本文中，我们将分享一些他们使用的幻灯片，并且按照我们的理解，评价这些内容是如何与数据网格的概念相契合的，我们还会略微深入一些——介绍摩根大通正在使用的一些工具，特别是围绕着亚马逊网络服务云的工具。
一切都围绕着商业价值
摩根大通的业务与钱有关，在那个世界中，一切都围绕着盈利展开。
首席信息官 James Reid 展示了上面的幻灯片，并谈到了该团队的总体目标，即聚焦云优先战略，对摩根大通的平台进行现代化。他专注于三个价值因素：第一，削减成本——当然，总是这样。第二，解锁新机遇或者加快价值实现的时间。我们非常喜欢的是第三点，为此我们用红色将它突出标示出来了——让数据复用成为基础价值成分。而他在这里的所讲的内容都是关于如何与各领域保持一致，最大限度地复用数据并确保妥善治理的。
不要被“数据湖”（data lake）这个术语困扰——我们认为这只是摩根大通内部沟通的方式。它对数据湖这个概念进行了投资——摩根大通喜欢各种与水相关的比喻。例如，他们使用的一个术语叫“数据水坑”（data puddles），即单个项目的数据集市和数据池，其中可能包含多个可以导入数据湖的“数据水坑”。
正如我们将会看到的那样，摩根大通不会将所有的内容都放进一个单一的数据湖，用这种方法来打造单一版本的事实。相反，该公司允许业务线创建并拥有自己的数据湖，其中会包含适合目标的数据产品。而该公司使用元数据目录来跟踪沿袭和出处，这样，当该公司向监管机构报告时，就可以确信它所传递的数据是最新的、准确的，并且和之前披露的数据一致。
承认混合云模式的云优先平台
摩根大通倾向于使用公共云，并且采用了敏捷方法和微服务架构。该公司将云计算视为一种基本推动因素。但是该公司也承认本地数据必须是数据网格方程中的一部分。
下面是开始介绍通用技术的一张幻灯片：
在这里，我们想提出几个与Zhamak Deghani 的原始概念相关的观点。
首先，与许多数据架构不同，此图将数据即产品放在了图表的中间。数据产品存在于业务领域之中，是这个架构的核心。左侧的数据库、Hadoop 集群、文件和 API 为数据产品构建者提供服务。
右侧的专业角色——DBA、数据工程师、数据科学家和数据分析师为数据产品构建者服务。因为数据产品归企业所有，所以它们天然地具有应用情境。这一点和绝大多数技术性数据团队有着细微但重要的差别，那些技术性的数据团队是处理流程的一部分，但是缺乏业务和相关领域的知识。
你可以在幻灯片底部看到，关键原则包括领域思维和数据产品的端到端所有权——即构建、拥有、运行/管理。
同时，目标是通过自助服务即平台使数据民主化。
关于数据网格，最大的争议焦点之一就是治理，正如Sarita Bakst 在会上所说，“元数据是你的朋友”。她说：“这听起来有点怪异”——但是我们同意她的观点，拥有一个元数据目录，以便了解数据所在的位置、数据的沿袭并进行整体的变动管理，这一点至关重要。
所以对我们来说，这很好地通过了数据网格的“气味测试”。
数据即产品：不要试图煮沸海洋
摩根大通的演讲者们表示，对他们来说，最困难的事情之一就是埋头了解数据产品。他们花了很多时间让这个概念发挥作用。下面是他们用来描述数据产品的一张幻灯片，它与他们在金融行业中所处的特定位置有关：
该团队强调，在这方面，通用语言和分类法非常重要。该团队表示，例如，定义什么是交易需要进行大量讨论和辩论。但是你可以站在更高的层面上看待这件事，三个产品组围绕着批发信用风险（Wholesale Credit Risk）、当事人、贸易和头寸数据即产品。每个产品组都可以有子产品（例如当事人类别下的KYC）。所以，摩根大通做法的关键是从大处着眼，然后随着时间的推移，不断地进行迭代，变得越来越精细。
围绕着谁拥有这些产品和子产品需要做出很多的决定。产品拥有者们必须捍卫为什么该产品应该存在，应该设立哪些边界，以及哪些数据集应该属于这个产品而哪些数据集不应该属于这个产品——以及哪些子产品应该成为这个循环的一部分。毫无疑问，这些话题很吸引人，而且随着各业务线负责人开辟自己的地盘，有时甚至会引起激烈的争论。
该团队并没有详细讨论这部分内容，而是试图回到数据网格，这些产品中的每一个产品——无论是在数据湖、数据中心、数据池、数据仓库还是在数据水坑之中，都是全球数据网格中的一个节点。
Sarita Bakst支持这一观点，她表示这不应该受基础设施的限制；从逻辑上讲，任何这些数据产品，无论是在本地还是在云端，都可以通过数据网格连接。
所以，我们再一次觉得这真的非常符合数据网格的概念。
关键技术考量
下图显示了摩根大通是如何从技术角度考虑这个问题的：
摩根大通必须考虑一些问题：如何写入各种不同的数据存储，你是否可以/如何才能将数据从一个数据存储转移到另一个数据存储之中？数据如何转换？数据位于何处？数据是否可信？如何实现轻松访问？谁有权访问数据？这些都是技术可以解决的问题。
为了解决这些问题，Arup Nanda 解释说，上面这张幻灯片的核心是Data Ingestor（相对于ETL——即提取/转换/加载）。所有的数据生产者/贡献者都将数据发送到 Ingestor。然后，Ingestor将数据注册到数据目录之中，它会对数据质量进行检查，并跟踪沿袭。然后数据会被发送给路由器，路由器则根据注册通知的最佳地点保存数据。
这是为了灵活而设计的。换句话说，数据产品的数据存储不是预先确定的，也不是固定的。相反，它是在存储点决定的，这样可以在一个地方轻松进行更改。路由器只需读取该最佳位置并将其发送给适当的数据存储即可。
如果写入时没有明确的架构（Schema），就将使用Schema Inferrer。在这种情况下，在推断并确定架构（Schema）之前，数据产品将不被允许使用。在这种情况下，数据进入原始区域，Inferrer确定正确的架构（Schema），然后更新库存系统，以便将数据路由到正确的位置并准确进行跟踪。
这是一段关于香肠工厂应用技术流程用例的高水平的视频。这段时长83分钟的视频非常有趣，对于技术从业者来说，至少其中的技术部分是非常值得观看的，这部分大约从视频的19分钟开始。
摩根大通如何利用 AWS 云实现数据网格
现在，让我们来看一看 AWS 上的具体实现并深入了解一些工具。
正如 Arup Nanda 详细描述的那样，上图显示了摩根大通团队使用的参考架构。其中显示了支持其数据网格的所有各种AWS服务和组件。
从 Kinesis 正下方的 Authorization 块开始。Lake Formation 是数据产品所有者的单点权利，并且有许多与之相关的“存储桶”——包括我们刚刚谈到的原始区域、可信存储桶、精炼存储桶和针对任何需要的操作调整的存储桶。
在这些存储桶下方，你可以看到数据目录注册（Data Catalog Registration）块。这是 Glue Catalog 所在的位置，它会检查数据特征以确定路由器将数据放在哪个桶中。例如，如果没有架构（schema），则数据会根据策略进入原始存储桶等。
在这里，你可以看到很多被使用到的AWS服务、身份、多年沉积下来的Hadoop 工作中的 EMR 集群，Redshift Spectrum 和 Athena。摩根大通将 Athena 用于单线程工作负载，将 Redshift Spectrum 用于可以相互独立查询的嵌套类型。
现在，请记住，非常重要的一点是，在这个用例中，没有一个单一的湖形成，而是多个业务线被授权创建自己的湖，这就带来了挑战。换句话说，如何才能够以灵活的方式完成这一切以满足业务负责人们的要求？
请注意：这是一篇以 AWS 为中心的博客，介绍了他们推荐如何实施数据网格。
进入数据网格
摩根大通采用了联合湖的概念形成账户，并支持该公司的多条业务线。每条业务线都可以按照自身的需要创建任意数量的数据生产者和消费者账户，然后将它们汇总到每个块中心显示的主要业务线湖形成帐户。如下图所示，在这个联合模型中，所有的数据产品都交叉连接在一起。
如上图中间部分所示，这些都汇总到主Glue目录中，这样，任何授权用户都可以找到特定数据元素的位置。这个超集目录包含多个源，并在整个数据网格中同步。
这让我们再一次觉得这是一个经过深思熟虑的数据网格的实际应用。是的，它包含了一些集中管理的概念，但是大部分的责任已经被划分给了业务线。它确实汇总到一个单一的主目录，但这是一项元数据管理工作，并且似乎是确保联合式、自动化治理的必要条件。
重要的是，在摩根大通，首席数据官办公室负责确保整个联合的治理和合规性。
数据网格领域中有哪些供应商？
让我们来看看这个数据网格世界中的一些玩家，然后看看ETR数据。
现在，当然，ETR 没有数据网格这个类别——也没有数据网格供应商这样的东西；你要构建数据网格，而不是购买它。因此，我们所做的是使用 ETR 数据集过滤某些行业，以识别可能对数据网格有贡献的一些公司，并了解它们的表现。
上面的图表描绘了一个我们经常喜欢分享的流行观点。它是一个二维图形，纵轴是Net Score或消费动量，横轴是数据集的市场份额或普及率。我们过滤了分析、数据仓库等板块的数据，这些数据反映了数据网格的参与状况。
让我们观察一下。
和通常情况一样，微软Azure和AWS以高消费速度和市场占有率在这个市场中遥遥领先。Oracle也很突出，因为这个世界上大部分的数据都存放在该公司的数据库之中——它没有消费动量，但是该公司仍然很突出。你可以看到谷歌云几乎没有存在感，但是它的动量有所提升。
请记住，在40%处的红色虚线代表了我们对高水平消费动量的主观看法。
Snowflake的惊鸿一瞥
Snowflake公司一直被认为是Net Score方面的金标准，并且在Enterprise Technology Research数据集方面保持了较高的支出水平。在许多方面，Snowflake的数据市场、数据云愿景和数据分享方法都非常契合数据网格的概念。Snowflake在营销中使用了“数据网格”这个术语，但是在我们看来，这种表述还不够清晰，我们觉得该公司仍然在试图弄清楚如何才能传达它的真正含义。
我们不认为 Snowflake 是一种整体架构，但是该公司的营销有时候会使用一些术语，让听众按照传统思维进行推断。我们的感觉是这实际上是由客户驱动的。我们的意思是，Snowflake 客户非常习惯于整体架构方法，并且因为 Snowflake 使用起来非常简单，所以为他们在旧有的组织结构和思维模式下采用Snowflake的产品“铺平了道路”。
实际上，在数据网格的情境下，Snowflake 的价值在于能够快速轻松地启动（和关闭）虚拟数据存储，并通过联合治理在Snowflake 数据云中共享数据。Snowflake 的愿景是抽象物理云位置（即 AWS、GCP 或 Azure）的底层复杂性，并在其治理的数据云中实现全球共享。在理想的状况下，这种方法能够最大程度地减少为了分享数据而制作拷贝的需要——尽管有时出于延迟的考虑，仍然需要拷贝。
最重要的是，实际上，我们认为Snowflake 非常契合数据网格概念，并且已经为未来做好了准备。
其他值得注意的供应商
Databricks这家公司也很有趣，因为该公司有动量，我们预计，该公司在IPO时在纵轴上的位置会进一步升高。该公司拥有强大的产品和非常好的管理服务。刚开始的时候，每个人都认为Databricks 会尝试成为大数据领域的红帽，并围绕着Spark 构建服务。
可是没有，这家公司努力的方向是构建具有强大人工智能和数据科学能力的托管服务，并且将数据湖提升到了新的水平。在我们看来，这家公司当然是值得关注的，并且会和Snowflake产生碰撞。我们需要做更多的研究，但是我们始终相信Databricks的做法非常契合联合式数据网格的模式。
出于显而易见的原因，我们把很多其他的数据库公司也纳入其中——例如Redis Labs公司、MongoDB公司、MariaDB 公司、Couchbase和Teradata。还有SAP SE；这并不完全是因为HANA for SAP，还因为它是这个市场的重要参与者，IBM也是如此。
Cloudera公司包含了Hortonworks公司和慧与的Ezmeral，后者包括慧与公司收购的 MapR 业务。其中包括一些正在发展的早期 Hadoop 部署。当然，Talend SA 和 Informatica公司也是两家值得注意的数据集成公司。
我们还把一些人工智能/机器学习专业公司和数据科学公司也纳入进来了，比如DataRobot，该公司刚刚获得了2.5亿美元的巨额融资；还有Dataiku、H2O.ai和ThoughtSpot，最后这家是使用人工智能让数据民主化的专业公司，在我们看来，也非常契合数据网格的概念。
我们将VMware公司的云放在图中作为参考，因为它确实是主流的本地基础架构平台。
摩根大通：一个数据网格的实际例子
首先，感谢摩根大通的团队分享这些数据。我们真的非常希望鼓励从业人员和技术人员去YouTube上观看这次会议的视频。而且也要感谢Zhamak Deghani 和整个数据网格社区，他们在挑战既定管理方面做出了出色的工作。摩根大通的演示文稿为你提供了真正的可信度，让数据网格超越了概念的范畴，并且展示了如何才能让这一概念变成现实。
这并不是一个完美的世界。你必须从某个地方开始，也会遇到一些失败。关键是要认识到，将所有内容都挤进单一数据架构将无法支持大规模，也无法获得类似于云的敏捷性。对于小型公司来说，这是一种很好的方法，但如果你正在构建一个全球平台和数据业务，那么是时候重新考虑你的数据架构了。而且，更重要的是，重新考虑你的组织。
虽然大部分的工作都是在云端实现的——但是云优先并不意味着你要把本地数据抛诸脑后。相反，你必须将非公共云数据包含在你的数据网格愿景中——就像摩根大通所做的那样。
快速地取得一些胜利是至关重要的，这样你就能够在组织内部赢得信誉并继续成长。
摩根大通团队的经验之一是教条的存在——例如围绕着数据产品和领域进行的组织。另一方面，你必须保持灵活性，因为技术会来，也会走。
如果你愿意接受水坑、池塘和湖泊之类的比喻，我们建议你干脆拓展范围，把数据海洋也包括进来，这是我们在theCUBE上广泛讨论过的一个概念。数据海洋——它非常大！你可以看看分析师 Ray Wang 和 John Furrier关于这个主题的这段有趣的视频。
想想看吧：正如我们在不断发展我们的语言一样，我们也应该发展我们的标准。过去十年中，大数据基本上都围绕着如何让技术发挥作用。启动、运行并管理大量的数据。围绕着建立基础架构和高速摄取数据，我们设立了许多的KPI。
这十年不仅仅是为了获得更好的洞察力。不仅如此。数据网格将我们带入了数据价值的新时代，这需要围绕数据产品货币化的新标准。例如，从数据产品创意到货币化需要花多长时间？什么时候是质量的时间？自动化、人工智能以及非常重要的数据团队的组织化重组将在未来几年内做出重大贡献。
所以，去学习，去精益求精地努力，并创造你的数据未来吧。
相关新闻：
首页
微信公众号
证券之星APP
