大数据架构最佳实践

软件供应商的营销部门已经做好了让大数据成为主流的工作，无论这会产生怎样的影响。如果我们使用大数据，我们可以实现任何承诺过的前景; 商业上的洞察力或是实现击败我们的竞争对手。但是，现在还没有公开的大数据的成功实现。问题是：为什么没有呢？显然，这个银弹(比喻大数据)让企业看到了数十亿美元的投资流入，但没有投资回报！这应该责怪谁？毕竟，企业不必公布其内部流程或项目。我对此有不同的看法，原因应该在于IT部门。大多数大数据项目都是由技术专家推动的，这些项目并不是因为需要将架构与未来的业务愿景对准而造成缺乏认识的业务。

在这里我还是要推荐下我自己建的大数据学习交流qq裙：522189307 ， 裙 里都是学大数据开发的，如果你正在学习大数据 ，小编欢迎你加入，大家都是软件开发党，不定期分享干货（只有大数据开发相关的），包括我自己整理的一份最新的大数据进阶资料和高级开发教程，欢迎进阶中和进想深入大数据的小伙伴。上述资料加群可以领取

初步阶段

大数据项目与任何其他IT项目没有什么区别。所有项目都会刺激业务需求/要求。这不是电影《黑客帝国》; 我们无法回答尚未提出的问题。在开始任何工作或讨论使用哪种技术之前，所有利益相关者都需要了解：

(本文中的组织是对企业、商业组织，政府机构等等组织的统称，中文无直接对应词语，也可以翻译成企业或组织，译者注)

• 组织的背景(The organisational context)
• 组织的关键驱动因素和要素(The key drivers and elements of the organisation)
• 体系结构工作的要求(The requirements for architecture work)
• 架构原则(The architecture principles)
• 要使用的框架(The framework to be used)
• 管理框架之间的关系(The relationships between management frameworks)
• 企业架构成熟度(The enterprise architecture maturity)

在大多数情况下，大数据项目都涉及了解当前的业务技术背景; 在当前和未来的应用和服务方面：

• 战略和商业计划(Strategies and business plans)
• 业务原则，目标和驱动因素(Business principles, goals, and drivers)
• 该业务目前正在实施的主要框架(Major framework currently implemented in the business)
• 管理和法律框架(Governance and legal frameworks)
• IT策略(IT strategy)
• 预先已存在的架构框架，组织模型和架构库(Pre-existing Architecture Framework, Organisational Model, and Architecture repository)

大数据连续性

大数据项目不是也不应该被孤立执行。大数据需要从其他系统提供的简单事实意味着应该在各个团队之间建立沟通渠道。为了有一个成功的架构，我想出了五个简单的图层/堆栈来实现大数据。对于技术更加倾向的建筑师来说，这看起来很明显：

• 数据源(Data sources)
• 大数据ETL(Big Data ETL)
• 数据服务API(Data Services API)
• 应用(Application)
• 用户界面服务(User Interface Services)

| 大数据协议栈 |

数据源

当前和未来的应用程序将产生越来越多的数据，这些数据需要进行处理才能从中获取一些竞争优势。数据有各种各样，但我们可以将它们分为两类：

1. 结构化数据 - 通常按照预定义格式进行存储，例如使用已知和已证实的数据库技术。并非所有结构化数据都存储在数据库中，因为有许多企业正在使用诸如Microsoft Excel或制表符分隔文件这样的平面文件来存储数据。
2. 非结构化数据 - 企业会生成大量非结构化数据，例如电子邮件，即时消息，视频会议，互联网，平面文件（如文档和图像），而且这些数据的种类是无止境的。我们称这些数据为“非结构化”数据，因为它们不遵循可以使用户查询其内容的格式。

在创造“大数据”之前，我在企业搜索技术方面投入了大量的工作。了解数据来自何处，以及对于成功实施大数据ETL项目而言具有什么样的价值。在编写一行编程代码之前，架构师必须尝试将数据规范化为通用格式。

大数据ETL

