MVP黄钊吉（發糞塗牆）

最近公司的安全部门在审计云环境安全性时经常提到service endpoint（SE）和priavate endpoint（PE）的术语，为此做了一些研究储备。云计算的本质就是网络， 默认情况下资源间及外部都是通过公网也就是互联网访问。为了安全，Azure引入了SE和PE 等服务。云环境网络流动主要有两个：inbound（入境）和outbound（出境），前者意味着站在某个资源角度比如一个storage account， 外部的数据流入。后者则表示storage account的数据返回。

Databricks家里在Apache Spark之上，是企业级的应对大规模数据处理的通用平台， 可以运行在AWS， Azure和GCP 之上。作为数据处理平台， ETL 必不可少，虽然在特定平台比如Azure上可以通过如ADF来实现数据抽取，但是这样对于云平台间迁移并没有什么帮助。Databricks自带了一个Autoloader功能，本文将介绍一下这个工具。

Databricks是很强大的工具和集成平台，但是随着越来越多地使用它，就没办法必须去面对一个现实——费用很高。特别是集群的使用时长越来越久。本文从Azure的Databricks为例介绍一下ADB 相关的费用内容。Azure Cost Management可以看到大部分azure 资源的费用，包括ADB， 不过里面会有一些细微差异。使得最终ADB 的费用并不准确。为了了解费用组成，首先要理解ADB 资源的结构。

本文属于。本文属于【Azure Databricks】系列。接上文DLT 通过自动化data pipeline编排，简化ETL 过程，强化了质量检查和优化性能。在以前，数据工程师只能通过手工调度notebook和校验，处理业务逻辑异常。DLT通过声明式ETL 框架抽象掉很多操作开销。声明式开发意味着可以以描述形式来处理需求。不需要再显式管理任务调度和集群资源。

在现代数据应用环境下，数据仓库（保存结构化数据）和数据湖（保存非结构化数据）被广泛地使用着，这个时候可以尝试Databricks提供的新特性——Lakehouse。它并不是一个可以从Databricks管理界面直接找到的选项。在最早期，数据存储以磁盘文件为主，然后出现数据库，然后出现数据仓库，接下来就出现了data lake。缺乏集中式数据治理，难以维护数据的一致性和安全性。如果没有足够的控制措施，它们可能会变得杂乱无章，从而导致数据完整性问题。包含多种数据类型，因此会导致数据湖或数据沼泽分散和隔离。

本文属于。本文属于【Azure Databricks】系列。接上文Databrics DLT 是一个ETL 框架，通过创建pipeline来简化开发难度，本文介绍两种DLT 与ADB搭配的架构。假设一个企业有一个销售系统，并且有两个独立的销售平台A, B，意味着客户信息可能是不一样的。销售系统需要把A, B 的客户信息合并并为后期数据分析做准备。

前面介绍了Delta Table，但是Databricks又推出了“Delta Live Tables（DLTs）”这两者名字太像了以至于很容易混淆。Delta Table是一个存储数据到表里面的方式。而DLTs可以用于通过声明式定义来描述在这些表之间的数据流。也就是说DLTs是一个通过创建和保持数据更新用于管理很多delta table的声明式框架。Delta Table：数据格式。Delta Live Tables：数据管道框架（data pipeline framework）

上文提到了Delta Lake， 但是这是一个概念，如果落实到具体的资源服务上，又会有一定的修改和限制。本文介绍一下Delta Lake如何跟Azure Data Lake Store 整合。Delta Lake是一个开源框架，可以构建在ADLS之上。ADLS 并不内置事务保障或者Delta Lake提供的性能优化。所以单纯ADLS 很难满足现今的数据需求。

ADB 除了UC 这个概念之外，前面【Azure 架构师学习笔记】- Azure Databricks (12) – Medallion Architecture简介中也提到了lakehouse， 那么现在再深入一下了解ADB 的lakehouse。同时看看Data Lake和Delta Lake之间的区别与联系。Data Lake是一个中央存储库，存储和处理原始数据。DeltaLake则是一个开源的，针对数据存储的“表结构对比起Data Lake， 它通过支持ACID架构演变数据版本控制。

上文搭建了ADB 与外部的交互部分，本篇搭建ADB 内部配置来满足medallion 架构。

上文已经介绍了关于Medallion的知识，本文开始用ADB 来实现， 但是基于内容较多，所以分为两篇。前面【Azure 架构师学习笔记】- Azure Databricks (11) – UC搭建中已经创建了一个空白的ADB 并启用了UC。从下图可以大概看出ADB 在Azure上的架构，这里有个大概了解即可：接下来稍微介绍一下ADB 集群的一些重要选项，并创建一个集群。Access Mode：有下面3中模式，但是从解释可以看出只有前两种支持UC ，这里选择默认的single即可。

