Apache Flink 在诞生之初就确立了使用同一个引擎支持多种计算形态的目标，包括流计算，批处理和机器学习等等。阿里巴巴在选择 Flink 作为新一代大数据引擎时也坚定不移的在贯彻这一目标。在我们的内部版本 Blink 中，我们使用了 SQL 作为流批一体的统一入口，并且在流计算和批处理上都做了大量的优化。流批一体也开始真正的发挥出了价值，在我们的搜索离线数据处理和机器学习平台上均获得了较好的效果。本演讲将分享 Blink 针对流批一体化的场景做了哪些优化，在支持实际业务上碰到了哪些问题，我们又是怎么解决的。

听众受益

1. 了解 Flink SQL 的技术栈和未来的方向；

2. 流批一体化如何在业务中产生实际价值；

3. 流批一体化面临的业务挑战和我们是如何解决的。

百度数据工厂以 Spark 为基础提供了流批一体的大数据分析解决方案，流式数据处理在里面承担了其中的实时计算和实时与离线转换功能。流式数据处理不仅提供了流批统一 SQL 引擎、流批统一 META 管理和实时落数仓等技术支持，还提供了流式数据处理的一体化平台，提供流式数据处理的提交、运维、监控等能力。以百度数据工厂为基础，流式数据处理在大型日志分析、广告物料分析、实时推荐、大屏展示等方面提供了强力支撑，获得了较好的效果。本演讲将分享我们就 Spark 流式数据处理在数据工厂内做了哪些技术支持、改造及相应的实践。

听众收益

1. 理解数据工厂在流批统一上的优势；
2. 了解数据工厂流式数据处理的技术改进；
3. 理解流式数据处理的一体化平台；
4. 数据工厂流式数据处理在百度内的实践。

大数据的处理方式主要分为两类，一类是基于有边界的历史静态数据的批处理；另一类是基于无边界的 event 和流数据的实时处理。

由于具体业务和大数据技术发展历程的原因，在实际应用中，批处理和流处理的数据和技术还是被分隔成两个不同的部分。这其中的一个原因是两种数据类型存储方式的不同：近实时的流、事件数据通常使用消息队列、日志存储系统进行存储；而批处理所需要的静态数据，通常使用文件系统、对象存储进行存储。这就意味着，数据科学家还是需要编写两套不同的计算逻辑来访问存储在不同存储系统中的数据。

Apache Pulsar 是 Yahoo 开源的下一代分布式消息系统，在 2018 年 9 月从 Apache 软件基金会毕业成为顶级项目。Pulsar 特有的分层分片的架构，在保证大数据消息流系统的性能和吞吐量的同时，也提供了高可用性、高可扩展性和易维护性。Pulsar 的分片架构将消息流数据的存储粒度从分区拉低到了分片，并且 Pulsar 提供了层级化存储功能，可以支持近乎无限大小的流存储。另一方面 Pulsar 也可以基于分片提供对有边界的静态数据的存储。这使得 Pulsar 可以完美地匹配和适配大数据计算框架中的批流一体的存储需求。

主要内容

1. 什么是 Pulsar；
2. 介绍 Pulsar 的分层和分片架构，以及为什么 Pulsar 的这种架构可以更好地适配批流一体计算框架；
3. 介绍 Pulsar 怎么跟流处理中的 Spark 和 Flink 以及批处理中的 Presto 和 Hive 结合，提供批流一体的高效的数据存储。

听众受益

1. 理解批流一体的处理优势；
2. 理解批处理和流处理对存储的不同需求； 
3. 深入理解 Apache Pulsar 的基础架构； 
4. 深入理解 Apache Pulsar 能匹配批流一体需求的原因。 

腾讯实时计算团队为业务部门提供高效、稳定和易用的实时数据服务。其每秒接入的数据峰值达到了 2.1 亿条，每天接入的数据量达到了 17 万亿条，每天的数据增长量达到了 3PB，每天需要进行的实时计算量达到了 20 万亿次。

