序言
如何构建当前企业数据体系架构呢?其实与许多其他技术一样，它实际上取决于企业要实现目标。以下特征通常与数据体系架构相关:
•来自内部系统、云计算系统的数据，以及来自合作伙伴和第三方的外部数据
•不同数据源和多结构化格式的数据
•流媒体实时数据,批量加载,或两者的结合的应用
•从中度到高度的数据量,
•基于云的混合交付模式
•提供分析数据集市等传统平台和语义层，专业数据库图,空间或NoSQL
•除了数据集成，还采用了数据虚拟化技术
•分析需求范围从运营BI到企业BI，再到高级分析和数据科学
•多平台数据架构以适应不同的需求
•采用迭代交付周期的敏捷交付方法
•为不同的用户群体提供支持，无论是普通数据消费者、数据分析师还是数据科学家
•自动化和DevOps，减少时间成本，确保解决方案的一致性和质量
一 业务需求推动数据架构发展和适应
今天企业的领导都认识到数据是做出明智和可支持的决策的关键。传统的数据仓库和商业智能方法因响应太慢而受到挑战。减少转化为价值的时间是现代数据体系结构的基本目标。传统上，数据仓库在简化数据访问和回答成功运营业务所需的许多问题方面表现出色。然而，不可能预测企业可能问的每一个问题和他们可能需要的每一份报告。在现代数据体系结构中，获取新数据应该相对容易，以便能够快速进行新的分析。
随着企业发现社交媒体、文档、评论、传感器和边缘设备所包含的价值，数据量呈爆炸式增长。15年前，公司从未想过要追踪社交媒体“赞”等信息。实际上捕获和分析任何类型数据的能力是一种关键的业务能力。
最后，用户需要知道数据湖中的数据是受管理的、高质量的，而不是混乱的、不可靠的沼泽。
所有围绕着数据湖和大数据的媒体炒作，很难理解像数据湖这样的技术如何甚至是否对你的分析需求有意义。有些人认为，实现数据湖意味着放弃他们的数据仓库，这种看法最终要么让他们走上了错误的道路，要么让他们把大数据和数据湖作为未来的项目搁置一边。数据湖不会取代企业现有的数据仓库。事实上，它们是互补的。有了现代的数据架构，组织可以继续利用现有的数据仓库，开始收集他们一直忽视或丢弃的数据，最终使分析师能够更快地获得见解。
二 现代数据体系结构的原理
数据湖等大数据技术支持并增强了现代分析，但它们通常无法取代传统系统。
1 多平台架构已经成为常态
在现代数据体系结构中，可以获取和存储任何类型的数据。有些实现者选择在数据湖中存储和集中所有数据。虽然这种“数据湖存储一切”的方法在架构上很简单，而且肯定可以提供重要的价值，但还有很多决定要做，这些决定最终会影响数据湖的使用方式。相反，多平台体系结构(如上所示)关注的是数据架构与数据需求的最佳匹配，它认为最有效的技术是基于数据本身的。这种思维过程，也称为多语言持久性策略，导致数据分布在不同的存储平台上。确实，没有一个单一的架构可以满足所有数据的所有要求，所以在架构的简单性和最佳匹配之间找到正确的平衡是很重要的。
(1)数据集成和数据虚拟化都很流行
许多IT专业人员越来越不愿意进行数据集成。也就是说，在使用或分析数据之前需要物理地移动数据。在现实中，仍然会出现大量的数据集成，但它更加深思熟虑和有目的。
数据虚拟化和逻辑数据仓库策略(例如跨多个数据存储的联邦查询)是“查询数据所在位置”的方法。减少数据移动在以下情况下很有用:
•大型数据集，不适合移动
•数据集成时间短
•数据隐私、监管、地域问题
•丢失元数据或无其他上下文
(2)数据分析能力的灵活性需求
现代数据体系结构的一个关键原则是它对快速出现的业务需求的敏捷性。能够在数据生命周期的早期(在数据被整理或优化以广泛使用之前)访问数据，提供了极大的灵活性。对数据进行分析以确定其值(读取时的模式)通常由数据分析师或数据科学家处理。被认为对大量受众有价值的数据可以从数据仓库或数据湖中交付，无论哪种方式，在这一点上都被认为是写入模式。
(3)体系结构不断地迭代变化
数据湖支持迭代和敏捷性。通过施加更少的预先约束，允许交付团队更快地概念化，并从业务中征求反馈。将这种协作提前到项目生命周期中可以防止代价高昂的误导。
•随着用例的确定，原始数据变得越来越精炼
•对数据的访问越来越不受限制，因为策划，友好的数据结构被创建
•沙盒或概念验证解决方案可以被更广泛的使用
与不可变的原始数据相比，现代数据体系结构的所有其他领域都受到迭代改进和更改的影响。
(4)数据湖和数据仓库协同工作
如本文开始时的图所示，数据湖和数据仓库都是数据存储区域的中心参与者。每一种都同样重要，并发挥互补作用。微软的Azure Synapse是一个通过集成数据仓库、数据湖、高级分析和商业智能服务来统一数据应用的案例之一。
三 数据湖&数据仓库的互补解决方案
传统的数据仓库是一个集中的存储库，包含来自多个源系统的信息，并以方便分析查询的用户友好的方式进行结构化。
数据仓库具有以下属性:
•它代表抽象的业务主题域
•数据经过高度转换、清理和结构化
•在定义了数据的用途之前，数据不会被添加到数据仓库中
•它通常遵循数据仓库先驱Ralph Kimball和Bill Inmon定义的方法
1数据仓库
数据仓库的特点是，在业务用户可以使用数据进行分析之前，需要进行大量的发现、规划、数据建模和开发工作。这种为用户消费准备数据的预先工作称为“写入模式”，因为必须在加载数据之前定义模式。数据仓库的重点是提供:
•经过清理的、用户友好的结构化数据
•可靠、准确的数据
•流程标准化
•预定义的数据结构
2数据湖
数据湖可以广泛存储各种格式的新数据，这与传统关系数据库中充满规则、高度结构化的存储有明显的不同。虽然这有助于关系数据库维护数据质量的高标准，但这种对数据集模式的强力强制可能会阻碍快速迭代开发。这种反向关系正是为什么数据湖和数据仓库是互补解决方案的原因。
数据湖的理念是立即接受新数据，很少限制，然后在使用(或“读取”)数据时应用严格的业务逻辑、类型检查和数据治理。这被通常称为“读模式”，与关系数据库的“写模式”方法相反。
这种灵活性允许使用传统数据仓库实现更困难或更耗时的新价值主张。数据湖专注于提供:
•一个架构平台，可以容纳任何类型的数据:机器生成的数据，人工生成的数据，以及传统运营数据
•数据获取的障碍更少
•访问低延迟和接近实时的数据
•降低了拥有成本，允许长期保存原始的、细粒度的数据
•不用考虑数据分析工作，直到知道价值和确定的要求
数据湖灵活性的折衷是通过“读模式”技术分析数据所需的额外努力，在此期间，在查询时定义数据结构以分析数据。
不同的特征导致了数据湖和数据仓库之间的相反关系:
数据仓库是业务认为重要的数据的高度结构化存储，而数据湖是更有机的数据存储，而不考虑数据的感知价值或结构。
(1)数据湖永久保留数据
在传统数据仓库的开发过程中，要花费相当多的时间来分析数据源、理解业务流程、分析数据和数据建模。结果是一个设计用于报告的高度结构化的数据模型。
通常，如果数据不用于回答特定的已知问题，或者定义的报告需要数据，那么数据可能会被排除在数据仓库之外。这样做通常是为了简化数据模型并明智地利用数据存储。
相比之下，数据湖可以获取所有类型的数据，并永久保存这些数据。数据仓库的默认模式是在存储数据之前证明对数据的需要，而数据湖的默认期望是获取所有数据并保留所有数据。除非需要一个明确的归档政策，否则长期的数据保存是合理的，因为未来的需求和需求是未知的。
这种保留大量数据的方法之所以成为可能，是因为数据湖的硬件通常与数据仓库使用的硬件有很大不同。廉价的存储允许以相当经济的方式将数据湖扩展到TB和PB。数据湖还可以充当“活动存档”区域，其中很少需要的旧数据从数据仓库传输到数据湖。这通常被称为DW中的热数据和数据湖中的冷数据。
最佳实践
经验是数据湖采集并保留“所有”数据。然而，也有有效的例外。例如，您可能正在获取员工数据，其中包括诸如出生日期和家庭地址等个人可识别属性。标准的数据治理和安全条款仍然适用于存储在数据湖中的数据。隐私合规性还可能影响数据湖的数据保留和删除策略。
(2)数据湖支持所有类型的数据
传统的关系数据仓库通常存储从事务性系统提取的数据。这些系统，比如销售和库存，通常由量化指标和描述它们的文本属性组成。
非传统数据源包括web服务器日志、传感器数据、社交网络活动、文本和图像等项。继续发现这些数据类型的新用途。在关系数据库中存储和使用多结构数据可能非常具有挑战性。
数据湖存储了这些非传统的数据类型。一个数据湖可以存储所有数据，无论其来源、结构和大小。最佳实践要求原始数据以原始的原生格式保留。不应该允许对原始数据进行任何更改，因为它被认为是不可变的。以原生格式保留和安全地备份原始数据尤为重要，以确保:
•所有从原始数据向下转换的数据都可以重新生成
•在特定的情况下可以访问原始数据。例如，数据科学家经常要求原始数据
•可以重新处理随时间变化的转换或算法，从而提高历史数据的准确性
•时间点分析可以实现，数据存储支持历史报告
最佳实践
从概念上讲，数据湖就像笔记本电脑上的硬盘，它存储一个文件，但与文件格式无关。虽然你可以放入任何类型的文件，但你可能需要做一些实验来找到最好的文件格式，它可以很好地读写，更好地处理模式变化，并支持你需要的数据类型。
(3)数据湖支持早期的数据探索
对数据仓库的主要抱怨之一是修改需要的时间太长。一个好的数据仓库设计可以适应更改，但是由于数据加载转换过程的复杂性以及简化分析和报告的工作，引入更改必然会消耗一些DW/BI团队资源。有些业务问题不需要等待数据仓库团队对系统进行调整。这种对更快答案的日益增长的需求是自助业务智能计划的主要驱动力之一。
在数据湖中，由于所有数据都是以原始形式存储的，因此需要快速访问数据的人可以访问这些数据。虽然对原始数据的直接访问应该受到高度限制，但可以授权选定的用户进行早期分析。
如果一个探索的结果被证明是有用的，并且希望重复利用它，那么可以对数据应用一个更正式的模式。可以将数据清理、转换、标准化、可重用性和自动化结合起来，通过数据仓库或数据湖的一个经过管理的数据区域将结果扩展到更广泛的受众。相反，如果最初的探索结果没有用处，那么可以不花额外的时间和精力就放弃它们。
最佳实践
提前获得数据是要付出代价的。处理原始的“未经管理的”数据有许多挑战。只有非常熟练的数据分析师和数据科学家才会想要处理关于原始数据的数据争论。对非核心数据分析师来说，一个折中方案是在数据湖中引入一个允许某些分析师访问的管理数据区域。管理数据区域包含结构化数据视图，类似于用户在查询数据仓库时习惯使用的视图，创建的工作量要少一些。所管理的数据可以按进度进行物理填充，也可以通过语义层公开。
(4)数据湖实现物联网和近实时数据
对数据仓库来说，获取和报告实时数据一直是一个非常大的挑战。
将数据加载到数据仓库的数据在批处理模式下性能最好。随着数据仓库系统扩展到更大的解决方案，MPP(大规模并行处理)系统的分布式特性使得提供接近实时的数据变得更加困难。
数据湖轻松获取数据的能力带来了更多的用例，尤其是与物联网相关的用例。关于接近实时的数据，我们经常看到的一个模式是将数据传输到两个输出:一个是将数据传输到流仪表板或应用程序，另一个是将数据永久保存在数据湖中。
最佳实践
尽管您可以将任何大小和形式的数据放入数据湖中，但也有实际的方面。由于写入文件和设置其属性(如安全设置)有开销，Data lake文件系统在中型到大型文件中运行效率最高。获取大量的小文件(比如几KB)，需要考虑一些技术，比如只添加文件、小批量文件或文件整合。
(5)数据湖支持数据科学和高级分析
数据湖提供了对多结构数据的更容易的访问，这在关系数据仓库中一直是困难的，这反过来打开了新的价值主张。
正如我们所知，数据仓库以其用户友好的数据结构面向业务用户。相反，数据湖对数据科学家更有吸引力是因为:
•数据湖提供了原始的、未清理的、未转换的数据。尽管BI专业人员可能会花时间转换数据以提高可用性，但数据科学家通常想要的是没有任何上下文应用的数据。该结构可以专门用于单个实验或分析
•由于数据湖可以捕获任何类型的数据，这使得多结构数据源的数据访问变得很容易，这已经变得很普遍
•现代分析工具和语言理解连接到多种类型的数据格式
数据工程师的目标是方便地访问数据，这样数据科学家和分析人员就可以把大部分时间花在运行实验和分析数据上，而不是获取和导入数据。
最佳实践
访问原始的数据也会带来额外的工作量和额外的责任。当使用不同的技术来构造数据时，肯定会发现不同的结果。这些是我们在自助式BI世界中多次学到的经验教训，其中一些也与数据科学活动相关。
四 设计数据湖的重要提示
有目的地组织数据湖的重要性不能被夸大，数据湖中的区域概念很重要。注意，区域可以是物理的，也可以只是概念上的。以下是常用的区域:
在设计原始数据区域时，应关注最优写性能，在设计被管理的数据区域时，重点关注数据发现的便利性和最优数据检索。
1 原始数据
在原始和策划区域内组织数据时，应注意以下事项:
•安全边界
•时间分区
•主题域
•保密级别
•数据访问的概率
•数据保留政策
•业主/数据管家/主题专家
2 数据目录
利用数据目录，为整个企业的数据源和报告提供可发现性和探索性，包括::
•元数据
•数据标签
•数据分类
•数据沿袭
一个技巧是尽可能在实际数据本身中包含数据沿袭和相关元数据。例如:表示数据来源的源系统的列。
3 数据格式
决定数据格式是一种选择，需要考虑的因素包括:
•与上游或下游系统的兼容性
•文件大小和压缩级别
•支持的数据类型
•随着时间的推移处理模式变化
•方便，易于使用，人的可读性
五 案例：基于Azure技术实现数据湖
数据湖非常适合云服务，比如微软Azure云平台。在本文中，主要关注体系结构的数据存储层和数据处理层。
1数据湖存储服务
设计数据湖时，首先要考虑的是数据存储。在决定哪个服务最适合用于数据存储时，有相当多的考虑事项。在不同的场景中同时使用Azure存储和Azure数据湖存储是很常见的。
2数据湖计算服务
一旦存储中的数据可用，就会有一定数量的计算服务可用。
由于存储中的数据可以跨各种计算服务重用，因此选择一个计算服务进行处理并不是一个非此即彼的命题。例如，可能有一个集群每天运行特定时间来处理数据处理操作，而另一个集群每天24小时运行来处理用户查询。通常，计算服务的成本远远超过数据存储的成本。
数据湖中的数据也可以与数据仓库一起使用。这可以通过一个成熟的第三方数据虚拟化提供商实现。还有许多方法可以在数据湖和关系数据库之间执行远程联邦查询。
六 云数据湖成功的考虑因素
基于云的服务已经成为新数据湖部署的最常见选择。通过将存储、计算和网络转移到托管解决方案，云服务提供商可以让组织避免管理本地数据中心的成本和麻烦。
现代数据体系结构通常涉及各种各样的技术，这些技术需要对本地数据中心进行大量的前期投资。使用云技术将成本转化为基于订阅的模型，这需要更少的成本和预先投资。云服务还提供许多其他优势，如易于配置、弹性、可伸缩性和减少管理。
以下是规划在云服务上部署数据湖时需要考虑的一些具体问题:
1类型的存储
数据湖是一种概念性的数据架构，而不是一种特定的技术。技术实现可以不同，这意味着可以利用不同类型的存储和存储特性。
最常见的数据湖实现利用:
•HDFS (Hadoop分布式文件系统)
•兼容HDFS的分布式文件系统
•对象存储(例如:Azure Blob存储或Amazon S3)
由于灵活性大大降低，以下技术不太常用:
•关系数据库
•NoSQL数据库
2一个数据湖vs多个数据湖
各企业一直在寻求“一个版本的真相”。一个包含所有组织数据的数据湖有时是一个目标，特别是当一个目标是将旧的遗留系统与更新类型的数据集成时。在现实中，许多组织最终会无意或有意地拥有多个数据湖或文档存储(例如，为了隔离业务单元)。在决定多湖环境时，安全、审计和数据共享等任务都是重要的考虑因素。在多湖环境中可以容忍某种程度的数据复制。
3安全功能
不同的技术平台实现安全性的方式不同。像Azure Data Lake Store这样的服务基于访问控制列表实现了分层安全，而Azure Blob Storage实现了基于密钥的安全。
4数据编目、元数据和标记
数据目录是促进自助解决方案数据发现的关键组件。设计良好的数据目录不仅可以作为数据字典，还可以帮助进行数据预览、数据分析和数据访问。清晰的文档、元数据、标记和数据分类功能对于用户能够有效地使用数据湖中的数据至关重要。如果用户不理解所提供的数据，他们就不会使用它，或者他们会创建自己的竖井数据集，从而降低数据湖的价值。
5弹性
基于云的部署最强大的特性之一是弹性，即根据需求增加或减少资源。这相当于在不需要处理能力时节省成本。数据湖中的服务在计算和存储方面应该是解耦的，可以提供独立的可扩展性和灵活性。
6客户端工具访问
分析部署成功的关键标准之一是用户的采用。推动用户采用的一个方面是客户端工具访问策划数据的灵活性。一个成功的数据湖部署可以通过自动化系统(如数据仓库加载)以及Excel、Power BI等工具进行数据访问。
7通用计算服务集成
数据湖应该能够通过本地集成或API为许多计算服务(如Databricks、Azure数据工厂和Synapse)提供健壮的存储。虽然可能不会使用所有的计算服务，但拥有多个兼容的服务将提供选择最佳选择的灵活性，并随着未来的需求增长。
8数据仓库集成
对于大多数公司来说，数据湖和数据仓库并不是非取舍的决定。相反，混合的方法通常是最有效的。最常见的两种数据湖与数据仓库的集成:
•将数据从数据湖转移到数据仓库的过程(反之亦然)
•能够发出联邦查询，通过单个查询从您的数据湖和数据仓库返回数据
9灾难恢复
从灾难恢复的角度来看，最关键的数据是原始数据，因为从理论上讲，经过规划的数据视图在任何时候都应该可以从原始数据中再现。数据中心宕机当然不常见，但当获取原始数据对业务至关重要时，确实需要预先计划和测试如何处理这种情况。在破坏性天气事件、系统错误或人为错误后恢复数据的能力是至关重要的。
七 如何开始使用数据湖
1确认数据湖确实是最好的选择
确保数据和用例真的非常适合数据湖。忽视猖獗的营销炒作，继续使用关系数据库技术，并在合适的时候将数据湖引入多平台体系结构。许多类型的数据源的存在,在不同格式,通常是一个大的指标数据湖用例。相反，如果您的所有数据源都是关系数据源，那么将该数据提取到数据湖中可能不是最佳选择，除非您希望保存时间点的历史记录。
2从一个小的实际项目开始
有一些更简单的方法可以让你开始使用数据湖:
•开始存储新的“不寻常”数据集，这样就有时间做长期规划和学习，同时开始积累数据。
•数据仓库暂存区，通过将数据仓库暂存区迁移到数据湖可以减少关系平台中的存储需求和利用大数据处理工具(例如Spark)。这对于低延迟数据集尤其有效。
•数据仓库存档区。存储的超过日期阈值的数据可以被卸载到数据湖以保留历史数据，它仍然可以用于查询，通常通过数据虚拟化技术。
3处理“准备就绪”的考虑
准备好处理模式，对读模式和对写模式方案的权衡。记住，结构需要在某些时候被应用，所以所有的决定都变成了“现在支付我或者以后支付我”的命题，这需要对用例进行正确的平衡。此外，还可以引入新技术和新开发模式。
4尽可能做一个POC
在引入新特性、新技术或新流程时，应该习惯进行概念技术验证(POC)。POC也可以被称为数据湖中的沙盒解决方案。在云服务中，特性和功能变化很快，因此POC可以帮助变得敏捷，并了解需要做什么才能实现完整的解决方案。总是存在一个风险，即POC被过快地推入生产就绪状态。因此，在运行POC/原型/沙盒工作时的考虑因素。
5做好前期计划
尽管敏捷性和较少的前期工作被吹捧为数据湖的优势，但这并不意味着没有前期计划。必须管理、计划、组织、保护和编目数据湖，这样它才不会变成可怕的“数据沼泽”。关于如何快速摄取原始数据和如何有效检索经过管理的数据的技术本质上是迭代的。
6执行正确的规程
在敏捷性与过程和严格性(实现一个健全的、可维护的、可扩展的体系结构)之间找到正确的平衡是一个挑战。每个公司的做法都不一样。随着更多关于读取方法的模式变得普遍，治理和数据编目的需求与以往一样重要，甚至更重要。
