前言

继上篇关于整体大数据平台的规划和架构设计方案之后，以国外一个航空公司的大数据实践进行剖析，来了解当只有比较有限资源投入时，且基于自身应用场景出发的视角，改如何推进大数据相关技术的引入和相关架构的建设。

航司企业级大数据规划（架构篇）- 大数据平台规划（1）：

航司企业级大数据规划（方法论） - 企业级数据资产管理：

航司企业级大数据规划（方法论） - 企业级大数据规划：

航司企业级大数据规划（实操篇） - 数据安全标准体系「草案」：

美联航与大陆航空合并

由于2008年金融危机的影响以及燃油价格上涨带来民航业的衰退并导致美联航亏损严重。美国民航业企图通过合并改善经营状况，2010年4月16日，美联航与美国大陆航空开启合并谈判，2010年5月3日正式宣布美国联合航与美国大陆航空合并，将沿用联合航空（United Airlines, Inc.）的名称。合并采用换股的方式，美国联合航以1.05股换取美国大陆航空1股股份。合并完成将成为世界最大的航空公司。

美联航企业大数据分析平台目标改善客户体验：期望减少预订时的客户不良体验；在机场敏捷和持续在各个渠道传递一致的信息(移动应用程序、网站、社交媒体等）改善员工体验：更敏捷的让员工更好地了解当前的情况，以便他们能够将其传达给客户；从问卷调查等中了解到客群的诉求，什么体验好、什么工作有效、什么需要优化。创收：航司可以为客户提供哪些个性化服务；Offer是否有竞争力。提高运行可靠性：更好地应对天气或其他运行中断；如何才能更好地管理机队，确保备份在需要的地方。过往数据分析的环境

两个主要的数据仓库平台：

Teradata：成熟的数据平台，已有20多年的历史；25人以上的专业团队；有良好的ACID合规性，可以进行相关数据更新操作；但大多数ETL与平台紧密耦合。Hortonworks平台：新兴技术，面向数据科学；数据湖模式；基于社区和支持，其框架的变化比更成熟的Teradata更快和高频；支持日志分析；非结构化数据和流式消息能够很高效的实现；读时模式(schema on read)。

企业分析团队技能：非常熟悉SQL、和构建工作报表和仪表板；不太适应并行处理和API相关工作，依赖Hive。

数据供应链逻辑：如下，依赖ETL实现从业务系统到传统Teradata数仓的数据采集及集中构建；日志类，例如shopping或客户浏览等行为，通过ETL进入Hortonworks平台。

陈旧的数据分析环境面对的挑战

挑战1，数据分析及数据科学等诉求，无法在Teradata上高效实现

预订和航班时刻表不断变化：所有这些都在Teradata中实时捕获，即“新状态=当前状态+更改”。数据科学所需数据和快照，有24小时的滞后：Teradata当初设计没有针对“告诉昨天发生了什么变化”，尤其是在<k，v>的情况下；额外的Teradata侧的Bookkeeping需要考虑，以实现数据科学的特定使用场景。是否直接写入到数据湖：是否在Hortonworks实现ACID表；写优化会影响读操作；Hive的并发模式，造成更新不能与上流同步；流式数据到原始存储，批处理后在磁盘上落地等，都造成延迟。查询应用：仍然使用Teradata的Spool空间。

挑战2，构建数据大数据端

预订和航班时刻表：成熟的关系模型，带有（大量）二次索引；需要从多个方向查询；预订和航班时刻表的LLAP缓存；RAM中是否有足够的空间；对于非标准化数据模型，在很多情况下不实用；分区、整合、ACID等要求，让Hive在并发模型读取块写入和写入块读取过程中，让作业调度复杂化。

针对性解决方案通过QueryGrid，同步Teradata数据到Hive：通过查询和数据复制两种方式。

数据复制可用如下模式：

（1）“小”数据集

（2）“大”数据集，其中新数据仅附加且不可变（将昨天附加到一个新分区上）

（3）“大”数据集，其中新数据更改“小”数量的现有分区（认为昨天的更改会影响一整年的数据）；甚至可以工作如果全年按月份划分，而不是按天划分，那就更好了(创建新的）

（4）“大”数据集，以<k，v>的方式访问(ACID）；可能需要重新划分一个嵌套的数据集以允许时间序列查询

长期视角，使用与平台独立的Nifi，将其作为公共摄取层；但需要构建定制的系统的连接器。部分场景将明确不能使用，需要特定处理方式，例如：

（1）经过GueryGrid将数据从Teradata同步到Hive时候，如果是“大”数据集，其中新数据更改了“大”数量的现有分区，则只能继续利用QG的传递查询功能。

（2）独立于任何平台的ETL，例如流式状态消息，其使用定制的C++代码和Teradata、HDP的数据流、Apache APEX、Apache Fink、NIFI+HBASE、Spark Batch。

（3）EMS/企业消息总线：其被设计时并不是为了支持分析场景，当时没有模式注册。

有关架构设计的其他考虑安全性：为了GDPR，Teradata上的通用安全策略

（1）根据访问需求在Active Directory中定义的组，用户分配给这些组。

（2）复制到Teradata和Apache Ranger的组和用户

（3）在每个平台上定义和审查的数据库角色/权限

治理：寻找覆盖两个平台的（价格合理的）解决方案

（1）Apache Atlas：通过Hive、Nifi、HDFS和Spark的可追溯性可以作为数据治理辅助；

（2）还需要使用API进行定制开发。

基于数据湖的架构体系及层次蓝图

如下是最终建议的，基于数据湖作为全面集中的企业数据存储，Nifi作为通用数据整合层，将数据通过特定ETL工具和对应的数据场景实现方案，落地到Teradata和HDP上，同时按需按场景支持外部数据应用和服务。

（1）即典型的通过企业既有EMS、批处理作业、数据集成方式作为最初的数据集成；

（2）之后较有统一数据集成或ETL平台实现更复杂的采集和数据湖构建，这里使用Nifi；

（3）之后将全部数据落地到Hadoop或HDP等构建的数据湖，形成企业集中数据存储；

（4）之后再沿用或新增数据湖的ELT模式，例如Spark等，往各个数据集市传递，譬如HDP和Teradata，其都被认为是数据集市。

（5）之后构建数据科学需要或配合SAS、R、Python等的使用场景、KPI的仪表盘、数据报表或可视化等等数据应用。

分析环境和场景下的逻辑架构

全部数据将一体化的有批处理作业、EMS等接入到与平台无关的ETL层，通过Nifi实现数据湖的构建，最终往目标数据集市推送（Teradata、HDP或其他）

架构应用案例航班信息聚合和时序化客户旅程整合和时序化总结

美联航的大数据应用，其主要是为了数据科学的场景支持，而进行改造和架构升级；由于数据科学需要的更多不是强ACID的模式，并需要更实时和多样的数据支撑。则这些都增加大数据的使用戏份，传统的Teradata的功能主要聚焦在数据统计分析和结构化的数据服务；为此美联航需要为不同的数据能够更体系和一致的接入和流转，定义清晰的架构分层，例如：

统一数据湖构建：使用Nifi与既有数据集成方案的融合，形成统一的ETL层次；企业数据湖：构建统一的，基于HDP的数据湖，为全部后续大规模的数据应用等提供统一的、企业级的、集中的数据存储。数据集市（包含数仓）：将过往的Teradata数仓和HDP的数据平台和存储等，作为数据集市来使用。数据运营及调度（包含数据治理、和安全）：在从数据湖到数据集市的数据流转中，先基于Spark，但将融入GDPR和数据安全、以及数据治理相关的能力；数据应用：其将是长在数据集市上的，面向场景的、对应特定用户的、按需的且纷杂的各类SAS、R、Python、报表、仪表盘、API、数据科学等等的各类输出。

另，横向对比各个云厂商的大数据整体解决方案：

评测项目

华为云

阿里云

腾讯云

大数据整体解决方案

FusionInsight

DataWorks

TBDS

大数据存储及计算

MRS

EMR

MapReduce

数据仓库

DWS(GaussDB A)

AnalyticDB for PgSQL

TDSQL-A

数据运营（开发、治理、调度等）

DGC（原来DAYU）

DataWorks

Dataphin（数据中台）

WeData

数据可视化分析

DLV

生态严选（永洪、亿信）

Quick BI

BI

人工智能/机器学习平台

ModelArts

PAI

TI-ML

数据可视化

--

DataV

RayData

数据湖构建

DIS，常规还有配DGC

DLF

DLF

全域消费者运营平台

Quick Audience

移动数据分析

Quick A+

大数据相关小工具

DSC

略

略