阿里巴巴大数据架构

① 目前各大互联网公司如阿里，腾讯，滴滴，美团，今日头条这些公司的大数据分析的框架是怎样的求解答！

阿里，腾讯 实力强，估计是自己开发或二次开发的，其他公司估计会版用开源或商用权的，但本质都是相同的，举例，不外乎一个分布式集群（hadoop），搭配一些部署组件（docker，zookeeper），分布MQ（kafka），处理&计算（spark，hive，MR），存储（es，hbase，mongo），可视化的话选择很多，比如vue，react，angular，画图可以选择highchart，echarts。
上述基本都是必备的，每个公司还会根据自己的需求增加额外的组件。

② 大数据之路

人类从“IT时代”进入“DT时代”。本书介绍了阿里巴巴的大数据系统架构，为了满足不断变化的业务需求，同时实现系统的 高扩展性 、 灵活性 以及 数据展现的高性能 。
数据体系主要包括： 数据采集 、 数据计算 、 数据服务 和 数据应用 四大层次。

事实表包括引用的 维度 和描述具体业务的 度量 。

事实表中一条记录描述的业务的细节程度称为 粒度 。粒度可以使用两种方式来表示：（1）维度属性组合（2）所表示的具体业务含义。

事实包括可加性、半可加性和不可加性三种类型：
半可加性：只可以针对特定维度做聚合，例如库存（不能按照日期，可按照仓库聚合）。
可加性：可以按照任意维度聚合。
不可加性：完全不具备可加性。（例如：比率，事实表可以拆分存储分子分母）

维度属性也可以存到事实表中，称为 退化维度 。

事实表有三种类型：事务事实表、周期快照事实表、累计快照事实表。
事务事实表描述的是业务过程上的原子事务，也称为 原子事实表 。
周期快照事实表是按照周期性规律的时间间隔记录事实。
累计快照事实表：累计快照事实表用来表示过程开始和结束过程之间的关键步骤事件，覆盖整个生命周期，通常用多个日期字段记录关键时间点，记录会随着时间变化而修改。

事实表设计原则：
原则1： 尽可能包含所有与业务过程相关的事实。
即时存在冗余，也尽可能存储。

原则2：只选择与业务过程相关的事实。

原则3：分解不可加事实为可加的组件。
例如：不存成单率，转而存储成单数和提单数。

原则4：选择维度和事实前，必须先声明粒度。
建议粒度设置的越细越好，这样可以最大限度的提高灵活性。可以通过业务描述或者维度属性组合的方式来定义粒度。

原则5：在同一个事实表中，不应该有不同粒度的事实。
例如：一个事实表中不应该包含某些精确到订单粒度的度量，同时又包含只精确到城市的度量。

原则6：事实的单位一致。

原则7：尽量处理掉事实表中的null值。
SQL中大于，小于的条件不适用与null值，所以尽量用数值替代null，例如0.

原则8：使用退化维度增加事实表的易用性。
在Kimball的维度设计模型中，分拆出单独的维度表，为了节省存储。但是为了减少使用时的关联次数，可以多使用退化维度提供事实表易用性。

事实表设计方法：
1.选择业务过程及确定事实表类型。2. 声明粒度。3.确定维度。4.确定事实。5.冗余维度（设计退化维度）。

事务事实表，即针对业务过程构建的一类事实表，用来跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细数据。

单事务事实表，即针对每一个业务过程设计一个事实表，这样可以方便地对每一个业务过程进行分析研究。

表示同一个事实表包含不同的业务过程。多事务事实表有两种实现方法：（1）使用两个不同的事实字段来保存各自业务过程。（2）使用同一个字段保存，但是增加一个业务过程标签。
下面举例说明，淘宝交易事务事实表同时包含下单、支付和成功完结三个过程，三个过程粒度一致，可以放在一个事实表。下面确定维度和事实，该表中的下单度量、支付度量和成功完结度量信息分别存在不同字段，如果不是当前业务处理，则用0来处理。
当不同业务过程的度量比较相似、差异不大时使用第二种事实表（使用一个字段保存），当不同业务过程的度量差异大时，使用第一种（多字段保存）。

