阿里巴巴数据中台是阿里云上实现数据智能的最佳实践，它是由数据中台方法论+组织+工具所组成，数据中台方法论采用实现企业数据的全局规划设计，通过前期的设计形成统一的数据标准、计算口径，统一保障数据质量，面向数据分析场景构建数据模型，让通用计算和数据能沉淀并能复用，提升计算效能；数据中台的建设实施必须有能与之配合的组织，不仅仅相应岗位的人员要配备齐全，而且组织架构建设也需要对应，有一个数据技术部门统筹企业的数字化转型，数据赋能业务中形成业务模式，在推进数字化转型中实现价值；数据中台由一系列的工具和产品组成，阿里云数据中台以智能数据构建与管理Dataphin产品、商业智能QuickBI工具和企业参谋产品为主体等一系列工具组成。

阿里云在过去几年中经过数十个实际项目沉淀形成实施标准化流程和方法论。阿里云OneData数据中台解决方案基于大数据存储和计算平台为载体，以OneModel统一数据构建及管理方法论为主干，OneID核心商业要素资产化为核心，实现全域链接、标签萃取、立体画像，以数据资产管理为皮，数据应用服务为枝叶的松耦性整体解决方案。其数据服务理念根植于心，强调业务模式，在推进数字化转型中实现价值。

数据中台与数据湖区别
业界近3年对datalake说的比较多，是结合近10年来大数据理念兴起的，首次由Dan Woods在2011年7月福布斯上的“Big Data Requires a Big, New Architecture”中提出，它提出CIO们应该考虑数据湖(“Data lake”)这个思维方式来替代数据仓库(“data warehouse”)的思维，它的架构和理念是把原先不存储的基础数据也存储起来，汇总各个数据源的数据方便以后的数据分析和查询，因此数据湖是数据的聚集、加工为目的数据资源池，但是数据湖只是解决了聚集问题，在数据加工方面由于不可控制的需求变得异常繁重，由于数据的繁杂和混乱引入数据治理让数据的加工更是举步维艰。

阿里巴巴数据中台解决方案，核心产品：
· Dataphin，以阿里巴巴大数据核心方法论OneData为内核驱动，提供一站式数据构建与管理能力；
· Quick BI，集阿里巴巴数据分析经验沉淀，提供一站式数据分析与展现能力；
· Quick Audience，集阿里巴巴消费者洞察及营销经验，提供一站式人群圈选、洞察及营销投放能力，连接阿里巴巴商业，实现用户增长。 

我们先看一下大数据产品的解决方案

 然后，我们先看一下方法论：

 OneData致力干统一数据标准，让数据成为资产而非成本；OneEntity致力于统一实体，让数据融通而以非孤岛存在；OneService致力于统一数据服务，让数据复用而非复制。 

OneData就是数据的标准化治理，OneEntity就是PID系统+用户画像，OneService就是封装的数据中台API

OneData体系方法论

OneData体系方法论至少包括：数据标准化、技术内核工具化、元数据驱动智能化3个方面。

(1)数据标准化。要从源头实施数裾标准化，而非在数据研发之后，基于数据指标梳理的数据字典实施数据标准化。因为，只有每一个数据都是唯一的，数据模型才能稳定、可靠，数据服务才是靠谱、可信的。

(2)技术内核产品化。所有的规范、标准等，如果没有一个全流程的工具作为保障, 则无法实现真正意义上的全链路通，因此，我们首先推进技术内核全面工具化。

(3)元数据驱动智能化。前文提到，阿里正在持续努力实现数据建模后的自动化代码生成，以及保障其实现和运行的智能计算与存储框架。为什么阿里能做这件事情？其中一个重要原因就是，在源头对每个元数据进行了规范定义，尽可能实现数据的原子化和结构化，并将其全部存在元数据中心里。这些元数据对于计算、调度、存储等意义非凡，因此有望实现从人工到半自动化，进而实现智能化。

OneEntity体系方法论

OneEntity体系方法论至少包括：技术驱动数据连接、技术内核工具化、业务驱动技术价值化3个方面。

(1)技术驱动数据连接。OneEntity要实现实体识别，首先依赖很强的实体识别技术，所以要用技术来驱动数据连接。

(2)技术内核产品化。产品化是目标，其发展过程不是一蹴而就的。一定要往这个方向努力，否则每一次进行标签画像（哪怕是类似的标签），都要通过人力重复做一次，这实在是一件让人非常痛苦的事情。所以，要高效地进行实体识別、用户画像，工具化是一条必由之路。当然，全部工具化总是很难实现的，一定还有工具无法替代人脑的部分，所以，努力追求的是将人脑智慧尽可能沉淀在工具型产品中。

