自从像AWS这样的公共云产品开辟了大数据分析功能以来，小企业通过挖掘大量的数据做到只有大企业才能做到的事情，至今大约有10年时间。这些事情其中包括网络日志、客户购买记录等，并通过按使需付费的方式提供低成本的商品集群。在这十年中，这些产品蓬勃发展，涵盖了从实时(亚秒级延迟)流媒体式分析到用于分析批量模式工作的企业数据仓库，而企业数据仓库则可能需要数天或数周才能完成。

以下将介绍用于大数据堆栈的五个最有用的架构，以及每个架构的优点，以便更好地理解和权衡。此外，还对成本(按$ - $$$$$的规模)、何时使用、热门产品，以及每种架构的提示和技巧进行了阐述。

五个大数据架构

在此并没有什么特别的顺序，用户在AWS公共云旅程中可能遇到的五个顶级大数据架构是：

流媒体- 允许摄取(并可能分析)任务关键型实时数据，这些数据可能会以爆发的形式出现在用户面前。通用(或特定)的批处理集群—在可扩展、经济高效的集群中提供通用存储和计算功能，可以执行其他四种架构的任何和所有功能。NoSQL引擎 - 使架构师能够处理“3V” —高速度、高容量，以及底层数据的多样性/可变性。企业数据仓库(EDW) - 允许组织为多年的历史数据维护一个单独的数据库，并对该数据运行各种长期运行的分析。就地分析 - 允许用户将数据“就地”保存在低成本存储引擎中，并针对该数据运行高性能的即席查询，而无需创建单独的、昂贵的“集群”。

1. 流媒体

流媒体解决方案由以下多个因素定义：

关键任务数据—即使丢失一笔交易也会给用户带来灾难性的后果。负载中的爆发尖峰——物联网的基础设施可能会从完全无声的状态转变为同时与其通话设备中的一个。实时响应 - 高延迟响应对用户来说可能是灾难性的。

这里有很多现实世界的例子，从特斯拉公司的电动汽车(基本上是移动的4G设备)不断将汽车的位置发送到数据中心，通知司机下一个充电站在哪里。此外，人们喜欢的日本一家高度自动化的寿司专营店：Sushiro。Sushiro所做的是将RFID传感器放在每个寿司盘底，然后，寿司传送带上的传感器跟踪每个盘子的动态，将数据点发送到AWS Kinesis，其后端响应仪表板的更新，通知寿司厨师，例如“丢掉即将过期变质的食物，或者制作更多的鸡蛋寿司，或者解冻更多的金枪鱼”，通过使用流媒体技术，该连锁店不仅有上述的实时效率推荐，而且还可以获得每家餐厅的历史信息，并且可以了解顾客购买的趋势。

Sushiro是一个很好的例子，因为它符合流媒体的所有三个要求。其仪表板现在对业务运营至关重要。

成本：$$ - $$$$$(通常为RAM密集型)适用性：任务关键型数据，负载爆发尖峰，实时响应。用户需要构建KPI的实时仪表板。注意事项：独立的流媒体解决方案的构建和维护成本很高。扩展可能具有挑战性，特别是如果在EC2上构建。失败对企业来说可能是灾难性的，但大多数产品都提供故障保护，例如复制优化、备份和灾难恢复，以避免这种情况。受欢迎的产品：Kinesis(托管服务)，Kafka(基于EC2)，Spark Streaming(作为托管服务和基于EC2)和Storm。提示和技巧：使用Kinesis作为初学者(易于使用、体积小、成本低)。许多组织转向基于EC2的Kafka(如果他们只需要流媒体)或Spark Streaming，以获得更好的控制，并降低大批量成本。这是AWS中为数不多的几次托管任务，像Kinesis这样的托管服务最终会比基于EC2的Kafka解决方案花费更多的费用。

2. 通用(或特定)的批处理集群

使用Hadoop/Spark这些系统，用户可以获得高度可扩展、低成本(商用硬件和开源软件)存储和计算，这些存储和计算可能会遇到大量问题，从而以尽可能低的成本对数据进行批量分析。

Hadoop技术非常成熟，提供了一个非常丰富的软件生态系统，可以利用这些通用计算和存储资源提供从数据仓库到流媒体，甚至NoSQL的所有内容。

在Hadoop之上，现在可以运行Spark，它带有自己的可扩展框架，以低延迟(高内存)方式提供上述所有功能，甚至适用于流媒体和NoSQL。

成本：$ - $$$$(高度依赖于内存需求)适用性：最低成本、最大灵活性。如果希望采用一个集群完成所有任务，并从Hadoop或Spark内部部署转移，那么这是一个不错的选择，非常适合机器学习。注意事项：一个全能的系统很少把每件事都做好，但这可以通过使用Spark和为每个工作量身定制的集群来大大减轻工作负荷。热门产品：EMR(托管服务，也将运行Spark)，Cloudera(基于EC2)，Hortonworks(通过EMR作为托管服务，基于EC2)。提示和技巧：在S3存储桶中长期存储源数据，构建集群，并根据需要将数据加载到集群中，然后在分析任务完成后立即关闭所有数据。这实际上正是默认情况下EMR的工作原理，但即使使用的是Cloudera或Hortonworks(现在功能几乎相同)，也可以轻松编写上述所有内容。利用EC2现场实例可以节省80%-90%的成本，并检查自己的分析，以便可以向上或向下旋转集群。以利用成本最低的spot窗口。

3. NoSQL引擎

Velocity(并发事务)在这里特别重要，这些引擎被设计为处理任意数量的并发读写。虽然其他系统通常不能用于最终用户(需要低延迟响应)和员工分析团队(可能会使用长时间运行的查询锁定多个表)，同时，NoSQL引擎可以扩展以适应一个系统的两个主服务器。一些开发允许以低延迟方式实时加入和查询该数据。

成本：$$ - $$$(通常为内存密集型)适用性：“3V”问题。简单和/或快速变化的数据模型。需要构建KPI的实时仪表板。警告：必须放弃交易和丰富多样的SQL。由于它不使用SQL，因此无法使用Tableau和Microstrategy等可视化工具直接查询数据。扩展(尤其是添加新节点和重新平衡)可能很困难，并且会影响用户延迟和系统可用性。受欢迎的产品：DynamoDB(托管服务)，Neptune(托管服务，目前仍处于测试阶段)，Cassandra(基于EC2)，CouchDB(基于EC2)和HBase(通过EMR作为托管服务，基于EC2)。提示和技巧：努力采用AWS管理的服务DynamoDB，而不是配置EC2并加载第三方系统。定期修剪最终用户DynamoDB表，并在这些历史表上创建每周或每月的表。使用Dynamic DynamoDB“自动调整”配置的容量，使其始终满足消耗。使用DynamoDB Streams可以对客户服务取消等关键事件进行实时响应，或者在第二个区域提供备份。

4. 企业数据仓库(EDW)

企业数据仓库(EDW)与此处提到的其他系统截然不同。它提供了人们称之为“OLAP”(在线分析处理，可以支持来自内部用户的一些长时间运行的查询)与“OLTP”(在线事务处理，可以支持来自最终用户的大量读取和写入)功能，如Oracle的RDBMS或MySQL。当然，可以使用OLTP系统作为企业数据仓库(EDW)，但是大多数人都将OLTP数据库集中在最近用户的低延迟，最近事件(如“跟踪上周的订单”)需求和定期(通常是每天)窗口更旧数据输出到OLAP系统，业务用户可以在数月或数年的数据中运行长时间的查询。

这些OLAP系统使用诸如列式存储、数据非规范化(创建具有几乎无限维度的“数据立方体”)等策略，并提供RDBMS级ANSI 92 SQL依从性，这意味着可以完全访问SQL功能，并且可以定制Tableau等可视化工具直接与他们合作。

成本：$$ - $$$$$(通常需要大量节点来存储和处理大量数据)。适用性：如果希望专门针对业务价值分析数据或构建KPI的实时仪表板。警告：确保团队了解OLAP和OLTP之间的区别，并确保他们以正确的方式使用每个OLAP和OLTP。提示和技巧：与EMR/Hadoop一样，只在需要时启动集群，将源数据保存在S3存储桶中(这实际上是Redshift默认工作的方式)。标记集群，以便用能够以自动方式快速识别和关闭未使用的容量。考虑保留以控制成本。真正了解可用的不同节点类型(高存储、高吞吐量)以便利用每个节点类型。采用本机加密，因为它可以将性能降低多达20%-25%。通过O'Reilly课程深入了解Redshift，或考虑通过出色的“数据仓库”课程进行面对面培训，该课程几乎完全涵盖Redshift。

5. 就地分析

几年前，Presto通过提供高性能的数据分析改变了游戏规则，而无需将数据从原生的、低成本的长期存储中移出。其最终结果是，可以简单地运行查询，而不是必须为昂贵的EMR或Redshift集群支付全部费用。而是只按使用的内容收费。

此外，人们需要很多时间来尝试选择(然后管理)EMR或Redshift集群的正确节点和节点数。采用Presto，人们不再知道也不关心这种差别，而这一切都在用户需要的时候起到作用。

最后，Presto支持RDBMS级别的ANSI-92 SQL兼容性，这意味着所有可视化工具都可以直接使用它，具有的SQL背景可以在ad-hoc查询中全面使用。

