近来数据中台概念大火，大家对它的定义也五花八门，不一而足。但无论怎么定义，一个完善的数据技术架构必不可少。了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。
一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。框架图如下：
这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。
针对不同的数据来源有各自的采集方式，从 APP/服务器 日志，到业务表，还有各种 API 接口及数据文件等等。其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于「重点关照」的对象。目前市面针对日志采集的有 Flume，Logstash，Filebeat，Fluentd ，rsyslog 几种常见的框架，我们挑应用较广泛的前两者介绍下：
Flume 是一款由 Cloudera 开发的实时采集日志引擎，主打高并发，高速度，分布式海量日志采集。它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。Flume 支持在日志系统中定制各类数据进行发送，用于采集数据；同时，它支持对数据进行简单处理，并写到各种数据接收方。目前有两个版本，OG和NG，特点主要是：
侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景
由java开发，没有丰富的插件，主要靠二次开发
配置繁琐，对外暴露监控端口有数据
Logstash 是 Elastic.co 旗下的一个开源数据收集引擎，可动态的统一不同的数据源的数据至目的地，搭配 ElasticSearch 进行分析，Kibana 进行页面展示，是著名的 ELK 技术栈中的「L」部分。特点主要是：
内部没有一个persist queue，异常情况可能会丢失部分数据
由ruby编写，需要ruby环境，插件很多
配置简单，偏重数据前期处理，分析方便
从两者的设计思想来看，Flume 最初并不是为了采集日志而设计，而是定位在把数据传入 HDFS 中，这和 Logstash 有根本的区别。所以它理所应当侧重于数据的传输和安全，且需要更多的二次开发和配置工作。而 Logstash 明显侧重先对日志数据进行预处理，为后续的解析做铺垫。它搭配 ELK 技术栈使用起来比较简单，更像是为你准备好的便当，开盒即食。
我们以 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 中，再进行后续的一系列操作。
Kafka 最初是由领英开发，并随后于 2011 年初开源, 并于 2012 年 10 月 23 日由Apache Incubato 孵化出站。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。
数据库存储方面，有单机/分布式、关系型/非关系型、列式存储/行式存储三个维度的划分，各种维度交叉下都有对应产品来解决某个场景下的需求。
在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的 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 内部对数据的理解和使用又到了什么样的高度。
大数据处理场景可分为批处理和流处理两个，分别对应离线分析和实时分析。常见框架分类有：
仅批处理框架：Hadoop MapReduce
仅流处理框架：Storm，Samza
混合框架：Spark，Flink
篇幅所限，除了上文已经提到的 Hadoop 生态外，我们再简单科普下 Spark：
Apache Spark 是一种包含流处理能力的下一代批处理框架。
批处理模式下，Spark 与 MapReduce 不同，它将数据处理工作全部在内存中进行，计算性能大幅改善。流处理模式下，Spark 主要通过 Spark Streaming 实现了一种叫做微批(Micro-batch)的概念。该技术可以将数据流视作一系列非常小的“批”，借此即可通过批处理引擎的原生语义进行处理。这种方式的实际效果非常好，但相比真正的流处理框架在性能方面依然存在不足。
综上所述，Spark是多样化工作负载处理任务的最佳选择。Spark批处理能力以更高内存占用为代价提供了无与伦比的速度优势。对于重视吞吐率而非延迟的工作负载，则比较适合使用 Spark Streaming 作为流处理解决方案。
而 Flink 作为更新一代的处理框架，拥有更快的计算能力，更低的延迟，已经慢慢崭露头角。不过一个框架的应用，特别是开源框架，需要足够长的时间进行运行，测试和优化。大数据技术在开源社区的推动下，迭代日新月异。在不久的将来，相信 Flink 会像 Spark 取代 Storm 一样，逐渐成为大数据处理技术的主流。
经过处理后的数据，还需要有高效的查询引擎才能被用户接触和使用。目前 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 的查询引擎，来提高查询的速度等等。
在数据可视化这块，一般会采取三个途径来进行数据展示。最基础的利用开源的图表库，如国外的 HighCharts、D3，百度的 ECharts，还有阿里 Antv 的 G2、G6、F2 等。往上一层是各个知名公司开源的可视化框架，如 Airbnb 的 Superset，Redash，metabase 等等。这些框架一般能够满足从数据源接入，自助制作报表和报表整理展示的功能，接入起来更加方便。再往上一层就是商用的可视化软件，如国外的 Tableau，Qlik ，国内的 FineReport，永洪 BI 等等。这种软件需要付费，但都具备更丰富的可视化功能并提供一些技术支持，对于那些没有精力折腾可视化的公司会是个不错的选择。
理解整个图表开源生态，我们得先了解下 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 是面条，皆微小但美好。
这里主要介绍下业内比较出名的 Superset 和 metabase。前者的方案更加完善，支持集合不同数据源形成对应的指标，再通过丰富的图表类型进行可视化。在时间序列分析上比较出色，支持移动平均及周期偏移等分析方法。同时与 Druid 深度集成，可以快速解析大规模数据集。劣势则是不支持分组管理报表，一旦报表多了使用起来很麻烦。且不提供图表下钻及联动功能，权限管理也不够友好。
metabase 则比较注重非技术人员(如产品经理和运营人员)的使用体验，让他们能自由地探索数据，回答自己的问题，界面相对来讲更加美观。在权限管理上做得较为完善，甚至无需账号也可以对外共享图表和数据内容。Dashboard 支持分类，便于管理报表。劣势在时间序列分析上不支持不同日期对比，还需要自定义SQL 实现。每次查询仅能针对一个数据库查询，操作比较繁琐。
在数据挖掘这块，目前主要集中在商用公司这块，通过和某些行业深度合作，从而训练和深化自己的学习模型，这里不多赘述。