Kappa Architecture数据库的提升了解

　　欢迎各位阅读本篇文章，本篇文章讲述了Kappa Architecture数据库的提升了解，随着 信息技术和市场的发展，特别是二十世纪九十年代以后， 数据管理不再仅仅是存储和管理数据，而转变成用户所需要的各种数据管理的方式。课课家教育平台提醒各位：本篇文章纯干货~因此大家一定要认真阅读本篇文章哦!

　　亚马逊Aurora让数据库可扩展，但Kappa Architecture让数据库的发展无极限，管理员可以跨服务器集群创建数据的物化视图。

　　传统的数据库有许多先进的功能，其中对开发者最重要的就是物化视图功能。这种存储查询会自动缓存创建耗时的查询，并将数据写入磁盘。但传统的数据库在数据的存储量和接受请求的吞吐方面的扩展性不佳。虽然亚马逊Aurora可以提高数据库的扩展能力，还单个数据库的处理能力仍然有限。Kappa Architecture可以在这点上有所助益。

　　Kappa Architecture是一种软件架构模式加上一个只允许追加不允许修改的日志。Kappa Architecture同Lambda架构系统类似，只是不支持批量处理。在数据库中，有个细节叫做事务日志，每一次对数据库的变更都会对日志进行写入。事务日志是用来重建部分数据库的内容，如果出现问题的话可以恢复到特定的时间点。该日志包含底层数据的每一个原始动作。例如，如果一个客户要购买一件物品，事务日志可能会这样显示：

　　at 1463086280008 row 123456 old value = [ "cust-123", 50 ] new value = [ "cust-123", 25]

　　该值显示在unix时间戳1463086280008的时候，123456行记录从“cust-123”，50变更为“cust-123”，25。

　　这就是被称为fact，表明在某个特定的时间，一个值被从某个值改为另一个值。这个事实是真的，不管之后会发生什么。举例来说，即便客户在此之后又增加了25个积分，他们在这个特定的时间点仍然是减少了25积分。

　　数据库常年都处理这种小细节，但大多作为一个小的实现细节。Kappa Architecture建议将此作为记录的主来源，其他的一切都作为数据的物化视图。传统的数据库可以在一台服务器上执行这种类型的活动，而这种方法允许管理员可以无限扩展和创建横跨不同服务器集群数据的物化视图。

　　管理员可以使用日志流来查看跨服务器集群的数据

　　此日志流成为一个只能追加的系统，只接受写入操作，在写入的时候加上基本的时间戳，然后将信息写入到磁盘中。这种交互的构想是，每一个写操作都是按顺序发生，所以该系统必须从头开始按顺序运行日志中的每一个事件，才能重建数据库当前完整的视图。

　　这使得开发人员可以在保持后台系统完全运作的同时增加额外的视图。每个数据视图可以在一个完全独立的系统或多个完全独立的系统里，只要这些系统有访问整个日志流的完整权限。日志流会通知每个视图任何一切操作以及操作发生的精确时间戳，这样所有的操作就可以顺序执行。然后每个视图可以获取其需要的所有信息以确保单个视图的正确建立。

　　Kappa如何在AWS上工作

　　创建Kappa这样的架构最显而易见的工具是Amazon Kinesis，这是一个专门用来处理数据流的工具。当一个进程附加到一个Kinesis流，它可以自动按顺序读取每一个事件，以建立自己的数据库视图。这可以用来将数据库的更改复制到其它数据存储，如亚马逊DynamoDB，甚至跨区域到其他的数据库，因为区域邻近优化的关系。

　　Kinesis的另一种替代选择是DynamoDB流，这对于使用DynamoDB数据库的开发者来说使用方便。将这个想成是专门针对DynamoDB的自动Kinesis流。不幸的是，无论来自Kinesis还是DynamoDB的流都只存储最近7天的记录。因此，要创建一个新的视图，开发人员必须首先从一个主数据库里读出包含所有变更的最终结果的全部数据。

　　想更深入的了解如何创建一个Kappa风格的视图，现在假设我们有两个DynamoDB表，Customer和Orders。公司的市场部门可能通常会问，“客户X这个月花了多少钱?”在传统的数据库方式下，查询该数据需要连接Customer表和Orders表，然后汇总出客户所花费的金额。

　　现在采用Kappa的方法，因为数据是存储在DynamoDB，而不是关系型数据库，这种类型的查询要么预先知晓，要么是我们为此建立的一个新的并会不断更新的视图。大量的数据被存在Orders数据库中，但营销部门可能并不想知道一个Customer ID，而是会查找一个客户的姓名或电子邮件地址。在这种情况下，开发人员可以创建一个包含Customer ID，Customer Name，Customer Email，Month和Total Spend的视图。你可以根据姓名和电子邮件来对这个视图建立索引。DynamoDB可以自动处理这个问题，但如果不使用DynamoDB，开发人员还可以创建两个独立的视图，一个根据名字建立索引和一个根据邮件索引。

　　Kappa Architecture结合AWS Lambda

　　首先，视图的创建脚本需要先连接到流，并开始存储DynamoDB流中的所有变更。该脚本可以从OldValue/NewValue的变化中识别出新的值。一旦脚本开始缓冲数据，会将当前数据表中所有的数据转存出来，写入到新表中。在所有的数据复制完毕后再开始处理事件。这种两阶段的方法有助于防止任何并发问题，以确保在数据被复制和脚本开始处理变更事件之间不会有数据丢失。