对于单事务事实表和多事务事实表的选择上，可以从以下一些方面来区分：
业务过程、粒度和维度（不同业务过程粒度相同，并且维度相似时，可以选用单事务事实表）、事实、下游业务使用、计算存储成本。电商环境下，有父子订单的概念，店铺多商品各生成一个订单，在一个店铺合成一个父订单。

1.事实完整性：事实表包含与其描述的过程有关的所有事实。
2.事实一致性：明确存储每一个事实以确保度量一致性。例如，有下单商品数和商品价格2个事实，同时保存下单金额（价格*商品数）。这样下游使用时，直接取下单金额，而不是再次计算，以保证指标的一致性。
3.事实可加性：为确保下游使用时，指标的可聚合性，尽量保存原始数，而不是计算后的比率指标。

对于事务度量，事务性事实表可以很好地表征。但是对于一些 状态度量 ，例如买卖家累计交易金额、商品库存、买卖家星级、温度（事务事实表无法聚合得到）等，事务事实表的效率较低或者无法处理。为了解决状态度量问题，引入周期性快照事实表（也称为 快照事实表 ）。

1.用快照采样状态：快照事实表以预定的间隔采样状态度量。
2.快照粒度：快照事实表通常总是被多维声明，即快照需要采样的周期以及什么将被采样。
3.密度和稠密性：稠密性是快照事实表的重要特征。事务事实表一般都是稀疏的，只要发生业务才会有相应记录。
4.半可加性：快照事实表的状态度量都是半可加的，例如商品库存，只针对商品维度可加，对日期维度不可加。

设计快照事实表，首先确定快照粒度，然后确定采样的状态度量。下面介绍几个快照事实表实例。
单维度每天快照事实表、混合维度每天快照事实表，这两种快照表都可以从事务事实表汇总得到。另外的一种产出模式是直接使用操作型系统作为数据源来加工，例如淘宝卖家的星级评分是在操作型系统中计算得出的，仓库直接拿来这部分数据加入事实表。全量快照事实表，是特殊类型的周期快照表，例如设计无事实的事实表来记录评论的状态度量。

对于研究事件之间的时间间隔需求时，累计快照事实表能较好符合需求。
特点：
1.数据不断更新：例如，在下单、支付和确认收货三个业务过程中，事务事实表会生成3条记录，而累计快照表会不断更新一条记录（不生成新记录）。
2.多业务过程日期：
累计快照表适用于具有较明确起止时间的短生命周期的实体，对于每个实体都经历从诞生到消亡等步骤。
3.存储历史全量数据。

1.事件类的，例如浏览日志。
2.条件范围资格类的，例如客户和销售人员的分配情况。

主要是提前聚合，为了增加数据访问的效率（不用再聚合了），减少数据不一致的情况。这类聚集汇总数据，被称为“公共汇总层”。
聚集的基本步骤：1.确定聚集维度。2.确定一致性上钻。3.确定聚集事实。

元数据主要记录数据仓库中模型的定义、各层级间映射关系、监控数据仓库的数据状态及ETL任务的运行状态。元数据分为 技术元数据 和 业务元数据 。
阿里巴巴技术元数据包括：
数据表、列等信息；ETL作业的信息；数据同步、任务调度、计算任务等信息。数据质量和运维相关元数据。
阿里巴巴业务元数据包括：
维度属性、业务过程、指标等。数据应用元数据，例如数据报表、数据产品等。

元数据价值：
元数据在数据管理方面为集团数据在计算、存储、成本、质量、安全、模型等治理领域上提供数据支持。

阿里MaxCompute提供了archive压缩方法，采用了具有更高压缩比压缩算法，将数据以RAID file的形式存储。这样可以节省空间，但是恢复起来也更复杂，所以适用于冷备份的数据。

MaxCompute基于列存储，通过修改表的数据重分布，避免列热点，将会节省一定存储空间。

存储治理项以元数据为基础，列出例如“62天内未访问的分区”、“数据无更新的任务列表”等等管理项推动ETL优化。形成现状分析、问题诊断、管理优化、效果反馈的存储治理项优化的闭环。

生命周期管理的目的是用最少的存储成本来满足最大业务需求，实现数据价值最大化。
1.周期性删除策略：
2.彻底删除策略：主要针对无用表，ETL中间过程表。
3.永久保存策略：
4.极限存储策略：
5.冷数据管理策略：针对重要且访问频率低的数据。
6.增量表merge全量表策略：