(3)业务驱动技术价值化。正如前文所述，将数据从孤岛变得融通，进而实现高价值，是需要业务来驱动的。在此过程中，再一次体现了业务和技术要“背靠背”“你情我愿”地进行双向联动的。

OneService体系方法论

OneService体系方法论至少包括：主题式数据服务、统一但多样化的数据服务、跨源数据服务3个方面。

(1)主题式数据服务。举一个例子，假设用户想要看的是“会员”这个主题下的数裾.，至于“会员”主题背后有1000张物理表还是2000张物理表，他都不关心。而主题式数据服务要做的是，从方便用户的视角出发，从逻辑层面屛蔽这1000张甚至是2000张物理表，以逻辑模型的方式构建而非物理表方式。

(2)统一但多样化的数据服务。例如，双十一当天上百亿次的调用服务是统一的，但获取形式可以是多样化的，可以通过API提供自主的SQL查洵数据服务，也可以通过API提供在线直接调用数椐服务。

(3)跨源数据服务。不管数裾服务的源头在哪里，从数据服务的角度出发，都不应该将这些复杂的情况暴露给用户，而是尽可能地屏蔽多种异构数据源。

首先利用Dataphin的数据同步功能，我们帮助H轻松地将来自不同业务库的数据同步到Dataphin，并根据其业务含义和来源划分不同的业务板块和项目，以更好地对数据进行逻辑隔离和物理隔离，实现数据整合；
其次，利用Dataphin的数据研发能力，我们帮助H对从生产到仓储再到销售的全链路业务流程进行了梳理，并从中提炼出可复用的商品类目、型号等维度；采购、下单等业务流程和支付金额、购买数量等原子指标并构建相应逻辑表，实现数据规范与统一；
接着，我们借助Dataphin的数据萃取功能，以OneID思想为核心帮助H对现有客户进行标签萃取，基于消费行为数据生产出属性标签和偏好类标签（主要是兴趣偏好和行业消费偏好），沉淀会员标签体系，实现消费行为数据萃取与标签生产；
• 最后，我们通过Dataphin的数据服务模块帮助H快速配置并生成可直接使用的API，使其能够简单快速使用基于以上步骤建立的公共数据中心和萃取数据中心数据，并对接QuickAudience等应用实现智能用户洞察和人群圈选，拓展现有营销投放路径，触达更多可能目标客户。
 

1.业界领先的产品技术栈
高性能计算存储引擎，成熟的产品技术栈，提供从数据集成、开发、查询、分析、可视化全链路大数据开发与治理平台
2.成熟的数据体系方法论及数据工具
不仅提供多年沉淀的完善数据体系方法论，同时提供高效易用智能大数据构建及管理的平台及工具
3.建设企业应用级全域数据体系
以统一计算平台为基础，整合业务板块数据资产体系，可持续性推进企业大数据从规模化、体系化、实时化走向智能化

 应用场景说明
全域数据融合，打破数据孤岛，构建数据仓库，将数据管理标准化、体系化、焕活数据价值。
帮助客户实现用户洞察及经营分析，在用户运营、会员增长、营销活动、广告调优等方面发挥数据驱动价值，为各种业务场景提供智能化数据营销分析服务。

数据湖的这种原始数据的复杂性意味着我们可以通过一些方式来将数据转变成一个易于管理的结构，这样还可以减少数据的体量，更易于处理。

数据中台的建设初衷：对于后台的很多功能，同样可以抽象出来，成为各业务共有的能力。这样可以让数据更灵活更敏捷地服务于前台的各项业务。
数据中台的建设误区：更有价值的中台是业务偏向的数据中台，而不是通用型的数据中台。这个观点，和前阿里数据委员会主席车品觉是一致的。
数据中台的建设目标：目的是敏捷地支撑业务部门的业务创新需求，打造快速服务商业需求的服务能力，并且尽量实时处理，体现数据的资产化及价值最大化。

数据库：业务数据库中的数据结构是为了完成交易而设计的，不是为了而查询和分析的便利设计的。业务数据库大多是读写优化的，即又要读（查看商品信息），也要写（产生订单，完成支付）。因此对于大量数据的读（查询指标，一般是复杂的只读类型查询）是支持不足的。