费用：$ - $$适用性：成本极低。没有任何管理。可以作为低成本、中等性能的企业数据仓库(EDW)。它不需要将数据复制到第二个系统。大型连接和复杂分析效果很好。警告：需要最低延迟。为了获得不错的性能，可能会使用序列化格式Parquet、压缩、重新分区等重新格式化存储的数据。可能需要多轮查询调整和/或重新格式化才能获得正确的结果。目前不支持UDF或事务。热门产品：AWS Athena(用于查询S3数据的托管服务)，EMR(托管服务-可以自动安装Presto)，自我管理的Presto(基于EC2–用户永远不想在AWS中执行此操作)。提示和技巧：只需使用Athena。利用AWS Glue构建ETL管道，以获取原始数据，并将其重新格式化为S3或Athena可以更有效地使用的内容。使用S3生命周期策略将原有的数据移动到低成本的归档存储(如Glacier)。

把它们放在一起

通过了解将在公共云中运行的五个顶级大数据架构，用户现在可以获得有关最佳应用位置的可操作信息，以及潜伏的位置。

一旦用户开始在AWS公共云中构建大数据架构，将很快了解到更多的架构，并且在很多情况下，企业可能会最终同时使用上述所有内容，可能使用Kinesis将客户数据流媒体传输到DynamoDB和S3。用户可能偶尔会在该源数据上启动EMR(进行某些机器学习)或Redshift(分析KPI)集群，或者可以选择以可以通过AWS Athena就地访问的方式格式化数据，让它像企业数据仓库(EDW)一样发挥作用。

具有执行TMTOWTDI的能力是一件好事，AWS公司努力提供最适合用户需求的服务。如果用户从头开始，在AWS认证的全球知识培训课程中花费三天时间将可以提供满足其需求的服务，并让用户尽快开始运营，并且顺利实施。

作者：Rich Morrow

【IT168 技术】摘要：通过对数据处理阶段性发展的解析，分析大数据、人工智能技术的发展趋势。结合实际生产需求，验证了基于容器云架构的新一代大数据与人工智能平台在数据分析、处理、挖掘等方面的强大优势。

关键词：大数据 人工智能 云计算 Docker 基础能力 多租户

Abstract：Through analyzing the staged development of data processing, this paper analyzes the development trend of big data and AI technology. According to the requirement of customers, the new generation of big data and AI platform based on Docker Cloud verify the powerful advantages in data analysis, processing, mining and so on.

Key Words：Big data; AI; cloud computing; Docker;basic abilities; Multi-tenant

引言

人工智能、大数据与云计算三者有着密不可分的联系。人工智能从1956年开始发展，在大数据技术出现之前已经发展了数十年，几起几落，但当遇到了大数据与分布式技术的发展，解决了计算力和训练数据量的问题，开始产生巨大的生产价值;同时，大数据技术通过将传统机器学习算法分布式实现，向人工智能领域延伸;此外，随着数据不断汇聚在一个平台，企业大数据基础平台服务各个部门以及分支机构的需求越来越迫切。通过容器技术，在容器云平台上构建大数据与人工智能基础公共能力，结合多租户技术赋能业务部门的方式将人工智能、大数据与云计算进行融合。

数据处理的发展阶段

随着信息技术的蓬勃发展，特别是近十年，移动互联技术的普及，运营商、泛金融、政府、大型央企、大型国企、能源等领域数据量更是呈现几何级数的增长趋势。数据量的膨胀除了带来了数据处理性能的压力外，数据种类的多样性也为数据处理手段提出了新的要求，大量新系统的建设同时产生了众多数据孤岛，给企业的数据运营维护与价值发掘带来了重大的挑战。随着大数据技术的不断发展，企业的数据处理技术转型也经历了几个阶段，如图1所示。

▲图1 企业数据处理转型的阶段变化

在第一阶段，大数据技术发展的早期，为了打破数据孤岛，将各类数据向大数据平台汇集，形成数据湖的概念，作为多源、异构的数据的数据归集，在此基础上进行数据标准化，建立企业数据的汇聚中心。在这个阶段，对非结构化数据处理以存储检索为主，对结构化数据处理提供各类API和少量SQL支持，使海量的以SQL实现为主的业务难以迁移到大数据平台，新业务开发使用门槛高，大数据技术的推广受到阻碍。

在第二阶段，企业客户的需求集中表现为，如何更好地处理结构化数据以及将老的IT架构迁移到分布式架构中。各大数据平台厂商开始在SQL on Hadoop领域进行研发和竞争，不断提高SQL标准的兼容程度。在这个过程中，Spark诞生并逐渐取代了过于笨重且TB量级计算性能存在缺陷的MapReduce架构，Hadoop技术开始向结构化数据处理分析更深度的应用领域进发。随着SQL on Hadoop技术的不断发展与星环科技解决了Hadoop分布式事务的难题，越来越多的客户在Hadoop上构建新一代数据仓库，将Hadoop技术应用于越来越多的业务生产场景，技术门槛的降低，使越来越多的客户可以利用强大的分布式计算能力轻松分析处理海量数据。在这个阶段后期，随着企业客户对实时数据分析研判需求的不断提高，流处理技术得以蓬勃发展。

在第三阶段，一部分企业已经完成了由基于关系型数据库为核心的数据处理体系向基于大数据技术为核心的数据处理体系的转变。在本阶段早期，很多企业客户不满足于通过SQL基于统计对数据的分析和挖掘，促使传统的机器学习算法开始实现分布化，但主要还是针对结构化数据的学习挖掘。随着深度学习技术和分布式技术的碰撞，演化出了新一代的计算框架，如TensorFlow等，计算能力的提升，并结合大量训练数据，使机器学习人工智能技术在结构化与非结构化数据领域产生巨大威力，开始应用于人脸识别、车辆识别、智能客服、无人驾驶等领域;同时，对传统机器学习算法产生了巨大冲击，一定程度上减少了对特征工程与业务领域知识的依赖，降低了机器学习的进入门槛，使人工智能技术得以普及。另一方面，可视化的拖拽页面、丰富的行业模板、高效率的交互式体验，极大地降低了数据分析人员的使用门槛，让人工智能技术进一步走入企业的生产应用。

大数据、人工智能与云技术的融合

随着企业内部对于数据资源的应用不再仅仅局限于IT部门，越来越多的内部项目组与分支机构加入大数据平台的使用中，加之数据处理技术的不断发展，如何解决基础平台的资源隔离问题、管理分配问题、编排调度问题;如何将企业业务应用需要的基础服务能力做更好地抽象，降低应用所需的基础服务的环境搭建、开发、测试部署周期，提升IT支撑效能;如何更好地管理众多的基于大数据与人工智能开发的应用等等成为企业急需解决的问题。

在大数据技术发展的早期，仅仅是在计算框架MapReduce中提供简单的作业调度算法，随着资源管理的需求，在Hadoop 2.0时代，Yarn作为单独组件负责分布式计算框架的资源管理。但是，一方面，Yarn仅仅能够管理调度计算框架的资源;另一方面，资源的管理粒度较为粗放，不能做到有效的资源隔离，越来越不能满足企业客户的需求。

云计算技术作为资源隔离封装虚拟化，以及管理调度的技术，本应应用于解决上述问题。但是，在Docker容器技术被广泛接受之前，云计算虚拟化技术主要基于虚拟机封装资源，并在其之上加载操作系统，资源利用率低，早期有厂商尝试将大数据平台构建在基于虚拟机技术的云化方案上，由于资源利用和稳定性问题，在私有云上的尝试鲜有成功案例。在公有云方面，借助公有云较为强大的基础平台硬件与运维支持能力，有一些非核心业务的应用尝试。

随着Docker、Kubernetes等容器技术的发展，与微服务等技术概念的形成，大数据与人工智能基础平台开始基于容器云构建底层资源管理与调度平台。容器云就像一个分布式的操作系统，将集群中的各类硬件资源进行封装、管理以及调度，将封装的资源作为容器承载大数据的相关组件进程，再将这些容器进行编排，组成一个个的大数据和人工智能的基础服务，如分布式文件系统HDFS、NoSQL数据库Hbase、分布式分析型数据库Inceptor、分布式流处理平台Slipstream、分布式机器学习组件Sophon等。由这些基础服务编排构建公共能力服务层，提供如数据仓库、数据集市、图数据库、全文搜索数据库、流处理服务、NoSQL数据库、机器学习平台服务、定制图像识别服务等，为企业打造全新的数据处理核心系统。基于这一核心系统服务于各类企业的不同部门。通过资源隔离技术，通过对每个租户的资源分配和权限管理，满足业务分析人员的个性化分析需求，专注于业务逻辑的开发和数据的分析挖掘。

技术融合的应用

中国邮政大数据平台建设以Transwarp Data Hub(以下简称TDH)与Transwarp Operating System(以下简称TOS)作为基础架构系统，搭建的新一代逻辑数据仓库和数据集市，完全取代了Teradata和Oracle。

总体架构与实现

中国邮政大数据平台服务于量收、邮务、名址等系统，同时运用容器云TOS实现创新多租户的数据分析挖掘环境。建立从业务层到管理层到决策层的智能分析体系，模拟量化风险和收益，实现对邮政各种业务数据进行分类、管理、统计和分析等功能，给各级管理人员提供各类准确的统计分析预测数据，使其能够及时掌握全面的经营状况，为宏观决策提供支持;为省分公司基层业务人员提供详尽的数据，供其对各自的工作目标、当前和历史状况进行准确的把握，对业务活动进行有效支撑，满足邮政经营分析管理及决策支持。

中国邮政大数据平台以五大基础服务集群域为基础，分别是数据湖集群域、企业数据仓库集群域、省分服务集群域、机器学习实验室集群域、开发/测试/培训集群域。