将一个数据表的成本分为存储成本和计算成本，除此之外，上游表对该表的扫描成本也应该计入。相应的计费分别核算为：计算付费、存储付费和扫描付费。数据资产的成本管理分为数据成本计量和数据使用计费。

③ 从IT到DT 阿里大数据背后的商业秘密

从IT到DT：阿里大数据背后的商业秘密

空气污染究竟在多大程度上影响了人们的网购行为？有多少比重的线上消费属于新增消费？为什么中国的“电商百佳县”中浙江有41个而广东只有4个？
这些电商的秘密就隐藏在阿里巴巴商业生态的“大数据”中。
“未来制造业的最大能源不是石油，而是数据。”阿里巴巴董事局主席马云如此形容“数据”的重要意义。
在他看来，阿里巴巴本质上是一家数据公司，做淘宝的目的是为了获得零售的数据和制造业的数据；做蚂蚁金服的目的是建立信用体系；做物流不是为了送包裹，而是这些数据合在一起，“电脑会比你更了解你”。与此同时，产业的发展也正在从IT时代走向以大数据技术为代表的DT时代。
而在阿里巴巴内部，由电子商务、互联网金融、电商物流、云计算与大数据等构成的阿里巴巴互联网商业生态圈，也正是阿里研究院所扎根的“土壤”。
具体而言，阿里巴巴平台的所有海量数据来自于数百万充满活力的小微企业、个人创业者以及数亿消费者，阿里研究院通过对他们的商务活动和消费行为等进行研究分析，从某种程度上可以反映出一个地方乃至宏观经济的结构和发展趋势。
而随着阿里巴巴生态体系的不断拓展和延伸，阿里巴巴的数据资源一定程度上将能够有效补充传统经济指标在衡量经济冷暖方面存在的滞后性，帮助政府更全面、及时、准确地掌握微观经济的运行情况。
从IT到DT
不同于一些企业以技术研究为导向的研究院，阿里研究院副院长宋斐告诉《第一财经日报》记者，阿里研究院定位于面向研究者和智库机构，主要的研究方向包括未来研究（如信息经济）、微观层面上的模式创新研究（如C2B模式、云端制组织模式）、中观层面上的产业互联网化研究（如电商物流、互联网金融、农村电商等）、宏观层面上新经济与传统经济的互动研究（如互联网与就业、消费、进出口等）、互联网治理研究（如网规、电商立法）等。
具体到数据领域，就是在阿里巴巴互联网商业生态基础上，从企业数据、就业数据、消费数据、商品数据和区域数据等入手，通过大数据挖掘和建模，开发若干数据产品与服务。
例如，将互联网数据与宏观经济统计标准对接的互联网经济数据统计标准，包括了中国城市分级标准；网络消费结构分类标准；网上商品与服务分类标准等。
而按经济主题划分的经济信息统计数据库则包括商品信息统计数据库；网购用户消费信息统计数据库；小企业与就业统计数据库；区域经济统计数据库。
还有反映电商经济发展的“晴雨表”——阿里巴巴互联网经济系列指数。其中包括反映网民消费意愿的阿里巴巴消费者信心指数aCCI、反映网购商品价格走势的阿里巴巴全网网购价格指数aSPI和固定篮子的网购核心价格指数aSPI-core、反映网店经营状态的阿里巴巴小企业活跃度指数aBAI、反映区域电子商务发展水平的阿里巴巴电子商务发展指数aEDI等等。其中，现有aSPI按月呈报给国家统计局。
而面向地方政府决策与分析部门的数据产品“阿里经济云图”，则将分阶段地推出地方经济总览、全景分析、监测预警以及知识服务等功能。宋斐告诉记者，其数据可覆盖全国各省、市、区县各级行政单位，地方政府用户经过授权后，可以通过阿里经济云图看到当地在阿里巴巴平台上产生的电子商务交易规模、结构特征及发展趋势。
“借助数据可视化和多维分析功能，用户可以对当地优势产业进行挖掘、对消费趋势与结构变动进行监测、与周边地区进行对比等等。”宋斐表示，该产品未来还可以提供API服务模式，以整合更多的宏观经济数据和社会公开数据，为当地经济全貌进行画像，给大数据时代的政府决策体系带来新的视角和工具。
数据会“说话”
对于如何利用“大数据”，马云在公司内部演讲中曾提到：“未来几年内，要把一切业务数据化，一切数据业务化。”
其中，后半句话可以理解为，让阿里巴巴各项业务所产生、积累的大数据来丰富阿里的生态，同时让生态蕴含的数据产生新的价值，再反哺生态，这是一个相辅相成的循环逻辑。
宋斐对记者举例称，蚂蚁金服旗下的芝麻信用已获得人民银行个人征信牌照批准筹备，未来将通过分析大量的网络交易及行为数据，如用户信用历史、行为偏好、履约能力、身份特质、人脉等信息，对用户进行信用评估，这些信用评估可以帮助互联网金融企业对用户的还款意愿及还款能力做出结论，继而为用户提供快速授信及现金分期服务。本质上来说，“芝麻信用”是一套征信系统，该系统收集来自政府、金融系统的数据，还会充分分析用户在淘宝、支付宝等平台的行为记录。
再如，对于如火如荼的农村电商领域，阿里研究院从2010年就已开始对“沙集模式”个案进行研究，后续一系列基于数据和案例调研所驱动的农村电商研究成果，对于地方政府科学决策，推动当地农村电子商务发展、创造就业和发展地方经济起到了助力作用。到2014年底，全国已经涌现了212个淘宝村，而阿里巴巴也在这一年启动千县万村计划,将在三至五年内投资100亿元,在农村建立起电子商务服务体系。
除了通过数据分析去助力业务外，宋斐告诉记者，有时候大数据报告可能会与传统的印象结论差异很大。
以区域电子商务为例，在阿里研究院发布的2014年中国电商百强县排行榜中，浙江有41个县入围，福建有16个，而广东只有4个，这个结果与传统的印象相差比较大。而事实上，这是因为浙江和广东两省电商发展在地理分布、产业结构等方面的明显不同而带来的。
再如，外界常常认为网络零售替代了线下零售，但事实上，麦肯锡《中国网络零售革命：线上购物助推经济增长》的研究报告，通过借鉴阿里研究中心（阿里研究院前身）和淘宝网UED用户研究团队的大量报告与数据，最后发现：“约60%的线上消费确实取代了线下零售；但剩余的40%则是如果没有网络零售就不会产生的新增消费。”
“这一研究成果，有助于社会各界准确认识网络零售与线下零售的关系，共同探索和建设良好的商业发展环境。”