在实际的企业环境中，很少甚至可以说禁止手动创建资源，因为很容易出错，并且大规模部署时会非常低效。因此大部分企业都会使用工具或者某些服务来实现这种可控，可复用，具有伸缩性的部署方式。本文把工具选定为Terraform。由于后续学习需要不停创建、删除Azure 资源，所以这里演示一下在本机（windows 10）上安装Terraform，并且创建一个Azure Storage Account.

使用ADB 或者数据湖，基本上绕不开一个架构“Medallion”， 它使得数据管理更为简单有效。ADB 通过把数据分为“金”，“银”，“铜” 三层来实现Medallion架构。同时搭配UC，使得medallion更加健壮，安全和合规。除了Medallion， 还有一些概念如data warehouse, data lake, 和data lakehouse。Data lake： 是一个中央存储库，以原始格式存储任意规模的结构化和非结构化数据。与传统存储相比，这样可以减少很多前期转换开销。

由于ADB 的更新速度很快，在几个月之后重新搭建ADB 时发现UC 已经更新了很多，为了后续做ADB 的功能测试时能有一个更准确的环境，这里从新搭建一次基于目前最新版本的UC。当有了一个ADB 之后，使用下面的步骤即可得到一个UC 环境。这里的SA是Databricks内部使用的，存储UC metadata和meanaged Tables。如果是Azure的storage account，注意一定要为ADLS Gen2，即启用了“Hierarchical namespace”。下图是为了这次所创建的ADLS

上一文介绍了环境搭建，接下来就在本地环境下使用一下。

随着无服务计算的兴起和大数据环境中的数据集成需求， 需要使用某些轻量级的服务，来实现一些简单操作。因此Azure Function就成了微软云上的一个必不可少的组成部分。下面先简单创建环境，并且在过程中介绍一些知识。

前面两章【Azure 架构师学习笔记】- Azure Private Endpoint和【Azure 架构师学习笔记】- Azure Service Endpoint分别介绍了PE 和SE的内容。那么这两者的区别在哪里，什么时候用？通过网上搜集资料和测试，总结了以下内容。

公有云的其中一个特点是默认允许公网访问， 这就对企业环境带来风险，也是很多年前企业对公有云抵触的其中一个原因，现在这类问题已经很少，因为有了很多技术来确保云上的资源被安全地访问。其中Private endpoint（PE）就起到了很重要的作用。云上的某个资源如VM会创建在特定的网络（VNet/Subnet）上， 而其他如Storage Account ， Azure SQL等PaaS服务则没有。如果你需要用VM 来访问这些PaaS资源，VM 就会通过资源的公网IP 来访问。

在做Azure 架构时，经常会被问到Service Endpoint这个点，那么这篇文章来介绍一下Service Endpoint（SE）。

Azure Synapse Link for SQL 可以提供从SQL Server或者Azure SQL中接近实时的数据加载。通过这个技术，使用SQL Server/Azure SQL中的新数据能够几乎实时地传送到Synapse（SQL DW）中。然后进行后续的数据分析。这个过程通过change feed技术最小化对Azure SQL/SQL Server的影响。在这个移动过程中，会使用ADLS Gen2 作为暂存，然后再加载到Synapse dedicated pool中。

本文属于。本文属于【Azure Databricks】系列。接上文中演示了如何配置一个UC。本文在配置的基础上大概演示其使用。

本文属于。本文属于【Azure Databricks】系列。接上文UC 是Databricks进行数据治理，集中权限管控， 提高大规模数据存储，共享安全性的新工具。通过基于角色的访问控制（Role-based access control）来实现这种控制。所以接下来我们将介绍角色。

UC 简单来说，就是管理两样东西：用户和元存储。

在以前的Databricks中，主要由Workspace和集群、SQL Warehouse组成， 这两年Databricks公司推出了Unity Catalog（UC）之后，整个Databricks架构都有了不一样的改变。它在Workspace之上添加了一层UC， 包含了用户管理（User Management）和元存储（Metastore）。

本文属于。本文属于【Azure Databricks】系列。接上文。

DataBricks Unity Catalog（UC）是一个统一的对数据资产治理的解决方案。它对所有数资产进行集中管理，搭配一系列数据治理框架和扩展的审计功能。还有一种描述：UC 是对data lake上的数据展示进行细粒度数据治理的解决方案。它帮助简化安全性，同时对数据治理提供一个集中区域进行统一的控制访问和审计访问。

Azure Databricks有access token，是具有ADB内部最高权限的token。在云环境中这些高级别权限的secret都需要很好地被保护起来。Azure Key Vault-backed： secret 存储在Azure Key Vault， ADB 通过创建于AKV支持的Secret Sope来实现引用Secret。Databricks-backed：Databricks自带有一个数据库，也可以通过存储在这个数据库来引用secret。

