每个组织都有数据孤岛——这些是由有限的特定人员群体严格控制的、被隔离的数据存储库和IT系统，他们对自己的数据守口如瓶。传统上，每个孤岛都作为一个自给自足的小型业务运作，彼此之间的重叠和数据交换极少。而在更大的组织中，数据孤岛通常围绕着共同的行业领先应用形成，每个应用都有自己的嵌入式数据模型，这进一步增加了数据整合的挑战。这个模式是自我延续的，需要特定的专业技能来支持每个领域或业务线。
我们可能并不意识到我们的日常工作也在助长数据孤岛的形成。就像站在树林中很难看到整片森林一样，数据孤岛常常是难以察觉的。只要我们退后一步，思考一下那些隐形的边界，保护着我们的数据——无论是物理上的，例如设备和位置，还是逻辑上的，比如网络访问、火墙和访问组等等。可以肯定的是，数据孤岛无处不在。我们需要做的就是看清这些边界，突破它们，因为这些数据孤岛锁住了潜在的价值，阻碍了我们最宝贵资产——数据的变现。
即使在小公司中，也有一些数据孤岛的例子，比如人力资源管理着员工信息、工作地点和多样性数据；财务部门管理着业务层级、成本中心和按产品线划分的收入数据。除此之外，还有许多其他（甚至令人意外的）例子可以让组织获益于打破数据孤岛，通过跨领域数据共享带来各种好处，其中一些是意料之外的。
我并不主张数据随意泄露，也不建议破坏适当的安全措施。我只是提出要通过打破数据孤岛，使数据能够民主化，释放出重要的元素以便跨领域报告和公共交换（可以收费），并且这一切都发生在一个高度安全的Snowflake数据云环境中，在这种环境下，数据所有者仍然保持完全控制。
但在此之前，我们必须将数据导入Snowflake，这正是我们面临挑战的开始。
为什么要打破数据孤岛
第一章讨论了50%的受访者表示他们经常与第三方共享数据，以推动产品和服务的创新。然而，相比之下，64%的受访者承认他们的组织在整合来自不同来源的数据时面临困难。这是那些打破了数据孤岛的公司，还是那些保持现状的公司？在没有上下文的情况下，简单地以此来断定哪一方是对的过于简化了。但明确的视角、态度和方法是非常重要的。挑战这三者，才能打破现有的局限，释放数据中所蕴藏的价值。
数据在正确的上下文中提供信息。这一点可以通过“数据、信息、知识、智慧”（DIKW）金字塔来更清晰地表述。通常，信息是通过数据来定义的，知识是通过信息来定义的，而智慧则是通过知识来定义的。图2-1展示了金字塔各层之间的关系，说明了每一层所带来的价值。
你必须理解你想要回答的问题，并从底层数据中构建上下文，以提供智慧。
例如，我的组织的收入来源在哪里？ 这个问题很容易回答；你只需查看财务系统并运行报告。但这个报告只能由指定并具有适当权限的财务人员查看，而这些人员必须有时间执行请求。
另一个例子是，如果系统X失败，收入会受到什么影响？ 这个复杂的问题就不那么容易回答了，因为上游系统可能不在财务领域，可能位于另一个数据孤岛中，如销售、营销或风险管理。这些正是打破数据孤岛后能够解答的问题。通过使用 Snowflake 数据云，我们拥有了一个平台来整理、分类、存储和保护我们的数据，将信息和知识提供给需要它的人——无论何时、以何种方式，他们都能方便地获取。
数据孤岛的存在
数据孤岛无处不在，这些通常无法访问的逻辑容器，我们可能会根据应用名称、供应商产品，或那些经常使用但不显眼的数据仓库来理解它们。
作为起点，我们可以绘制出我们组织的运营模型、业务线和职能单位，以识别潜在的信息来源。在这一阶段，我们正在分析“可能的艺术”，通过创造性地想象如果我们能在一个地方、同时访问到数据，结果会是什么……
正如老将军莫尔特克所说：“没有计划能够在与敌人接触后幸存。” 这句话在我们导航组织时有一定的道理，因为对许多数据所有者而言，知识就是力量。数据控制锁住了信息、知识和智慧，成为了需要打破的数据孤岛。但你正在读这本书，我鼓励你接受新的思维，否则现状永远不会改变，我们也将永远被过去束缚。第1章讨论了创新扩散理论，类似的逻辑同样适用。你也想成为改变思维的创新者/早期采用者吗？
知识被锁在数据孤岛中会迅速变得陈旧。例如，营销数据每个季度都会下降25%，而技术知识——也就是我们大脑中的“如何做”的数据孤岛——也会随着新工具和新技术的出现而退化。更新的文档有帮助，而分享知识是保持最新状态的有效方式；自我教育也是另一种方式。
数据孤岛不仅仅是业务职能或业务线之间的边界。它们也存在于同一领域的系统之间。例如，一家大型欧洲银行仅在HR领域就有146个系统，其中一些是基于云的，有些则是本地部署的。每个领域都有建设自己数据仓库来解决自己问题的倾向，通常使用不同的技术，这加剧了我们试图解决的问题，迅速走向复杂化，直到第1章提到的二极管点，之后恢复就变得不可能。
我们还看到数据孤岛和小范围行业的蔓延，满足了供应商提供的战略平台的缺陷。产品可能不支持所需的工作流，超负荷的支持团队无法快速实现所需的变更，或者需求是“现在就要”，一周的延迟是无法接受的。战术解决方案的传播增加了技术债务，这是一种必须在某个时刻偿还、拆解并重新与源系统对账的负担。又一组松散耦合的数据孤岛与来源相联系，如果有一个系统专门用于目录这些用户开发的应用程序（EUDAs），那就应该引起我们的重视。如果有人有先见之明，建立了一个中央注册表来记录这些EUDAs，我们就能有一个不错的起点，逐步识别并系统性地解决这些问题。
对于那些完全投入、沉浸其中并充满激情地工作的人来说，**如何保持那份激情呢？**如何保持超越表现、超额交付并不断突破边界的动力呢？
一些答案可以从我们的工作环境中找到。研究表明，在认知负荷较高的环境中工作的人，更容易分享他们的技能、知识和专业，但如果同事和/或管理层期望他们分享知识，将其他人带到同一标准上时，这种分享就不容易发生。在经常被打断的时间里，人们往往会感到退缩、缺乏参与感，而这正是我们希望避免的行为。
我个人的看法是，**要继续鼓励你的愿景者和思想领袖进行创新，推动边界。**这些是每周能拿到11分的表现者，他们迫不及待地想上班，总能从袖子里掏出一些令人惊讶的东西，或者是那些能看到机会、远在别人之前的自我驱动者。给那些思维不同的人自由是很不舒服的，但正是这些人能找到突破数据孤岛的方式（往往是非常规的），让其他人将他们的技能、知识和专业付诸实践。他们能看到那些明面上看不见的东西。他们的横向思维和连接点的能力往往能带来竞争优势。
当他们越过界限、制造噪音时，宽容他们的过错，为他们提供掩护，让他们继续创新，并最终为我们的组织带来价值。因为如果我们把这些“火箭科学家”束缚在规范中，坚持噪音减少，满足管理层对安静和平和的喜好，那么雷电就会从瓶子里逃出。一旦那股能量消失，它就再也不会回来了，我们将剥夺我们组织持续成功的核心本质。钢铁是靠钢铁磨砺的，聪明的人无论身处何方都会激发伟大，并解锁他人的巨大潜力，往往自己都没意识到自己的影响力。他们的存在和几句智慧的话语在我们组织的各个角落产生了巨大的积极涟漪效应。
我们有很少的思想领袖，更少的愿景者。让我们鼓励并留住这些人。他们总有可能去其他更开明的团队和组织工作，但他们对组织的贡献和价值远远超过了他们所制造的噪音。换句话说，噪音是某些事情正在发生的证据。
注意：教训很清晰：促进、装备、赋能并释放，而不是约束、过度负担并最终扼杀我们的思想领袖和愿景者。我们的组织无法在没有他们的情况下生存。
回到更具体的数据孤岛讨论，我们可以把Word文档也看作数据孤岛。考虑系统文档中包含目录（TOC）以及每个章节的信息。如果我们能通过Snowflake集中访问我们的系统文档，并支持非结构化文档，那么目录就可以提取并以编程方式用来查询每个章节的内容，并将结果存储到表中。
想象一下一个模板文档，它有一个常见的目录。通过非结构化文档支持，我们可以将所有命名相同的章节汇总，并使用SQL进行查询。或者，想象一下扫描的发票，其中的关键值对（如发票号和金额）可以通过编程方式提取。现在，谁还需要昂贵的OCR软件呢？第10章解释了如何实施提取文本的工具，并为你提供了一个实际的例子，可以用来实施和扩展。
一旦我们从非结构化文档中捕获了数据，**我们的业务将如何使用这些数据呢？**这些数据将如何影响我们的决策？为什么了解这些很重要？只有你能开始回答这些问题，自然，这本书也只能提供有限的工具来缓解你对智慧的渴求。但在你手中，你已经拥有了一个起点和新的思维方式，希望它能改变你的视角。
我们不能把数据孤岛仅仅看作是我们组织的一部分领域，或者一组物理服务器和磁盘驱动器。相反，我们应该从识别价值所在的角度来处理数据孤岛，然后确定访问路径以解锁这些价值。数据内容决定了容器是否是孤岛。
数据孤岛无处不在，我们只需要具备看到它们的眼睛和解锁它们的想象力。
正如Snowflake开发者Saurin Shah所说：“我们如何存储数据并不重要，重要的是如何共享和消费数据。 ”Saurin的这句话隐含着一个前提——我们必须能够从存储容器中解锁数据，然后使数据可以被访问，从而允许消费。
Saurin的启示挑战了我们对数据孤岛的定义，因为今天对数据孤岛的定义与10年后的定义将会大不相同，届时会有许多新型的、目前难以想象的格式和媒介。而作为极端例子，谁曾想到我们自己的DNA会是如此丰富（且复杂）的信息源呢？谁能预见到我们的DNA中的信息会如何为人类的未来带来益处？
无论我们在哪里找到有价值的数据，我们都必须开发和维护访问模式来解锁所需的内容，原因有很多。新兴的数据格式需要新的自定义处理器；现有的处理器需要升级，因为产品和代码版本在不断变化；新平台需要对处理器进行重构。对于一些人来说，这就是一个现成的商业创意。为Snowflake提供插件，从难以获取的来源获取数据。
教训非常明确：即使我们今天没有起点、没有部署好的工具套件，甚至没有最基本的执行能力，我们也必须做好准备。未来正在以越来越快的速度朝我们奔来，现在正是开始的时刻。千里之行始于足下。
如何打破数据孤岛
到目前为止，我们已经了解了我们感兴趣的数据类型、它们可能的业务位置、数据所有者，以及如何与数据孤岛进行交互的思路。自然，恰当的治理会决定哪些实体和属性可以被访问。
你还必须考虑组织的网络拓扑结构，因为访问数据并非简单的任务。为了将数据整合，我们需要考虑从源头到目的地的端到端连接性，这使得我们的数据能够流动。对于那些有幸能够享受自来水的人来说，我喜欢用水龙头来做类比。当我打开水龙头时，我可以得到水，但是什么促成了水的到来呢？从逻辑上讲，必须有管道从水源到达目的地。
同样，我们可以将数据获取策略分为两部分：管道提供端到端的连接性，水龙头决定通过管道流动的数据量，受限于管道的最大容量或我们网络带宽的限制。虽然这两者是相关的，但它们应该作为两个独立的交付项来考虑。在大型组织中，架构治理机构通常关注的是“管道”部分。任何系统间的互联都应该需要批准，以避免发生混乱。然而，流经管道的数据则由另一个权威机构来治理。在打破数据孤岛时，重要的是要记住这一区别，并分别与各个机构进行沟通，尽管我们的网络安全同事会坚决要求在连接、传输以及最终存储到Snowflake的过程中确保数据安全。这背后的潜在观点是，打破孤岛的过程需要高度的人际互动与协作。
每个数据孤岛都有其格式、结构和访问权限（允许访问的前提条件）。一些常见的例子包括SharePoint、Excel电子表格、业务应用程序、档案、日志文件、数据库、目录、活动目录和共享网络驱动器。这个列表并不详尽，每个孤岛可能包含一个或多个对象类型，其中存储着有价值的数据，且可能需要定制的连接器来与之交互并获取价值。
我们必须确保我们的组织已经准备好，具备了加速的能力，并且做好了迎接挑战的准备。要想成功，我们必须具备正确的态度和方法，这需要在展示、展示会、内部教育以及通过宣扬我们的方式和产品来不断正面强化。如果我们自己都不热衷于支持自己的工作，为什么别人会相信我们并对我们有信心呢？问题不在于技术，而在于人和流程。
注意：展示能力并进行“赢得人心”的工作对于我们的成功至关重要。
数据如何演变
在讨论数据孤岛时，无法忽视数据演变的过程。我们希望避免重蹈过去的覆辙，并为未来的数据民主化奠定基础。此前提到的未来数据增长主题包括物联网（IoT）生成的传感器数据、图像以及半结构化记录。但我们还必须关注医疗数据，以及个性化基因疗法、卫星影像、来自不同光谱的数据和气候数据等可能性。这个列表远远不止这些。
我们希望处理越来越复杂和具有挑战性的数据，这推动了传统数据库技术的边界。我们并不总是拥有应对一切的工具，但我们可以随着时间的推移开发出这些工具。数据的消费本身并不是一个终点。相反，消费促使现有数据集的融合，从中得出新的洞察力和机会，进而为我们的组织带来益处。
我们正经历数据量、速度和多样性的指数级增长，通常可以将其归为三个主题：结构化数据，即我们（希望）已经充分理解的第三范式OLTP数据库、数据仓库、数据金库或星型模式。更近期，半结构化数据如JSON、XML、AVRO、Parquet和ORC格式都得到了Snowflake工具的支持和管理。而最后，非结构化数据，包括Microsoft Word文档、图像、音频、视频、传感器数据等，正在不断发展和扩展。考虑到Snowflake Data Cloud，我们可以将这三个主题视为数据演变的过程，以及它们的管理，如图2-2所示。
在图2-2中，各个主题之间没有严格的边界，通过一些努力，我们可以在这些主题之间实现无缝过渡，尽管我们需要投入时间和精力来开发每一个过渡。Snowflake提供了足够的工具和示例，帮助我们摸索出集成模式和实现Snowflake Data Cloud的方案。在第10章中，我们还将探讨自制工具，特别是针对半结构化和非结构化数据，提供一些实践示例，展示如何从图像文件中提取文本内容。
从数据演变的趋势中，最重要的收获是实现数据互操作性。也就是说，将这三个主题中的数据整合成易于使用的数据集，供所有人使用。我们必须隐藏复杂性，同时保持完整的数据血统（即从数据摄取点到消费点的完整可追溯性），并尽可能提供自助服务功能。Snowflake拥有实现这一切的工具。
常见参考数据
令人惊讶的是，大多数组织并没有一个统一的标准参考数据源。虽然也有一些例外，但通常每个领域都拥有自己的参考数据。如果参考数据是一致的，这一切看似无问题，实际上，国家和货币的变化虽然不多，但也会发生。良好的数据治理应当解决整个组织中公共参考数据的问题。但这并不总是容易实现，因为大公司往往会收购子公司或剥离组织的其他部分。这个话题将在第12章进一步讨论。
我们通过实施Snowflake Data Cloud可以获得的一项直接好处是：能够共享已批准的黄金来源参考数据，这些数据由中央管理和维护，可以即时供所有人使用。
Snowflake与OLTP
你可能会想，为什么我们不将Snowflake作为主要的数据存储，并替代那些由供应商提供的，托管在任何平台上的数据库。这是一个很好的问题，答案将在第3章中讨论，但现在让我们先考虑一下Snowflake所处的市场领域。
Snowflake从一开始就设计用于数据仓库市场，这里涉及的是巨量数据的访问、排序和筛选，目的是回答复杂的业务问题。数据仓库中的基本存储模式与传统的OLTP系统截然不同，后者关注的是单个记录的管理。两者的差异在于规模。Snowflake针对海量数据量进行了优化，而OLTP系统则针对低数据量进行了优化，尽管它们也有实现数据仓库功能的能力，但并不像Snowflake那样在同一规模上执行。
访问数据孤岛
IT软件行业已经经历了多年发展，许多组织在特定市场领域和行业部门推出了市场领先的平台，例子包括Oracle Financials、ServiceNow、Salesforce和Workday。还有许多其他成熟的供应商以及无休止的新进入者，急于争取你的业务。
每个供应商自然都会通过实施复杂（甚至不可能）的人类可读数据库模式、专有的上传附件压缩算法、紧密关联的数据和逻辑存储在大型二进制对象中，以及许多其他棘手的方法，来保护他们的知识产权，挑战那些不小心的用户。所有这些做法，以及其他类似的手段，都加剧了数据孤岛的存在，阻止了数据交换，除非通过预定义且通常有限的接口，这样做保护了供应商的利益，却很少为数据所有者的利益着想。
每个大型供应商应用程序都包含三个核心组件，这些组件会导致三种主要的数据访问模式，如图2-3所示。本节将讨论每个核心组件及其使用模式的优缺点。这不是一篇详尽无遗的论文，确实，在一些特定领域中，针对某些问题也有现成的解决方案。但我们这里讨论的是一般性的内容，旨在揭示普遍存在的挑战，供广泛的受众了解。
解决特定领域问题的选项
安全架构
数据安全必须是我们在数据生态系统中进行的所有操作的“核心”内容，无论是本地部署还是云端。然而，云端的安全要求要比本地部署更为严格。实际上，这一部分内容更适合放在第3章。但在此简要提及，是因为我们正在讨论数据在容器之间的流动，我们必须确保数据的安全性。
在考虑要移动的数据集之前，我们首先需要考虑如何安全地连接到数据源、数据在传输过程中的保护（特别是在公共互联网中），以及Snowflake如何保护传入的数据（见图2-4）。
每个数据源应用程序至少提供一个安全的身份验证机制来建立连接，希望能有几个可供选择的机制。我们必须选择由网络安全架构师支持和批准的连接机制。同时，我们还需要确保数据流动的管道是受到保护的。数据在传输过程中必须进行加密。最后，我们与Snowflake的连接也必须是安全的。我们知道，Snowflake不允许第三方创建自己的驱动程序。相反，Snowflake开发并维护自己的驱动程序，确保身份验证和数据流动到Snowflake时是安全的。
数据模型
每个应用程序都有一个数据模型。基本的数据结构使得应用程序能够保存和管理其版本的真实数据。在数据库术语中，我们称之为模式（Schema）。当然，通常一个数据库中有多个模式，但在此解释中，我们将讨论单一模式。
可以将任何数据库想象成一组俄罗斯套娃。这个类比有些不完美，但简而言之，模式就像是内层的一个娃娃——一个逻辑容器，里面可以放入多个其他俄罗斯套娃，更准确地说，是表和视图。表就像是电子表格中的一个标签，包含数据。视图则类似于应用于表格单元格的公式，是一种附加的价值增益。
表之间可以有关系，连接“相似”的数据，并允许在表之间导航。其结果可以比作一幅挂毯，因为这些关系展现了数据之间的联系。然而，在一个结构不良的模式中，挂毯的另一面更能反映实际情况，线头到处乱飞，表之间的导航极为困难，因为关系被掩盖，数据之间的联系不明显。
在某些模式中，表名具有特定的意义，而在其他模式中，表名是一些代码，目的是隐藏其真实含义，有时表面上还有几个层次的视图进行抽象，但通常并没有实际的含义。这种做法和前面提到的其他做法是供应商锁定的信号——这使得我们很难从其定制的产品套件中脱离，形成了供应商持续的收入流。
同样，其他软件公司也专门破解供应商特定的锁定，并根据其产品收费。一个令人沮丧的现象是，已退役且不再支持的应用程序的供应商仍然维持数据锁定，以防止在其工具之外访问数据。考虑到10年或更长时间的数据保留期，大量本地硬件和磁盘存储被无谓消耗，仅为偶尔访问数据提供支持。稍后我将讨论如何处理归档遗留数据集。
回到数据模型，数据通过专有的界面或数据屏幕输入到数据模型中，这些数据可以（或应该）在插入之前进行验证，以检查数据的完整性和正确性。我们应该能够依赖数据始终具有良好的质量和适用性。然而，出于各种原因，我们常常发现数据存在差距——不一致、重复和缺失的参考数据等等，问题层出不穷。数据修正发生在数据捕获后，其成本远高于在数据摄取时进行修正。需要知道，我们在数据模型中拥有大量数据，这些数据可能结构不佳或难以理解，我们需要将这些数据迁移到Snowflake。对于有兴趣的读者，数据模型的类型将在第13章中讨论。
业务模型
现在，你大概了解了数据模型是什么、如何工作以及为何需要数据模型。每个数据模型之上都存在一个业务模型，它是一个概念性的、逻辑的模型，而不是一个物理“实体”，通常用于描述信息如何在系统中流动。在这里，功能与数据交互并赋予数据意义。
让我们用一个简单的例子来说明。假设我们有一个包含地址数据的表。我们可能会实现功能来验证邮政编码与提供的参考数据是否匹配，以确保每个地址有效并且有房号，在英国，邮政编码和房号的组合可以精确地指定一个送货地点。我们还可能访问每个邮政编码的经纬度，这在英国提供了地理位置数据，我们可以利用更多功能来推导地址密度，并将地址图形化映射。我们还可以计算从配送中心到交付地址的距离，或者计算在不同时间点之间的旅行时间，使用现成的地理位置服务。
但仅仅知道地址并没有太大价值。我们需要知道每个地址的上下文信息，例如是住宅还是商业地址，以及公司名称或房主的姓名。本质上，这些是前面讨论的数据模型中的关系，使用我们之前的挂毯类比。正是从这些关系中我们提取信息。这个业务模型是数据模型的逻辑附加层，我们可以看到数据的摄取和消费。我通常简单地把它称为：左侧是数据，中间是某种处理或功能，右侧是数据消费。没有数据模型就不存在业务模型，没有业务模型，数据模型也无用。简而言之，业务模型通过提供来自数据的信息，为数据模型提供了上下文和意义。
在数据建模中，约定非常重要，因为它们提供了结构和意义，这种结构和意义通常（但并非总是）能够跨领域传递。如前节所述，数据模型的质量和可读性差异很大。我们的目标应该始终是应用KISS原则：保持简单，笨蛋。或者说是奥卡姆剃刀原理，这两者大体上意味着同样的事情。
如果供应商锁定模糊了意义，那么我们考虑将完整的业务模型复制、克隆或逆向工程到我们的Snowflake副本中时，最后要考虑的事情就是这种方法，因为供应商会更改他们的数据结构，添加新功能，重构表和关系，使得我们的复制机制无效，带来相关的依赖管理、维护、紧急修复和所有消费者的痛苦。
在具体案例中，我们可能会考虑将小部分业务逻辑重构为一套报告对象或视图，这样可以为我们的消费者提供足够的实用性。这种方式在处理归档应用程序时特别有效，并且在风险可控的情况下，可能是一个可接受的前进方向。理想情况下，我们需要某种形式的抽象层，将我们与底层数据模型和叠加的业务模型的变化隔离开来。接下来会讨论这一点。
应用接口或报告服务
现在你已经了解了理解和解释我们的数据及业务模型中固有的问题，部分解答已经涉及到了业务模型。幸运的是（尽管有一些警告），我们还有其他选项。
大多数供应商提供进入其业务模型的技术网关，通常被称为应用程序编程接口（API）或报告即服务（RaaS）。虽然也有其他术语和不同的访问路径，比如内置的报告界面，但为了避免增加过多的复杂性，我们将API和RaaS视为同义词。
假设我们已经有了访问路径，以便从底层业务模型中提取信息。接下来就顺利了吧？错，非常错。因为即使我们拥有API或RaaS的访问路径，假设我们之前已经解决了管道问题，这也会引出一系列新的挑战——如何“打开水龙头”。
自然，供应商并不容易让我们理解调用其API的所有细节和隐含含义。虽然他们提供了示例代码，但这些代码很少（几乎从不）完全符合我们的具体需求，并且需要我们通过试错来发现很多信息。我们的挑战在于找到那些拥有技能、知识和经验的人员，来理解如何调用API以获得所需的结果数据集。这些人员难以找到，并且更难聘请，因为他们是高需求的主题专家（SMEs），因此他们的服务费用通常很高。每个精打细算的组织——也就是说，每一个组织——只有少数几位SME。每个SME的工作负荷都很大，以便从他们身上获取最大的价值。我们需要他们经理的支持来获取SME的时间，而在数据孤岛问题尚未得到解释或理解的情况下，额外的需求更是对这一宝贵资源的进一步消耗。
假设我们能够接触到SME，我们的下一个挑战是解释我们希望从API中获得什么，并确保结果格式能够得到双方的接受。我们可能会考虑使用类似JSON的半结构化格式，这样可以为后续的处理提供嵌套记录，最终转换为扁平化的关系记录。我们还必须考虑调用API的权衡，遍历结果数据集，以及递归调用相同的API，尽管参数略有不同，因为每次往返都需要时间，消耗带宽，而且由于各种原因可能会失败。一种解决方案是让我们的SME编写一个包装器，解决所有递归调用，并返回一个完整的数据超集，但这需要时间来阐明和理解需求，然后开发适当的包装器，进一步增加了我们提取数据的挑战。
根据返回的数据集格式，还会产生其他考虑。有些属性包含嵌入的逗号，而我们已指定了逗号分隔值格式。嵌入的逗号可能导致额外的列。因此，我们更倾向于使用管道分隔符的输出，假设数据中没有嵌入管道符。你可以理解其中的含义。除此之外，API和RaaS可能并不能提供我们从系统中获取的所有信息的100%的覆盖。
然而，使用API和RaaS时，我们应该能够依赖于某种程度的隔离，避免底层数据模型和业务模型的变化影响到我们实现的稳定性。如前所述，供应商对这两者的更改可能会导致我们的实现变得脆弱，造成意外的失败、紧急修复以及不必要的额外工作。在调查第三方应用程序和工具时，必须考虑市场上可用的SME，并且要考虑组织是否愿意投入资源培训员工，以减轻执行风险。
我们还必须考虑另一种供应商锁定策略：对API和RaaS调用进行速率限制，以限制返回的记录数量以及在特定时间内可以调用API或RaaS的次数。
内置报告界面
一些供应商产品附带内置的报告工具，包括现成报告（即开箱即用的报告）以及开发自定义报表的能力。内置报告工具可以用来提取数据源，并可能根据实现的不同提供定时调度功能。
与API和RaaS解决方案类似，内置报告界面可能为生成数据提取提供了一个有吸引力的选项，同时也提供了一定程度的隔离，避免底层数据模型和业务模型的变动。报告界面的另一个优势是，它们可以由业务强用户开发，不需要SME的知识。这有助于运营人员更紧密地合作，提供必需的上下文信息。如果你了解我们的系统为何使用，以及典型的访问路径，你就能够更好地理解变更的影响。
自定义视图
数据库视图是存储的SQL查询，覆盖我们的数据模型。它们是物理数据库对象，提供了一个抽象层，在这里我们可以加入逻辑来连接表、预筛选、聚合或汇总数据。我们通常使用视图将数据模型进行非规范化处理，转换成更容易为业务理解的术语和表现形式，从而减少理解数据所需的技术知识。
与业务模型一样，可能会创建一小组自定义报告视图，以便有效地提取数据。这些视图需要在底层数据模型发生变化时进行维护。由于高度依赖SME的知识并且可能会产生更多技术债务，自定义视图的效果只取决于底层SQL的质量。任何过滤、聚合或汇总操作都应在文档中有详细描述。
应用连接器
Salesforce 集成通过 Tableau CRM Sync Out Connector 实现，提供开箱即用的增量数据加载到 Snowflake（见图 2-5）。
提供了配置 Snowflake 的示例脚本，之后必须配置 Salesforce 连接。请注意，数据同步的类型和频率由 Salesforce 配置决定。这是一个仅从 Salesforce 推送到 Snowflake 的接口，管理对象创建，提供了一定程度的隔离，防止 Salesforce 数据模型的变化影响。需要注意的是，脚本中并未提及数据模型增量变化，只是涉及对象创建。作者没有测试 Tableau CRM Sync Out Connector，但更多信息可以在 www.snowflake.com/blog/integr… 上找到。
第三方产品
历史上，Snowflake 并未将自己视为数据集成工具的供应商。相反，Snowflake 通常会将集成问题转交给其 Partner Connect 项目，该项目可以通过 Snowflake 用户界面访问。许多 ETL/ELT 供应商，如 Boomi 和 Matillion，提供连接器，能够抽象出实现 API 或 RaaS 调用的细节，换句话说，简化了数据交换的过程。
我们观察到一个明显的趋势，即将不同来源的数据集整合到 Snowflake 中，以实现跨领域、一致的战略报告，这一趋势在市场上得到了广泛关注。从不同数据源和供应商平台到 Snowflake 的连接便捷性，是值得关注的发展方向。另一种选择是使用第三方工具来复制整个数据库和模式。Partner Connect 提供了多个相关工具。
内部应用开发
在讨论了典型供应商提供的应用栈并暴露了许多打破数据孤岛的挑战后，我们不得不问，IT 是否通过解散高性能的现场开发团队、将定制实现交给离岸团队的管理者，而不是将优秀的开发者转型为功能型经理，来为我们的组织提供了良好的服务。一些组织失去了其关键系统的企业知识，而曾经优秀的开发者也失去了核心的技术技能。你不使用它，它就会丢失。但我们无法回到过去，只能向前看，面对当初决策时未曾预见的后果。
数据捕获方法
数据捕获有许多方法，在实施 Snowflake 时，我们应考虑采用基于模式的方法。那么，什么是基于模式的方法？我们如何开发模式？最重要的是，为什么我们要这么做？很高兴你问了这个问题。
模式提供了一种易于描述、文档化、可重复且一致的集成路径，用于数据集的引入。相反，针对每个数据集采用自定义的集成路径将难以维护、复用、向他人解释和支持。自然，一种方案并不适合所有情况。因此，我们可能会有几个模式，但不会很多；理想情况下，最好是少数几个。
如果我们希望加速软件交付，降低运营风险，并使我们的系统更健壮、更具可扩展性，我们应当采用基于模式的方法。此外，我们可能需要架构治理来批准我们的提案，允许变更发生，通过实现通用模式，我们也可以使他们的工作变得更轻松。还记得第 1 章中的挂毯类比吗？模式改变了我们的视角，使我们看到的是图案，而不是背面。模式和一个示例将在第 12 章中介绍。
战术方法
我们经常面临压力，要求尽快交付，而不顾长期后果和技术债务，而这些问题往往没有得到解决。IT 并不是一个完美的学科，正如你所看到的，它的复杂性不会很快减少，反而是相反的。意识到业务消费者需要从数据中提取知识和智慧时，我们经常会在交付质量和健壮数据集时遇到限制，往往依赖某人手动将数据拼凑到电子表格中。总比什么都没有好，我们总是可以稍后重构，或者我们是这么被告知的。但在此期间，我们增加了运营风险，因为数据集是战术性的，并且技术债务增加，因为我们必须后来用战略性数据替代战术性数据流。
采用基于模式的方法，其中基于规则的引擎自动创建对象并与我们的持续交付管道集成，是完全可以实现的。这种方法虽然不能满足第 11 章中所述的数据管理原则，但提供了一个自动化数据摄取能力的起点。
对于每个工作项目，如果战术方法是短期内唯一可行的选项，我强烈建议，战术数据流的接受应当以获得资金支持为条件，用于在战略数据集可用时进行后期修复。我们的最终目标应当是停用所有战术性数据流并重新指向战略性数据流，下面会讨论这个问题。
战略方法
什么是战略数据集，它与战术数据集有何不同？战略数据集的一种定义是通过从系统中程序化地获取数据，该系统保存了系统的记录源，也就是所谓的“黄金数据源”。
我们首选的数据摄取方法应当是尽可能使用战略性数据，并在最早的机会迁移战术数据流。减少技术债务需要纪律性和决心。如果我们允许——或者更糟的是鼓励——依赖非权威数据源数据集，我们就没有为组织提供良好的服务。
无论我们在组织中的位置如何，我们都有责任采取共同的方法来减少技术债务。没有高质量的数据，我们无法期望准确的信息，知识可能会受到损害，智慧与现实脱节。数据质量（完整性、体积、验证）和真实性（准确性、及时性、可靠性）有助于改善决策并获得更好的结果。
数据管道与数据内容
之前，你已经了解了为什么我们要将管道工作与数据流分开。在资源受限的情况下，我建议首先关注管道工作，包括安全影响，因为这是最大的挑战，然后是调用 API/RaaS，因为不同的挑战会随之而来。这种方法还可以缓解大规模工作交付的风险，因为资源并不总是在需要时可用，我们往往需要等待资源的可用性。因此，我们应该在广泛的领域内推进，并在等待其他机会打开时，处理当前可行动的机会。
变更数据捕获（CDC）
CDC 是一种捕获仅已更改记录的技术，也就是捕获增量数据。根据源系统处理变更记录的方式，CDC 可能无法在没有重大重做、测试和后续部署的情况下使用；换句话说，这可能不值得投入。然而，CDC 是一种优雅且强大的方法，可以最小化捕获的数据量，从而便于后续处理，因此应该在每个接口中考虑使用。
你还可以考虑实现 Data Vault 2.0，其中 CDC 是必要的。虽然基于 Data Vault 2.0 设计的交付并不简单，但如果做得好，结果是值得投资的。Data Vault 2.0 会在第 13 章中讨论。
批量加载或涓流加载
一些数据集适合批量加载方法，而另一些数据集则适合涓流加载方法。并不是“一刀切”，我们必须为每个数据流确定合适的方法。作为经验法则，对于接收不频繁的数据，月度数据流可能是可以接受的，例如组织中新员工的数据。然而，库存变动可能需要每日内数据流，以便按需出货，保持仓库库存水平。无论采用哪种方法，Snowflake 都内置了工具来简化实现。
数据使用
一旦我们将数据存入 Snowflake 数据云，我们必须解决数据的所有权和使用问题。考虑到在一个业务线或职能领域中可能存在来自多个源系统的数据，我们必须确定数据访问的基本规则。
对于一些组织，用户只需要属于某个业务线或职能领域，就可以获得对所有受管数据集的访问权限。对于其他组织，通常更倾向于细粒度的控制，即为每个应用数据集创建基于角色的访问控制（RBAC）。
前者方法有些笨拙，可能无意中将数据访问权限授予不应有访问权的人员。后者方法需要更多的管理（通常通过 AD 群组成员资格），但提供更严格的控制，这是我们首选的方法。放松控制总是比后来加强控制更容易。
行级安全（RLS）控制对数据子集的访问，通常适用于为数据消费创建的对象。我们将在第 9 章中进一步讨论数据消费。
从 Snowflake 的迁移
尽管我们坚信 Snowflake 数据云是前进的正确方向，基于前面所解释的诸多优点，但我们仍然需要考虑 Snowflake 可能成为另一个数据孤岛的可能性。此外，未来一些产品可能会超越 Snowflake 的核心能力，我们可能希望将数据迁移到这些新平台。
将 Snowflake 视为数据孤岛是一个有趣的概念。虽然 Snowflake 采取的是开放市场的方式，工具本身将数据“锁定”是与其理念相悖的，但这一可能性虽然非常低，也不能完全排除。
迁移数据平台在一个组织的生命周期中是非常罕见的事件。通常，供应商锁定、不可转移的员工技能、系统接口和基础设施、资金不足以及缺乏动力，都会阻碍做出大胆的重新平台化决策。然而，一些架构治理论坛可能会将退出计划作为审批流程的一部分。
我们已经确定 SQL 技能是可以转移的，因为它是数据库的通用语言。因此，我们从 Snowflake 迁移的唯一可能平台是那些已经在日常使用中并且常见的数据平台，实际上就是我们正在从中迁移的数据仓库平台。我相信我并不是唯一一个看到这里讽刺的人。我很难想象在五年内会有新的平台出现；因此，退出计划的问题应该推迟，直到问题变得相关为止，因为任何当前的答案都是推测性的。无论如何，Snowflake 承诺在退出后继续提供访问权限，这可能在您的主服务协议中有所体现，或者简单地恢复为按需计费模式。
总结
本章首先解释了为什么每个组织都有数据孤岛，并识别了锁定价值的数据孤岛类型。接着我们探讨了组织为何存在数据孤岛及其 perceived benefits（感知的好处），系统地分解了相关论点，并为 Snowflake 数据云提供了支持的理由。
展望未来，面对不可预见的数据类型和新的媒体形式，您已经开始理解如何应对未来的状态数据需求。我们现在可以开始从“是”作为我们的首选回应，背后有能力开发工具来访问数据，而不是立即说“不”，因为这些答案超出了我们的技能、知识、专业和舒适区。
这段讨论带领您走过了一些访问数据孤岛的复杂性，提出了我们将面临的一些关键依赖性和挑战，其中包括我们的安全姿态。并且，已经建立了正确的思维方式，以准备深入探索我们的数据孤岛，让我们打开下一章的大门，讨论 Snowflake 的架构。