④ 阿里巴巴的大数据包括

1. 大数据基础服务包括 Maxcompute 分析型数据库等

2. 大数据分析于展现包括内容 Date V Quick BI 画像分析等
   

3. 大数据应用 包括 推荐引擎 企业图谱

建议可以从阿里云的大数据认证了解，参加阿里云大数据认证培训快速熟悉阿里云产品

⑤ 阿里巴巴四大业务板块

阿里巴巴集团经营多项业务，业务包括核心电商、云计算、数字媒体和娱乐以及创新项目另外也从关联公司的业务和服务中取得经营商业生态系统上的支援。业务和关联公司的业务包括：淘宝网、天猫、聚划算、全球速卖通、阿里巴巴国际交易市场、1688、阿里妈妈、阿里云、蚂蚁金服、菜鸟网络等。

2014年9月19日，阿里巴巴集团在纽约证券交易所正式挂牌上市，股票代码“BABA”，创始人和董事局主席为马云。《财富》世界500强排行榜发布，阿里巴巴集团排名300位。2018年12月，阿里巴巴入围2018世界品牌500强。

(5)阿里巴巴大数据架构扩展阅读：

1、阿里巴巴业务板块：

阿里系的电子商务服务、蚂蚁金融服务、菜鸟物流服务、大数据云计算服务、广告服务、跨境贸易服务、前六个电子商务服务以外的互联网服务。

2、阿里巴巴组织架构：

2012年7月23日，阿里巴巴集团对业务架构和组织进行调整，从子公司制调整为事业群制，成立淘宝、一淘、天猫、聚划算、阿里国际业务、阿里小企业业务和阿里云共七个事业群。

3、阿里巴巴业务模式：

