从数据到云端：数据处理与云架构构建

# 从数据到云端：数据处理与云架构构建 ## 1. 理解数据 在云计算的背景下，我们需要明确数据的存在位置，收集数据的相关信息（如模式和元数据信息），并运用业务原则来确定数据的流向和原因。实施基于云的解决方案，不仅仅是在问题域内所有系统中移动和存储数据，还需要企业明确信息在其中的流动方式，以及它与核心服务和核心业务流程的关系。 ### 1.1 识别数据 - **创建系统列表**：识别和定位数据信息的第一步是创建问题域内的系统列表，通过该列表确定支持这些系统的数据库。 - **收集数据库信息**：接下来要确定数据库的所有者、物理位置、相关设计信息，以及数据库技术的品牌、型号和版本等基本信息。 - **借助逆向工程技术**：能够对现有物理和逻辑数据库模式进行逆向工程的技术，有助于识别问题域内的数据。但模式和数据库模型虽能揭示数据库结构，却无法确定信息在应用程序中的使用方式。对于一些打包信息系统中的数据，可能需要依赖供应商提供相关信息和访问权限。 ### 1.2 创建数据字典 需要为分析的数据创建数据字典，以存储所有元数据和其他相关信息。通常按系统创建数据字典，因为不同系统的数据属性差异较大，难以用统一属性进行跟踪。数据字典中通常跟踪的信息包括： - 特定数据元素存在的原因 - 所有权 - 格式 - 安全参数 - 在逻辑和物理数据结构中的角色 有一些工具（如存储库）可用于创建和维护数据字典，部分数据库的数据库管理系统（DBMS）也内置了数据字典。无需过于纠结数据字典的维护方式，可在不同工具间转移，当前重点是列出正确信息。 ### 1.3 理解完整性问题 在为云计算分析数据库时，完整性问题频繁出现。为解决这些问题，需理解数据库构建时应用的规则和逻辑。例如，应用程序是否允许在未先更新人口统计信息表的情况下更新客户信息表中的客户信息。 大多数连接本地系统和云的中间件会考虑所连接数据库的结构或规则。若不能正确理解和定义数据关系，可能会对目标数据库的完整性造成损害。虽然部分数据库（包括本地和基于云的系统）有内置的完整性控制（如存储过程或触发器），但多数依赖应用程序逻辑来处理数据库的完整性问题。考虑到云计算系统的广泛分布性，创建通用的控制机制来保护数据库完整性颇具挑战。缺乏数据级的完整性控制，或绕过应用程序逻辑直接访问数据库，可能会导致严重问题。架构师和开发人员在向云计算迁移时需谨慎对待，避免损害数据库的完整性。 ### 1.4 理解数据延迟 数据延迟是指数据信息的及时性特征，这是利用云计算时需要确定的数据属性之一。了解数据延迟情况有助于架构师确定何时将信息复制或移动到其他企业系统（如从本地到云端）以及移动的速度。 为云计算架构定义数据延迟时，主要分为以下三类： | 数据延迟类型 | 描述 | 示例 | | --- | --- | --- | | 实时数据 | 数据发生时立即存入数据库，几乎无延迟。数据库更新后，信息可立即供需要处理的人员或应用程序使用。 | 从华尔街实时获取的股票价格信息 | | 近实时数据 | 信息按设定间隔更新，而非即时更新。可视为“足够及时”的数据，即满足需求的及时性数据。 | 网站上发布的股票报价，通常延迟20分钟或更久 | | 有时数据 | 在给定时间段内通常仅更新一次。 | 客户地址或账户号码 | 数据类型的确定不仅仅是将数据分类为实时、近实时或有时数据，还涉及确定数据的属性（如更新和编辑增量）以及数据随时间的变化情况。为了创建最有效的基于云计算的面向服务架构（SOA），需要回答应用程序如何使用特定数据、使用频率以及数据随时间的变化等问题。 ### 1.5 案例研究：蓝山吊床公司的数据定义 蓝山吊床公司（BMH）成立于1973年，拥有传统的IT系统，包括： - 一个使用Oracle数据库、用C++构建应用程序的销售自动化系统，该应用程序还连接到公司的在线商店。 - 一个使用Java和MySQL构建的开源库存管理系统。 - 一个使用基于PC的dBase数据库的打包会计系统作为总账系统。 这些系统运行在不同的硬件和软件平台上，均部署在本地。公司管理层希望通过云计