(1)数据湖集群域：基于TDH平台搭建的数据湖，主要承担多源异构的数据归集，数据湖内包括：原始数据池、清洗加工数据池、整合加工数据池等。

(2)企业数仓集群域：基于TDH搭架的数据仓库集群，基于大数据创新搭架逻辑数据仓库，用于迁移改造原有基于Teradata搭架的数据仓库，数据集市和基于Oracle搭建的报刊集市的邮政量收管理系统。

(3)省分服务集群域：基于TOS搭建容器化多租户数据分析平台云。为省、市分公司开发人员和业务人员提供省分多租户的平台环境，集团分发数据与自有数据存储计算，自有应用的开发与管理，独立租户使用运行。

(4)机器学习实验室集群域：基于TOS搭建的容器化多租户大数据机器学习平台，为集团数据中心分析师提供多租户的开发实验环境平台，进行数据探查、业务建模、算法研究、应用开发、成果推广等。

(5)开发/测试/培训集群域：为应用开发人员、系统测试人员、培训师、学员提供多租户的大数据与机器学习平台，为开发商及内部单位提供开发测试培训服务。

以此为基础，达到了数据管理、服务管理、运维管控、安全管控四个维度的统一。在风险管控、决策支持、服务支撑、流程优化、品牌创新、交叉营销六大应用领域展开应用。实现了租户管理、数据治理、数据加工、数据挖掘、数据探索、数据展现六大平台功能。

数据湖和数据仓库基于TDH构建，将包括业务系统数据、实时流数据、合作单位数据、互联网数据等不同数据源，通过ESB接入、ETL工具、Kafka、Sqoop、文本上传、人工接入等方式，统一汇聚进入数据湖。加工后获得的数据资产发布到数据资产目录，通过数据资产目录的构建TDH与TOS用户间数据交互体系。便于用户快速检索数据，通过数据资产目录实现对数据的集成、融合、安全、共享。数据资产目录包括：元数据、主数据、数据安全、数据标准、数据质量、数据轮廓、数据生命周期等。此外，企业用户通过大数据门户按需申请租户存储计算资源、数据资源、审批流程通过后，集群资源管理员按需快速部署集群，自动化将数据从数据湖加载入数据分析集群或省分集群对应的租户空间，供数据开发人员使用。数据开发人员会将数据应用成果固化到数据湖内，对外提供数据服务。

数据仓库与数据集市的完整迁移

中国邮政大数据平台是全球首个采用Hadoop(TDH)技术完全取代Teradata和Oracle的混合架构搭建新一代逻辑数据仓库和数据集市的系统。

原量收系统使用Teradata的数据仓库和Oracle的数据库，数据使用空间目前已接近30TB，现有使用用户约5万人，提供近约900张报表的灵活查询，单日报表查询频次最高能达到40万次，月初高峰查询需支持约2000计算查询并发。

通过项目前期大量调研准备工作，制定了切实可行的项目实施方案。量收管理系统的总体架构、ESB、BI工具、ETL工具、调度工具、门户等都保持不变，仅将原量收系统的数据仓库和数据集市，使用大数据平台进行完全替换，降低了整个迁移风险。

整个迁移过程中，包括环境部署、模型迁移改造、接口迁移改造、数据迁移、ETL迁移改造、报表迁移改造、数据核对、性能优化、业务应用迁移、风险控制，系统测试等。例如模型迁移改造，不改变原有业务逻辑，只需对接口层模型，基础层模型、汇总层模型进行轻度改造。对于模型改造来说，系统基础层模型结构相对复杂，关联度相对较高，原系统使用Teradata数据库。TDH全面兼容Teradata的数据类型与SQL方言，降低了迁移成本。同时迁移完成后，性能大幅提升，见图2。

▲图2 迁移前后数据集市业务场景500并发测试性能对比

基于容器云的大数据与机器学习平台的全面应用

基于TOS实现的多租户新模式，将大数据与机器学习平台组件完全容器化实现，并在TOS提供能力服务。集团统一部署企业内部云平台，对邮政各个租户(集团、省分、市局等)动态分配存储、计算、网络等资源，并实现完整的资源隔离，使得各个租户数据分析人员和业务人员获得相对独立的资源环境，赋能业务创新，同时可动态调配资源，实现资源的共享优势。

集团、省分、市局各级人员通过多租户平台，实现资源发布、申请，使用及应用开发、成果推广。通过项目立项申请审批后，省分项目组人员在租户空间内，接入访问数据资源，使用平台服务资源，大数据分析工具及机器学习挖掘工具展开数据分析挖掘工作，具体开展数据处理、模型开发、算法应用、应用发布等，在审批验收之后，将成果推广到数据湖上部署对全集团提供数据应用服务。

通过TOS+TDH搭架厚平台、薄应用的微服务架构，实现租户之间的异构性、独立测试与部署、资源按需伸缩、高性能计算能力、租户间错误问题隔离、团队全功能化。实现数据资产化管理。面对集团数据多样、海量、跨板块、跨专业的需求，集团对数据进行了全面梳理，创新集成各版块、专业数据，创建数据资产目录便于快速检索获取资产，管控治理资产，让数据即资产从理论阶段上升到实现阶段。

结语

随着企业数据处理与服务需求的不断发展，由大数据的汇聚，分布式技术释放计算能力开始，技术不断延伸发展，大数据、人工智能与云计算的边界越来越模糊，�...

阿里妹导读：搜索离线数据处理是一个典型的海量数据批次/实时计算结合的场景，阿里搜索中台团队立足内部技术结合开源大数据存储和计算系统，针对自身业务和技术特点构建了搜索离线平台，提供复杂业务场景下单日批次处理千亿级数据，秒级实时百万TPS吞吐的计算能力。

背景

什么是搜索离线？

一个典型的商品搜索架构如下图所示，本文将要重点介绍的就是下图中的离线数据处理系统（Offline System）。

何谓离线？在阿里搜索工程体系中我们把搜索引擎、在线算分、SearchPlanner等ms级响应用户请求的服务称之为“在线”服务；与之相对应的，将各种来源数据转换处理后送入搜索引擎等“在线”服务的系统统称为“离线”系统。商品搜索的业务特性（海量数据、复杂业务）决定了离线系统从诞生伊始就是一个大数据系统，它有以下一些特点：

1. 任务模型上区分全量和增量

1）全量是指将搜索业务数据全部重新处理生成，并传送给在线引擎，一般是每天一次。这么做有两个原因：有业务数据是daily更新；引擎需要全量数据来高效的进行索引整理和预处理，提高在线服务效率。

2）增量是指将上游数据源实时发生的数据变化更新到在线引擎中。

3）性能方面有较高要求。全量需要极高吞吐能力，确保数以亿计的数据可以在数小时内完成。增量则需要支持数万TPS秒级的实时性，还需要有极高的可用性。

2. 需要支持多样化的输入和输出数据源，包括：Mysql，ODPS，TT等各种数据库和消息队列作为输入，搜索、Ranking、图、推荐等各种引擎作为输出。

3. 需要提供一定能力的数据处理能力，例如多表Join、UDTF支持等，以方便搜索业务的开发和接入。

在后续的段落中我们会看到离线系统架构围绕着这些特点，针对搜索业务的变化，做出的各种演进和发展。

发展简介

阿里商品搜索体系肇始于淘宝搜索，大约在2008年初第一代搜索系统诞生，离线系统随之上线。搜索离线系统经历多年发展，技术架构几经迭代，数据处理能力、业务支持能力不断提升。下面会分阶段介绍搜索离线的主要技术架构和特点。

★ 淘宝搜索阶段

在2008-2012这个阶段，我们重点支持淘宝搜索的业务发展，随着淘宝商品量的不断增加，逐步引入Hadoop、Hbase等开源大数据计算和存储框架，实现了搜索离线系统的分布式化，有力地支持了淘宝搜索业务的发展。但是在这个阶段，我们支持的业务线只有淘系合计不到5个业务线，为此投入了大约10名开发人员，整体效率不高。另一方面相关系统框架代码与淘系业务高度耦合，量身定制了很多特殊代码，不利于架构的推广和其它业务的支持。

★ 组件&平台化阶段

2013年底以来，特别是最近两年，随着集团技术业务线的梳理以及中台化战略的推行，搜索离线系统需要为越来越多的不同业务团队（飞猪、钉钉、1688、AE、Lazada等等）提供支持，技术框架复用、开发效率提升和平台化支持的需求越来越强烈。另一方面随着大数据计算、存储技术的发展，尤其是流计算引擎的飞速发展，离线系统技术架构上的进一步演进也具备了绝佳的土壤。

我们可以看到整个搜索离线系统的演进是沿着性能和效率两条主线，以业务和技术为双轮驱动，一步一个脚印的走到今天。这是一个技术与业务高度融合互动，互相促进发展的典型样例。

离线平台技术架构

上一节我们简要介绍了离线系统的发展历史，也简要提到技术架构的演进，下面将会把离线平台的技术架构展开介绍，主要分为平台流程以及计算和存储架构等几个方面。

平台组件和任务流程

上图描述了离线平台技术组件结构，其中部分组件的简介如下：