阿里巴巴已经形成了一个通过自有电商平台沉积以及UC、高德地图、企业微博等端口导流，围绕电商核心业务及支撑电商体系的金融业务，以及配套的本地生活服务、健康医疗等，囊括游戏、视频、音乐等泛娱乐业务和智能终端业务的完整商业生态圈。

参考资料来源：阿里巴巴官网-公司简介

⑥ 阿里的总监将大数据、数字化的经验，总结成资料干货，可以收藏

阿里把企业的数字化转型划分为“数字化重构”和“数字化增长”两大类别，这个概念是不是听着很难懂？

重构，就是转型嘛；增长，就是更进一步嘛，说白了还是原来的老样子，换了个解释而已。

说到数字化转型，我觉得这是一个非常好的话题，甚至能衍生出很多干货，无论是传统企业，还是顶尖的互联网大公司，如阿里腾讯，老板都在朝这个方向努力。

所以和大数据有关的知识，还是很有必要学习的。

我给大家整理了很多干货，我从一个10年从业者和管理者的角度，这份干货，无论是底层干活的，中层管控的，上层布局的，都能够很清楚的学习到。

涉及到的方面还是很广的：大数据、数仓、中台、AI、IT规划、大数据平台、BI工具。

我是怎么总结的？

从架构入手，到每个模块的分解，再到每个地方的注意点，基本上就行了，太细的也不是通过文字去说清楚的。

只要能做到，看了干货资料，能对实际工作产生指导，就可以了。

这只是一部分，还有更多，自己来看就好。

⑦ 阿里巴巴采用自己研发的分布式数据库系统叫什么,它有哪些特点

AanlyticDB，可以兼容Mysql5.x系列和抄SQL等，阿里巴巴袭自主研发、唯一经过超大规模以及核心业务验证的PB级实时数据仓库。自2012年第一次在集团发布上线以来，至今已累计迭代发布近百个版本，支撑起集团内的电商、广告、菜鸟、文娱、飞猪等众多在线分析业务。阿里巴巴最初通过单节点Oracle进行准实时分析,后来转到OracleRAC，随着业务的飞速发展,集中式的SharedStorage架构需要快速转向分布式，迁移到了Greenplum，但不到一年时间便遇到扩展性和并发的严重瓶颈。为了迎接更大数据集、更高并发、更高可用、更实时的数据应用发展趋势，从2011年开始，在线分析这个技术领域，阿里实时数仓坚定的走上了自研之路。特点和性能参考这个网络网页链接

⑧ 阿里巴巴由哪些部门构成的，具体系统怎么运作的

阿里巴巴由25个事业部组成。具体事业部的业务发展将由各事业部总裁（总经理）版负责。新体系由战权略决策委员会和战略管理执行委员会构成。阿里巴巴集团经营多项业务，另外也从关联公司的业务和服务中取得经营商业生态系统上的支援。

25个事业部及其负责人：

(8)阿里巴巴大数据架构扩展阅读

阿里巴巴网络技术有限公司（简称：阿里巴巴集团）是以曾担任英语教师的马云为首的18人于1999年在浙江杭州创立。

阿里巴巴集团经营多项业务，另外也从关联公司的业务和服务中取得经营商业生态系统上的支援。业务和关联公司的业务包括：淘宝网、天猫、聚划算、全球速卖通、阿里巴巴国际交易市场、1688、阿里妈妈、阿里云、蚂蚁金服、菜鸟网络等。

⑨ 阿里巴巴运用大数据包括哪些

1. 大数据计算服务（MaxCompute，原ODPS）

2. Data IDE（原BASE）

3. 数据集成（原CDP云道）

4. 大数据基础服务包括 Maxcompute 分析型数据库等
   

5. 大数据分析于展现包括 Date V Quick BI 画像分析等
   

6. 大数据应用 包括 推荐引擎 企业图谱

⑩ 转载：阿里巴巴为什么选择Apache Flink

本文主要整理自阿里巴巴计算平台事业部资深技术专家莫问在云栖大会的演讲。

合抱之木，生于毫末

随着人工智能时代的降临，数据量的爆发，在典型的大数据的业务场景下数据业务最通用的做法是：选用批处理的技术处理全量数据，采用流式计算处理实时增量数据。在绝大多数的业务场景之下，用户的业务逻辑在批处理和流处理之中往往是相同的。但是，用户用于批处理和流处理的两套计算引擎是不同的。