(ETL，即Extract Transform Load，ETL是数据抽取（Extract）、转换（Transform）、加载（Load ）的简写，它是指：将OLTP系统中的数据抽取出来，并将不同数据源的数据进行转换和整合，得出一致性的数据，然后加载到数据仓库中。 )

这是激励技术人员，尤其是开发团队的部分。每天发布大量关于大数据工具的博客和文章，这会造成非技术人员之间的混淆。每个人都对使用该块最酷的孩子处理PB级数据感到兴奋：Hadoop及其生态系统。在我们被带走之前，我们首先需要设置一些基线：

• 实时处理(Real-time processing)
• 批量处理(Batch processing)

| 大数据 - 数据合并 |

Extract Transform Load 项目的目的是，无论是否使用Hadoop，都将数据整合到单个视图主数据管理中，以便按需查询。Hadoop及其生态系统处理大数据的ETL方面而不是查询部分。所使用的工具在很大程度上取决于项目的实际处理需求：实时或者批处理; 即Hadoop是针对大量数据的批处理框架。数据处理完毕后，主数据管理系统（MDM）可以被存储在基于NoSQL或RDBMS的数据存储库中 - 这仅仅取决于查询需求。

数据服务API

由于大多数人关注的都是ETL的工具，所以通常忽略了一个非常重要的领域，一直到后来它几乎成为一个次级思维(secondary thought)。MDM需要被存储在库中以便在需要时检索信息。而在真正的面向服务体系结构的精神下，数据存储库应该能够将一些接口暴露给外部第三方应用程序进行数据检索和操作。过去，MDM主要是在RDBMS中创建的，通过使用结构化查询语言进行检索和操作。那么这不必改变，但架构师应该知道其他形式的数据库，如NoSQL类型。选择数据库解决方案时应该提出以下问题：

• 有没有标准的查询语言(Is there are standard query language)
• 我们如何连接到数据库; DB驱动程序或可用的Web服务(How do we connect to the database; DB drivers or available web services)
• 数据量会随着数据的增长而扩大规模吗(Will the database scale when the data grows)
• 有什么安全机制来保护一些或全部数据(What security mechanism are in place for protecting some or whole data)

上表中还应包括与该项目相关的其他问题。

商业应用

到目前为止，我们已经提取了数据，将其转换并加载到主数据管理系统中。规范化数据现在通过Web服务（或数据库驱动程序）来公开，以供第三方应用程序使用。商业应用程序是首先使用大数据项目的原因。有人会争辩说我们应该聘请数据科学家（？）。根据许多博客所言，Data Scientist的角色是理解数据，探索数据、原型（未知问题的新答案）并评估他们的发现。这很有趣，因为它让我想起了电影“黑客帝国”，在那里，架构师甚至在Neo提问他们之前就知道问题的答案，并决定哪一个是相关或不相关的。而现在这不是企业运行的方式。如果数据科学家可能会潜意识地（Inception）建议一种新的方式去做某些事情，但大多数情况下问题将来自业务，并由数据科学家或知道数据的人回答，这将非常有价值。商业应用将成为这些问题的答案。

用户界面服务

用户界面是项目的成败关键。设计糟糕的用户界面会影响采用率，无论背后的数据如何，更加直观的设计将会提高采用率，也许用户会开始质疑数据的质量。用户将以不同方式访问数据; 移动，电视和网络为例。用户通常会关注数据的某个方面，因此他们需要以定制化的方式呈现数据。其他一些用户则会希望通过他们当前的仪表板直接获得数据，并匹配他们当前的外观和感觉。与之前一样，安全也是一个问题。企业门户已经存在了很长时间，而且通常用于数据集成项目。尽管如此，诸如Web Services for Remote Portlets (WSRP)等标准使得用户界面可以通过Web Service调用来提供。

结论·

本文展示了在从事项目之前架构大数据项目的重要性。该项目需要符合业务愿景，并且对当前和未来的技术状况有很好的了解。数据需要能够为企业带来价值，因此企业需要从一开始就参与其中。了解如何使用数据是其成功的关键，采用面向服务的体系结构方法将确保数据能够满足多种业务需求。