Maat：分布式任务调度平台，基于Airflow发展而来，主要改进点是调度性能优化、执行器FaaS化、容器化、API及调度功能扩展等四个部分，在保持对Airflow兼容的基础上，大幅提升性能，提高了稳定性。 一个离线任务的多个Blink job会通过Maat建立依赖关系并进行调度。Bahamut：执行引擎，是整个离线平台的核心，负责离线任务的创建、调度、管理等各种功能，后文会详细介绍。Blink：Flink的阿里内部版本，在大规模分布式、SQL、TableAPI、Batch上做了大量的优化和重构。离线平台的所有计算任务都是Blink job，包括stream和batch。Soman：UI模块，与Bahamut后端对接，提供任务信息展示、状态管理等可视化功能，也是用户创建应用的开发业务逻辑的主要入口。Catalog： 存储表信息管理，提供各种数据源表的DDL能力，负责离线平台存储资源的申请、释放、变更等各种功能。Hippo：阿里搜索自研的分布式资源管理和任务调度服务，类似于Yarn，提供Docker管理能力，主要服务于在线系统。Swift：阿里搜索自研高性能分布式消息队列，支持亿级别消息吞吐能力，存储后端为HDFS，存储计算分离架构。

下图则描述了一个离线任务从数据源到产出引擎服务数据的整个过程，流程图分成三层：

数据同步层：将用户定义的数据源表的全量和增量数据同步到Hbase内部表，相当于源表的镜像。这个镜像中我们包含cf和d两个列族，分别存储数据库的镜像和Daily更新的数据。数据关联计算层：按照数据源中定义的各种关系，将不同维度的数据关联到一起，把数据送到自定义的UDTF中进行处理，产出引擎所需的全量和增量数据。数据交互层：提供全量和增量数据的存储信息，与在线服务build模块进行交互。

全增量统一的计算模型

那么如何实现对用户屏蔽离线平台内部的这些技术细节，让用户只需要关注业务实现呢？回顾第一节介绍的离线任务概念，离线任务包含全量和增量，它们业务逻辑相同，但是执行模式上有区别。为了让用户能够专注业务逻辑的开发，屏蔽离线平台技术细节实现全增量统一的计算逻辑，我们引入了Business Table（业务表）的概念。

Business Table（业务表）：Business Table是一个抽象表，由一个全量数据表和/或一个增量流表组成，全量/增量表的Schema相同，业务含义相同。

基于业务表和数据处理组件，用户可以开发出一个描述离线处理流程的业务逻辑图，我们称之为Business Graph。下图就是一个Business Graph的样例，其中上侧红框标识的就是只包含ODPS全量数据源的Business Table，最下方红框中标识的是包含Hdfs+Swift的Business Table，除此之外我们还支持Mysql+DRC/ODPS+Swift等多种业务表的组合。图中还可以看到Join、UDTF等常用的数据处理组件，业务表与处理组件结合在一起就能够描述常见的离线业务处理逻辑。

那么如何把这个Business Graph转化为真正的离线任务呢？Bahamut作为离线平台的执行引擎，会按照Business Graph->APP Graph->Job Graph->(Blink Job/Maat Job)的顺序把一个业务描述转化为可执行的离线任务，具体如下：

1. Business Graph->APP Graph：在这个环节中我们主要有2个重要的工作：

1）正确性校验：根据BG中的节点信息，校验节点间连接的合法性（例如两个输入源节点不能直接连接）、节点配置的正确性（数据库配置/ODPS的配置是否正确）、Schema推导是否正确。

2）任务分层优化：为了用Blink Stream模式来统一完成全量和增量的执行，我们需要将输入源数据存入内部Hbase，直接使用Blink维表Join功能来完成数据的连接。于是在节点遍历过程中遇到Join、Merge组件时，需要在AppGraph中插入一个内部的HTable节点，将Merge或者Join上游的数据同步进入Hbase。

2. APP Graph->Job Graph：JobGraph是一个Blink/Maat任务的配置DAG，其中每个节点包含配置信息，可以在后续的过程中直接转化为计算或者调度任务。

1）Blink JobGraph：从数据源业务表节点开始遍历AppGraph，每当碰到一个内部HTable节点时，会生成两个（增量/全量）同步层的Blink JobGraph。所有同步层Blink JobGraph生成后，以所有的内部HTable/queue为输入，生成两个（增量/全量）关联处理层的Blink JobGraph。

①同步层：采用Business Table中的全量/增量表配置，分别生成全量和增量的Blink任务配置，描述把数据从数据源同步到内部HTable过程。例如对于Mysql+DRC的表，全量阶段将会从mysql中拉取全表数据并转化为HFile bulkload到HTable中，增量阶段则是从DRC中拉取变化数据，直接写入HTable，并根据需求写入驱动queue。②关联处理层：关联多个HTable，生成大宽表后调用UDTF处理，产出最终的进入引擎的数据。同样需要分别生成全量和增量任务配置2)Maat JobGraph：基于Maat的调度任务描述DAG，主要目的是将各个层次的Blink任务按照依赖进行调度，同时执行特定的脚本完成与外部系统的交互等职责。一般来说一个离线任务会生成Build/Publish/Stop/Release等多个Maat JobGraph。3. Job Graph->Blink/Maat Job：遍历JobGraph，调用Translator将JobGraph转换为Blink/Maat的任务代码。引入JobGraph的目的是将底层的计算引擎与计算任务描述解耦，例如：我们底层的计算引擎曾经是MapReduce +Blink-1.4-TableAPI，最近刚完成了Blink-2.1 基于SQL的升级，我们所有的工作基本上是重写了一套Translator，对上层的代码结构没有任何变动。

经过了上述的三个步骤，我们完成了BusinessGraph（业务描述）到Blink/Maat job的转化，生成了若干数据同步/处理的Blink job，以及将这些Blink job进行依赖调度的完成不同功能的Maat job。特别的针对搜索离线的场景，在调度流程中加入了大量与下游引擎交互的逻辑，包括24小时不间断增量、触发引擎消费数据、切换引擎消费增量queue等重要的业务流程。

存储与计算

★ 基于Hbase的存储架构

搜索离线大约在2012年即引入了Hbase作为数据的存储引擎，有力的支持了搜索业务从淘宝主搜到离线平台的整个发展历程，历经多次双11考验，稳定性和性能都得到明确的验证。从功能层面，搜索离线引入Hbase的原因主要是以下几点：

通过Scan/Get可以批量/单条的获取数据，通过bulkload/put可以批量/单条的导入数据，这与搜索的全量/增量模型完全吻合，天然适合支持搜索离线业务。底层存储基于HDFS，LSM-Tree的的架构能够确保数据安全性，计算存储分离的架构保证了集群规模水平可扩展，易于提高整体的吞吐。通过单机性能优化（Async、BucketCache、Handler分层、Offheap）和集群的扩容，确保了业务大幅增长时，存储从来没有成为系统的瓶颈。Free Schema的特性能够很好的应对业务数据频繁变化的情况，也能够方便支持一些特殊业务场景的数据逻辑。

通过引入Hbase做为离线系统的内部数据存储，我们成功解决了每天全量时对上游Mysql造成很大压力的问题，大幅度的提升了整体系统的吞吐。数据存储到Hbase也是全量任务向流式处理流程转型（MR->Stream）的基础，而这一点为后来Blink流引擎在搜索离线的孕育和发展也埋下了伏笔。

当然Hbase也不是毫无缺点，JVM内存管理的痼疾、单机Handler打满导致雪崩、缺乏容器化部署能力等也带来了不少烦恼，很快我们就会替换Hbase为阿里内部发展的另外一套存储引擎，期望能够部分的解决这些问题。

★ 基于Flink的计算架构

2016年中，搜索离线逐渐开始引入Flink作为计算引擎，重点解决搜索实时计算场景碰到的大量问题。在社区Flink版本的基础上，实时计算团队开发了Blink，增加原生yarn模式、Incremetal checkpoint等若干解决Flink大规模分布式运行问题的特性，另一方面，在DataStream/DataSet接口的基础上，进一步加强了TableAPI和SQL的功能，真正统一了Stream和Batch的调用接口，并实现计算业务逻辑的sql化开发模式。

离线平台是Blink的早期使用者和开发者，从0.8版本开始经历了多个Blink版本的升级和变迁，先后使用了DataStream、TableAPI和SQL作为任务接口，同时也开发了大量Connector以支持不同数据源之间的交互。目前离线平台已经在使用最新的Blink-2.1.1，Bahamut利用SqlTranslator直接生成SQL来描述任务逻辑，通过Bayes（Blink SQL开发平台）服务化直接提交任务到不同的Yarn集群，这样做有以下几个明显的优势：

采用SQL来描述Blink任务业务逻辑非常清晰，可以直接利用Blink提供的各种Operator完成数据处理，方便任务的调试，例如：dim join、groupby，而不是在Datastream时期需要自行编写完成类似Hbase Join的Operator。Blink 2.1原生支持Batch，采用Batch模式可以直接完成生成HFile的任务，下线MR任务，彻底统一计算引擎到Blink。Batch模式任务执行时采用分阶段调度可以大幅的节省计算资源，提高集群效率。Blink SQL可以通过修改提交模式，分别转化为Stream或Batch任务，在保持业务逻辑稳定的同时方便任务调试和验证。通过Bayes这样的开发平台服务化的方式提交任务到不同集群，彻底解决以前任务通过GateWay提交运维复杂的问题，添加新的Yarn集群只需要简单配置即可完成。另外在Bayes上同样会保存Bahamut自动生成提交的Sql，可以在Bayes上直接进行任务的调试和管理，方便了开发人员。下图是一个Bahamut自动生成的Blink Sql样例，描述同步层的一个任务，任务中包含Source，Select Oper和Sink三个O...