因此，用户通常需要写两套代码。毫无疑问，这带来了一些额外的负担和成本。阿里巴巴的商品数据处理就经常需要面对增量和全量两套不同的业务流程问题，所以阿里就在想，我们能不能有一套统一的大数据引擎技术，用户只需要根据自己的业务逻辑开发一套代码。这样在各种不同的场景下，不管是全量数据还是增量数据，亦或者实时处理，一套方案即可全部支持， 这就是阿里选择Flink的背景和初衷 。

目前开源大数据计算引擎有很多选择，流计算如Storm,Samza,Flink,Kafka Stream等，批处理如Spark,Hive,Pig,Flink等。而同时支持流处理和批处理的计算引擎，只有两种选择：一个是Apache Spark，一个是Apache Flink。

从技术，生态等各方面的综合考虑。首先，Spark的技术理念是基于批来模拟流的计算。而Flink则完全相反，它采用的是基于流计算来模拟批计算。

从技术发展方向看，用批来模拟流有一圆轮定的技术局限性，并且这个局限性可能很难突破。而Flink基于流来模拟批，在技术上有更好的扩展性。从长远来看，阿里决定用Flink做一个统一的、通用的大数据引擎作为未来的选型。

Flink是一个低延迟、高吞吐、统一的大数据计算引擎。在阿里巴巴的生产环境中，Flink的计算平台可以实现毫秒级的延迟情况下，每秒钟处理上亿次的消息或者事件。同时Flink提供了一个Exactly-once的一致性语义。保证了数据的正确性。这样就使得Flink大数据引擎可以提供金融级的数据处理能力橘仿信。

Flink在阿里的现状

基于Apache Flink在阿里巴巴搭建的平台于2016年正式上线，并从阿里巴巴的搜索和推荐这两大场景开始实现。目前阿里巴巴所有的业务，包括阿里巴巴所有子公司都采用了基于Flink搭建的实时计算平台。同时Flink计算平台运行在开源的Hadoop集群之上。采用Hadoop的YARN做为资源管理调度，以 HDFS作为数据存储。因此，Flink可以和开源大数据软件Hadoop无缝对接。

目前，这套基于Flink搭建的实时计算平台不仅服务于阿里巴巴集团内部，而且通过阿里云的云产品API向整个开发者生态提供基于Flink的云产品支持。

Flink在阿里巴巴的大规模应用，表现如何？

规模： 一个系统是否成熟，规模是重要指标，Flink最初上线阿里巴巴只有数百台服务器，目前规模已达上万台，此等规模在全球范围内也是屈指可数；

状态数据： 基于Flink，内部积累起来的状态数据已经是PB级别规模；

Events： 如今每天在Flink的计算平台上，处理的数据已经超过万亿条；

PS： 在峰值期间可以承担每秒超过4.72亿次的访问，最典型的应用场景是阿里巴巴双11大屏；

Flink的发展之路

接下来从开源技术的角度，来谈一谈Apache Flink是如何诞生的，它是如何成长的大帆？以及在成长的这个关键的时间点阿里是如何进入的？并对它做出了那些贡献和支持？

Flink诞生于欧洲的一个大数据研究项目StratoSphere。该项目是柏林工业大学的一个研究性项目。早期，Flink是做Batch计算的，但是在2014年，StratoSphere里面的核心成员孵化出Flink，同年将Flink捐赠Apache，并在后来成为Apache的顶级大数据项目，同时Flink计算的主流方向被定位为Streaming，即用流式计算来做所有大数据的计算，这就是Flink技术诞生的背景。

2014年Flink作为主攻流计算的大数据引擎开始在开源大数据行业内崭露头角。区别于Storm,Spark Streaming以及其他流式计算引擎的是：它不仅是一个高吞吐、低延迟的计算引擎，同时还提供很多高级的功能。比如它提供了有状态的计算，支持状态管理，支持强一致性的数据语义以及支持Event Time,WaterMark对消息乱序的处理。

Flink核心概念以及基本理念

Flink最区别于其他流计算引擎的，其实就是状态管理。

