大数据产品生态
大数据技术本质上无非解决4个核心问题：
- 存储，海量的数据怎样有效的存储？主要包括hdfs、Kafka；
- 计算，海量的数据怎样快速计算？主要包括MapReduce、Spark、Flink等；
- 查询，海量数据怎样快速查询？主要为Nosql和Olap，Nosql主要包括Hbase、 Cassandra 等，其中olap包括kylin、impla等，其中Nosql主要解决随机查询，Olap技术主要解决关联查询；
- 挖掘，海量数据怎样挖掘出隐藏的知识？也就是当前火热的机器学习和深度学习等技术，包括TensorFlow、caffe、mahout等；
一、Hadoop是怎么来的？
大数据技术生态其实是一个江湖....
在一个夜黑风高的晚上，江湖第一大帮会Google三本阵法修炼秘籍流出，大数据技术江湖从此纷争四起、永无宁日...
这三本秘籍分别为：
- 《Google file system》：论述了怎样借助普通机器有效的存储海量的大数据；
- 《Google MapReduce》：论述了怎样快速计算海量的数据；
- 《Google BigTable》：论述了怎样实现海量数据的快速查询；
PDF
PDF
在Google三大秘籍流出之后，江湖上，致力于武学开放的apache根据这三本秘籍分别研究出了对应的武学巨著《hadoop》，并开放给各大门派研习，Hadoop包括三大部分，分别是hdfs、MapReduce和hbase：
- hdfs解决大数据的存储问题。
- mapreduce解决大数据的计算问题。
- hbase解决大数据量的查询问题。
之后，在各大门派的支持下，Hadoop不断衍生和进化各种分支流派，其中最激烈的当属计算技术，其次是查询技术。存储技术基本无太多变化，hdfs一统天下。
以下为大概的演进：
1，传统数据仓库派说你mapreduce修炼太复杂，老子不会编程，老子以前用sql吃遍天下，为了将这拨人收入门下，并降低大数据修炼难度，遂出了hive，pig、impla等SQL ON Hadoop的简易修炼秘籍；
2，伯克利派说你MapReduce只重招数，内力无法施展，且不同的场景需要修炼不同的技术，太过复杂，于是推出基于内力（内存）的《Spark》，意图解决所有大数据计算问题。
3，流式计算相关门派说你hadoop只能憋大招（批量计算），太麻烦，于是出了SparkStreaming、Storm，S4等流式计算技术，能够实现数据一来就即时计算。
4，apache看各大门派纷争四起，推出flink，想一统流计算和批量计算的修炼；
二、Hadoop是什么？解决了什么问题？
官方解释：hadoop是一个分布式计算框架。怎么理解？
Hadoop官方文档：https://hadoop.apache.org/docs/stable/
中文版（年代过于久远，仅供了解）：http://hadoop.apache.org/docs/r1.0.4/cn/index.html
一句简单的话，最需要深入的去理解。
这句话有两层含义：
面向用户：它是一个分布式计算，解决的传统单机计算、传统数据仓库的瓶颈，包括海量大规模数据的存储、计算和查询。对应其三大组件，HDFS解决海量的数据怎样有效的存储，Mapreudce解决海量的数据怎样快速计算，hbase解决海量数据怎样快速查询。
面向码农：它是一个框架，封装实现了分布式计算的读写问题，包括数据分片、数据一致性、计算分发等分布式计算需要考虑的共性问题，让码农只需关心分布式计算的业务逻辑实现。
事物与相同事物的比较
相信看完以上，你有一个感觉：“哇，hadoop好厉害！！好牛逼！！让人飞一般的感觉！！“。
讲hadoop的书籍、文章，基本都只会说它有多厉害，它有哪些优势，一般不说它有什么缺点。
但凡事都有优缺点！
跳出本事物，只有它跟相同事物相比较时，才会凸显它的不足和优势。
分布式计算方面，看看它与其它类似事物（spark、flink）相比的缺点，这里注意，与spark、flink相比都只是分布式计算这个组件，不包括分布式存储和分布式数据库；
分布式存储方面，hdfs与对象存储等比较的优缺点；
分布式数据库方面，hbase与mongodb、cassandra等分布式数据库的比较；
资源调度方面，yarn应该是mesos、k8s等比较
1. 大数据存储之Hadoop HDFS
大数据处理的第一步自然是要先找到一个存放数据的地方。HDFS提供的便是海量文件的存储技术。
HDFS是谷歌GFS技术的开源实现版本。HDFS将文件分成块分布到不同的机器上，从而借助成千上万台廉价PC实现海量数据的高可靠性存储。
在HDFS中，一份文件会拥有多份分布在不同机器上的复制，因此即使某台机器坏了数据也不会丢失，具备极高的可靠性。
尽管HDFS使用了很多复杂的分布式存储技术，但是对用户来说，使用HDFS和使用以往的文件系统一样简单。用户不用关心文件是如何分块的或者文件存储在集群的哪个节点上这种问题，只需要连上HDFS，之后像使用Linux本地文件系统一样使用HDFS即可。
2.大数据计算之Hadoop MapReduce
数据有地方存了，接下来要做的当然是对数据进行分析了。
Hadoop MapReduce和Google的MapReduce一样，提供海量数据的分布式处理能力。通过MapReuduce，成百上千台机器可以共同协作去计算同一个问题，从而依靠大量机器的共同力量去解决海量数据的计算问题。
MapReduce通过Map和Reduce两个主要阶段。在Map阶段，MapReuce把数据划分成很多个部分读入，然后将数据解析成方便计算和key-value形式。在Reduce阶段，数据按照key的不同被再次划分到不同的机器，然后每台机器格子对数据进行聚合计算，最终形成用户期望的计算结果。下边一张图可以让你对MapReduce的过程有一个更形象的认识：
MapReduce过程
MapReduce实际的计算流程要比上边描述的复杂的多，而你只要记住，MapReduce解决的本质问题就是如何将数据合理的分布到很多台机器上进行计算，以及如何合理的合并多台机器上的计算结果。
Pig：
通过编写MapReduce脚本已经可以借助大数据手段解决几乎所有的海量数据的计算和分析问题。但是，MapReduce存在一个严重的问题，那就是MapReduce脚本编写起来实在是太费劲了！想编写MapReuce程序，你首先需要弄懂MapReduce的原理，合理的把计算过程拆分成Map和Reduce两步，然后你还需要正确的配置一大堆MapReduce的执行参数，之后提交任务，反复检查运行状态，检查运行结果，这时候如果你的MapReduce脚本存在问题，那么你还需要去翻log分析问题出在哪里，然后修改你的脚本再来一遍。因此，想写出一个能用的MapReduce程序不但有较高的难度，还需要耗费大量的时间和精力。
那么，如果我很懒，实在不想去写复杂的MapReduce程序，那么有没有什么办法能够简化写MapReduce的这个繁杂的过程呢？当然有，那就是Pig了（此时你一定明白Pig这个名称的由来了，就是为懒人服务的工具）。Pig的意义就是替你编写复杂的MapReduce脚本，从而简化MapReduce的开发流程，大大缩短开发周期。
Pig实现了一种叫做Pig Latin的语言，你只需要编写简单的几行Latin代码，就可以实现在MapReduce需要大量代码才能实现的功能。Pig帮你预设了多种数据结构，从而帮助你方便的将输入文本中的内容转换为Pig中结构化数据。Pig还提供了诸如filter、group by、max、min等常用的计算方法，帮助你快速实现一些常规的数据计算。执行和查看结果在Pig中也非常的简单，你不再需要配置MapReduce中的一大堆复杂的参数，也不再需要手动到HDFS上下载运行结果并对下载结果进行排版，Pig会直接把运行结果用良好的排版展示给你看，就像在SQL数据库中一样方便。
有了Pig，不用写MapReduce了，数据开发也快多了。但是Pig仍然存在一些局限，因为使用Pig从本质上来说还相当于用MapReduce，只是脚本的编写比以前快了，但是你仍然要一行一行的去写Pig脚本，从而一步一步的实现你的数据分析过程。此时如果有工程师说自己已经懒得无可救药了，连Pig脚本也不想写；或者有数据分析师说自己不懂技术，压根不会写脚本，只会写几句简单的SQL，那么有没有什么比Pig还简单的办法呢？那么下边就该Hive出场了！
Hive：
Hive是一种数据仓库软件，可以在分布式存储系统的基础之上（例如HDFS）构建支持SQL的海量数据存储数据库。
简单的说，Hive的作用就是把SQL转换为MapReduce任务进行执行，拿到结果后展示给用户。如此一来，你就可以使用普通的SQL去查询分布在分布式系统上的海量数据。
尽管Hive能提供和普通SQL数据库一样好用的SQL语句，但是Hive的查询时延是要远高于普通数据库的，毕竟查询时间和数据规模二者还是不能兼得的啊！由于Hive并且每次查询都需要运行一个复杂的MapReduce任务，因此Hive SQL的查询延时是远高于普通SQL的。与此同时，对于传统数据库必备的行更新、事务、索引这一类“精细化”操作，大条的Hive自然也都不支持。毕竟Hive的诞生就是为了处理海量数据，用Hive处理小数据无异于杀鸡用牛刀，自然是无法得到理想的效果，因此，Hive只适合海量数据的SQL查询。
Spark
有了Hive，不会编程的你也能用SQL分析大数据了，世界似乎已经美好了很多。可惜好戏不长，慢慢的，你还发现Hive依旧有一堆的问题，最典型的问题就是查询时延太长（这里特指MapReduce Hive，而非Spark Hive）。受限于MapReduce任务的执行时间，查一次Hive快则几十分钟，慢则几小时都是有可能的。试想领导着急的问你还要报表，而你只能无奈的等待缓慢的Hive查询运行完，此时的你一定急的想砸显示屏了。那么有没有什么既好用，又执行迅速的大数据工具呢？下边就该我们的新星级产品Spark登场了。
与MapReduce类似，Spark同样是分布式计算引擎，只是Spark的诞生要比MapReduce晚一些，但是Spark后来者居上，如今在很多领域都大有取代MapReduce的趋势。
Spark相较于MapReduce最大的特点就是内存计算和对DAG模型的良好支持，借助这些特点，对于计算任务，尤其是需要分很多个阶段进行的复杂计算任务，Spark的执行速度要远远快于MapReeduce。
在MapReduce执行过程中，需要将中间数据先写入到磁盘中，然后再加载到各个节点上进行计算，受限于巨大的磁盘IO开销，MapReduce的执行经常要很长时间。而Spark则是将中间数据加载在内存中，因此能取得远高于MapReduce的执行速度。
Spark的优点还远不止此。相较MapReduce，Spark提供了很多高层次封装的功能，在易用性上和功能丰富程度上都要远远高于MapReduce。用Spark你甚至只需要一行代码就能实现group、sort等多种计算过程。这点上Spark可以说是同时融合了Pig和Hive的特点，能够用简单几行代码实现以往MapReduce需要大量代码才能实现的功能。下边来一行Spark代码让大家感受下：
val wordCounts = textFile.flatMap(line => line.split(" ")).groupByKey(identity).count()
以上代码实现Word Count。
除此之外，Spark还支持Python、Scala、Java三种开发语言，对于Python和Scala甚至还提供了交互式操作功能，对于非Java开发者以及科研工作者真是友好到爆，事实上Spark确实也广受科研工作者的欢迎。
新版本的Spark还提供了Spark SQL、Spark streaming（后边会介绍）等高层次的功能，前者提供类似Hive的SQL查询，后者提供强大的实时计算功能（后边会详细介绍），大有一统大数据分析领域的趋势。因此Spark绝对是当今发展势头最好的大数据组件之一。
不过Spark也并非真的就无敌了，内存计算的特点还是会对Spark能够应对的数据规模产生影响。另外，对于计算过程的控制和调优，Spark也不如MapReduce灵活。
Storm
有了前边讲的这一系列工具，我们已经能够对海量数据进行方便的计算分析了。但是前边的这些工具，从基础的MapReduce到简单易用的Hive，都依然存在一个问题，那就是计算过程需要较长的时间。也就是说，从你开始执行数据分析任务，到MapReduce生成你要的结果，常常需要若干小时的时间。由于这个延时的存在，MapReduce得到的数据分析结果是要比线上业务慢半拍的，例如今天得到昨天的日志分析结果，也因此，MapReduce又被称作离线数据处理或者批处理。
但是，如果你希望能够立刻得到数据的分析结果，例如像天猫双十一实时大屏那样实时的显示最新的成交额，那么你就需要一些实时数据处理工具了。
最新火起来的实时数据处理工具要当属Apache Storm了。我们直到在MapReduce这类离线处理工具中，数据是要一批一批的被处理的，并且每批数据都需要一定的处理时延。而在Storm中，是没有批这个概念的，在Storm中数据就如同水龙头中的水一样源源不断地流出，并被实时的进行处理。因此，在Storm中，只要你搭建好了数据处理流程，数据就会源源不断的，永不停止的被接受并处理，并且你可以随时看到数据的最新处理结果。
Storm
尽管Storm和MapReduce的处理流程差异很大，但是它们的基本思路是一致的，都是把数据按照key分散到不同的机器上，之后由各个机器对数据进行处理，最终将各个机器的计算结果汇总在一起。
不同的是，Storm中的数据处理是一条一条实时进行的，因此结果会处于一种不断的刷新过程中；而MapReduce是一次性处理完所有输入数据并得到最终结果，因此你将会直接看到最终结果。
例如，假设有大量的文章需要统计单词的出现次数，对于MapReduce，你将直接看到最终结果：hello: 3, world: 2, you: 6；而对于Storm，你将会看到hello:1, world:1, you: 1, world: 2, you:2……这样的处于不断刷新中的统计结果。
另外值得一提的是，Storm和MapReduce也并不是一个互相取代的关系，而是一个互补的关系。Storm可是让你实时的得到数据的最新统计状态，但是在数据吞吐量方面是要低于MapReduce的，并且对于相同的数据量，如果只关注最终结果，MapReuce得到最终结果所需的时间和资源肯定是要小于Storm的。因此，如果你需要实时的查看数据的最新统计状态，用Storm；如果你只关注数据的最终统计结果，用MapReduce。
Flink和Spark Streaming
谈完Storm，就必须顺带也谈一下另外两种同样火爆的实时数据处理工具，那就是Flink和Spark Straming。这两种技术要晚于storm诞生，但是现在大有后来者居上的趋势。
Flink与Storm非常类似，都能够提供实时数据流处理功能。区别在于Flink还能够支持一些更高层的功能，例如group by这种常用算法。另外，Flink还具备比Storm更高的吞吐量和更低的延时，这是因为Flink在处理完一条条数据的时候是分组批量确认的，而Storm则是一条一条确认。Flink的这种特性带来了很大的性能优势，但是也会对单条数据的处理时延带来很大的不稳定因素，因为任何相邻数据的处理失败都会导致整组数据被重新处理，从而严重影响一组数据的处理时延。因此，如果你追求更高的吞吐量，可以选择Flink，如果你对每条数据的处理时延都有极高的要求，那么选Storm。
至于Spark Streaming，其实并不能算得上是纯正的实时数据处理，因为Spark Streaming在处理流数据时依然用的是批处理的模式，即凑齐一批数据后启动一个Spark任务得到处理结果。你甚至可以把Spark Streaming简单看成是带流输入的Spark。得益于Spark任务执行快速的优点，尽管Spark Streaming是一种伪实时处理系统，但是依然能得到还不错的实时性（秒级），当然要跟Storm比的话实时性还是差不少的，但是Spark在吞吐量方面要强于Storm。
Spark Streaming和Flink除了吞吐量这个优点外，还有另一个重要的优点，那就是能够同时支持批处理和实时数据处理。也就是说，你只需要一套系统就能够同时分析你的实时数据和离线数据，这对于架构精简（tōu lǎn）来说是大有好处的。
三、大数据平台与数据中台的介绍
本文主要介绍大数据平台与数据中台的关系，以及市面主流产品的架构、功能与差异。
前述：今年听到最多的，新经济玩不动了，企业喊的要转型，怎么转？上云，做中台；怎么做，进阿里生态。作为阿里，阿里定义的中台战略，及以中台为抓手，拉企业上云，没有产品，企业为什么要上云。战略必定要以产品为支撑，产品必须为战略服务。具体产品体现为计算存储、数据中台、应用平台。作为厂商，大家都把阿里当渠道商，一家大了，必定很难受。但没办法，就他玩的好，跟着做吧，做了，会死；不做，等死，试试吧。
1、数据中台
数据中台是数据资产化和价值化体系。它致力于构建既“准”且“快”的“全”“统”“通”的“智能”大数据体系；它在数据赋能业务中形成业务模式，在推进数字化转型中实现价值。部分企业内部将数据中台及其业务模式产品化，提供数据中台智能化解决方案。数据中台由数据资产平台、基础技术平台、数据构建与管理平台、数据服务平台组成。阿里云数据中台解决方案如下图示。
说白了，阿里定义的中台战略，及以中台为抓手，拉企业上云，具体产品体现为计算存储、数据中台、应用平台，其中包括以下内容。
- 应用平台：经营分析场景QuickBI、营销场景Quick Audience
- 数据中台：数据采集与研发、数据连接与萃取、数据资产管理
- 计算与存储：Maxcompute、Hadoop、EMR。
在这里日志做分发的时候用Flink、Blink，做离线计算时使用Maxcompute，QA是做人群标签与人群洞察，QBI抄了BI报表工具，按各家买了的金主的反馈，各个都是眼角含着泪：好不好用，谁用谁知道。
阿里内部的两款大数据开发套件，Datawork与Dataphin，以及市面上的竞对，竞争优势，各有不同。
在实施层面，第一步，先进行服务器的采购，虚拟机的创建。第二步骤，购买大数据开发平台，类似市面上阿里的Dataworks，Dataphin，袋鼠的数栈，数澜的数栖平台。第三步，包括了数据开发、算法开发、数据共享服务开发，在这里，可以引入ISV厂商做实施。第四步，即为数据应用的建设，其中包括了数据分析、可视化大屏、用户画像、标签工厂。往往你告诉客户，数据中台是方法论，客户不认，需要在应用层面找价值，这也是当前在交付层面，遇到阻力比较大的问题,阿里的P8 PPT里的三级火箭、五朵金花、以面找点，以点破面的概念，在客户交付面前，都显得有些苍白无力。
2、来源与分析
先说对比与结论，在依依展开产品介绍与对比。
一开始大数据开发套件，部分厂商做的相对比较简单，与星环这种独立做计算引擎厂商不同，就是单纯的RD-OS封装Hadoop，Spark。后来进行产品的不断完善，在PaaS层进行开源的深度封装，其中包括了离线计算Spark ，实时计算Flink，产品变得可视化，便捷，具有可操作性。Cloudera是对Hadoop做了封装，各家数据平台厂商在基础上，做封装发行版，封装Hadoop后变成傻瓜式安装。
在产品上来说，Dataworks相对比较成熟，基于阿里自研的Maxcompute计算引擎，也就是原来的ODPS，在完全自主知识产权的基础上，面向项目停供数据平台软硬件服务，当然这个也比较贵，大概在1000w左右。
Dataphin使用了基于阿里自研的Maxcompute计算引擎，同时还带了开源的Hadoop引擎，主打的定位也不一样，在用户不愿选择封住后的Maxcompute，可以选择开源Hadoop，价格不高，大概500w左右，虽然今年阿里主推该产品，但是相对不是很成熟，萃取模块还是有很大的问题。
在部署上，阿里的Maxcompute，Dataworks底座是CDN，硬件是30台-50台，早期甚至是上百台，非常的吃资源，开销非常大。
部分厂商，采用服务器的轻部署，不限制服务器、ECS的数量，10台以下，小型机。物理服务器，8核16g。每个企业的数据量，会把5台扩到20台，由于是分布式的，所以扩展起来，也比较方便。
3、大数据平台Dataphin
Dataphin是一款集成了阿里巴巴集团OneData理念的产品，定位为智能大数据构建与管理平台，旨在通过提供智能数仓规划、数据引入、数据规范定义、数据建模研发、数据连接萃取、数据资产管理、数据主题式服务的全链路、一站式产品+技术+方法论服务，助力客户高效、优质完成数据中台最核心的大数据建设工作。
3.1、Dataphin产品
在产品层面，Dataphin产品由四部分组成，分别是技术内核、工具层、数据层和管理服务层。
- 技术内核，一套屏蔽底层计算、存储、软件系统差异的技术框架，保证数据研发可兼容多计算引擎与计算时效，代码自动化生成并实现智能存储与计算，数据服务支持混合存储等。
- 工具层，面向开发者的数据构建与管理的工具，包括基础数据的标准规范及集成引入，公共数据的标准规范定义、智能建模研发、调度运维及机器学习，萃取数据的ID识别连接及标签生产。
- 数据层，在技术内核基础上，通过工具加工生产，输出三种层次的结构化数据，构建出高保真、面向各业务的基础数据中心，模型化、面向主题的公共数据中心，深度加工、以实体为中心的萃取数据中心。
- 管理及服务层，将数据及数据服务以资产化视角进行管理，以支持数据研发人员及业务人员都可以获取高质量且统一的数据资产;从业务视角将已有数据包装加工为主题式的数据服务，以保障业务可以统一地查询 与调用数据。
3.2、Dataphin技术
在技术层面上，DataPhin私有化部署技术架构自下而上由五部分组成，分别是存储集群、Mesos调度集群、Master集群、Worker集群和最上层的访问层。
- 存储集群，从各个业务系统数据源离线采集的业务数据采用阿里云MaxCompute进行存储；DataPhin平台中涉及的所有非结构化数据采用OSS进行存储；Dataphin用户行为审计日志和系统错误日志采用SLS日志服务进行存储；DataPhin平台相关的账号、权限、各种任务配置运行及数据规范定义等元数据采用RDS关系数据库PostgreSQL进行存储；对于DataPhin平台经验使用的账号权限等热点数据采用Redis进行缓存以提升效率。
- 调度集群，采用3个高规格（24C96G）云服务器节点组成，由Apach Mesos分布式资源管理服务和Zookeeper负责分布应用协调服务混布方式组成，Mesos负责整个集群的资源管理和调度，Zookeeper负责应用配置管理和一致性同步。
- Master集群，采用由规格为4C8G的云服务其部署组成3节点的Master控制集群。
- Worker集群，采用由规格为12C48G的云服务器部署组成多节点的Worker工作集群，负责DataPhin任务的执行。
- 访问层，采用阿里云SLB负载均衡和DNS服务，作为Dataphin平台的统一访问入口。
3.2.1、离线流处理
- 业务系统数据接入，直接使用DataPhin数据引入功能，配置批量数据同步任务，定时将数据同步业务系统数据同步到数据中台ODS层的数据缓冲区存储。
- 日志数据接入，针对不同类型或接口的日志数据定制化开发日志搜集的应用，通过此日志收集应用对接日志数据，并定期将日志数据转换成固定格式可解析的文件存储到OSS对象存储中，再通过DataPhin数据引入功能，将OSS对象存储中半结构化的日志数据，定期同步至数据中台ODS层的数据缓冲区存储。
- 第三方数据接入，针对不同API接口的提供的外部数据，通过定制开发程序定期通过API接口获取外部数据写入用于存储第三方数据汇总的RDS关系数据库，再定期通过DataPhin数据引入功能将此RDS关系数据库的数据同步至ODS层的数据缓冲区存储。
在数据进入数据中台ODS层的数据缓冲区后，针对每天全量同步或每天增量同步的数据在进入ODS层的数据服务区时，针对全量同步的数据会对数据进行统一的数据类型转换处理再存入数据服务区的每日全量数据分区，针对增量同步的数据会对数据进行统一的数据类型转换处理的同时还会对前一天全量数据和当天的增量数据进行数据合并后再存入数据服区。
进入数据中台ODS层的数据服务区后的数据，可以提供给CDM层或ADS层进行数据加工处理。CDM层会从ODS层的数据服务区获取维度和事实数据经过转换后按照新的数据模型分别存入DIM维度表和DWD明细事实表。基于公共汇总指标的需求，基于CDM层的DIM维度数据和DWD明细事实数据，加工生成汇总统计数据存储DWS汇总事实表。
ADS层的数据一般优先来源于CDM通用数据模型层数据，但对于一些特殊应用的个性化数据需求或复杂数据需求，可直接从ODS层的数据服务层取数据加工后生成ADS层直接面向业务的数据。
最后ADS应用层和CDM公共层的数据同步至数据接口服务层的在线存储产品，通过统一的数据接口服务层，为上层的数据应用和业务系统提供统一的数据服务。
3.2.2、实时流处理
针对不同的数据源，阿里云DTS实时数据传输服务和定制化开发的日志搜集应用，分别从关系数据库和其他数据源类型（如数据API）实时获取数据，将数据实时写入阿里云DataHub存储。
在数据写入DataHub后，针对需要实时计算的业务场景，通过阿里云StreamCompute流计算引擎实时进行运算，将运算后的结果数据，推送到数据接口服务层，提供给数据应用和业务系统使用。
很多场景需要将实时数据流产生的数据保存下来供离线计算使用，采用定期对DataHub的数据进行归档存储到数据中台ODS层的数据缓冲区。数据存入ODS层的数据缓冲区后，后续的数据加工及流转过程和离线数据流相同
4、大数据平台DataWorks
DataWorks（数据工场，原大数据开发套件）是阿里云重要的PaaS平台产品，为您提供数据集成、数据开发、数据管理、数据质量和数据服务等全方位的产品服务，一站式开发管理的界面，帮助企业专注于数据价值的挖掘和探索。
DataWorks基于MaxCompute作为核心的计算、存储引擎，提供海量数据的离线加工分析、数据挖掘等功能。
- 全面托管的调度
DataWorks提供强大的调度能力，支持根据时间、依赖关系，进行任务触发的机制。同时支持每日千万级别的任务，根据DAG关系准确、准时地运行。支持分钟、小时、天、周和月多种调度周期配置。完全托管的服务，无需关心调度的服务器资源问题。提供隔离功能，确保不同租户之间的任务不会相互影响。
- 支持多种节点类型。
DataWorks支持数据同步、Shell、MaxCompute SQL、MaxCompute MR等多种节点类型，通过节点之间的相互依赖，对复杂的数据进行分析处理。 数据转化：依托MaxCompute强大的能力，保证了大数据的分析处理性能。
据同步：依托DataWorks中数据集成的强力支撑，支持超过20种数据源，为您提供稳定高效的数据传输功能。
- 可视化开发
DataWorks提供可视化的代码开发、工作流设计器页面，无需搭配任何开发工具，简单拖拽和开发，即可完成复杂的数据分析任务。只要有浏览器有网络，便可随时随地进行开发工作。
- 监控公告
运维中心提供可视化的任务监控管理工具，支持以DAG图的形式展示任务运行时的全局情况。
四、数据人必须了解的大数据中台技术架构
近来数据中台概念大火，大家对它的定义也五花八门，不一而足。但无论怎么定义，一个完善的数据技术架构必不可少。了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。 因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。
一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。框架图如下：
1. 数据采集传输
这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。
针对不同的数据来源有各自的采集方式，从 APP/服务器 日志，到业务表，还有各种 API 接口及数据文件等等。其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于「重点关照」的对象。目前市面针对日志采集的有 Flume，Logstash，Filebeat，Fluentd ，rsyslog 几种常见的框架，我们挑应用较广泛的前两者介绍下：
1.1 Flume 和 Logstash
Flume 是一款由 Cloudera 开发的实时采集日志引擎，主打高并发，高速度，分布式海量日志采集。它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。Flume 支持在日志系统中定制各类数据进行发送，用于采集数据；同时，它支持对数据进行简单处理，并写到各种数据接收方。目前有两个版本，OG和NG，特点主要是：
- 侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景
- 由java开发，没有丰富的插件，主要靠二次开发
- 配置繁琐，对外暴露监控端口有数据
Logstash 是 http://Elastic.co 旗下的一个开源数据收集引擎，可动态的统一不同的数据源的数据至目的地，搭配 ElasticSearch 进行分析，Kibana 进行页面展示，是著名的 ELK 技术栈中的「L」部分。特点主要是：
- 内部没有一个persist queue，异常情况可能会丢失部分数据
- 由ruby编写，需要ruby环境，插件很多
- 配置简单，偏重数据前期处理，分析方便
从两者的设计思想来看，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 数据传输 Kafka
Kafka 最初是由领英开发，并随后于 2011 年初开源, 并于 2012 年 10 月 23 日由Apache Incubato 孵化出站。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。
2. 数据存储
数据库存储方面，有单机/分布式、关系型/非关系型、列式存储/行式存储三个维度的划分，各种维度交叉下都有对应产品来解决某个场景下的需求。
在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的 MySQL。数据量大到一定程度后，就必须采取分布式系统了。目前业界最知名的就是 Apache 基金会名下的 Hadoop 系统，它基本可以作为大数据时代存储计算的经典模型。
HDFS
HDFS 作为 Hadoop 里的分布式文件系统，为 HBase 和 Hive 们提供了高可靠性的底层存储支持，对应于 Google GFS 的开源实现。一般也会用于一些批次分析的场景。
HBase
HBase 是 Hadoop 数据库，作为基于列的非关系型数据库运行在 HDFS 上。它具备 HDFS 缺乏的随机读写能力，因此比较适合实时分析。HBase 以 Google BigTable为蓝本，以 Key-Value 形式存储，能快速在主机内数十亿行数据中定位所需的数据并访问它。
Hive 和 Pig
Hive 和 Pig 都是集成在 Hadoop 顶层的查询语言，提供静态数据的动态查询，支持类 SQL 语言，底层经过编译转为 MapReduce 程序，省去了自己编写 MR 程序的繁琐。区别是 Hive SQL 是类 SQL 的查询语言，要求数据存储于表中，而 Pig 是面向数据流的一个程序语言，常用于开发简洁的脚本来转换数据流从而嵌入到较大的应用程序中。
MapReduce
MR 开创了分布时代计算的先河，使得大批量数据处理成为可能。简单来讲，就是将比较庞大的计算任务先分组，再汇总，提高计算效率。举例来讲，如果你新家需要装修，要在不同地方购置很多东西。你一个人（单机）去买估计得花十天。现在叫了一堆小伙伴（分布式），每个人负责去一个地方买东西（Map），最后再拿到家里分类汇总（Reduce），一天就搞定了。
其他辅助工具
上图中的其他工具是为了保证整个大数据计算存储系统更加健壮和开放，如 Zookeeper 提供了稳定服务和 failover 机制，Sqoop 则为 Hadoop 提供了方便的 RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向 HBase 中迁移变的非常方便。
值得一提的是，Hadoop 生态其实是建立在 Google 2003 年发表的三大论文的基础之上。可能是当时 Google 有意改善业内落后的现状，让大家稍微跟得上他的脚步才发布的论文…这么多年过去了，不知道 Google 内部对数据的理解和使用又到了什么样的高度。
3. 数据计算&查询
3.1 批计算和流计算
大数据处理场景可分为批处理和流处理两个，分别对应离线分析和实时分析。常见框架分类有：
- 仅批处理框架：Hadoop MapReduce
- 仅流处理框架：Storm，Samza
- 混合框架：Spark，Flink
篇幅所限，除了上文已经提到的 Hadoop 生态外，我们再简单科普下 Spark：
3.2 Spark 和 Flink
Apache Spark 是一种包含流处理能力的下一代批处理框架。
批处理模式下，Spark 与 MapReduce 不同，它将数据处理工作全部在内存中进行，计算性能大幅改善。流处理模式下，Spark 主要通过 Spark Streaming 实现了一种叫做微批（Micro-batch）的概念。该技术可以将数据流视作一系列非常小的“批”，借此即可通过批处理引擎的原生语义进行处理。这种方式的实际效果非常好，但相比真正的流处理框架在性能方面依然存在不足。
综上所述，Spark是多样化工作负载处理任务的最佳选择。Spark批处理能力以更高内存占用为代价提供了无与伦比的速度优势。对于重视吞吐率而非延迟的工作负载，则比较适合使用 Spark Streaming 作为流处理解决方案。
而 Flink 作为更新一代的处理框架，拥有更快的计算能力，更低的延迟，已经慢慢崭露头角。不过一个框架的应用，特别是开源框架，需要足够长的时间进行运行，测试和优化。大数据技术在开源社区的推动下，迭代日新月异。在不久的将来，相信 Flink 会像 Spark 取代 Storm 一样，逐渐成为大数据处理技术的主流。
3.3 数据查询
经过处理后的数据，还需要有高效的查询引擎才能被用户接触和使用。目前 OLAP 的查询技术框架大致可分为三类：
- 基于 HBase 做预聚合：如 Opentsdb, Kylin 等，均需指定预聚合的指标，在数据接入的时候进行聚合运算，适合相对固定，维度较多的业务报表类需求
- 基于 Parquet 做列式存储：如 Presto, Drill，Impala 等，基本是完全基于内存的并行计算，Parquet 系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的 Join 支持可能不够好
- 基于 Lucene 做外部索引：如 ElasticSearch，Solr 等，能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋
我们以常见的 Presto，Druid，Kylin 三个模型来讲讲各自的特点：
- Presto：由 Facebook 开源，是一个分布式数据查询框架，原生集成了 Hive、 Hbase 和关系型数据库。它背后所使用的执行模式与Hive有根本的不同，并没有使用 MapReduce。因其所有的处理都在内存中完成（与上文的 Spark 类似），大部分场景下要比 Hive 快一个数量级
- Druid：由 MetaMarket 开源，是一个分布式、面向列式存储的准实时分析数据存储系统，延迟性最细颗粒度可到 5 分钟。它能够在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、分析与可视化功能
- Kylin：Cube 预计算技术是其核心，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。劣势在于每次增减维度必须对 Cube 进行历史数据重算追溯，非常消耗时间。据说 Kylingence 在前几天的新品发布会上已经解决了这个问题，拭目以待
下图引自快手在 OLAP 技术选型时的评价，以供大家参考：
很多时候，在计算和查询这块没有明显的边界区分。这里为了方便阐述分成了两个部分。事实上，对于技术能力比较强的团队，可以针对这些开源系统进行魔改，比如采用 Kylin 的预计算能力+Druid 的查询引擎，来提高查询的速度等等。
4. 数据可视化及分析
在数据可视化这块，一般会采取三个途径来进行数据展示。最基础的利用开源的图表库，如国外的 HighCharts、D3，百度的 ECharts，还有阿里 Antv 的 G2、G6、F2 等。往上一层是各个知名公司开源的可视化框架，如 Airbnb 的 Superset，Redash，Metabase 等等。这些框架一般能够满足从数据源接入，自助制作报表和报表整理展示的功能，接入起来更加方便。再往上一层就是商用的可视化软件，如国外的 Tableau，Qlik ，国内的 FineReport，永洪 BI 等等。这种软件需要付费，但都具备更丰富的可视化功能并提供一些技术支持，对于那些没有精力折腾可视化的公司会是个不错的选择。
4.1 图表库
理解整个图表开源生态，我们得先了解下 SVG 和 Canvas 这两个浏览器提供的原生能力。SVG 全称叫可缩放矢量图，跟 HTML 一样，有自己的命名空间，使用 XML 标签来绘图。而 Canvas 是 HTML5 中的新标签，用于客户端的图形绘制，有一个基于 JavaScript 的绘图 API。
D3.js 全称是 Data-DrivenDocuments，支持 SVG 和 Canvas。相对于其他产品，它更偏底层，并没有对图表进行归类。开发者可以通过 D3 丰富的类库来方便的操作 DOM，绘制任何想绘制的图形，以增加开发复杂度的代价，覆盖更加全面的可视化场景。
而国外的 HighCharts 是基于 SVG 开发的图表库，ECharts 和 G2 则均基于 Canvas。ECharts 有完整的图表封装，开箱即用，而 G2 则是一套基于可视化编码的图形语法，以数据驱动，具有高度的易用性和扩展性。阿里后续基于 G2 又往上封装了一套基于 React 的图表库 Bizcharts，主打电商业务图表可视化，沉淀电商业务线的可视化规范。在 React 项目中实现常见图表和自定义图表。
ECharts 和 G2 的对比可借用 ECharts 作者的一句话，G2 是面粉，ECharts 是面条，皆微小但美好。
4.2 可视化框架
这里主要介绍下业内比较出名的 Superset 和 Metabase。前者的方案更加完善，支持集合不同数据源形成对应的指标，再通过丰富的图表类型进行可视化。在时间序列分析上比较出色，支持移动平均及周期偏移等分析方法。同时与 Druid 深度集成，可以快速解析大规模数据集。劣势则是不支持分组管理报表，一旦报表多了使用起来很麻烦。且不提供图表下钻及联动功能，权限管理也不够友好。
Metabase 则比较注重非技术人员（如产品经理和运营人员）的使用体验，让他们能自由地探索数据，回答自己的问题，界面相对来讲更加美观。在权限管理上做得较为完善，甚至无需账号也可以对外共享图表和数据内容。Dashboard 支持分类，便于管理报表。劣势在时间序列分析上不支持不同日期对比，还需要自定义SQL 实现。每次查询仅能针对一个数据库查询，操作比较繁琐。
在数据挖掘这块，目前主要集中在商用公司这块，通过和某些行业深度合作，从而训练和深化自己的学习模型，这里不多赘述。
文章的最后，鸣谢网络上各位知识的分享者，以下是主要参考内容的链接，大家可以自行查阅。本人非技术出身，所有资料均系网上整理而成，是互联网的自由分享精神让这篇文章成为可能。同时，特别鸣谢转转数据技术负责人军哥友情斧正。如还有纰漏之处，欢迎留言指教。
参考文章：
浙公网安备 33010602011771号