从菜鸟到架构师，不仅需要的是时间的磨练，更需要的是机会和平台。对于大数据技术的应用，不管是传统行业还是互联网行业，已经开始大范围的应用。很多人也轰轰烈烈的加入到大数据技术学习的行列中来，但大多数是三分钟热情高涨但又无法坚持到底。原因不是不想学，而是太复杂，坑太多。

对于接触过大数据技术的人应该比较清楚，大数据技术框架都是开源的，一个项目的完成需要众多技术的整合，包括安装、部署、开发、集成等。开源的也就免费，免费的东西有好的一方面，也有不好的一方面，好的一面就是企业应用不用花钱，尽管用。不好的一面也是学习者都感同身受，比较苦恼，就是坑太多，不是这个版本有bug，就是那个版本不兼容。在企业应用中对框架补漏修改是常有的事。也正因为这个，成就了行业很多的技术高手。当然，这也是为啥大数据人才稀缺并且薪水高的原因。

所以本篇我们为大家分享一套完整的大数据项目架构设计与实施方案，也是希望有基础的学习者能通过这个课程，一点画面，系统的学习，并且能彻彻底底的感受学习大数据技术所带来的成就感。体验自己如何根据零碎的基础知识能快速的架构设计大数据项目，并且完整的得以实施。

先来谈谈我们的需求，我们要对某新闻网做用户行为分析，需要达到以下几个要求：

实时捕获用户浏览日志信息并且存储（TB级别）实时分析前20名流量最高的新闻话题实时统计当前线上已曝光的新闻话题量离线分析统计哪个时段用户浏览量最高报表对外发布数据

针对以上的需求，如果是你该如何架构设计满足用户需求的系统呢？

先来看看卡弗卡大数据对以上需求实现的需求结果：

以上图描述的很清晰，基本完成了我们三个需求。接下来就是我们要分享的核心：系统架构设计。这个是非常重要的，他是在你完全熟练掌握技术基础之上，根据业务需求的理解而进行的设计工作。我们来看第一张图：

系统架构设计

架构设计中的所有技术框架在我们的系统实施过程中都得到了应用，当然，如何没用，我们也不会放在架构图中。哈哈。如果你能看懂这张图，那得恭喜你，你快入行了，如果看不懂，那说明你还只是个菜鸟，继续努力吧。

系统数据流程设计

在需求中我们提的很明确，有三个要点：第一是数据实时获取并存储；第二是数据实时在线分析；第三数据批量离线分析。所以在流程图上会有两个不同颜色的流程分支，一个是代表实时数据处理，一个是代表离线批量数据处理。如果你想学点什么，你应该会仔细的看这张图，因为图上的每一个标识，不管图标大小所描述的都是核心，都是重点。切记！

集群服务节点规划

大数据项目，玩的都是集群。没有一个企业会在单节点机器上玩大数据应用。除非你自己学习之用。上图是我们对此系统的服务节点规划，一个机器上放什么节点服务，这都是有原因的。不是你想放什么节点就放什么节点。所以架构设计中的机器规划部署也是非常重要的，在业务需求的基础上要做好资源的合理规划，包括扩展性和稳定性。

说了这么多，该如何实施呢？

一个完整项目的全流程实施，从架构设计、技术选型、环境配置、安装部署、研发、整合集成、数据可视化交互等各个方面所要求的知识点很多，如果是新手或者初学者，不是几篇文章能说的清楚的，也不是一朝一夕你能的搞明白的。当然这不是个人能力的问题，而是大数据技术框架本身的坑很多，如果没有系统完整案例的指导，你可能得自己一个一个的去填坑才有可能到达你想要的结果。我说的一点也不严重，不信你可以去试试，呵呵。

如果你想尽快的掌握一个完整的大数据项目架构与实施，请参加我们的线上直播课，没有别的，只是让我们的经验有价值的得到分享。

大数据平台架构的层次划分没啥标准，以前笔者曾经做过大数据应用规划，也是非常纠结，因为应用的分类也是横纵交错，后来还是觉得体现一个“能用”原则，清晰且容易理解，能指导建设，这里将大数据平台划分为“五横一纵”。

当前BAT基本公开了其大数据平台架构，从网上也能查询到一些资料，关于大数据平台的各类技术介绍也不少，但在那个机制、那个环境、那个人才、那个薪酬体系下，对于传统企业，可借鉴的东西也是有限的。

技术最终为业务服务，没必要一定要追求先进性，各个企业应根据自己的实际情况去选择自己的技术路径。

与传统的更多从技术的角度来看待大数据平台架构的方式不同，笔者这次，更多的从业务的视角来谈谈关于大数据架构的理解，即更多的会问为什么要采用这个架构，到底能给业务带来多大价值，实践的最终结果是什么。

它不一定具有通用性，但从一定程度讲，这个架构可能比BAT的架构更适应大多数企业的情况，毕竟，大多数企业，数据没到那个份上，也不可能完全自研，商业和开源的结合可能更好一点，权当抛砖引玉。

大数据平台架构的层次划分没啥标准，以前笔者曾经做过大数据应用规划，也是非常纠结，因为应用的分类也是横纵交错，后来还是觉得体现一个“能用”原则，清晰且容易理解，能指导建设，这里将大数据平台划分为“五横一纵”。

具体见下图示例，这张图是比较经典的，也是妥协的结果，跟当前网上很多的大数据架构图都可以作一定的映射。

何谓五横，基本还是根据数据的流向自底向上划分五层，跟传统的数据仓库其实很类似，数据类的系统，概念上还是相通的，分别为数据采集层、数据处理层、数据分析层、数据访问层及应用层。

同时，大数据平台架构跟传统数据仓库有一个不同，就是同一层次，为了满足不同的场景，会采用更多的技术组件，体现百花齐放的特点，这是一个难点。

数据采集层：既包括传统的ETL离线采集、也有实时采集、互联网爬虫解析等等。

数据处理层：根据数据处理场景要求不同，可以划分为HADOOP、MPP、流处理等等。

数据分析层：主要包含了分析引擎，比如数据挖掘、机器学习、 深度学习等。

数据访问层：主要是实现读写分离，将偏向应用的查询等能力与计算能力剥离，包括实时查询、多维查询、常规查询等应用场景。

数据应用层：根据企业的特点不同划分不同类别的应用，比如针对运营商，对内有精准营销、客服投诉、基站分析等，对外有基于位置的客流、基于标签的广告应用等等。

数据管理层：这是一纵，主要是实现数据的管理和运维，它横跨多层，实现统一管理。

1、数据采集层，这是基础。

离线批量采集，采用的是HADOOP，这个已经成为当前流线采集的主流引擎了，基于这个平台，需要部署数据采集应用或工具。

诸如BAT都是自己研发的产品，一般企业，可以采用商用版本，现在这类选择很多，比如华为BDI等等，很多企业技术实力有，但起步的时候往往对于应用场景的理解比较弱，细节做工很差，导致做出来的产品难以达到要求，比如缺乏统计功能等，跟BAT差距很大，传统企业去采购这类产品，要谨慎小心。

一个建议是，当采购产品的时候，除了技术先进性和指标外，更多的应该问问是版本啥时候上线的，是否在哪里成功部署，是否有足够多的客户，如果能做个测试就更好，否则，你就是小白鼠哦，这个坑踩了不少。

能做和做成产品是两个境界的事情，小的互联网企业当然也能做出对于自己好用的采集工具，但它很难抽象并打造出一个真正的产品，BAT自研其实形成了巨大的优势。

实时采集现在也成了大数据平台的标配，估计主流就是FLUME+KAFKA，然后结合流处理+内存数据库吧，这个技术肯定靠谱，但这类开源的东西好是好，但一旦出现问题往往解决周期往往比较长。

除了用FLUME，针对ORACLE数据库的表为了实现实时采集，也可以采用OGG/DSG等技术实现实时的日志采集，可以解决传统数据仓库抽全量表的负荷问题。

爬虫当前也逐渐成为很多企业的采集标配，因为互联网新增数据主要靠它，可以通过网页的解析获取大量的上网信息，什么舆情分析、网站排名啥的，建议每个企业都应该建立企业级的爬虫中心，如果它未在你的大数据平台规划内，可以考虑一下，能拿的数据都不拿，就没什么好说了。

企业级的爬虫中心的建设难度蛮大，因为不仅仅是需要爬虫，还需要建立网址和应用知识库，需要基于网页文本进行中文分词，倒排序及文本挖掘等，这一套下来，挑战很大，当前已经有不少开源组件了，比如solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修远兮。

还有一个就是，如果有可能，笔者建议将数据采集平台升级为数据交换平台，因为其实企业内有大量的数据流动，不仅仅是单向的数据采集，而且有很多数据交换，比如需要从ORACLE倒数据到GBASE，从HBASE倒数据到ASTER等等，对于应用来讲，这个价值很大。

既然数据采集和数据交换有很多功能非常类似，为什么不做整合呢?也便于统一管理，感觉企业的数据交换大量都是应用驱动，接口管理乱七八糟，这也是我的一个建议。

总得来讲，建设大数据采集平台非常不易，从客户的角度讲，至少要达到以下三个要求：

多样化数据采集能力：支持对表、文件、消息等多种数据的实时增量数据采集(使用flume、消息队列、OGG等技术)和批量数据分布式采集等能力(SQOOP、FTP VOER HDFS)，比基于传统ETL性能有量级上的提升，这是根本。

可视化快速配置能力：提供图形化的开发和维护界面，支持图形化拖拽式开发，免代码编写，降低采集难度，每配置一个数据接口耗时很短，以降低人工成本。