什么是状态？例如开发一套流计算的系统或者任务做数据处理，可能经常要对数据进行统计，如Sum,Count,Min,Max,这些值是需要存储的。因为要不断更新，这些值或者变量就可以理解为一种状态。如果数据源是在读取Kafka,RocketMQ，可能要记录读取到什么位置，并记录Offset，这些Offset变量都是要计算的状态。

Flink提供了内置的状态管理，可以把这些状态存储在Flink内部，而不需要把它存储在外部系统。这样做的好处是第一降低了计算引擎对外部系统的依赖以及部署，使运维更加简单；第二，对性能带来了极大的提升：如果通过外部去访问，如Redis,HBase它一定是通过网络及RPC。如果通过Flink内部去访问，它只通过自身的进程去访问这些变量。同时Flink会定期将这些状态做Checkpoint持久化，把Checkpoint存储到一个分布式的持久化系统中，比如HDFS。这样的话，当Flink的任务出现任何故障时，它都会从最近的一次Checkpoint将整个流的状态进行恢复，然后继续运行它的流处理。对用户没有任何数据上的影响。

Flink是如何做到在Checkpoint恢复过程中没有任何数据的丢失和数据的冗余？来保证精准计算的？

这其中原因是Flink利用了一套非常经典的Chandy-Lamport算法，它的核心思想是把这个流计算看成一个流式的拓扑，定期从这个拓扑的头部Source点开始插入特殊的Barries，从上游开始不断的向下游广播这个Barries。每一个节点收到所有的Barries,会将State做一次Snapshot，当每个节点都做完Snapshot之后，整个拓扑就算完整的做完了一次Checkpoint。接下来不管出现任何故障，都会从最近的Checkpoint进行恢复。

Flink利用这套经典的算法，保证了强一致性的语义。这也是Flink与其他无状态流计算引擎的核心区别。

下面介绍Flink是如何解决乱序问题的。比如星球大战的播放顺序，如果按照上映的时间观看，可能会发现故事在跳跃。

在流计算中，与这个例子是非常类似的。所有消息到来的时间，和它真正发生在源头，在线系统Log当中的时间是不一致的。在流处理当中，希望是按消息真正发生在源头的顺序进行处理，不希望是真正到达程序里的时间来处理。Flink提供了Event Time和WaterMark的一些先进技术来解决乱序的问题。使得用户可以有序的处理这个消息。这是Flink一个很重要的特点。

接下来要介绍的是Flink启动时的核心理念和核心概念，这是Flink发展的第一个阶段；第二个阶段时间是2015年和2017年，这个阶段也是Flink发展以及阿里巴巴介入的时间。故事源于2015年年中，我们在搜索事业部的一次调研。当时阿里有自己的批处理技术和流计算技术，有自研的，也有开源的。但是，为了思考下一代大数据引擎的方向以及未来趋势，我们做了很多新技术的调研。

结合大量调研结果，我们最后得出的结论是：解决通用大数据计算需求，批流融合的计算引擎，才是大数据技术的发展方向，并且最终我们选择了Flink。

但2015年的Flink还不够成熟，不管是规模还是稳定性尚未经历实践。最后我们决定在阿里内部建立一个Flink分支，对Flink做大量的修改和完善，让其适应阿里巴巴这种超大规模的业务场景。在这个过程当中，我们团队不仅对Flink在性能和稳定性上做出了很多改进和优化，同时在核心架构和功能上也进行了大量创新和改进，并将其贡献给社区，例如：Flink新的分布式架构，增量Checkpoint机制,基于Credit-based的网络流控机制和Streaming SQL等。

阿里巴巴对Flink社区的贡献

我们举两个设计案例，第一个是阿里巴巴重构了Flink的分布式架构，将Flink的Job调度和资源管理做了一个清晰的分层和解耦。这样做的首要好处是Flink可以原生的跑在各种不同的开源资源管理器上。经过这套分布式架构的改进，Flink可以原生地跑在Hadoop Yarn和Kubernetes这两个最常见的资源管理系统之上。同时将Flink的任务调度从集中式调度改为了分布式调度，这样Flink就可以支持更大规模的集群，以及得到更好的资源隔离。