　　AWS Lambda是最有效的处理变更事件的方法。创建完用于创建该视图的Lambda函数后，进入Event Sources页，然后选择Add event source。

　　从Event Sources页选择‘Add event source’。

　　在弹出框中，选择DynamoDB。

　　选择DynamoDB作为事件源类型

　　接下来，填写细节，确保选择正确的DynamoDB表(Orders)，在Starting Position处填写Trim Horizon。Batch size列出在某个时间最多有多少条记录被发送给AWS Lambda函数的单个实例。这意味着Lambda函数需要在单次执行中处理多个事件。

　　为Lambda函数配置DynamoDB表，batch size和starting position

　　接下来，Add Amazon DynamoDB Permissions to your role，以便Lambda函数可以访问DynamoDB流。开发者还应确保为角色添加AWS身份和访问管理权限，使其能够写入到新的DynamoDB表，这将是新创建的视图。开发人员应该首先测试Lambda函数;钩上Enable event source，直到函数的功能验证成功。在确保函数工作之后，使用同样的Event Sources控制台暂时禁用流，直到新的视图初始化完成。确保视图初始化完成后再重新启用源。

　　在重新启动流之前，最后一步是将所有现有的记录复制到新的视图。这涉及到用一个外部脚本来读取Orders数据库中的每条记录，并将其提交给Lambda函数。开发人员可能会想临时增加读取吞吐量直到新的视图产生，这样可以快速创建新视图。请记住，DynamoDB Kinesis流将在日志中最多保留七天的事件。

　　最后，写一个额外的句柄来处理Customer的DynamoDB表的变更，将任何变化，如电子邮件地址或姓名，更新到与该客户相关的新视图是一个不错的主意。

　　Kappa Architecture是一个很好的方式将经常请求的查询进行缓存从而给出快速高效的响应。不幸的是，它本意不是为了同AWS一起用。AWS用户可以运行一个Apache Kafka实例作为数据的主存储，这将确保能够建立新的视图更简单的能力。DynamoDB云则作为客户的只读源。同亚马逊Kinesis的自动扩展能力相比，这种方法的缺点是开发人员将不得不维护Kafka以及处理关于扩展性的一切问题。

　　尽管如此，使用Kafka让企业可以避免厂商的完全锁定，因为所有的数据会以非专有的方法提供，能够在别的数据存储中复制，如果数据库不得不在一个完全不同的云平台重建的话。

　　知识分享：数据库发展阶段

　　数据库发展阶段大致划分为如下的几个阶段：人工管理阶段、文件系统阶段、 数据库系统阶段、 高级数据库阶段。

　　人工管理阶段:

　　20世纪50年代中期之前，计算机的软 硬件均不完善。硬件存储设备只有 磁带、卡片和纸带， 软件方面还没有 操作系统，当时的计算机主要用于 科学计算。这个阶段由于还没有 软件系统对数据进行管理， 程序员在程序中不仅要规定数据的 逻辑结构，还要设计其 物理结构，包括存储结构、 存取方法、输入输出方式等。当数据的物理组织或存储设备改变时， 用户程序就必须重新编制。由于数据的组织面向应用，不同的计算 程序之间不能共享数据，使得不同的应用之间存在大量的重复数据，很难维护 应用程序之间数据的一致性。

　　这一阶段的主要特征可归纳为如下几点：

　　(1)计算机中没有支持 数据管理的 软件，计算机系统不提供对用户数据的管理功能，应用程序只包含自己要用到的全部数据。用户编制程序，必须全面考虑好相关的数据，包括数据的定义、存储结构以即存取方法等。程序和数据是一个不可分割的整体。数据脱离了程序极具无任何存在的价值，数据无独立性。

　　(2)数据不能共享。不同的程序均有各自的数据，这些数据对不同的程序通常是不相同的，不可共享;即使不同的程序使用了相同的一组数据，这些数据也不能共享，程序中仍然需要各自加入这组数据，哪个部分都不能省略。基于这种数据的不可共享性，必然导致程序与程序之间存在大量的重复数据，浪费存储空间。

　　(3)不能单独保存数据。在 程序中要规定数据的逻辑结构和物理结构，数据与程序不独立。基于数据与程序是一个整体，数据只为本程序所使用，数据只有与相应的程序一起保存才有价值，否则毫无用处。所以，所有程序的数据不单独保存。 数据处理的方式是 批处理。

　　文件系统阶段

　　这一阶段的主要标志是计算机中有了专门管理数据库的 软件—— 操作系统( 文件管理)。

　　上世纪50年代中期到60年代中期，由于计算机大容量直接存储设备如 硬盘、磁鼓的出现，

　　推动了 软件技术的发展，软件的领域出现了操作系统和高级软件，操作系统中的文件系统是专门管理外存的数据管理软件，操作系统为用户使用文件提供了友好 界面。操作系统的出现标志着 数据管理步入一个新的阶段。在文件系统阶段，数据以文件为单位存储在外存，且由操作系统统一管理，文件是操作系统管理的重要资源。

　　小结：在信息化社会，充分有效地管理和利用各类信息资源，是进行科学研究和决策管理的前提条件。数据库技术是管理信息系统、办公自动化系统、决策支持系统等各类信息系统的核心部分，是进行科学研究和决策管理的重要技术手段。更多资讯，尽在课课家教育!