大数据中台架构栈
大数据中台架构栈说课材料
大数据中台架构栈近来数据中台概念大火，大家对它的定义也五花八门，不一而足。
但无论怎么定义，一个完善的数据技术架构必不可少。
了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。
因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。
一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。
框架图如下：1. 数据采集传输这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。
针对不同的数据来源有各自的采集方式，从 APP/服务器日志，到业务表，还有各种 API 接口及数据文件等等。
其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于「重点关照」的对象。
目前市面针对日志采集的有 Flume，Logstash，Filebeat，Fluentd ，rsyslog 几种常见的框架，我们挑应用较广泛的前两者介绍下：1.1 Flume 和 Logstash Flume 是一款由 Cloudera 开发的实时采集日志引擎，主打高并发，高速度，分布式海量日志采集。
它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。
Flume 支持在日志系统中定制各类数据进行发送，用于采集数据；同时，它支持对数据进行简单处理，并写到各种数据接收方。
目前有两个版本，OG和NG，特点主要是：1.侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景2.由java开发，没有丰富的插件，主要靠二次开发3.配置繁琐，对外暴露监控端口有数据Logstash 是 Elastic.co 旗下的一个开源数据收集引擎，可动态的统一不同的数据源的数据至目的地，搭配 ElasticSearch 进行分析，Kibana 进行页面展示，是著名的 ELK 技术栈中的「L」部分。
数据中台架构设计方案
数据中台架构设计方案随着大数据时代的到来，数据中台架构设计成为了企业不可忽视的重要环节。
本文将从数据中台的概念、架构设计要点以及实施步骤等方面进行探讨，为读者提供一个完整的数据中台架构设计方案。
一、数据中台概述数据中台是指将企业内外部数据进行整合和共享，构建一个统一的数据中心平台，能够满足企业内部各业务部门和外部合作伙伴对数据的需求。
数据中台的核心目标是提高数据的价值和利用率，促进数据驱动决策的实现。
二、数据中台架构设计要点1. 数据采集与存储数据中台的第一步是采集和存储各类数据源的数据。
在数据采集方面，可以通过数据管道将数据从各类业务系统中抽取出来，并进行数据清洗和转换，确保数据的准确性和一致性。
在数据存储方面，可以采用分布式存储技术，如Hadoop、Spark等，以满足大数据量和高并发的需求。
2. 数据标准化与治理数据中台的第二个要点是对数据进行标准化和治理。
通过定义统一的数据标准和数据字典，实现不同数据源之间的数据对齐和交互。
同时，建立数据质量监控机制，对数据进行质量评估和纠正，确保数据的准确性和完整性。
3. 数据计算与分析数据中台的核心价值在于数据的计算和分析。
通过建立统一的数据计算和分析平台，实现对数据的实时计算和深度分析。
可以利用机器学习和人工智能等技术，挖掘数据中的关联规律和价值洞察，为企业决策提供有力的支持。
4. 数据开放与共享数据中台的最终目标是实现数据的开放和共享。
可以通过开放API接口，将企业的数据资源对外开放，与合作伙伴进行数据交换和共享。
这样可以促进产业链上下游合作，实现资源的共享和协同创新。
三、数据中台架构设计实施步骤1. 确定数据中台的战略目标和价值主张，明确数据中台的定位和定位。
2. 分析现有数据资源和数据需求，建立数据清单和需求清单，明确数据中台的范围和边界。
3. 设计数据中台的整体架构和模块划分，确定数据中台的技术栈和解决方案。
4. 开展数据采集和存储的工作，制定数据采集和存储的规范和流程，实施数据清洗和转换。
2023-大数据中台技术架构方案V2-1
大数据中台技术架构方案V2“大数据中台技术架构方案V2”是一个关于数据处理的技术解决方案，旨在为企业提供一个通用、高效、灵活的数据处理中心。
本文将从以下几个方面分步骤阐述该技术架构方案：第一步：数据采集数据采集是大数据中台的第一步，其目的是从各个数据源中收集到企业所需的数据，为后续的数据处理提供基础。
在大数据中台技术架构方案V2中，数据采集可以通过实时流数据和批量数据两种方式实现。
实时流数据可以通过Kafka、MQTT等消息中间件进行采集，而批量数据则可以通过各种ETL工具实现。
第二步：数据存储数据存储是大数据中台的核心，其用途是将采集到的数据进行持久化存储，为后续的数据处理和分析提供基础。
在大数据中台技术架构方案V2中，数据存储可以选择Hadoop的HDFS、NoSQL数据库等多种存储方式。
同时，为了提高数据存储的安全性，建议使用分布式存储方案。
第三步：数据处理数据处理是大数据中台的核心技术，其主要对采集到的数据进行清洗、整合、分析等操作，为企业提供实时的业务支持和决策分析。
在大数据中台技术架构方案V2中，数据处理可以选择Spark、Flink等流式计算框架进行实时处理，也可以使用Hadoop、MapReduce等离线计算框架进行批量处理。
第四步：数据可视化数据可视化是大数据中台的最终目的，其主要将处理后的数据通过图表、地图、关系图等各种方式展示出来，以便企业管理层进行决策分析。
在大数据中台技术架构方案V2中，数据可视化可以选择Tableau、Power BI等可视化工具进行实现。
综上所述，大数据中台技术架构方案V2是一个通用、高效、灵活的数据处理方案，它可以在数据采集、数据存储、数据处理和数据可视化等方面提供多种解决方案，为企业提供全方位的数据支持和决策分析。
如果你正在寻找一个适合自己的大数据中台技术架构方案，那么大数据中台技术架构方案V2是一个值得考虑的选择。
大数据中心架构栈
大数据中心架构栈概述大数据中心架构栈是指用于构建和管理大数据中心的技术架构和组件的集合。
它包括硬件、软件和网络等方面的要素，旨在支持大规模数据处理和分析。
架构层次大数据中心架构通常包含以下几个层次：1. 基础设施层：该层包括服务器、存储设备和网络设备等基础设施组件。
这些设备提供数据中心的物理基础，负责数据的存储、传输和处理等功能。
基础设施层：该层包括服务器、存储设备和网络设备等基础设施组件。
这些设备提供数据中心的物理基础，负责数据的存储、传输和处理等功能。
2. 数据处理层：在数据中心中，大数据处理是一个关键的任务。
数据处理层包括数据处理引擎、分布式文件系统和数据处理工具等。
它们能够实现高效的数据处理和分析，支持实时和离线的数据处理应用。
数据处理层：在数据中心中，大数据处理是一个关键的任务。
数据处理层包括数据处理引擎、分布式文件系统和数据处理工具等。
它们能够实现高效的数据处理和分析，支持实时和离线的数据处理应用。
3. 数据存储层：大数据中心需要存储海量的数据。
数据存储层包括分布式数据库、分布式文件系统和分布式存储系统等。
这些系统能够提供高可靠性、高可扩展性和高性能的数据存储服务。
数据存储层：大数据中心需要存储海量的数据。
数据存储层包括分布式数据库、分布式文件系统和分布式存储系统等。
这些系统能够提供高可靠性、高可扩展性和高性能的数据存储服务。
4. 数据安全层：大数据中心中的数据安全是一个重要的问题。
数据安全层包括身份认证、权限管理、数据加密和安全审计等。
这些措施能够保护数据中心中的数据免受未授权访问和数据泄露的风险。
数据安全层：大数据中心中的数据安全是一个重要的问题。
数据安全层包括身份认证、权限管理、数据加密和安全审计等。
这些措施能够保护数据中心中的数据免受未授权访问和数据泄露的风险。
架构组件大数据中心架构栈涵盖了众多的技术组件，下面是一些常见的组件：1. Hadoop：Hadoop是一个开源的分布式计算框架，能够存储和处理大规模数据，并提供高可靠性和高性能。
数据中台架构框架
数据中台架构框架1. 简介本文档旨在介绍数据中台架构框架的基本概念和组成部分，以及其在企业中的应用。
2. 数据中台概述数据中台是一种集中管理和共享数据资源的架构框架。
它通过建立一个统一的数据中心，将企业各个部门的数据集中存储和管理，实现数据的共享和协同应用。
3. 架构框架的组成数据中台架构框架包括以下核心组成部分：3.1 数据采集层数据采集层负责从各个业务系统中采集数据，并将其转换为标准的数据格式。
这一层可以通过各种数据接口和技术实现数据的抽取和导入。
3.2 数据存储层数据存储层是数据中台的核心组成部分，它用于存储和管理各个业务系统采集的数据。
这一层通常采用关系数据库或大数据存储系统作为数据存储的基础。
3.3 数据处理层数据处理层是对存储在数据中台中的数据进行清洗、转换和计算的地方。
这一层可以使用各种数据处理技术和工具，如ETL工具、数据挖掘算法等。
3.4 数据服务层数据服务层用于向外部应用程序或系统提供数据服务。
这一层可以通过API或其他方式将数据中台的数据暴露给外部系统使用。
4. 数据中台的应用数据中台可以在企业中有多种应用，以下是一些常见的应用场景：- 数据分析和报表：通过数据中台，可以方便地对企业的数据进行分析和生成各种报表，帮助企业做出更明智的决策。
- 业务集成和协同：数据中台可以集成和协同各个业务系统的数据，提供统一的视图和接口，方便业务部门之间的协作和交互。
- 数据应用开发：数据中台可以作为数据应用开发的基础平台，提供数据访问和数据处理的接口和工具，加速应用开发过程。
5. 总结数据中台架构框架是一种有效的数据管理和应用架构，在企业中有广泛的应用。
它能够实现数据的集中管理和共享，提高数据的质量和可用性，为企业决策和业务发展提供有力的支持。
数据中台与业务中台架构设计方案(46页 PPT)
提供一些通用的技术开发工具包，减少重复造轮子，提高开发效率
节点组
服务器节点与租户、用户、服务的关系，帮助租户、用户能找到对应服务的节点
主数据
指系统间共享的数据，比如供应商、客户、物料等
基础数据
主要指变化较慢的数据，基础数据包含主数据，比如用户、角色、消息、参数配置等
功能架构
基本功能
辅助
IoT服务
……
设备管理服务
MQTT服务
连接管理服务
AI服务
……
语音识别连接
文本关键字段提取
OCR连接
平台简介
基于微服务架构模式每项服务都是独立而灵活的，可以提高服务的重用性
业务模块化，加快迭代速度随着各业务共享服务的沉淀积累，可帮助企业加快业务场景的迭代实现，支撑企业快速变革
包含许多开箱即用的通用服务组件如权限认证服务，数据一致性服务等都已包含在框架中。其中应用数据一致性服务去解决微服务间组合调用引发的不一致问题。
数据加密存储
客户端
组件
EXCEL导出
文件管理客户端
统一编码规则应用
消息应用客户端
调度执行应用
文件导入客户端
……
服务治理
通用服务
门户管理服务
调度服务
服务治理服务
工作流服务
数据分发服务
报表服务
登录&注册
用户管理
消息管理短信管理邮件管理站内消息管理
数据多语言TL语言表字段多语言
主数据管理
HR组织架构
业务组织架构
数据分发管理
系统配置
个人首选项
静态文本管理
编码规则
租户管理
报表展现
门户管理
SQL数据集定义、参数定义、数据模型可视化定义；套打报表报表访问权限控制
数据中台技术架构方案
数据中台技术架构方案随着大数据技术的快速发展和企业对数据价值的认知不断提高，数据中台作为一种新兴的数据架构模式，逐渐引起了各行各业的关注和应用。
数据中台用于企业将分散在各个业务部门的数据集中管理、分析和应用，从而实现数据的高效价值利用和业务的迭代创新。
本文将探讨数据中台技术架构方案，分析其核心组成和实施流程，并对其在企业中的应用进行解析。
一、数据中台的定义和背景在数字化时代，企业积累了大量的数据资源，这些数据分布在各个业务系统中，造成了数据孤岛和信息孤岛的问题。
数据中台的概念应运而生，其目标是将企业内部各业务线的数据资源集中起来，通过数据集市的形式为各个业务部门提供数据支持和服务，实现数据的高质量、高效益的利用，为企业的业务创新提供支撑。
二、数据中台的核心组成1. 数据接入层：负责将企业内部各个业务系统的数据进行采集、清洗和整合，构建数据标准化和一致性的基础。
2. 数据存储层：用于存储和管理各种类型的数据，包括结构化数据、半结构化数据和非结构化数据等。
3. 数据计算层：提供数据处理和计算能力，包括数据分析、数据挖掘、机器学习等，为业务部门提供数据分析和挖掘的技术支持。
4. 数据服务层：将数据加工成可供业务使用的数据产品，为业务部门提供数据接口和服务，满足不同业务场景的需求。
5. 数据治理层：负责数据质量管理、数据安全管理、数据合规管理等，保障数据的质量和安全。
三、数据中台的实施流程1. 确定目标和愿景：明确数据中台建设的目标和愿景，明确业务需求，制定建设规划和路线图。
2. 数据建设和整合：对业务系统进行数据调研和评估，建立数据标准和规范，进行数据的采集、清洗和整合。
3. 架构设计和技术选型：根据企业需求和数据特点，设计数据中台的技术架构，选择合适的技术工具和平台。
4. 系统开发和集成：进行数据中台系统的开发和集成，实现数据的接入、存储、计算和服务能力。
5. 测试和优化：对数据中台系统进行测试，发现和解决问题，优化系统性能和用户体验。
数据中台技术架构解读
数据中台技术架构解读目录前言 (3)一当前关于“中台”问题研究存在诸多问题 (3)二科学界定“数据中台”问题的基本原则 (7)三小数据是理解数据中台的关键 (11)前言数据中台最近特别火，之前还在炒概念，现在突然就看到有的企业已经宣传自家的数据中台了，有的企业向外介绍如何构建自己的数据中台，利用数据中台打造数据驱动的经营能力。
大家热衷于讨论什么是“数据中台”，并且还有“有一千个企业，就有一千个数据中台”的说法，但大家真的都理解了什么是数据中台了吗？本文基于笔者的个人思考，首先介绍了当前关于“中台”问题研究存在的3个主要问题，然后从3个方面说明了科学界定数据中台的基本原则，最后指出小数据是理解数据中台的关键，以更加科学合理的角度使读者更加清晰、全面的认识数据中台。
”一当前关于“中台”问题研究存在诸多问题Supercell，芬兰移动游戏巨头，成立于2010年，拥有《部落冲突》、《卡通农场》、《海岛奇兵》、《皇室战争》和《荒野乱斗》等全球热门游戏。
据说，2015年12月马云亲自率队到Supercell公司进行商务拜访，马云对Supercell的高效运营无比感慨，将其经营秘密概括为中台战略，要求阿里巴巴按照“大中台、小前台”的组织原则进行公司架构改革。
不管上述“中台”的马云说是否属实，但“中台”的概念确实在近年来不断发酵并从去年开始流行起来，日益成为行业共识，但大家对如何认识这个共识还没有达成一致意见，同时当前关于“中台”问题的研究还存在诸多问题。
1.1对数据中台的定义不清目前关于数据中台的定义很多，笔者根据网上数据中台相关著作或文章，搜集了一些对数据中台的定义，供读者参考，如下表所示。
表1 网上关于数据中台的定义从上表这些定义来看，人们对于中台的解释还是很不一致的，有的定义甚至还谈不上是严格的定义，充其量只能说是对其某方面属性的简单描述，还谈不上是对其本质属性的界定。
1.2缺乏明确的数据中台架构模型阿里巴巴从2009年就开始建设共享业务事业部，已经为中台战略在转型过程中将会面临的组织间业务协作、业务核心能力的沉淀、组织KPI考核等方面都做了很好的实践和经验沉淀，阿里巴巴共享业务事业部的架构图也被阿里的人看作是解读阿里中台战略最常用的一个图，讨论阿里中台战略的时候都会用到。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
近来数据中台概念大火，大家对它的定义也五花八门，不一而足。
但无论怎么定义，一个完善的数据技术架构必不可少。
了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。
因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。
一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。
框架图如下：1. 数据采集传输这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。
针对不同的数据来源有各自的采集方式，从 APP/服务器日志，到业务表，还有各种 API 接口及数据文件等等。
其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于「重点关照」的对象。
目前市面针对日志采集的有 Flume，Logstash，Filebeat，Fluentd ，rsyslog 几种常见的框架，我们挑应用较广泛的前两者介绍下：1.1 Flume 和 Logstash Flume 是一款由 Cloudera 开发的实时采集日志引擎，主打高并发，高速度，分布式海量日志采集。
它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。
Flume 支持在日志系统中定制各类数据进行发送，用于采集数据；同时，它支持对数据进行简单处理，并写到各种数据接收方。
目前有两个版本，OG和NG，特点主要是：1.侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景2.由java开发，没有丰富的插件，主要靠二次开发3.配置繁琐，对外暴露监控端口有数据Logstash 是 Elastic.co 旗下的一个开源数据收集引擎，可动态的统一不同的数据源的数据至目的地，搭配 ElasticSearch 进行分析，Kibana 进行页面展示，是著名的 ELK 技术栈中的「L」部分。
特点主要是：1.内部没有一个persist queue，异常情况可能会丢失部分数据2.由ruby编写，需要ruby环境，插件很多3.配置简单，偏重数据前期处理，分析方便从两者的设计思想来看，Flume 最初并不是为了采集日志而设计，而是定位在把数据传入 HDFS 中，这和Logstash 有根本的区别。
所以它理所应当侧重于数据的传输和安全，且需要更多的二次开发和配置工作。
而 Logstash 明显侧重先对日志数据进行预处理，为后续的解析做铺垫。
它搭配 ELK 技术栈使用起来比较简单，更像是为你准备好的便当，开盒即食。
1.2 日志采集如何工作我们以 Flume 为例子讲些日志采集 Agent 是怎么工作的。
Flume 由三个部分组成：Source，Channel 和 Sink，对应于采集，缓存和保存三个环节。
其中，Source 组件用来采集各种类型的数据源，如 directory、http、kafka 等。
Channel 组件用来缓存数据，有 memory channel，JDBC channel和 kafka channel 三种。
最后再通过 Sink 组件进行保存，分别支持 HDFS，HBase，Hive 和 Kafka 四种存储方式。
下面结合一个大数据实时处理系统阐述下 Flume 在实际应用中所扮演的重要角色。
该实时处理系统整体架构如下：通过将 Agent 部署在 Web 服务器，一旦发生新增的日志数据，就会被 Flume 程序监听到，并且最终会传输到 Kafka 的 Topic 中，再进行后续的一系列操作。
1.3 数据传输 KafkaKafka 最初是由领英开发，并随后于 2011 年初开源, 并于 2012 年 10 月 23 日由Apache Incubato 孵化出站。
该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。
其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。
2. 数据存储数据库存储方面，有单机/分布式、关系型/非关系型、列式存储/行式存储三个维度的划分，各种维度交叉下都有对应产品来解决某个场景下的需求。
在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的 MySQL。
数据量大到一定程度后，就必须采取分布式系统了。
目前业界最知名的就是 Apache 基金会名下的 Hadoop 系统，它基本可以作为大数据时代存储计算的经典模型。
HDFSHDFS 作为 Hadoop 里的分布式文件系统，为 HBase 和 Hive 们提供了高可靠性的底层存储支持，对应于Google GFS 的开源实现。
一般也会用于一些批次分析的场景。
HBaseHBase 是 Hadoop 数据库，作为基于列的非关系型数据库运行在 HDFS 上。
它具备 HDFS 缺乏的随机读写能力，因此比较适合实时分析。
HBase 以 Google BigTable为蓝本，以 Key-Value 形式存储，能快速在主机内数十亿行数据中定位所需的数据并访问它。
Hive 和 PigHive 和 Pig 都是集成在 Hadoop 顶层的查询语言，提供静态数据的动态查询，支持类 SQL 语言，底层经过编译转为 MapReduce 程序，省去了自己编写 MR 程序的繁琐。
区别是 Hive SQL 是类 SQL 的查询语言，要求数据存储于表中，而 Pig 是面向数据流的一个程序语言，常用于开发简洁的脚本来转换数据流从而嵌入到较大的应用程序中。
MapReduceMR 开创了分布时代计算的先河，使得大批量数据处理成为可能。
简单来讲，就是将比较庞大的计算任务先分组，再汇总，提高计算效率。
举例来讲，如果你新家需要装修，要在不同地方购置很多东西。
你一个人（单机）去买估计得花十天。
现在叫了一堆小伙伴（分布式），每个人负责去一个地方买东西（Map），最后再拿到家里分类汇总（Reduce），一天就搞定了。
其他辅助工具上图中的其他工具是为了保证整个大数据计算存储系统更加健壮和开放，如 Zookeeper 提供了稳定服务和failover 机制，Sqoop 则为 Hadoop 提供了方便的 RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向 HBase 中迁移变的非常方便。
值得一提的是，Hadoop 生态其实是建立在 Google 2003 年发表的三大论文的基础之上。
可能是当时Google 有意改善业内落后的现状，让大家稍微跟得上他的脚步才发布的论文…这么多年过去了，不知道Google 内部对数据的理解和使用又到了什么样的高度。
3. 数据计算&查询 3.1 批计算和流计算大数据处理场景可分为批处理和流处理两个，分别对应离线分析和实时分析。
常见框架分类有：1.仅批处理框架：Hadoop MapReduce2.仅流处理框架：Storm，Samza3.混合框架：Spark，Flink篇幅所限，除了上文已经提到的 Hadoop 生态外，我们再简单科普下 Spark：3.2 Spark 和 FlinkApache Spark 是一种包含流处理能力的下一代批处理框架。
批处理模式下，Spark 与 MapReduce 不同，它将数据处理工作全部在内存中进行，计算性能大幅改善。
流处理模式下，Spark 主要通过 Spark Streaming 实现了一种叫做微批（Micro-batch）的概念。
该技术可以将数据流视作一系列非常小的“批”，借此即可通过批处理引擎的原生语义进行处理。
这种方式的实际效果非常好，但相比真正的流处理框架在性能方面依然存在不足。
综上所述，Spark是多样化工作负载处理任务的最佳选择。
Spark批处理能力以更高内存占用为代价提供了无与伦比的速度优势。
对于重视吞吐率而非延迟的工作负载，则比较适合使用 Spark Streaming 作为流处理解决方案。
而 Flink 作为更新一代的处理框架，拥有更快的计算能力，更低的延迟，已经慢慢崭露头角。
不过一个框架的应用，特别是开源框架，需要足够长的时间进行运行，测试和优化。
大数据技术在开源社区的推动下，迭代日新月异。
在不久的将来，相信 Flink 会像 Spark 取代 Storm 一样，逐渐成为大数据处理技术的主流。
3.3 数据查询经过处理后的数据，还需要有高效的查询引擎才能被用户接触和使用。
目前 OLAP 的查询技术框架大致可分为三类：1.基于 HBase 做预聚合：如 Opentsdb, Kylin 等，均需指定预聚合的指标，在数据接入的时候进行聚合运算，适合相对固定，维度较多的业务报表类需求2.基于 Parquet 做列式存储：如 Presto, Drill，Impala 等，基本是完全基于内存的并行计算，Parquet 系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的 Join 支持可能不够好3.基于 Lucene 做外部索引：如 ElasticSearch，Solr 等，能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋我们以常见的Presto，Druid，Kylin三个模型来讲讲各自的特点：1.Presto：由 Facebook 开源，是一个分布式数据查询框架，原生集成了 Hive、 Hbase 和关系型数据库。
它背后所使用的执行模式与Hive有根本的不同，并没有使用 MapReduce。
因其所有的处理都在内存中完成（与上文的 Spark 类似），大部分场景下要比 Hive 快一个数量级2.Druid：由 MetaMarket 开源，是一个分布式、面向列式存储的准实时分析数据存储系统，延迟性最细颗粒度可到 5 分钟。
它能够在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、分析与可视化功能3.Kylin：Cube 预计算技术是其核心，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。
劣势在于每次增减维度必须对 Cube 进行历史数据重算追溯，非常消耗时间。
据说 Kylingence 在前几天的新品发布会上已经解决了这个问题，拭目以待下图引自快手在 OLAP 技术选型时的评价，以供大家参考：很多时候，在计算和查询这块没有明显的边界区分。
这里为了方便阐述分成了两个部分。
事实上，对于技术能力比较强的团队，可以针对这些开源系统进行魔改，比如采用 Kylin 的预计算能力+Druid 的查询引擎，来提高查询的速度等等。