最近在搞微软的Azure平台上的数据分析工具，这套工具，专门整合以前企业使用，以前企业在内部ETL，现在可以在云上进行ETL。确实是方便很多。我们都是在讨论数据湖要搞几个，开发，测试，生产都来一个。如果你是在自己数据中心，这是不可能讨论的话题。
Azure的ETL Cloud版本的工具集，名字是Data Factory。你基本就是在Azure的门户上完成所有的操作，包括写代码。
数据工厂的配置，其实就是一个Json文件。你做的配置，其实就是修改json文件。所以是有需求，把这些文件放到git来进行管理。
对于企业来说，肯定都是有开发，测试，生产，3套环境，或者至少2套环境。那么开发后的环境，如何部署到生产环境下呢。那么微软想到的通过Azure DevOps服务，实现CI CD。
这套东西的玩法，应该是最近一年，微软在狂推。和正常的开发流程的CI CD是有差异的地方，需要理解的地方。我这里整理一下，刚好今天Azure的pipeline服务挂掉了。导致只能写文章。
Azure的数据工厂，Azure Data Factory，我们简称ADF
下面的工作就是把这个对着这个架构图来进行配置。
开发环境ADF
登录Azure，其实第一件事情就是
- 建立一个开发使用是资源组，RG
- 创建ADF，注意区域，git 后面配置就可以
- 在开发资源组里，创建一个存储，这可是data lake存储，一定要注意区域
- 创建key vault服务，注意区域，
需要注意的就是region，RG，资源组，是没有区域的概念。不过对于数据分析来说，肯定是要求相同的region。ADF，storage，key vault服务。
创建 Key vault的服务，有两个地方可以进行配置，这样可以后面运行的更加方便
- policy，设置上面刚刚创建的ADF，可以访问
- 创建访问存储的密钥名字，里面包含存储的访问密钥。后面会用到。
这里为了理想化，Dev，Test，Prod，使用不同的
- ADF
- Data Lake
- Key Vault
为了安全，我们都独立的。
打开数据工厂，进行配置
连接服务
对于任何的数据工厂，基本是需要对接外面不同的服务，那么她至少是需要2个服务，
- Data Lake gen2 连接
- key vault 连接
key vault 是专门管理密钥。对企业来说，安全还是第一位，免得人家说三道四。
ADF默认连接到Data lake，是采用密码去连接的，所以这里改成key vault的连接，配置 Data Lake gen2 连接，采用key vault。上面已经配置，允许ADF访问key vault。这个时候，会很顺利。
Dataset
数据的格式，配置数据进入和输出的格式，这个地方，应该是比较复杂，对于我demo演示，倒是简单，copy数据，input和output，都是一样的。
Pipeline
pipeline，是核心，就是把数据处理的步骤用一条管道连接起来，目前是从Data lake获取数据，也是输出到Data Lake。
我就demo一个copy数据的例子，改天研究一下行列转换的例子，这样高大上不少。
对接Azure git
当你的ADF的demo可以完美的运行，后面的步骤就到了关键时刻。配置ADF连接Azure的DevOps。
连接上以后，其实需要理解的就是一个地方
你在ADF里，save，其实就是把配置save在master分支上。如果你publish，其实是把代码推送到ADF分支。
对于Azure认为，ADF分支，你可以理解是stable分支。ADF分支，其实是Azure帮你默认配置的。
如果你在ADF连接Azure git遇到麻烦，可以看这个地方，我确实也遇到了，
你是可以在ADF里，
- 创建一个自己的分支，例如feature1，通过save保存到git的代码仓库里。
- 创建一个merge request，merge到master，
- publish，一定是直接把代码推到ADF stable版本。你是很可能直接吧feature 1的代码直接推送到ADF branch里的，这个要避免。
Azure DevOps
这是Azure提供的一个服务，算是以前微软的TFS改进版本，微软马上就要废掉TFS，2020的版本，本地部署的版本，可以实现和公有云的版本一致体验。
目前世纪互联的版本，还没开通。所以你就只能使用国际版本。用你国际账号，登录就可以。
Azure的DevOps，基本就是Jira+ Comfluence + github. 整合起来给用户使用。
- 组织：对于个人来说，就是你的名字：chenshake
- 项目名字
- repo名字。对于大项目来说，一个可能会多个repo ，
Azure pipeline
对于开发人员或者用过DevOps平台的人，感觉有点怪怪，我如何提交代码？
对于ADF来说，你登录Azure的门户，进入ADF进行配置，这个时候，就是写代码，save，就是把代码提交到master分支里，publish，就是把你的代码merge 到stable版本里。
有代码了，我们一般来说，要编译一次，搞出一个制品库：Artifacts，然后拿着Artifacts去部署到生产环境或者测试环境。
对于ADF来说，代码都是json，配置文件。所谓的编译，制品库，据说copy文件夹而已。
流程上，我们要创建一条pipeline，把代码复制到制品库里。这就是build pipeline。
我们再创建一条release pipeline，就是把代码推送到测试环境或者生产环境。
对于ADF来说，release pipeline，需要做的工作，还是需要做一点有技术含量的工作。
我们是开发环境的Json文件，里面包含里不少开发环境的参数，我们需要替换成测试环境
- 资源组名字，DevRG，要改成QARG
- ADF名字，DevADF，要改成QAADF
- key vault 名字
- Data Lake名字
- 如果你对接数据库，数据库名字和密码
这时候，你就需要设置pipeline的变量，UAT，Prod，使用不同的变量来部署。
对于ADF的生产环境部署，Azure上，还是无法做到自动化，key vault创建 密钥名字，只能在图形化界面完成，目前是没有接口API。这个也是我目前发现的Azure服务，没API接口的。
我们可以利用powershell，通过pipeline去自动化创建
- 资源组
- Data lake
- key vault
- ADF
这些是一次性的工作，而且Azure上，也是无法做到全程自动化，所以这些我们都是提前手工创建好。Release pipeline所做的事情，其实是把这些服务，通过配置ADF，利用Json文件，配置起来。
微软很多服务名字要求是全局唯一，所以很多时候，你的服务名字要么加一串数字，要么就会面临名字重复，无法创建。
流程
这里就总结一下我对整个ADF的DevOps流程的理解
- 开发环境下的ADF，配置，save，保存到master分支，publish，推送到ADF分支
- 检测到ADF分支变化，触发Artifacts pipeline，上传一个制品库，就是把代码复制到一个目录下。
- 当制品库的pipeline完成后，触发release pipeline，利用pipeline的参数配置，对QA的资源组进行部署，实现QA环境的ADF正常工作
- 对于Prod，其实步骤和QA是一样，企业内部希望如何实现都是可以的。可以在QA完成部署后，马上部署Prod环境，也可以在QA测试完成后，手工去触发Prod环境的部署。
命名规范
Azure上的服务名字，有时候让人崩溃
- 有些服务，只能小写字母，不能用下横杠，
- 有些服务可以大小写，不能下横杠
- 有些服务大小写，下横杠都可以
- 有些服务要求全局唯一，有些是不要求
- 有些服务，你删掉后，重新创建，名字还不能相同，有软删除的功能，例如key vault服务。
所以建议大家，先搞一个Excel表格，把涉及的服务，名字都整理好。实际中，如果遇到重复，可以在名字后面加数字。你的服务名字，一般都加上公司名字，这样可以大幅减少重复概率。
愿景
对于Azure的DevOps服务，不仅仅是用在ADF，还能在Data bricks，就是Azure的Spark上，还能用在Power BI的报表开发上。
希望我可以有一天，通过DevOps，完成全部的Demo，从ADF，一直到PowerBI.