数据仓库的作用在于：
数据结构为了分析和查询的便利；只读优化的数据库，即不需要它写入速度多么快，只要做大量数据的复杂查询的速度足够快就行了。
那么在这里前一种业务数据库（读写都优化）的是业务性数据库，后一种是分析性数据库，即数据仓库

Impala与Hive的异同

相同点：

数据存储：使用相同的存储数据池都支持把数据存储于HDFS, HBase。
元数据：两者使用相同的元数据。
SQL解释处理：比较相似都是通过词法分析生成执行计划。
不同点：

执行计划：

Hive: 依赖于MapReduce执行框架，执行计划分成map->shuffle->reduce->map->shuffle->reduce…的模型。如果一个Query会被编译成多轮MapReduce，则会有更多的写中间结果。由于MapReduce执行框架本身的特点，过多的中间过程会增加整个Query的执行时间。
Impala: 把执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询，而不用像Hive那样把它组合成管道型的map->reduce模式，以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。
数据流：

Hive: 采用推的方式，每一个计算节点计算完成后将数据主动推给后续节点。
Impala: 采用拉的方式，后续节点通过getNext主动向前面节点要数据，以此方式数据可以流式的返回给客户端，且只要有1条数据被处理完，就可以立即展现出来，而不用等到全部处理完成，更符合SQL交互式查询使用。
内存使用：

Hive: 在执行过程中如果内存放不下所有数据，则会使用外存，以保证Query能顺序执行完。每一轮MapReduce结束，中间结果也会写入HDFS中，同样由于MapReduce执行架构的特性，shuffle过程也会有写本地磁盘的操作。
Impala: 在遇到内存放不下数据时，当前版本0.1是直接返回错误，而不会利用外存，以后版本应该会进行改进。这使用得Impala目前处理Query会受到一定的限制，最好还是与Hive配合使用。Impala在多个阶段之间利用网络传输数据，在执行过程不会有写磁盘的操作（insert除外）。
调度：

Hive: 任务调度依赖于Hadoop的调度策略。
Impala: 调度由自己完成，目前只有一种调度器simple-schedule，它会尽量满足数据的局部性，扫描数据的进程尽量靠近数据本身所在的物理机器。调度器目前还比较简单，在SimpleScheduler::GetBackend中可以看到，现在还没有考虑负载，网络IO状况等因素进行调度。但目前Impala已经有对执行过程的性能统计分析，应该以后版本会利用这些统计信息进行调度吧。
容错：

Hive: 依赖于Hadoop的容错能力。
Impala: 在查询过程中，没有容错逻辑，如果在执行过程中发生故障，则直接返回错误（这与Impala的设计有关，因为Impala定位于实时查询，一次查询失败，再查一次就好了，再查一次的成本很低）。但从整体来看，Impala是能很好的容错，所有的Impalad是对等的结构，用户可以向任何一个Impalad提交查询，如果一个Impalad失效，其上正在运行的所有Query都将失败，但用户可以重新提交查询由其它Impalad代替执行，不会影响服务。对于State Store目前只有一个，但当State Store失效，也不会影响服务，每个Impalad都缓存了State Store的信息，只是不能再更新集群状态，有可能会把执行任务分配给已经失效的Impalad执行，导致本次Query失败。
适用面：

Hive: 复杂的批处理查询任务，数据转换任务。
Impala：实时数据分析，因为不支持UDF，能处理的问题域有一定的限制，与Hive配合使用,对Hive的结果数据集进行实时分析。
Impala的优缺点

优点：

支持SQL查询，快速查询大数据。
可以对已有数据进行查询，减少数据的加载，转换。
多种存储格式可以选择（Parquet, Text, Avro, RCFile, SequeenceFile）。
可以与Hive配合使用。
缺点：

不支持用户定义函数UDF。
不支持text域的全文搜索。
不支持Transforms。
不支持查询期的容错。
对内存要求高。
在Cloudera的测试中，Impala的查询效率比Hive有数量级的提升。从技术角度上来看，Impala之所以能有好的性能，主要有以下几方面的原因。

Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销。
省掉了MapReduce作业启动的开销。MapReduce启动task的速度很慢（默认每个心跳间隔是3秒钟），Impala直接通过相应的服务进程来进行作业调度，速度快了很多。
Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想另起炉灶，因此可做更多的查询优化，从而省掉不必要的shuffle、sort等开销。
通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销。
用C++实现，做了很多有针对性的硬件优化，例如使用SSE指令。
使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。

腾讯云的ckafka架构解决了什么样的问题？
1、在高负载情况下的调优
2、增强了容错机制
3、增强了故障处理机制