统一调度管控能力：实现采集任务的统一调度，可支持Hadoop的多种技术组件(如 MapReduce、Spark 、HIVE)、关系型数据库存储过程、 shell脚本等，支持多种调度策略(时间/接口通知/手工)。

2、数据处理层，现在有个词叫混搭，的确是这样。

Hadoop的HIVE是传统数据仓库的一种分布式替代。应用在传统ETL中的数据的清洗、过滤、转化及直接汇总等场景很适合，数据量越大，它的性价比越高。但目前为止看，其支撑的数据分析场景也是有限的， 简单的离线的海量分析计算是它所擅长的，相对应的，复杂的关联交叉运算其速度很慢。

一定程度讲，比如企业客户统一视图宽表用HIVE做比较低效，因为涉及到多方数据的整合，但不是不可以做，最多慢点嘛，还是要讲究个平衡。

hadoop到了X000台集群的规模也撑不住了,当前很多企业的数据量应该会超过这个数量，除了像阿里等自身有研发能力的企业(比如ODPS)，是否也要走向按照业务拆分Hadoop集群的道路?诸如浙江移动已经拆分了固网、移网、创新等多个hadoop集群。

Hadoop的SPARK的很适合机器学习的迭代，但能否大规模的应用于数据关联分析，能否一定程度替代MPP，还需要实践来验证。

MPP应该来说，是采用分布式架构对于传统数据仓库最好的替代，毕竟其实际上是变了种的关系型数据库，对于SQL提供完整支持，在HIVE做了转化分析后，数据仓库的融合建模用它来做性能绰绰有余，其性价比较传统DB2更好一点，比如经过实用，Gbase30-40台集群就能超过2台顶配的IBM 780。

MPP现在产品很多，很难做优劣判断，但一些实践结果可以说下，GBASE不错，公司很多系统已经在上面跑了，主要还是国产的，技术服务保障相对靠谱，ASTER还有待观望，自带一些算法库是有其一些优势，GreenPlum、Vertica没用过，不好说。

现在有个说法是MPP最终也要被Hadoop那套框架替代，毕竟诸如SPARK啥的都在逐步稳定和成熟，但在短期内，我觉得还是很靠谱的，如果数据仓库要采用渐进的演化方式，MPP的确是很好的选择。

现在诸如中国移动，eBAY等大量公司都在采用这类混搭结构，以适应不同的应用场景，显然是一种自然的选择。

大数据平台的三驾马车，少不了流处理。

对于很多企业来讲，其显然是核武器般的存在，大量的应用场景需要它，因此务必要进行建设，比如在IOE时代不可想象的实时、准实时数据仓库场景，在流处理那里就变得很简单了，以前统计个实时指标，也是很痛苦的事情，当前比如反欺诈实时系统，一天系统就申请部署好了。

只尝试过STORM和IBM STREAM，推荐IBM STREAM，虽然是商业版本，但其处理能力超过STORM不是一点半点，据说STORM也基本不更新了，但其实数据量不大，用啥都可以，从应用的角度讲，诸如IBM这种商业版本，是不错的选择，支撑各类实时应用场景绰绰有余。

流处理集群以流处理技术结合内存数据库，用以实时及准实时数据处理，基于IBM Streams流处理集群承载公司的实时业务：

3、数据分析层，与时俱进吧。

先谈谈语言，R和Python是当前数据挖掘开源领域的一对基友，如果要说取舍，笔者真说不出来，感觉Python更偏向工程一点，比如有对分词啥的直接支撑，R的绘图能力异常强大。但他们原来都以样本统计为主，因此大规模数据的支撑有限。

笔者还是更关注分布式挖掘环境，SPARK是一种选择，建议可以采用SPARK+scala，毕竟SPARK是用scala写的，对很多原生的特性能够快速支持。

TD的MPP数据库ASTER也内嵌了很多算法，应该基于并行架构做了很多优化，似乎也是一种选择，以前做过几度交往圈，速度的确很快，但使用资料屈指可数，还需要老外的支持。

传统的数据挖掘工具也不甘人后，SPSS现在有IBM SPSS Analytic Server，加强了对于大数据hadoop的支撑，业务人员使用反馈还是不错的。

也许未来机器学习也会形成高低搭配，高端用户用spark，低端用户用SPSS，也是要适应不同的应用场景。

深度学习现在渐成潮流，TensorFlow是个选择，公司当前也部署了一套，希望有机会使用，往人工智能方向演进是大势所趋。

无论如何，工具仅仅是工具，最终靠的还是建模工程师驾驭能力。

4、数据开放层，也处在一个战国时代。

有些工程师直接将HIVE作为查询输出，虽然不合理，也体现出计算和查询对于技术能力要求完全不同，即使是查询领域，也需要根据不同的场景，选择不同的技术。

HBASE很好用，基于列存储，查询速度毫秒级，对于一般的百亿级的记录查询那也是能力杠杠的，具有一定的高可用性，我们生产上的详单查询、指标库查询都是很好的应用场景。但读取数据方面只支持通过key或者key范围读取，因此要设计好rowkey。

Redis是K-V数据库，读写速度比HBASE更快，大多时候，HBASE能做的，Redis也能做，但Redis是基于内存的，主要用在key-value 的内存缓存，有丢失数据的可能，当前标签实时查询会用到它，合作过的互联网或广告公司大多采用该技术，但如果数据越来越大，那么，HBASE估计就是唯一的选择了?

另外已经基于IMPALA提供互联网日志的实时在线查询应用，也在尝试在营销平台采用SQLFire和GemFire实现分布式的基于内存的SQL关联分析，虽然速度可以，但也是BUG多多，引入和改造的代价较大。

Kylin当前算是基于hadoop/SPARK的多维分析的杀手级工具，应用的场景非常多，希望有机会使用。

5、数据应用层，百花齐放吧。

每个企业应根据自己的实际规划自己的应用，其实搞应用蓝图很难，大数据架构越上层越不稳定，因为变化太快，以下是运营商对外变现当前阶段还算通用的一张应用规划图，供参考：

6、数据管理层，路漫漫其修远兮

大数据平台的管理有应用管理和系统管理之分，从应用的角度讲，比如我们建立了DACP的可视化管理平台，其能适配11大搭数据技术组件，可以实现对各类技术组件的透明访问能力，同时通过该平台实现从数据设计、开发到数据销毁的全生命周期管理，并把标准、质量规则和安全策略固化在平台上，实现从事前管理、事中控制和事后稽核、审计的全方位质量管理和安全管理。

其它诸如调度管理、元数据管理、质量管理当然不在话下，因为管住了开发的源头，数据管理的复杂度会大幅降低。

从系统管理的角度看，公司将大数据平台纳入统一的云管理平台管理(私有云)，云管理平台包括支持一键部署、增量部署的可视化运维工具、面向多租户的计算资源管控体系(多租户管理、安全管理、资源管理、负载管理、配额管理以及计量管理)和完善的用户权限管理体系，提供企业级的大数据平台运维管理能力支撑，当然这么宏大的目标要实现也非一日之功。

总结下大数据平台的一些革命性价值。

大数据时代，大多数企业的架构必然向着分布式、可扩展及多元化发展，所谓合久必分，不再有一种技术能包打天下了， 这冲击着传统企业集中化的技术外包模式，挑战是巨大的。

大数据及云计算时代，面多这么多技术组件，要采用一项新的技术，机遇和风险共存：

对于大数据平台的商业版本，企业面对的是合作伙伴的服务跟不上，因为发展太快，对于开源版本，企业面临的是自身运维能力和技术能力的挑战，对于自主能力实际要�...

文 | 帆软数据应用研究院 贾强

数据分析平台的搭建从规模上分类，确定企业规模，明确合作点，非常重要。

以服装行业为例，大型企业如波司登，本身的大数据系统架构已经完善，数据分析平台（报表/商业智能软件）在整个系统架构下的角色定位为“工具”更合适，发挥工具易用、高效开发、交互性强，稳定等优点。

中小型企业从成本上考虑，并没有成熟的架构以及大量的投入。对于整合数据，构建数据中心报表系统，我们可以进行合理规划，控制整个项目建设和运维成本，从而能够达成更好的合作。

在时尚业行业中，对于各个分店的有效管理，如何构建合理高效的报表中心变得非常关键。这里从两方面讲述，系统架构和技术实现方式，主要是鞋服行业，其他行业仅供借鉴。

首先是系统架构，从架构上分为分店管理系统（ERP和POS）及数据库、服务器和应用层客户端。系统架构如图：

（１）分店管理系统及数据库。分店使用管理系统管理本店进销存业务及相关管理工作，并定期按需将各个分店数据上传至云端服务器。

（２）服务器。构建服务器集群。数据分散在不同的服务器主机上可以并行存取，提高了数据的存取速度。服务器负责存储分店采集的各种数据，并以这些数据为基础构建数据仓库。再部署帆软数据分析平台，将处理结果给返回客户端，供业务层和决策层使用。

（３）应用层客户端。应用层客户端分为决策和统筹管理两部分。决策层根据所获得的报表、图形和走势图等来支持其决策。设置一个统筹管理的职能部门，统筹各分店统一促销，畅销商品管理和会员行为分析。企业通过云改变了以前处理数据和接入数据的方式，数据更集中，数据一致性更强，数据质量提高，分店之间的联系更紧密更便捷，在这种环境下，企业的决策依据将更准确。

