大数据中台架构栈
大数据中台架构栈说课材料
大数据中台架构栈近来数据中台概念大火，大家对它的定义也五花八门，不一而足。
但无论怎么定义，一个完善的数据技术架构必不可少。
了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。
因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。
一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。
框架图如下：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」部分。
数据中台与企业架构
数据中台与企业架构随着大数据时代的到来，企业面临着海量数据的处理和管理的挑战，数据中台作为一种新的概念和架构，逐渐受到了企业的重视。
数据中台是一种以数据为核心的架构模式，旨在解决企业数据孤岛的问题，实现数据的一体化管理和应用。
而企业架构则是一种组织结构和技术架构的综合体，用于支持企业的战略目标和业务需求。
本文将从数据中台和企业架构的关系、数据中台架构的特点和优势以及数据中台对企业架构的影响等方面进行探讨。
首先，数据中台与企业架构有着密切的关系。
企业架构是一个系统化的框架，旨在定义和组织企业的战略、业务和技术等方面的要素。
而数据中台则是企业架构中的一个重要组成部分，它通过将数据整合在一起，为企业的业务和决策提供支持和便利。
数据中台的设计和构建需要遵循企业的整体架构，与企业的战略和业务需求相一致，从而确保数据的再利用和价值最大化。
其次，数据中台架构具有以下几个特点和优势。
首先，数据中台架构强调数据的一体化管理和共享，通过建立统一的数据模型和标准化的数据处理流程，使得不同部门和业务之间能够共享和使用相同的数据资源。
其次，数据中台架构注重数据的质量和价值，通过数据质量管理、数据治理和数据分析等手段，提高数据的准确性、完整性和及时性，发挥数据在企业决策和运营中的作用。
此外，数据中台架构还具有灵活性和可扩展性，能够适应不同规模和需求的企业，支持快速的业务创新和技术升级。
最后，数据中台对企业架构有着积极的影响。
首先，数据中台能够帮助企业实现数据的整合和一体化管理，打破数据孤岛，减少数据的冗余和重复，提高数据的质量和可信度。
其次，数据中台能够提供准确和实时的数据分析和洞察，为企业的战略决策和业务优化提供有力的支持。
此外，数据中台还能够促进企业的数字化转型，提高企业的竞争力和创新能力。
综上所述，数据中台是一种以数据为核心的企业架构模式，通过数据的一体化管理和应用，为企业提供支持和便利。
数据中台架构具有数据的一体化管理、数据质量和价值的提升以及灵活和可扩展的特点和优势。
中台架构是什么
中台架构是什么⼀、该不该使⽤微服务架构根据业务发展的时间来区分1. 业务发展早期建议使⽤单体架构，开发⽅便，速度快，迭代更新及时。
优点如下：部署简单: 由于是完整的结构体，可以直接部署在⼀个服务器上即可。
技术单⼀: 项⽬不需要复杂的技术栈，往往⼀套熟悉的技术栈就可以完成开发。
⽤⼈成本低: 单个程序员可以完成业务接⼝到数据库的整个流程。
2. 什么时间微服务化需要看业务发展速度，性能是否达到瓶颈。
所以选择架构时，建议先单体后微服务，不要上来就搞微服务架构。
⼆、微服务架构设计思想分⽽治之单⼀职责关注分离三、SAAS多租户1. 多租户SaaS架构⼩A、⼩B、⼩C⼤学毕业后，⼀起同租了⼀套三室两厅的房⼦。
三个⼈都拥有⾃⼰独⽴的房间，且每个房间都有配有⼀把钥匙，保证三个⼈独⽴的空间私密性。
如果其他⼈要进⼊别⼈的房间，就需要拥有配套房间的钥匙进⾏开锁。
⽽客厅、餐厅、厨房等属于公共区域，三⼈共同享有这些资源。
这⾥⼩A、⼩B、⼩C就属于应⽤SaaS多租户解决⽅案的企业实体。
应⽤运⾏在同⼀个或同⼀组服务商（即三个⼈同租⼀套房⼦，厨房、餐厅、客厅是多租户环境下的系统和应⽤程序、组件），每个数据库都存储来⾃多个独⽴租户的数据（即房⼦拥有三间不同的房间），然后通过使⽤保护数据隐私的机制来逻辑隔离不通租户之间的数据（即每个房间都有配套的钥匙来保证安全隔离）。
因此多租户架构也被称为单实例架构（Single Instance）。
在多租户环境中，由于应⽤都运⾏在相同的服务器上，所有的数据都保存在同⼀个多租户隔离的数据库中，因此多租户模式通常会⽐较节省硬件资源。
但是由于多租户SaaS架构需要具备相同的硬件、⽹络和操作系统配置能⼒，所以很难实现根据单⼀⽤户的需求去做功能上的定制化，也很难根据某个⽤户的请求进⾏常规的系统升级、重启之类的操作。
2. 单租户SaaS架构如果多租户是多个⼈租⼀套房⼦，每个⼈拥有⼀个房间，那么单租户就是⼀个⼈租⼀套房⼦，⽆须与其他⼈共享客厅、餐厅、厨房等资源。
多图详解数据中台建设框架（建议收藏）
多图详解数据中台建设框架（建议收藏）大数据DT提供大数据、AI等领域干货学习资源的「宝藏号」，跟50万技术人共同成长，一起玩转大数据、Python、数据分析、数据科学、人工智能！还会有各种好玩又奇葩的数据解读，边学习边吃瓜！531篇原创内容公众号导读：近日，舞动数字·2021数字化转型系列论坛由机械工业出版社华章公司成功举办。
在数字化能力与平台构建专场中，《数据中台》的核心作者、数澜咨询及解决方案的负责人铁平老师发表了主题演讲。
铁平老师从技术、服务、数据、运营4个体系回顾了数据中台建设框架1.0，并在此基础上优化给出了数据中台建设框架2.0，同时指出数据中台是企业数字化转型的关键创新引擎。
以下为演讲全文，大数据DT经授权发布。
作者：铁平来源：大数据DT（ID：hzdashuju）今天我给大家分享一下企业数据中台的建设框架。
我叫沈金，花名是铁平，是目前数澜咨询及解决方案的负责人，是《数据中台》的核心作者之一，也在去年撰写了《数据中台咨询白皮书》。
从我个人的经历来讲，前5年做的事情更多是让数据跑起来，所以更多关注的是数据库，以及数据库相关的一些工作。
后七八年更多关注于让数据用起来，所以关注整体的数据架构，包括数据的整体解决方案。
是早期阿里集团OneID的一个核心开发者以及运营者。
01 数据中台：企业数字化转型关键创新引擎关于数据中台，我们有一个观点，就是我们始终认为数据中台是一种让企业数据快速持续用起来的机制，它绝对不是一个技术平台。
通过数据中台可以让企业拥有什么呢？•第一，让企业拥有数据价值释放的一个通道能力。
•第二，让企业具备开发整个复用、快速试错的一个交付能力。
•第三，让企业拥有数据交换、数据资产化，以及资产服务化的技术能力。
所以，数据中台是不是技术平台？其实在去年7月份，Gartner颁布了一个《2020中国ICT成熟度曲线报告》，正式建议企业的管理者把数据中台当作整个数据化转型的关键创新引擎，从而解决数字化的收入，以及实现可持续的交互的业务能力。
大中台架构解析--架构师必备
大中台架构解析--架构师必备概念中台概念出现之前，在信息化模式上，前端为支撑业务的应用端，后端为各个应用系统，为前端用户，如：客户、供应商、伙伴、社会，提供服务，但随着市场、用户需求、业务的多变性，底层僵硬的应用无法及时提供支撑。
企业需要一个强大的中间层为高频多变的业务提供支撑，为不同的受众用户提供多端访问渠道，基于此类需求“中台”概念出现，接着开始对企业客户、中间件厂商、数据平台厂商、甚至传统应用软件厂商都有较大的概念冲击。
恰逢此时，微服务技术和架构、容器化的生态、Devops概念和工具处于大发展的阶段，最后基于“大中台、小前台”的信息化建设模式开始流行。
1. 概念产生对于大中台来讲，现在并没有十分严格的定义，每个企业对其的理解都是不同的，有的在技术上使用大中台模式，有的在业务上使用大中台模式，有的将两者相结合。
“大中台，小前台”的机制最初阿里提出的时候，主要应用于O2O线上线下协同、电商等场景，对于电商来说，市场环境是瞬息万变的，而前台是主要的一线业务，这时就需要一个强大的技术中台提供快速设计方法和系统性后端服务，去应对市场变化，灵活快速的做出应对策略。
2. 应用模式就阿里平台与个体商家的关系而言，虽然互相为独立的主体，但因为业务之间存在的联系，一定程度上已经分不清彼此，对于阿里来说，“大中台，小前台”理念中的前台强调创新和灵活多变，包括云计算、大数据、零售电商、广告业务、物流配送、售后维护以及其它业务；中台强调协调和规划管控，为前台业务开展提供底层技术、数据等资源支撑，多为平台类体系产品，一般都是外购、开源、自研相结合、不同的企业比重不同。
中台划分如今大中台模式不再拘泥于电商行业，随着发展和演变逐渐走向集团型、大型企业，为整个集团提供运营数据能力、技术能力、支撑能力、产品能力等，这时对于大中台的运用与划分也不再只是技术中台，还包括基础中台、数据中台、业务中台共同构成。
1. 基础中台基础中台为大中台模式的底层基础支撑，也称之为PaaS容器层，而对于中台模式来说，要求平台灵活高效，这就意味着对容器集群管理与容器云平台的选择十分重要，技术运用的是否到位直接影响平台的开发效率和运维程度，在这方面目前Docker和K8S独占鳌头，同时对应的DevOPS与CI/CD理念也随着兴起。
大数据中心架构栈
大数据中心架构栈概述大数据中心架构栈是指用于构建和管理大数据中心的技术架构和组件的集合。
它包括硬件、软件和网络等方面的要素，旨在支持大规模数据处理和分析。
架构层次大数据中心架构通常包含以下几个层次：1. 基础设施层：该层包括服务器、存储设备和网络设备等基础设施组件。
这些设备提供数据中心的物理基础，负责数据的存储、传输和处理等功能。
基础设施层：该层包括服务器、存储设备和网络设备等基础设施组件。
这些设备提供数据中心的物理基础，负责数据的存储、传输和处理等功能。
2. 数据处理层：在数据中心中，大数据处理是一个关键的任务。
数据处理层包括数据处理引擎、分布式文件系统和数据处理工具等。
它们能够实现高效的数据处理和分析，支持实时和离线的数据处理应用。
数据处理层：在数据中心中，大数据处理是一个关键的任务。
数据处理层包括数据处理引擎、分布式文件系统和数据处理工具等。
它们能够实现高效的数据处理和分析，支持实时和离线的数据处理应用。
3. 数据存储层：大数据中心需要存储海量的数据。
数据存储层包括分布式数据库、分布式文件系统和分布式存储系统等。
这些系统能够提供高可靠性、高可扩展性和高性能的数据存储服务。
数据存储层：大数据中心需要存储海量的数据。
数据存储层包括分布式数据库、分布式文件系统和分布式存储系统等。
这些系统能够提供高可靠性、高可扩展性和高性能的数据存储服务。
4. 数据安全层：大数据中心中的数据安全是一个重要的问题。
数据安全层包括身份认证、权限管理、数据加密和安全审计等。
这些措施能够保护数据中心中的数据免受未授权访问和数据泄露的风险。
数据安全层：大数据中心中的数据安全是一个重要的问题。
数据安全层包括身份认证、权限管理、数据加密和安全审计等。
这些措施能够保护数据中心中的数据免受未授权访问和数据泄露的风险。
架构组件大数据中心架构栈涵盖了众多的技术组件，下面是一些常见的组件：1. Hadoop：Hadoop是一个开源的分布式计算框架，能够存储和处理大规模数据，并提供高可靠性和高性能。
数据中台架构及其建设运营策略
数据中台架构及其建设运营策略作者：刘水生来源：《中国信息化》2021年第08期一、背景大数据蓬勃发展的背景下，各行各业越来越重视大数据给企业带来的业务革新动力，希望借助数据驱动业务新发展。
烟草行业在此背景下积极探索数据管理和数据应用，完成了以“一体化数据中心、一体化数据管理、一体化数据分析”三个一体化为核心的数据中心建设，为各业务部门提供高质量的数据以及丰富的数据分析手段，为各级人员管理决策提供了有效支撑。
但我们也应当看到，目前的数据中心，无论是专题、报表或取数，主要是烟囱式数据生产模式或者是项目制建设方式，如果当初模型的扩展性设计的不好，或者时间太紧，或者出于系统稳定的考虑，致使数据模型扩展性较差。
久而久之，数据得不到沉淀和持续发展，从而造成模型不能真正成为可重用的组件，无法支撑数据分析的快速响应和创新。
在这种情况下，通常的做法是另起炉灶，构建一套新的模型来满足当前的需求，这又导致了一个新”烟囱”的产生，长此以往，数据中心将演变为一个个的数据孤岛，不再具有对外提供统一数据服务的能力。
因此，亟需建立企业的数据中台，构建中台的运营体系，真正做到打通数据孤岛并且以统一的标准进行建设，以达到技术降本、应用提效、业务赋能的目标。
二、数据中台架构设计数据中台建设主要包含基础平台、数据中台（数据及服务层、企业数据公共层）以及應用平台。
（一）基础平台基础平台主要提供弹性可伸缩的CPU、网络、存储虚拟化能力及兼顾离线计算及实时分析的大数据处理能力。
包括弹性计算服务器，数据库，负载均衡，对象存储等提供基础算力，以及离线计算、流计算、图计算和分析性数据库等。
基础平台是数据中台中的底座和主要基础支撑，其弹性、敏捷、数据、智能是其核心服务价值。
（二）数据中台数据中台包括数据及服务层、企业数据公共层两个核心层以及面向应用的统一数据服务中间层。
数据及服务层是基于数据智能套件、智能报表、大屏监控等提供核心的数据中台中间件，支撑数据中台建设。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
近来数据中台概念大火，大家对它的定义也五花八门，不一而足。
但无论怎么定义，一个完善的数据技术架构必不可少。
了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。
因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。
一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。
框架图如下：1.数据采集传输这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。
针对不同的数据来源有各自的采集方式，从APP/服务器日志，到业务表，还有各种API接口及数据文件等等。
其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于「重点关照」的对象。
目前市面针对日志采集的有Flume，Logstash，Filebeat，Fluentd，rsyslog几种常见的框架，我们挑应用较广泛的前两者介绍下：1.1Flume和LogstashFlume是一款由Cloudera开发的实时采集日志引擎，主打高并发，高速度，分布式海量日志采集。
它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。
Flume支持在日志系统中定制各类数据进行发送，用于采集数据；同时，它支持对数据进行简单处理，并写到各种数据接收方。
目前有两个版本，OG和NG，特点主要是：1.侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景2.由java开发，没有丰富的插件，主要靠二次开发3.配置繁琐，对外暴露监控端口有数据Logstash是Elastic.co旗下的一个开源数据收集引擎，可动态的统一不同的数据源的数据至目的地，搭配ElasticSearch进行分析，Kibana进行页面展示，是著名的ELK技术栈中的「L」部分。
特点主要是：2.内部没有一个persistqueue，异常情况可能会丢失部分数据3.由ruby编写，需要ruby环境，插件很多4.配置简单，偏重数据前期处理，分析方便从两者的设计思想来看，Flume最初并不是为了采集日志而设计，而是定位在把数据传入HDFS中，这和Logstash有根本的区别。
所以它理所应当侧重于数据的传输和安全，且需要更多的二次开发和配置工作。
而Logstash明显侧重先对日志数据进行预处理，为后续的解析做铺垫。
它搭配ELK技术栈使用起来比较简单，更像是为你准备好的便当，开盒即食。
1.2日志采集如何工作我们以Flume为例子讲些日志采集Agent是怎么工作的。
Flume由三个部分组成：Source，Channel和Sink，对应于采集，缓存和保存三个环节。
其中，Source组件用来采集各种类型的数据源，如directory、http、kafka等。
Channel组件用来缓存数据，有memorychannel，JDBCchannel和kafkachannel三种。
最后再通过Sink组件进行保存，分别支持HDFS，HBase，Hive和Kafka四种存储方式。
下面结合一个大数据实时处理系统阐述下Flume在实际应用中所扮演的重要角色。
该实时处理系统整体架构如下：通过将Agent部署在Web服务器，一旦发生新增的日志数据，就会被Flume程序监听到，并且最终会传输到Kafka的Topic中，再进行后续的一系列操作。
5.数据传输KafkaKafka最初是由领英开发，并随后于2011年初开源,并于2012年10月23日由ApacheIncubato孵化出站。
该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。
其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。
6.数据存储数据库存储方面，有单机/分布式、关系型/非关系型、列式存储/行式存储三个维度的划分，各种维度交叉下都有对应产品来解决某个场景下的需求。
在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的MySQL。
数据量大到一定程度后，就必须采取分布式系统了。
目前业界最知名的就是Apache基金会名下的Hadoop系统，它基本可以作为大数据时代存储计算的经典模型。
HDFSHDFS作为Hadoop里的分布式文件系统，为HBase和Hive们提供了高可靠性的底层存储支持，对应于GoogleGFS的开源实现。
一般也会用于一些批次分析的场景。
HBaseHBase是Hadoop数据库，作为基于列的非关系型数据库运行在HDFS上。
它具备HDFS缺乏的随机读写能力，因此比较适合实时分析。
HBase以GoogleBigTable为蓝本，以Key-Value形式存储，能快速在主机内数十亿行数据中定位所需的数据并访问它。
Hive和PigHive和Pig都是集成在Hadoop顶层的查询语言，提供静态数据的动态查询，支持类SQL语言，底层经过编译转为MapReduce程序，省去了自己编写MR程序的繁琐。
区别是HiveSQL是类SQL的查询语言，要求数据存储于表中，而Pig是面向数据流的一个程序语言，常用于开发简洁的脚本来转换数据流从而嵌入到较大的应用程序中。
MapReduceMR开创了分布时代计算的先河，使得大批量数据处理成为可能。
简单来讲，就是将比较庞大的计算任务先分组，再汇总，提高计算效率。
举例来讲，如果你新家需要装修，要在不同地方购置很多东西。
你一个人（单机）去买估计得花十天。
现在叫了一堆小伙伴（分布式），每个人负责去一个地方买东西（Map），最后再拿到家里分类汇总（Reduce），一天就搞定了。
其他辅助工具上图中的其他工具是为了保证整个大数据计算存储系统壮，如Z o o k e e p e r 提供了稳和 f a i l v e r 机制，S q 为H a d o o p 提供了方便的R D B M S （关系型数据库）数据导入功能，统数据 库HBase 中迁移变的非常方便。
值得一提的是，H a d o o p 生态其实在G o o g l e 2003年发表的三大论的基础之上。
可时 G o o g l e 有意改善业内落后的现状，让大家稍微跟得上他的脚步才发布的文⋯这么多了道 Google 内部对数据的理解和使用又到了什么样的高度。
7.数据计算&查询3.1批计算和流计算 大数据处理场景可分为批处理和流处理两个，分别对应离线分析和实时分析框有： 1.3仅批处理框架：HadoopMapReduce 1.4仅流处理框架：Storm ，Samza 1.5混合框架：Spark ，Flink 篇幅所限，除了上文已经提到的H a d o o p 生态外，我们下Spark ： 4.Spark 和Flink ApacheSpark 是一种包含流处理能力的下一代批处理框架。
批处理模式下，Spark 与MapReduce 不同，它将数据处理工作全部在内存中进行，计算性能大幅改善。
流 处理模式下，Spark 主要通过SparkStreaming 实现了一种叫做微批（Micro-batch ）的概念。
该技术可 以将数据流视作一系列非常小的“批”，借此即可通过批处理引擎的义进行处理。
这种方式的实际 效果非常好，但相比真正的流处理框架在性能方面依然存在不足。
综上所述，S p a r k 是多样化工作负载处Spark 批处理能力以更高内存占用为代价提供 了无与伦比的速度优势。
对于重视吞吐率而非延迟的工作负比较适合使用SparkStreaming 作为 流处理解决方案。
而F l i n k 作为更新一代的处理框架，拥有更快的计算能力，更低的延迟，已经慢。
不过一个框 架的应用，特别是开源框架，需要足够长的时间行，测试和优化。
大数据技术在开源社区的推动下， 迭代日新月异。
在不久的将来，相信Flink 会像Spark 取代Storm 一样，逐渐成为大数据处理技术的主 流。
5.数据查询 经过处理后的数据，还需要有高效的查询引擎才能被用和使前O分为三类： 1.基于HBase 做预聚合：如Opentsdb,Kylin 等，均需指定预聚合的指标，在数据接入的时候进行聚合运 算，适合相对固定，维度较多需求8.基于Parquet做列式存储：如Presto,Drill，Impala等，基本是完全基于内存的并行计算，Parquet系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的Join支持可能不够好9.基于Lucene做外部索引：如ElasticSearch，Solr等，能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋我们以常见的Presto，Druid，Kylin三个模型来讲讲各自的特点：1.6Presto：由Facebook开源，是一个分布式数据查询框架，原生集成了Hive、Hbase和关系型数据库。
它背后所使用的执行模式与Hive有根本的不同，并没有使用MapReduce。
因其所有的处理都在内存中完成（与上文的Spark类似），大部分场景下要比Hive快一个数量级1.7Druid：由MetaMarket开源，是一个分布式、面向列式存储的准实时分析数据存储系统，延迟性最细颗粒度可到5分钟。
它能够在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、分析与可视化功能1.8Kylin：Cube预计算技术是其核心，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。
劣势在于每次增减维度必须对Cube进行历史数据重算追溯，非常消耗时间。
据说Kylingence在前几天的新品发布会上已经解决了这个问题，拭目以待下图引自快手在OLAP技术选型时的评价，以供大家参考：很多时候，在计算和查询这块没有明显的边界区分。
这里为了方便阐述分成了两个部分。
事实上，对于技术能力比较强的团队，可以针对这些开源系统进行魔改，比如采用Kylin的预计算能力+Druid的查询引擎，来提高查询的速度等等。
1.9数据可视化及分析在数据可视化这块，一般会采取三个途径来进行数据展示。
最基础的利用开源的图表库，如国外的HighCharts、D3，百度的ECharts，还有阿里Antv的G2、G6、F2等。
往上一层是各个知名公司开源的可视化框架，如Airbnb的Superset，Redash，Metabase等等。
这些框架一般能够满足从数据源接入，自助制作报表和报表整理展示的功能，接入起来更加方便。