随着阿里系的应用几乎覆盖了移动互联网的全行业，阿里巴巴开始致力于搭建世界一流的计算引擎。
在2015年，阿里巴巴开始将视线转向Flink，发现表现不错，于是开始将其投入到计算引擎的测试中，并定义内部名称为Blink。在随后的一年克服了稳定性和可靠性的问题；而到了2017年，就开始专注于Blink各组件性能的提升，包括SQL的功能及平台。
在Blink的生态系统中，自下而上分别是资源管理及存储、Blink运行引擎、数据流API及数据集API、统一的SQL API。在SQL API之上，阿里开发了两个平台，一个是SQL平台，允许用户使用SQL编译，或部署SQL任务；另一个平台是机器学习平台，这个平台是纯图形化UI，用户可以在界面上拖动任务或组件，以达到配置和连接的目的。有了这两大平台，就足以支撑阿里系上述的所有互联网产品。
阿里为何选择SQL作为整个平台的底层接口（Blink的上层接口）呢？SQL有以下5大特点：
- 通用性：各种平台的开发人员都熟悉SQL
- 易于理解：更易描述业务逻辑
- 性能优化：SQL系统的核心优化器能使任务更快捷地执行
- 稳定性：甚至可以平滑替换运行引擎
- 统一性：即可用户Batch任务，也可用于Streaming任务
这里大家可能就会有疑问了，为什么SQL会适用于Streaming的任务呢？我们知道SQL适用于表的查询，而在流处理任务中根本没有表啊，即使有也是不断在更新变化的表。阿里就率先提出了动态表的概念：用户可以通过标准SQL语句查询数据流，也就是说数据流和表之间可以无缝转换。这其实也不难理解，只要我们把数据流看作是表的变更日志，就得到了动态表；把表的变更日志导出就得到了数据流，阿里称之为“表流二相性”。
当然，在对历史数据做查询时，还要用到SQL的DDL，DML以及QueryConf语句。在查询涉及多个数据流的时候，可以用SQL的JOIN语句将数据流与数据流、数据流与表组合在一起。组合方式分为lookup JOIN和snapshot JOIN。前者指当系统收到SQL指令需要查询表的结果时，这时需要在JOIN语句中加入处理时间（PROCTIME()），这样SQL运行优化器就会找到对应时刻的查询结果；后者需要用户输入一个常量时间，在系统支持版本数据的情况下将对应时刻的数据返回给用户。