（４）服务器的构建。架构如图，ETL工具通过远程访问。各个分店的服务器完成数据收集的任务，收集的数据是最原始的数据不做处理，先存储在数据中心。数据中心为基础数据库，数据中心集中了所有分店的数据。数据上传完成后继续对数据进行ETL处理，并将处理后的数据存入到数据仓库。数据分析应用程序根据客户端的请求调用数据仓库中的数据进行处理，并将结果返回给请求客户端，同时将常用的分析按计划定期自动分析并将结果保存到预定义分析结果模块中。每个分店和总部的管理层都有接入云的权限，云端数据共享。作为总部，可以监控各个分店的运营情况，作为分店可以及时了解其他分店的运行情况，借鉴经验并制定销售策略。

其次是技术实现方式，包含数据仓库、ETL、数据分析平台。

数据仓库（DataWarehouse，DW）是一个收集、组织、存储和共享历史数据的系统，其中数据ETL工具（选开源工具的话，可以用Kettle）。支持多种类型的数据源，还可以将数据库文件下载到本地进行ETL工作。PDI分为两个步骤，一个叫Transformation，另一个叫job，可以设定这些转换的执行时间和频率，这一点对于数据仓库的自动化更新是很有帮助。

下面聊一聊数据采集与分析

每个分店有各自的分店管理系统及数据库，根据中央服务器要求将需要的数据进行上传。对于零售业来说，需要上传的数据主要包括销售数据、会员数据、商品数据、库存数据、调研数据等。需要预定义所需采集的数据，包括数据的类型、数据结构。对于数据库的数据，数据库名称、表名称、表字段都采取统一格式和名称。对于文本型数据也要统一格式，或以xml方式存储。服务器收集各个分店管理数据库的数据并对每个分店的数据标记以区分。统一标准数据可很大程度地提高数据采集的质量和后续处理效率。

对于除了分店以外的数据源，如商业共享数据平台等，需要根据实际情况设计相应接口和采集方法，帆软数据分析平台内置采集数据功能，可以非常方便根据业务情况定制数据采集模块。

数据的分析工作在按照数据仓库对数据的要求并选择合适的工具对不同类型的数据进行处理，然后保存到数据仓库中。随着时间的推移，数据中心的数据量会不断增加，运用大数据工具是非常有必要的。大数据工具的主要特点是通过服务器集群中的主机并行处理数据，将一个庞大的任务分解为小任务处理。

应用程序部署到云端以后，客户端通过浏览器调用相应的功能，只需将结果返回给客户端，在客户端进行数据分析结果的展现。针对时尚业的数据分析可以包括多个方面，比如：销量分析、客户购买偏好分析、商品关联分析、精准推送服务等。

标签 | 大数据 架构

作者 | 张逸

无论是采集数据，还是存储数据，都不是大数据平台的最终目标。失去数据处理环节，即使珍贵如金矿一般的数据也不过是一堆废铁而已。数据处理是大数据产业的核心路径，然后再加上最后一公里的数据可视化，整个链条就算彻底走通了。

数据处理的分类

如下图所示，我们可以从业务、技术与编程模型三个不同的视角对数据处理进行归类：

业务角度的分类与具体的业务场景有关，但最终会制约技术的选型，尤其是数据存储的选型。例如，针对查询检索中的全文本搜索，ElasticSearch会是最佳的选择，而针对统计分析，则因为统计分析涉及到的运算，可能都是针对一列数据，例如针对销量进行求和运算，就是针对销量这一整列的数据，此时，选择列式存储结构可能更加适宜。

在技术角度的分类中，严格地讲，SQL方式并不能分为单独的一类，它其实可以看做是对API的封装，通过SQL这种DSL来包装具体的处理技术，从而降低数据处理脚本的迁移成本。毕竟，多数企业内部的数据处理系统，在进入大数据时代之前，大多以SQL形式来访问存储的数据。大体上，SQL是针对MapReduce的包装，例如Hive、Impala或者Spark SQL。

Streaming流处理可以实时地接收由上游源源不断传来的数据，然后以某个细小的时间窗口为单位对这个过程中的数据进行处理。消费的上游数据可以是通过网络传递过来的字节流、从HDFS读取的数据流，又或者是消息队列传来的消息流。通常，它对应的就是编程模型中的实时编程模型。

机器学习与深度学习都属于深度分析的范畴。随着Google的AlphaGo以及TensorFlow框架的开源，深度学习变成了一门显学。我了解不多，这里就不露怯了。

机器学习与常见的数据分析稍有不同，通常需要多个阶段经历多次迭代才能得到满意的结果。下图是深度分析的架构图：

针对存储的数据，需要采集数据样本并进行特征提取，然后对样本数据进行训练，并得到数据模型。倘若该模型经过测试是满足需求的，则可以运用到数据分析场景中，否则需要调整算法与模型，再进行下一次的迭代。

编程模型中的离线编程模型以Hadoop的MapReduce为代表，内存编程模型则以Spark为代表，实时编程模型则主要指的是流处理，当然也可能采用Lambda架构，在Batch Layer（即离线编程模型）与Speed Layer（实时编程模型）之间建立Serving Layer，利用空闲时间与空闲资源，又或者在写入数据的同时，对离线编程模型要处理的大数据进行预先计算（聚合），从而形成一种融合的视图存储在数据库中（如HBase），以便于快速查询或计算。

场景驱动数据处理

不同的业务场景（业务场景可能出现混合）需要的数据处理技术不尽相同，因而在一个大数据系统下可能需要多种技术（编程模型）的混合。

场景1：某厂商的舆情分析

某厂商在实施舆情分析时，根据基于需求，与数据处理有关的部分就包括：语义分析、全文本搜索与统计分析。通过网络爬虫抓取过来的数据会写入到Kafka，而消费端则通过Spark Streaming对数据进行去重去噪，之后交给SAS的ECC服务器进行文本的语义分析。分析后的数据会同时写入到HDFS（Parquet格式的文本）和ElasticSearch。同时，为了避免因为去重去噪算法的误差而导致部分有用数据被“误杀”，在MongoDB中还保存了一份全量数据。如下图所示：

场景2：Airbnb的大数据平台

Airbnb的大数据平台也根据业务场景提供了多种处理方式，整个平台的架构如下图所示：

Panoramix(现更名为Caravel)为Airbnb提供数据探查功能，并对结果进行可视化，Airpal则是基于Web的查询执行工具，它们的底层都是通过Presto对HDFS执行数据查询。Spark集群则为Airbnb的工程师与数据科学家提供机器学习与流处理的平台。

大数据平台的整体结构

行文至此，整个大数据平台系列的讲解就快结束了。最后，我结合数据源、数据采集、数据存储与数据处理这四个环节给出了一个整体结构图，如下图所示：

这幅图以查询检索场景、OLAP场景、统计分析场景与深度分析场景作为核心的四个场景，并以不同颜色标识不同的编程模型。从左到右，经历数据源、数据采集、数据存储和数据处理四个相对完整的阶段，可供大数据平台的整体参考。

马总说过这是一个DT的时代，一个从IT到DT转变的时代。确实这几年到处都能听到诸如“云计算”、“大数据”、“上云”的谈论，确实随着云计算的兴起，依托于相对低成本、高稳定性的云设施构建平台的成本越来越低，越来越多的公司都在推数据相关的平台、产品。如阿里、京东、百度、腾讯，以及一些打着大数据旗号的创业公司都有出自己的数据平台和产品，用户依托于平台确实大大降低了数据处理、使用的难度，降低了从数据挖掘价值的时间成本。于此同时，平台架构的变迁也成为备受关注的问题。今天我们就来看看有哪些大数据的平台架构你不知道。

489034603

一、首先是数据方面（大数据时代以数据为主导）：如何进行模型分层？一般模型分层计算程序，以哪种语言为主？

从数据仓库 或 大数据平台 的角度来讲，数据的分层，大体有两种思路：

a) 基础数据层：主要避免后续数据应用层的大变更。一般面向各业务系统或数据源集，利用业界较为先进的数据模型（如FS-LDM），按数据的特性（即数据驱动）进行数据的整合,以形成相对稳定的基础数据模型层。

b) 应用数据层：一般是面向各应用需求 或 业务用户，利用业界较为合理的数据模型理念（如星型\维度模型），按需求的要求（即需求驱动）进行数据的分布，以形成统计方便、展示友好、满足需求的应用数据模型层。

在数据流向 或 数据处理的过程中，所使用到的语言或方式可能更多的是以下两大类：

a) 基于传统数据库：大多采用ETL的方式，进行数据的抽取、清洗、整合；这中间，可能会利用到类似DataStage，Kettle等工具，用得最多的，可能就是各数据库提供的SQL语言了，SQL语言使用简单、方便、学习门槛较低，且易于掌握。

b) 基于大数据平台：大多采用的开源的工具 或 语言，如Hive, Hbase , Spark,Python等。这里面，可能使用更多的是Hive 与 Python， 这两个工具学习简单，易于掌握，并且，进行数据处理时，也更直观、方便。

二、架构方面：在架构过程中，一般以7点展开，如：

a. 存储和计算都基于HIVE；

b. GREENPLUM作为HIVE的“cache”存在，供用户做一些小数据的快查询，报表存储；

c. 调度：和canaan框架进行整合，支持用户快速新增任务，并自动导入任务依赖；

d. 主数据：保存了数据仓库元数据信息，供用户查询和系统内部各个模块交互；

e. ACL：构建了数据仓库数据访问权限控制，包括用户权限申请、审批者审批、数据赋权等；

f. 传输；

g.监控：由于任务数量增长较快（2000+），运维已经是个问题此外，需花了较大精力做了可视化的工作：

