大数据中台架构栈(20201115224128)
大数据中台架构栈说课材料
大数据中台架构栈近来数据中台概念大火，大家对它的定义也五花八门，不一而足。
但无论怎么定义，一个完善的数据技术架构必不可少。
了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。
因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。
一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。
框架图如下：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. 数据采集传输这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。
针对不同的数据来源有各自的采集方式，从 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」部分。
大数据云平台基础架构介绍
随着数据重要性的不断提高，大数据云平台需要 提供更加安全可靠的数据保护和服务，保障数据 安全和隐私。
智能化趋势
大数据云平台正在不断引入人工智能技术，实现 智能化数据分析、处理和存储，提高数据处理效 率和准确性。
绿色环保趋势
随着能源消耗的不断提高，大数据云平台需要采 取更加绿色环保的技术和措施，降低能源消耗和 碳排放。
06
大数据云平台案例分享
案例一：阿里巴巴的大数据云平台
总结词
分布式、可扩展、弹性
详细描述
阿里巴巴的大数据云平台是基于开源平台构建的分布式系统，具备可扩展和弹性的特点。它采用了分 布式文件系统，如HDFS，用于存储海量数据，并支持多种数据访问模式。同时，该平台还集成了弹 性计算、弹性存储和弹性网络等云基础设施，以提供稳定、高效的大数据处理服务。
提供数据挖掘和机器学习功能，以发现数 据中的潜在规律和价值。
应用层
数据报表与可视化
提供数据报表和可视化功 能，以直观展示数据分析 结果。
数据服务
提供数据服务功能，包括 数据查询、数据挖掘、机 器学习等服务，以支持各 种业务应用。
安全管理
提供安全管理功能，包括 用户认证、访问控制、加 密传输等，以确保大数据 云平台的安全性。
据，为后续数据分析提供准确的基础。
数据转换与整合
03
实现数据的转换和整合，以满足不同业务场景的需求
。
数据分析层
分布式计算框架
提供分布式计算框架，如Hadoop、 Spark等，以处理大规模数据。
数据库查询与分析
提供数据库查询和分析功能，支持SQL、 NoSQL等数据库查询语言和分析工具。
数据挖掘与机器学习
谢谢您的聆听
2023-中台技术架构演进解决方案-1
中台技术架构演进解决方案随着数字化时代的来临，越来越多的企业开始寻求数字化转型，而其中最重要的一步就是中心平台(central platform)的构建。
中台技术架构演进解决方案慢慢成为了数字化转型时期最为关键的一环。
下面将分步骤阐述中台技术架构演进解决方案。
第一步：基础架构中台技术架构演进解决方案的第一个步骤是要先明确和构建基础架构。
建立基础架构是为了实现所有中台系统的基础设施和基础环境的一致性，包括硬件设备、操作系统、网络环境、数据库等，这些要求必须满足所有中台系统的需求。
在明确了这些基础设施后，可以构建一个统一的中间件平台，提供共享服务，如负载均衡、缓存、消息队列、日志、监控等等。
第二步：数据共享中台技术架构演进解决方案的第二个步骤是数据共享。
确定数据的共享方式是至关重要的。
在设计中台的数据共享模式时，必须考虑数据的一致性、安全性和性能等方面的问题，同时还需要思考数据主人的责任和数据扩展性的问题。
要通过数据资源的智能化管理，实现数据共享和集成，提高数据的利用效率，同时还要确保数据的安全性和完整性。
第三步：统一规范中台技术架构演进解决方案的第三个步骤是规范化中台技术框架。
规范是保证中台系统互通性和稳定性的关键。
在建设中台系统架构的同时，必须根据业务需求和技术标准来妥善设计和布局架构。
要根据一些重要的规范方案，如RESTful、SOA、微服务架构等来实现中台系统的复用性和互操作性，同时实现标准化的接口、组件、框架等互相合作的能力。
第四步：平台合作中台技术架构演进解决方案的第四个步骤是要加强和信任开发者和运营者之间的交流和合作，以便更好地实现中台系统的稳定、高效和可扩展性。
要建立一个完整的开发社区和运营社区，搭建协作平台，实现真正的开放式合作。
在开发中央平台时，必须采用敏捷开发模式，确保能快速适应业务需求的不断变化。
与此同时，还要保证系统的性能和稳定性等方面。
中台技术架构演进解决方案对于数字化转型而言，是至关重要的一步。
大数据中心架构栈
大数据中心架构栈概述大数据中心架构栈是指用于构建和管理大数据中心的技术架构和组件的集合。
它包括硬件、软件和网络等方面的要素，旨在支持大规模数据处理和分析。
架构层次大数据中心架构通常包含以下几个层次：1. 基础设施层：该层包括服务器、存储设备和网络设备等基础设施组件。
这些设备提供数据中心的物理基础，负责数据的存储、传输和处理等功能。
基础设施层：该层包括服务器、存储设备和网络设备等基础设施组件。
这些设备提供数据中心的物理基础，负责数据的存储、传输和处理等功能。
2. 数据处理层：在数据中心中，大数据处理是一个关键的任务。
数据处理层包括数据处理引擎、分布式文件系统和数据处理工具等。
它们能够实现高效的数据处理和分析，支持实时和离线的数据处理应用。
数据处理层：在数据中心中，大数据处理是一个关键的任务。
数据处理层包括数据处理引擎、分布式文件系统和数据处理工具等。
它们能够实现高效的数据处理和分析，支持实时和离线的数据处理应用。
3. 数据存储层：大数据中心需要存储海量的数据。
数据存储层包括分布式数据库、分布式文件系统和分布式存储系统等。
这些系统能够提供高可靠性、高可扩展性和高性能的数据存储服务。
数据存储层：大数据中心需要存储海量的数据。
数据存储层包括分布式数据库、分布式文件系统和分布式存储系统等。
这些系统能够提供高可靠性、高可扩展性和高性能的数据存储服务。
4. 数据安全层：大数据中心中的数据安全是一个重要的问题。
数据安全层包括身份认证、权限管理、数据加密和安全审计等。
这些措施能够保护数据中心中的数据免受未授权访问和数据泄露的风险。
数据安全层：大数据中心中的数据安全是一个重要的问题。
数据安全层包括身份认证、权限管理、数据加密和安全审计等。
这些措施能够保护数据中心中的数据免受未授权访问和数据泄露的风险。
架构组件大数据中心架构栈涵盖了众多的技术组件，下面是一些常见的组件：1. Hadoop：Hadoop是一个开源的分布式计算框架，能够存储和处理大规模数据，并提供高可靠性和高性能。
数据中台与业务中台架构设计方案(46页 PPT)
提供一些通用的技术开发工具包，减少重复造轮子，提高开发效率
节点组
服务器节点与租户、用户、服务的关系，帮助租户、用户能找到对应服务的节点
主数据
指系统间共享的数据，比如供应商、客户、物料等
基础数据
主要指变化较慢的数据，基础数据包含主数据，比如用户、角色、消息、参数配置等
功能架构
基本功能
辅助
IoT服务
……
设备管理服务
MQTT服务
连接管理服务
AI服务
……
语音识别连接
文本关键字段提取
OCR连接
平台简介
基于微服务架构模式每项服务都是独立而灵活的，可以提高服务的重用性
业务模块化，加快迭代速度随着各业务共享服务的沉淀积累，可帮助企业加快业务场景的迭代实现，支撑企业快速变革
包含许多开箱即用的通用服务组件如权限认证服务，数据一致性服务等都已包含在框架中。其中应用数据一致性服务去解决微服务间组合调用引发的不一致问题。
数据加密存储
客户端
组件
EXCEL导出
文件管理客户端
统一编码规则应用
消息应用客户端
调度执行应用
文件导入客户端
……
服务治理
通用服务
门户管理服务
调度服务
服务治理服务
工作流服务
数据分发服务
报表服务
登录&注册
用户管理
消息管理短信管理邮件管理站内消息管理
数据多语言TL语言表字段多语言
主数据管理
HR组织架构
业务组织架构
数据分发管理
系统配置
个人首选项
静态文本管理
编码规则
租户管理
报表展现
门户管理
SQL数据集定义、参数定义、数据模型可视化定义；套打报表报表访问权限控制
通用数据中台体系架构
通用数据中台体系架构数据中台的目标是让数据持续用起来，通过数据中台提供的工具、方法和运行机制，把数据变为一种服务能力，让数据更方便地被业务所使用。
下图为数据中台总体架构图，数据中台是在底层存储计算平台与上层的数据应用之间的一整套体系。
数据中台屏蔽掉底层存储平台的计算技术复杂性，降低对技术人才的需求，让数据的使用成本更低。
通过数据中台的数据汇聚、数据开发模块建立企业数据资产。
通过资产管理与治理、数据服务把数据资产变为数据服务能力，服务于企业业务。
数据安全体系、数据运营体系保障数据中台可以长期健康、持续运转。
一个通用的数据中台架构应该如何构建？1.数据中台总体架构图数据汇聚数据汇聚是数据中台数据接入的入口。
数据中台本身几乎不产生数据，所有数据来自于业务系统、日志、文件、网络等，这些数据分散在不同的网络环境和存储平台中，难以利用，很难产生业务价值。
数据汇聚是数据中台必须提供的核心工具，把各种异构网络、异构数据源的数据能够方便地采集到数据中台进行集中存储，为后续的加工建模做准备。
数据汇聚方式一般有数据库同步、埋点、网络爬虫、消息队列等；从汇聚的时效性来分，有离线批量汇聚和实时采集。
数据开发通过数据汇聚模块汇聚到中台的数据，没有经过什么处理，基本是按照数据的原始状态堆砌在一起的，这样业务还是很难使用。
数据开发是一整套数据加工以及加工过程管控的工具，有经验的数据开发、算法建模人员利用数据加工模块提供的功能，可以快速把数据加工成对业务有价值的形式，提供给业务使用。
数据开发模块主要是面向开发、分析人员，提供离线、实时、算法开发工具以及任务的管理、代码发布、运维、监控、告警等一些列集成工具，方便使用，提升效率。
2.数据资产体系有了数据汇聚、数据开发模块，中台已经具备传统数仓平台的基本能力，可以做数据的汇聚以及各种数据开发，就可以建立企业的数据资产体系。
之前说数据资产体系是中台的血肉，开发、管理、使用的都是数据。
大数据时代，数据量大，增长快，业务对数据的依赖也会越来越高，必须考虑数据的一致性和可复用性，垂直烟囱式的数据和数据服务的建设方式注定不能长久存在。
大数据中台架构栈
大数据中台架构栈大数据中台架构栈是指以大数据技术为核心，集成多种数据处理、存储、计算等技术的架构，旨在提供高效的数据处理能力，支持企业的数据驱动决策和业务创新。
它是大数据时代的核心基础设施，承载着企业各种数据需求的应用场景。
数据采集是指从各种数据源中提取数据，并将其存储到中台系统中。
数据源可以包括传感器、智能设备、网络爬虫、第三方API等。
常用的数据采集技术包括ETL（抽取、转换、加载）、实时数据流处理、分布式文件系统等。
数据存储是指将采集到的数据进行存储和管理。
根据数据特点和应用场景的不同，选择不同的存储方案。
常用的大数据存储技术包括HDFS （分布式文件系统）、HBase（分布式列式数据库）、Cassandra（分布式NoSQL数据库）、Elasticsearch（开源引擎）等。
数据处理是指对存储在中台系统中的数据进行分析、挖掘和计算。
常用的数据处理技术包括数据挖掘、机器学习、图计算等。
同时，为了提高数据处理的效率和灵活性，很多企业也引入了大数据处理框架，如Hadoop、Spark等。
数据可视化是指将处理后的数据以图表、仪表盘等形式展现出来，以便用户能够直观地理解和分析数据。
常用的数据可视化技术包括BI工具（如Tableau、Power BI）、数据仪表盘等。
除了以上四个方面，大数据中台架构栈还包括数据安全、数据治理和数据治理等方面。
数据安全是指保护中台系统中的数据不被未授权的访问和恶意攻击。
常用的数据安全技术包括身份认证、数据加密、访问控制等。
数据治理是指对中台系统中的数据进行规划、管理和监控，保证数据的质量、一致性和可用性。
常用的数据治理技术包括数据清洗、数据集成、数据验证等。
数据治理是指对中台系统中的数据进行规范、管理和运营，确保数据对于业务决策和创新具有高效性和可靠性。
常用的数据治理技术包括数据架构设计、数据流程管理、数据质量监控等。
综上所述，大数据中台架构栈是以大数据技术为核心，包括数据采集、数据存储、数据处理和数据可视化等多个方面的综合技术架构。
- 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 的查询引擎，来提高查询的速度等等。