快速创建低代码，直观的自定义程序开发方式， 跟Logic App比较对非技术人员更加友好。非技术人员可以通过自行编写应用来满足业务需求。

在对Databricks有了初步了解之后，如果要深入使用则需要对其进行更深层次的了解。

在上文中提到了ADB 的其中一个核心就是集群，所以这里专门研究一下ADB 的集群。

Databricks 已经成为了数据科学的必备工具，今时今日你已经很难抛开它来谈大数据，它常用于做复杂的ETL中的T， 数据分析，数据挖掘等，特别适用于做数据建模，机器学习等。那么顺应时代，现在也来看看这个工具的内容。首先要有一个环境，基于Azure 的Databricks简称ADB。托管在Azure 上的Databricks已经被Azure进行了很大的优化， 在搭建时只需要简单的几步即可拥有一个环境，不过要提醒一句ADB的集群并不便宜，用完马上删掉或停止， 否则一晚过百美金就会烧掉。

存储帐户作为其中一个数据终端存储，对安全性的要求非常高，不管在云还是本地环境中，基于角色的权限定义（RBAC: Role-based Access Control)变得越来越普及。RBAC通过预设或者自定义一些通用角色，然后分配常规权限，用户只需要于这些角色进行关联就可以获得对应的权限。这种方式不是新东西，但是在云环境这种大规模，多租户的情况下，很好地降低了权限管理的难度和工作量。

上一文介绍了存储帐户的概述，还有container的一些配置，在container下面存放的就是文件夹和文件，也就是数据。之所以单独一文描述是因为当一个项目考虑使用云存储时，除了一些必要的外部设置这种“硬”设计之外，还需要考虑文件结构这种“软”设计。本文讲述的就是比较通用的“软”设计部分。在container下面，按照业界的一些最佳实践，会定义一些列的Zone， 目录，当然还要配置安全控制，将在下一文介绍。

不管在云还是非云环境中， 存储是IT 系统的其中一个核心组件。在Azure 上，云存储主要以存储帐户（Storage Account）来实现。在使用Storage Account时，又有很多需要考虑的事项，比如安全，高可用，文件结构等。本系列分3篇文章，以最常用的Azure Data Lake Store Gen2 （ADLS Gen2）作为例子演示一些架构方面的配置和考虑， 包括：Storage Account的物理结构、文件系统设计、安全配置。

Azure Data Factory， ADF 是微软Azure 的ETL 首选服务之一， 是Azure data platform中的一种PaaS， 托管的， Serverless的服务。通过把ETL功能封装在各种类型的Pipeline中并按需执行，从而实现数据的传输和转换。

PaaS服务默认都经过公网传输， 这对很多企业而言并不安全，那么就需要对其进行安全改造，本文介绍一下ADF 在这方面的内容。当我们需要用ADF 访问SQL DB 时，如何使用更加安全？如果有一定ADF 基础的人可能知道ADF 可以使用SHIR，和Azure IR两种主流方式， SHIR 基于VM ，IaaS是可以通过网络配置使其私有化，更加安全。对于Azure IR，默认使用Internet。

上一文演示了如何从ADF 写入消息到Storage Queue， 本文接着演示如何用ADF从Queue中读取消息。

随着ADF 连接其他资源的需求越来越多，内置的功能很多时候没法直接使用，比如访问Storage Queue就没有对应的activity可以用，这个时候就可以考虑使用Web Activity来实现。首先创建一个队列：https://你的storage account.queue.core.windows.net/queue的名字/messages方法：可以看到有GET， POST，PUT， DELETE，PATCH可选。这里我们选择POST。

Azure Storage Queues 是一个专门用来处理基于云环境队列的Azure 服务。每个队列都维护着一些消息（messages）。在消息队列中，需要有发送者（Sender）和接收者（Receiver），发送者把消息放进队列中，接收者把消息从前面的队列中读取并处理。消息队列常用于社交媒体的消息发送中， 由于它的实时性要求并不是非常高，可以把消息先放到队列中，然后放到多个管道中进行后续发布，这样可以很大程度上减缓压力。

大数据引起了存储革命， 云计算又为大容量高速存储提供了可能的方案，每个商业云供应商都会提供特殊的云存储。而Azure 对应的云存储则称为存储帐户(Storage account)。它被广泛使用在各种云系统、服务中，作为数据的临时或者永久存储，现在建立在云上的PaaS类型的系统，几乎无一例外会使用到它，虽然可能需要自建，也可能是服务自带的。Storage Account（下称SA）具有可扩展性，相对价格低廉，性能稳定的特点， 不过在正式使用时，往往会有一些疑问，SA 到底怎么用？