有些朋友不认为Hive是一个数据库，认为Hive是一个类似传统数据库的SQL引擎的工具，虽然Hive有自带的元数据存储库，但这个库里面，也只是存放了Hive工具为完成用户提交的请求而必须要的Hadoop的元数据信息 及两者的映射关系数据；并没有存放用户的任何数据，用户的数据还是存放在Hadoop或Hbase等文件系统或数据库中。

在以上这7点中，最难的就是：数据治理 与 系统监控 这两块

三、数据应用：数据一般以哪种形式，呈现给用户？技术上是通过哪些策略实现？

数据应用主要分成两大类：

a) 面向业务人员：一般是自行研发一个界面美观的WEB应用，调用业界成熟的工具（如MSTR,COGNOS)的API，实现数据展示给终端用户进行查看。

b) 面向IT专业人员：一般是直接从数据库/文件系统中，借助SQL或其它的开源工具，直接查询、统计、分析、挖掘；这样会更直接、更方便。

以上这些可供大家测试一下，有哪些知识是自己还不熟练的，可以再学习，个人观点不喜勿喷，谢谢大家。

另外，如果小伙伴想学习大数据技术，可以加下图片下面的交流群，群里有很多学习视频都可以下载，而且每天大数据架构师马士兵老师都会在群里分享大数据的技术。。

随着大数据越来越被重视，数据采集的挑战变的尤为突出。今天为大家介绍几款数据采集平台：

Apache Flume Fluentd Logstash Chukwa Scribe Splunk Forwarder

大数据平台与数据采集

任何完整的大数据平台，一般包括以下的几个过程：

数据采集–>数据存储–>数据处理–>数据展现(可视化，报表和监控)

其中，数据采集是所有数据系统必不可少的，随着大数据越来越被重视，数据采集的挑战也变的尤为突出。这其中包括：

我们今天就来看看当前可用的六款数据采集的产品，重点关注它们是如何做到高可靠，高性能和高扩展。

1、Apache Flume

Flume 是Apache旗下的一款开源、高可靠、高扩展、容易管理、支持客户扩展的数据采集系统。 Flume使用JRuby来构建，所以依赖Java运行环境。

Flume最初是由Cloudera的工程师设计用于合并日志数据的系统，后来逐渐发展用于处理流数据事件。

Flume设计成一个分布式的管道架构，可以看作在数据源和目的地之间有一个Agent的网络，支持数据路由。

每一个agent都由Source，Channel和Sink组成。

Source

Source负责接收输入数据，并将数据写入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支持监视一个目录或者文件，解析其中新生成的事件。

Channel

Channel 存储，缓存从source到Sink的中间数据。可使用不同的配置来做Channel，例如内存，文件，JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。

Sink

Sink负责从管道中读出数据并发给下一个Agent或者最终的目的地。Sink支持的不同目的地种类包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent。

Flume在source和sink端都使用了transaction机制保证在数据传输中没有数据丢失。

Source上的数据可以复制到不同的通道上。每一个Channel也可以连接不同数量的Sink。这样连接不同配置的Agent就可以组成一个复杂的数据收集网络。通过对agent的配置，可以组成一个路由复杂的数据传输网络。

配置如上图所示的agent结构，Flume支持设置sink的Failover和Load Balance，这样就可以保证即使有一个agent失效的情况下，整个系统仍能正常收集数据。

Flume中传输的内容定义为事件(Event)，事件由Headers(包含元数据，Meta Data)和Payload组成。

Flume提供SDK，可以支持用户定制开发：

Flume客户端负责在事件产生的源头把事件发送给Flume的Agent。客户端通常和产生数据源的应用在同一个进程空间。常见的Flume 客户端有Avro，log4J，syslog和HTTP Post。另外ExecSource支持指定一个本地进程的输出作为Flume的输入。当然很有可能，以上的这些客户端都不能满足需求，用户可以定制的客户端，和已有的FLume的Source进行通信，或者定制实现一种新的Source类型。

同时，用户可以使用Flume的SDK定制Source和Sink。似乎不支持定制的Channel。

2、Fluentd

Fluentd是另一个开源的数据收集框架。Fluentd使用C/Ruby开发，使用JSON文件来统一日志数据。它的可插拔架构，支持各种不同种类和格式的数据源和数据输出。最后它也同时提供了高可靠和很好的扩展性。Treasure Data, Inc 对该产品提供支持和维护。

Fluentd的部署和Flume非常相似：

Fluentd的架构设计和Flume如出一辙：

Fluentd的Input/Buffer/Output非常类似于Flume的Source/Channel/Sink。

Input

Input负责接收数据或者主动抓取数据。支持syslog，http，file tail等。

Buffer

Buffer负责数据获取的性能和可靠性，也有文件或内存等不同类型的Buffer可以配置。

Output

Output负责输出数据到目的地例如文件，AWS S3或者其它的Fluentd。

Fluentd的配置非常方便，如下图：

Fluentd的技术栈如下图：

FLuentd和其插件都是由Ruby开发，MessgaePack提供了JSON的序列化和异步的并行通信RPC机制。

Cool.io是基于libev的事件驱动框架。

FLuentd的扩展性非常好，客户可以自己定制(Ruby)Input/Buffer/Output。

Fluentd从各方面看都很像Flume，区别是使用Ruby开发，Footprint会小一些，但是也带来了跨平台的问题，并不能支持Windows平台。另外采用JSON统一数据/日志格式是它的另一个特点。相对去Flumed，配置也相对简单一些。

3、Logstash

Logstash是著名的开源数据栈ELK (ElasticSearch, Logstash, Kibana)中的那个L。

Logstash用JRuby开发，所有运行时依赖JVM。

Logstash的部署架构如下图，当然这只是一种部署的选项。

一个典型的Logstash的配置如下，包括了Input，filter的Output的设置。

几乎在大部分的情况下ELK作为一个栈是被同时使用的。所有当你的数据系统使用ElasticSearch的情况下，logstash是首选。

4、Chukwa

官网：https://chukwa.apache.org/

Apache Chukwa是apache旗下另一个开源的数据收集平台，它远没有其他几个有名。Chukwa基于Hadoop的HDFS和Map Reduce来构建(显而易见，他用Java来实现)，提供扩展性和可靠性。Chukwa同时提供对数据的展示，分析和监视。很奇怪的是它的上一次 github的更新事7年前。可见该项目应该已经不活跃了。

Chukwa的部署架构如下：

Chukwa的主要单元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去相当复杂。由于该项目已经不活跃，我们就不细看了。

5、Scribe

代码托管：https://github/facebookarchive/scribe

Scribe是Facebook开发的数据(日志)收集系统。已经多年不维护，同样的，就不多说了。

6、Splunk Forwarder

以上的所有系统都是开源的。在商业化的大数据平台产品中，Splunk提供完整的数据采金，数据存储，数据分析和处理，以及数据展现的能力。

Splunk是一个分布式的机器数据平台，主要有三个角色：

Search Head负责数据的搜索和处理，提供搜索时的信息抽取。

Indexer负责数据的存储和索引 Forwarder，负责数据的收集，清洗，变形，并发送给Indexer

Splunk内置了对Syslog，TCP/UDP，Spooling的支持，同时，用户可以通过开发 Input和Modular Input的方式来获取特定的数据。在Splunk提供的软件仓库里有很多成熟的数据采集应用，例如AWS，数据库(DBConnect)等等，可以方便的从云或者是数据库中获取数据进入Splunk的数据平台做分析。

这里要注意的是，Search Head和Indexer都支持Cluster的配置，也就是高可用，高扩展的，但是Splunk现在还没有针对Farwarder的Cluster的功能。也就是说如果有一台Farwarder的机器出了故障，数据收集也会随之中断，并不能把正在运行的数据采集任务Failover到其它的 Farwarder上。

总结

我们简单讨论了几种流行的数据收集平台，它们大都提供高可靠和高扩展的数据收集。大多平台都抽象出了输入，输出和中间的缓冲的架构。利用分布式的网络连接，大多数平台都能实现一定程度的扩展性和高可靠性。

其中Flume，Fluentd是两个被使用较多的产品。如果你用ElasticSearch，Logstash也许是首选，因为ELK栈提供了很好的集成。Chukwa和Scribe由于项目的不活跃，不推荐使用。

Splunk作为一个优秀的商业产品，它的数据采集还存在一定的限制，相信Splunk很快会开发出更好的数据收集的解决方案。

【IT168评论】随着IT架构的不断演进，云计算必定会成为未来所有IT应用的基石，而大数据作为数据应用分析的基础技术未来将会变的越来越重要，大数据为人工智能提供基础物料，为企业决策者提供数据支撑，但是另一方面大数据的高成本和高门槛也让普通企业望而生畏。

但即便如此，依然无法阻挡不少企业对大数据的追求，但大数据平台选型是一个复杂的过程，因此，知名企业的大数据平台架构图就有着重要的参考作用。

10月19日，一年一度的中国系统架构师大会(SACC)再度盛装来袭。SACC 2017云集了百余位国内外的顶级专家，围绕云计算、人工智能、大数据、移动互联网、产业应用等热点领域进行思维碰撞和技术交流。

就在19日下午的《大数据平台架构技术实践(上)》专场中，来自滴滴大数据平台负责人罗李，知乎大数据平台负责人王雨舟，腾讯云托管hadoop服务平台技术负责人陈龙分别分享了各自所在企业的大数据平台架构图。

▲滴滴大数据体系架构图

▲知乎大数据平台架构图

▲腾讯云大数据平台架构图(EMR)

▲更多信息尽请关注IT168专题报道