随着业务规模不断扩大，业务需求不断增多，原先基于 Storm 构建的实时计算平台遇到了很多问题。在此背景下，我们选择用 Flink 替换 Storm 作为新一代的实时流计算引擎，我们对社区版的 Flink 进行了深度的优化，并在此之上构建了一个集开发、测试、部署和运维于一体的一站式可视化实时计算平台——Oceanus；同时，我们也基于 Oceanus 向云端客户提供了流计算服务——Stream Compute Service，应用到电商、游戏、互联网金融等泛互联网企业客户。本分享我们会介绍腾讯流计算技术的演进过程，产品化及云端对外服务进展。 

听众受益

1. 为什么要实时计算引擎从 Storm 替换成 Flink；

2. 我们在使用社区版的Flink时遇到了哪些问题，做了哪些改进与增强；

3. 腾讯实时计算平台提供了哪些功能特性来简化用户构建流计算应用复杂度；

4. 腾讯实时计算平台后续的功能、特性预览。

实时分析平台的架构选型是一个需要多维度权衡的问题。NoSQL 提供了非常低的延迟，但分析能力往往孱弱；Hadoop + MPP 引擎或者分析型数据库提供了复杂的分析能力，但很难胜任实时要求高的场景。如果把他们当做光谱的两端，那其中还有各种不同方案尝试填补空缺，用户往往需要通过复杂的架构来补齐不同方案的短板。

TiDB 是一款开源分布式 NewSQL 数据库，它提供了良好的延展性和应对复杂场景的分析能力。对比 NoSQL，它拥有完整的数据库特性支持，降低开发成本；而相对数据湖和分析数据库，它又能很好地承载较高并发的分析场景；配合 TiFlash 以及 TiSpark，传统 Hadoop 平台上的复杂分析也能良好地解决。因此除了传统的 OLTP 场景之外，TiDB 也可以胜任诸多实时分析的场景，甚至在一些场合，它可以作为一个整合的数据平台大大简化系统架构。本次分享将和大家探讨 TiDB 关于实时分析场景的特性和设计以及适用场景，对比它与其他方案的优劣，以及进行中和计划中的相关改进。

听众受益

1. TiDB 的基本原理及其针对实时分析场景的特性和设计；

2. TiDB 相对其他实时分析方案的优劣；

3. TiDB 的使用场景以及实际用户案例分析。

Kafka 在字节跳动内部扮演着重要的角色，不仅作为消息队列服务于在线核心业务，同时也作为流式/批量任务的数据源支撑着模型训练、数据分析等离线应用场景。目前 Kafka 在高峰时段的写入流量超过 600GB/s，读取流量更是写入流量的好几倍，面对如此高吞吐的场景，字节跳动在 Kafka 上面遇到了一些挑战和痛点。本主题将会基于这些挑战和痛点介绍面向高吞吐场景构建的存储/计算分离架构的下一代分布式消息队列，以及相应的实践。

主题摘要

1. Kafka 在字节跳动的应用场景以及面临的挑战；

2. ByteMQ 的架构设计；

3. ByteMQ 在字节跳动的实践以及与 Kafka 的对比；

4. ByteMQ 的未来规划。

听众收益

1. 了解大规模 Kafka 集群在高吞吐场景下面临的挑战和痛点；

2. 了解 ByteMQ 的设计理念；

3. 了解存储/计算分离以及高可扩展性在实践中的灵活性。

随着近几年的发展，实时计算的技术日趋成熟，实时计算的场景也越来越繁多，Flink 也渐渐成为实时计算引擎的首选之一，从简单的实时 ETL 到复杂的 CEP 场景 Flink 都能够很好的驾驭。本次分享主要介绍携程如何基于 Flink 与 Tensorflow 构建携程实时智能异常检测平台，用于解决规则告警系统准确率低、时效性低、规则配置复杂与耗费人力等诸多问题，实现业务指标毫秒级延迟与智能化检测，依托 Flink 实现了强大的容错机制。

听众受益

• Flink 如何应用于异常检测类型的场景；
• 实时计算与深度学习结合的典例；
• 了解 Prophet 的架构设计与实现。