数据仓库上云那些事儿

专注微软平台的商业智能解决方案
骂别人不革命，便是革命者，则自己不做事，而骂别人的事做得不好，自然便是更做事者。
若与此辈理论，可以被牵连到白费唇舌，一事无成，也就是白活一世，于己于人，都无益处。
我现在得了妙法，是谣言不辩，诬蔑不洗，只管自己做事。——鲁迅1934年6月21日信

数据仓库上云已经不是什么新鲜概念，这里简单聊一聊在这个过程中需要考虑的问题。

首先，某些话题不是一两句能说清楚，所以，这里我们不聊以下话题：

技术平台的对比。这里我们不做任何对比分析，如不特殊说明均指Azure以及微软相应的产品。
某个产品的好坏。
法务，合规。不同公司有不同的规定。
国家大事。这个我们知道就好，不在这里聊。但是我想强调一点是，即使只搞技术，国家民族大义也是头等大事，不然你会吃亏。

To be or not to be, this is a question.

首先上云肯定是有优势的，而且是不只技术层面的优势。

也许有人说上云反而更贵，这也仅仅是计算方法不同导致的而已，毕竟不会所有人都会关心服务器的采购，供应商的沟通，以及续保等问题。

对于什么样的数据上云，不同的公司有不同的规定。对于保守的公司这里不做讨论，不过目前大环境可以看到，这个趋势被越来越多的公司所认可，也都有了相应的项目上云，但还是会对能掌握命门的数据有所保留，而只是把相对能公开的数据上云，比如跟销售市场相关的。

国内 or 国外

首先要知道，国内的Azure很多功能还是缺失的，相应的团队正在加大力度引入更多海外版的功能。所以，在做设计，以及参考微软的文档前，要先确认相应的功能是否已经上线，比如虚拟机自动关闭的功能，在当前这个时间节点2020年9月还没有在国内上线。

另外不同的项目也需要参考相应的规定。比如某些数据是不允许脱离所在国家的。

PAAS or IAAS

这两个方式各有优劣，需要根据自己的情况选择。

PAAS的话什么都是现成的，同时也省去了你做底层维护的困扰，但是如果你需要底层数据的支持进行故障分析或者调优的工作，会受到很多限制，比如服务没有响应，是不是CPU超负荷导致的。

IAAS需要你从虚拟机开始搭建，跟传统不上云的方式没什么区别，好多底层，打补丁之类的维护你需要自己考虑怎么解决（还好微软有现成方案）。但是获取底层数据排查问题的时候会有更多的自由度。

如果你在范畴用IAAS的话类似打补丁的运维工作怎么处理，那么也大可不用担心，Azure平台有现成的功能，配置下就可以，平时多监控着就行了。

另外如果你的数据仓库是基于大数据平台构建的话，那么推荐考虑PAAS平台，毕竟一个集群的搭建和管理所花的成本还是很大的。

这也是需要考虑的一个问题，因为你上云了，不见得其它系统也会跟着上云。所以当你需要获取这些系统的数据的时候需要考虑些特殊的方式，而这些方式可能会影响到你对于大量数据的传输。

首先数据库直连就不要考虑了，任何一家公司的网关也不会冒这个风险给你开绿灯。

那么就需要看看所在公司层面是否提供类似的平台，比如文件传输平台，或者是专线。

如果有现成的文件传输平台，并且能够保证传输的安全，那么就可以考虑数据从源系统导出的方式。

如果有了现有专线，那么可能会方便一些。但是否能保证两边数据库直连，也要看各家公司网管的脾气。如果可行的话，那么就需要在公司层面统一规化内网IP段的使用，确保在进行互连的时候不会冲突。

当然，如果你是微软所说的理想情况，所有其它应用都在云端，那么恭喜你。

从技术层面（是的，仅仅是技术层面），数据安全需要从两个方面去考虑。首先是数据的存储安全。这个微软的平台基本都支持。其次是数据的传输安全，这个需要根据你用到的不同产品去具体分析，基本上要确保，即使数据仓库的内部通信，也要保证数据的传输不是明文，而是加密的，所以什么HTTPS，SSL之类的能上都上。

你的架构在云上，那么他就有可能被黑客骚扰吗？这个是很有可能的，基本上如果你设置日志，那么就可以看到时不时有东西在嗅探你公开出来的端口，尤其是数据库之类的端口。

要解决这个问题，首先，网络层面的设计可以参考各种最佳时间，比如对虚拟网络里子网的划分，管理层，应用层，数据层都分开。数据层不允许任何公网ip的请求，应用层通过内网ip对数据层进行访问。只有管理层才有对应用层以及数据层的远程权限。

当然方法不只这一种，总体的思路基本都是，尽量缩小在公网暴露出来的端口，减少被扫描到的可能性。

这个是上不上云你都需要考虑的。

首先如果你不上云，那么你可能需要去配置单独的作业去做备份计划。

如果上云的话，你也可以这么做，但是你还有更多的选择，比如就借助Azure平台的功能，这也是我推荐的。

另外有些对于存储备份的功能，国内部分功能还没上线，比如对于Azure Files的，这个在设计的时候需要留意。不过已经上线的功能已经能满足你的大部分应用。

所以，如果在自己定义备份计划脚本和用平台的备份功能选择的话，我建议用平台级功能。

这个要看你系统承诺的RTO以及RPO。

跟其它平台以及虚拟化平台一样，Azure平台也提供了不错的功能，你可以通过配置指定你的灾难恢复方式。比如从上海到北京。

对于RTO，虽然很少有平台能承诺一个时间，但主流的云厂商都会把20分钟看成一个重要指标。如果你去测试的话基本上你的资源在这个时间范围内也都能恢复过来。

RPO要具体去分析。对于应用层的服务器，比如报表服务，基本不会有什么压力。主要是数据层的数据仓库。虽说平台级都是实时的数据传输，但是也不能保证被恢复的数据库就是100%成功的，即使这个失败的机率很小，那也是应该考虑的。所以对于数据仓库服务器，建议灾难恢复以及数据库备份都开着。

对于解决方案的判断，需要有自己的判断，不能盲目迷信。比如对平台市场及销售人员，也许你只需要一个大众，在未来一段时间换奥迪都会感觉困难，但是偏偏就会有人跟你说这个世界的车只有宾利或者保时捷。

价格方面也是很多项目关心的，还好国内平台官网上已经提供了比较详细的报价，只要你对相应的知识点都有了解，那么来理解这些价格信息是不会有什么难度的。

账单，这个需要尽量多的关注，避免有些你已经不用的功能还在收费，因为有些资源不是你删除了主资源之后也会跟着删除的。

技术上的支持，平台方的支持也是很不错的，如果你是订阅用户都有免费和收费级别的服务。对于指定问题，跟同内部的技术团队沟通一样，一定要让问题尽量明确，这样才会得到平台方最高效的回复。

---------------------------------------------------------------

aspnetx的BI笔记系列索引：

使用SQL Server Analysis Services数据挖掘的关联规则实现商品推荐功能

一起玩转SQL Server 2012 下的分析服务

使用SQL Server分析服务定位目标用户

---------------------------------------------------------------

来自博客园的aspnetx宋卫东

文章来源于https://www.cnblogs.com/aspnetx/p/13661874.html