https://medium.com/@lewisdgavin/how-to-architect-the-perfect-data-warehouse-b3af2e01342e
从表面上看，近年来在数据收集、存储和仓储方面似乎发生了很大的变化。NoSQL、“大数据”、图形化和流媒体技术的引入和接管似乎已经改变了格局，但还是保留一些基本原理。 在当前的工作中，我们使用Amazon Redshift(一种可轻松扩展的完全托管型 PB 级数据仓库服务)来应对数据仓库。然而，无论我们使用Oracle构建传统的数据仓库还是Hadoop中的数据湖，核心架构都还是保持不变。 核心架构可归结为一些预处理和三个独立区域，分别是缓存区域，主区域，报表区域(如果使用Redshift的模式)。在这篇文章中，将详细讨论每一种方法。
不幸的是，并不是所有的数据都是平等的，但是毕竟还是数据，还是有价值的。 为了有序的处理外部数据的复杂性，一些预处理是必须的，特别是有很多不同的数据源。预处理的主要目的是将外部的数据源加工成可以加载到数据仓库的格式。 包括但不限于： ·将Excel电子表格转换为CSV ·解析JSON数据(Json 是一种轻量级的数据交换格式。它基于 javascript的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据) ·清理掉坏的或错误的数据文件 准备好后，还需要一个中心位置来存放这些文件以便加载到数据仓库。 比如将所有文件放入到Amazon S3 bucket中，这个具有多功能，便宜以及集成了众多的技术的特点，如果你使用Redshift来应对数据仓库，可以很好的融合在一起。
缓存区域是任何数据仓库的基础。 一个合格的数据仓库会有多个不同的数据源，尽管每个数据源会有各自的差别，格式和命名规范。 缓存区域是一个数据经过预处理(虽然并不是所有的数据都要经过预处理)之后可以临时存放的地方，一直到进一步进行处理为止。 就好像是实际仓库的卸货区，这个货物卸货的地点既不是最终的目的地也不是材料或者产品的最终形态，只是一个等候区而已。 这个只是允许你第一次拥有数据仓库范围内的全部数据以便进一步去处理以及建模。 我个人的观点是缓存区域的数据尽可能的接近源数据(当然，你可以在预处理时做一些更改，但是不能更改源数据里面的内容)，甚至是保留源数据的列名以及表名，这样可以更方便的去查找在调查以及报告中发现的源数据问题。 缓存区域应当被当做一个暂存区。 你应该在缓存区域的保留数据一段时间，然后再进行删除掉，比如你可能需要保留一个为期一个月的数据滚动窗口，以防数据加载失败或者其他的调查。 这是数据在被当做源数据的最后一个点，从这个点开始，数据就应该符合数据仓库的标准。
主区域是加载的数据呈现真实样子的地方。 主模式应该包含正确建模的表，并适当的命名，列名称也需要随着它们的类型进行改正，这样就可以更容易的理解这张表以及这张表的内容。就像旧学校的文件归档一样。 当你将数据从缓存区域移动到主区域时，应该考虑对这些数据进行清洗。 比如： ·将所有日期格式和时区进行标准化(在适当的情况下) ·对数字进行四舍五入时，在适当的情况下以更小的小数位为准。 ·清理字符串时应该固定大小写以及删除掉字段前面跟后面的空格 ·将地址进行标准化 ·将数据拆分成多列或者从JSON中提取我还会花时间确保用来关联的列之间的列名。 比如，你拥有来自博客的一些用户数据，一些储存在MongoDB中的数据，而且还有一些关于用户的广告数据，这些来源都希望能包含用户的唯一标识符，但是可能都不是同一个东西。 通过对列名进行标准化，你或者使用数据的其他一些用户就可以更直观的理解哪些数据是可以进行关联的。 这是作为一个数据工程师的最终的目标。 当你拥有干净的数据，适当的命名来匹配业务数据，正确的建模时，就可以准备后续的任何探究或计算了。
当基础工作做完了，我们准备好吸收，建模和清理了，就可以向这个世界展示崭新的数据了。这就是报表层的作用。 此时，如果你在ORACLE中使用基于行的数据仓库，你就可以创建一些事实表跟数据集市。对于报表层来说，这是非常合理的用例，你可以在上面插入任何合适的报表工具。 然而，这些传统的数据仓库技术中有一些考虑到了基于行的存储解决方案(如Oracle)的效率。这些系统在数据关联之间执行效率很高，但在执行包含很多列的行时效率很低，主要是因为基于行的方法必须处理整行，即使只查询几列。 如果使用基于列的数据仓库，比如Amazon Redshift，那你的方法应该有所不同，Redshift不介意宽表，与多个维度相比，将维度和事实反规格化到一个表上是首选。 当使用Redshift时，以这种方式建模数据的好处包括: ·与处理大量连接相比，Redshift更乐于处理宽表，从而提高了效率。 ·对于不熟悉数据模型的终端用户或分析人员来说，使用起来很方便，因为他们不需要与连接作斗争。 ·由于报告的实体所需的所有数据都在一个位置，因此查询起来更容易。 例如，假设您想要报告您的客户。在吱吱作响的清理大师层中有一个客户表、一个订单表、一个营销日志表和一些web分析数据。 在Redshift中，您将在报表层中构建一个Customer表。这将包含任何标准的客户数据(减去他们的个人信息，因为不应该要求他们报告)，例如他们的注册日期，可能是邮政编码，等等。 你可以输入他们是否在移动设备上注册，或者他们是否安装了你的智能手机应用程序或桌面应用程序。 您可以连接订单数据并构建一些事实列，例如，到目前为止的总开销、第一个订单日期、最后一个订单日期、订单数量。 你也可以在marketing表格中创建一些相关的事实，比如发送的邮件数量、打开的邮件数量和点击的邮件数量等等。 从web分析中，您可能会得到他们最近的网站访问日期、他们最喜欢的设备、最常见的设备类型(桌面、移动设备等等)等等。 你懂的。 所有这些都会导致一个包含所有相关维度和事实的超宽customer表。你的分析师可以用它来计算一切，从采用率、跨客户群的设备使用变化、高价值客户(以及他们之间的任何共性)、客户流失和参与度等等。 所有这些都在一个地方完成，不需要连接，并且使用数据仓库的强大功能完成了大部分应该完成的繁重工作。 数据仓库并不便宜，它的设计初衷就是处理数据。充分利用它，在这里尽你所能。解放您的分析师去挖掘见解，而不是等待不那么强大的报表服务器来完成艰苦的工作。 如果你让它变得足够简单和快速，你可能会发现不仅仅是分析师愿意使用它。
按照这种简单的方法，我相信您可以构建一个功能齐全的数据仓库，它不仅易于扩展，而且易于理解。 您可能希望将登台层、主控层和报告层视为逻辑事物。这可能对你有用。我更喜欢将它们物理上分开，因为这样不仅感觉更干净，而且还允许您限制最终用户可以使用和查看的内容。