另一个是实现了增量的Checkpoint机制，因为Flink提供了有状态的计算和定期的Checkpoint机制，如果内部的数据越来越多，不停地做Checkpoint,Checkpoint会越来越大，最后可能导致做不出来。提供了增量的Checkpoint后，Flink会自动地发现哪些数据是增量变化，哪些数据是被修改了。同时只将这些修改的数据进行持久化。这样Checkpoint不会随着时间的运行而越来越难做，整个系统的性能会非常地平稳，这也是我们贡献给社区的一个很重大的特性。

经过2015年到2017年对Flink Streaming的能力完善，Flink社区也逐渐成熟起来。Flink也成为在Streaming领域最主流的计算引擎。因为Flink最早期想做一个流批统一的大数据引擎，2018年已经启动这项工作，为了实现这个目标，阿里巴巴提出了新的统一API架构，统一SQL解决方案，同时流计算的各种功能得到完善后，我们认为批计算也需要各种各样的完善。无论在任务调度层，还是在数据Shuffle层，在容错性，易用性上，都需要完善很多工作。

篇幅原因，下面主要和大家分享两点：

● 统一 API Stack

● 统一 SQL方案

先来看下目前Flink API Stack的一个现状，调研过Flink或者使用过Flink的开发者应该知道。Flink有2套基础的API，一套是DataStream，一套是DataSet。DataStream API是针对流式处理的用户提供，DataSet API是针对批处理用户提供，但是这两套API的执行路径是完全不一样的，甚至需要生成不同的Task去执行。所以这跟得到统一的API是有冲突的，而且这个也是不完善的，不是最终的解法。在Runtime之上首先是要有一个批流统一融合的基础API层，我们希望可以统一API层。

因此，我们在新架构中将采用一个DAG（有限无环图）API，作为一个批流统一的API层。对于这个有限无环图，批计算和流计算不需要泾渭分明的表达出来。只需要让开发者在不同的节点，不同的边上定义不同的属性，来规划数据是流属性还是批属性。整个拓扑是可以融合批流统一的语义表达，整个计算无需区分是流计算还是批计算，只需要表达自己的需求。有了这套API后，Flink的API Stack将得到统一。

除了统一的基础API层和统一的API Stack外，同样在上层统一SQL的解决方案。流和批的SQL，可以认为流计算有数据源，批计算也有数据源，我们可以将这两种源都模拟成数据表。可以认为流数据的数据源是一张不断更新的数据表，对于批处理的数据源可以认为是一张相对静止的表，没有更新的数据表。整个数据处理可以当做SQL的一个Query，最终产生的结果也可以模拟成一个结果表。

对于流计算而言，它的结果表是一张不断更新的结果表。对于批处理而言，它的结果表是相当于一次更新完成的结果表。从整个SOL语义上表达，流和批是可以统一的。此外，不管是流式SQL，还是批处理SQL，都可以用同一个Query来表达复用。这样以来流批都可以用同一个Query优化或者解析。甚至很多流和批的算子都是可以复用的。

Flink的未来方向

首先，阿里巴巴还是要立足于Flink的本质，去做一个全能的统一大数据计算引擎。将它在生态和场景上进行落地。目前Flink已经是一个主流的流计算引擎，很多互联网公司已经达成了共识：Flink是大数据的未来，是最好的流计算引擎。下一步很重要的工作是让Flink在批计算上有所突破。在更多的场景下落地，成为一种主流的批计算引擎。然后进一步在流和批之间进行无缝的切换，流和批的界限越来越模糊。用Flink,在一个计算中，既可以有流计算，又可以有批计算。

第二个方向就是Flink的生态上有更多语言的支持，不仅仅是Java，Scala语言，甚至是机器学习下用的Python，Go语言。未来我们希望能用更多丰富的语言来开发Flink计算的任务，来描述计算逻辑，并和更多的生态进行对接。

最后不得不说AI，因为现在很多大数据计算的需求和数据量都是在支持很火爆的AI场景，所以在Flink流批生态完善的基础上，将继续往上走，完善上层Flink的Machine Learning算法库，同时Flink往上层也会向成熟的机器学习，深度学习去集成。比如可以做Tensorflow On Flink, 让大数据的ETL数据处理和机器学习的Feature计算和特征计算，训练的计算等进行集成，让开发者能够同时享受到多种生态给大家带来的好处。