数据孤岛问题直接制约了大量大数据和机器学习应用的开发，而在目前规制愈发严格，GDPR类似的规则逐渐在全球制定实施的背景下，直接物理整合数据变得越发不可能。针对这个问题，微众银行人工智能团队开发并开源了工业级的联邦学习技术框架，在不暴露任何底层数据的情况下，也能实现多方联合建模，共享模型收益。基于联邦学习连接数据孤岛，可能构建一种新的大数据合作生态。

演讲提纲：

1. 数据孤岛的成因和博弈机制
2. 联邦学习的原理
3. 联邦学习在金融行业的应用案例
4. 联邦学习的应用推广前景

听众受益点：

• 了解联邦学习这一新的技术领域
• 了解联邦学习原理和应用案例
• 了解参与和应用这个技术的路径和方法

Hologres 是阿里巴巴计算平台自研的新一代实时数据仓库产品。本演讲首先会介绍Hologres 产品的整体架构，以及其优化器，查询引擎，存储引擎和分布式运行时与框架等各个组件的特点。然后分享 Hologres 在阿里巴巴集团内的搜索，广告，Lazada，菜鸟以及数据中台等部门的业务场景的应用案例。这些案例包括实时报表，算法实时调控，人群定向等秒级响应场景，也含有在离线联合查询分析等业务的应用。
 

Making Nested Columns as First Citizen in Apache Spark SQL

Apple Siri is the world's largest virtual assistant service powering every iPhone, iPad, Mac, Apple TV, Apple Watch, and HomePod. We use large amounts of data to provide our users the best possible personalized experience. Our raw event data is cleaned and pre-joined into an unified data for our data consumers to use. To keep the rich hierarchical structure of the data, our data schemas are very deep nested structures. In this talk, we will discuss how Spark handles nested structures in Spark 2.4, and we'll show the fundamental design issues in reading nested fields which is not being well considered when Spark SQL was designed. This results in Spark SQL reading unnecessary data in many operations. Given that Siri's data is super nested and humongous, this soon becomes a bottleneck in our pipelines.

Then we will talk about the various approaches we have taken to tackle this problem. By making nested columns as first citizen in Spark SQL, we can achieve dramatic performance gain. In some of our production queries, the speed-up can be 20x in wall clock time and 8x less data being read. All of our work will be open source, and some has already been merged into upstream.

参考译文：

Apple Siri是世界上最大的虚拟助理服务，为每部 iPhone，iPad，Mac，Apple TV，Apple Watch 和 HomePod 提供服务支持。我们使用大量数据来为用户提供最佳的个性化体验。所有的原始事件数据被清理并预先加入到统一数据中，供我们的数据使用者使用。为了保持数据的丰富层次结构，我们的数据模式采用了非常深的嵌套结构。

在本次演讲中，我将讨论 Spark 如何处理 Spark 2.4 中的嵌套结构，还会展示读取嵌套字段时的基本设计问题，这些问题在设计 Spark SQL 时并未得到充分考虑。这就导致了 Spark SQL 在许多操作中读取不必要的数据。鉴于 Siri 超级嵌套的数据非常庞大，它很快就成了瓶颈所在。

之后，我会介绍为解决这个问题所采取的各种方法。将嵌套列作为 Spark SQL 中的第一个公民，在性能上获得显着的提升。在我们的一些生产查询中，加速20倍，读取的数据减少8倍。我们所有的工作都将开源，有些已经合并到了核心区域。

Bridging the gap between Spark Datasets and DataFrames

Apple leverages Apache Spark for processing large datasets to power key components of Apple’s production services. The majority of users rely on Spark SQL to benefit from state-of-the-art optimizations in Catalyst and Tungsten. As there are multiple APIs to interact with Spark SQL, users have to make a wise decision which one to pick. While DataFrames and SQL are widely used, they lack type safety so that the analysis errors will not be detected during the compile time such as invalid column names or types. Also, the ability to apply the same functional constructions as on RDDs is missing in DataFrames. Datasets expose a type-safe API and support for user-defined closures at the cost of performance.

译文参考：

Apple 利用 Apache Spark 处理大型数据集，为 Apple 生产服务的关键组件提供动力。 大多数用户依靠 Spark SQL 从 Catalyst 和 Tungsten 中最先进的优化中受益。由于有多个 API 与 Spark SQL 交互，因此用户必须明智地决定最终选择哪一个。虽然 DataFrame 和 SQL 被广泛使用，但它们缺乏类型安全性，因此在编译期间无法检测到分析错误，例如无效的列名称或类型。此外，在 RDDs 上应用相同功能结构的功能却不能在 DataFrames 中使用。Datasets 以牺牲性能为代价公开了类型安全的 API，并支持用户定义的闭包。

This talk will explain cases when Spark SQL cannot optimize typed Datasets as much as it can optimize DataFrames. We will also present an effort to use bytecode analysis to convert user-defined closures into native Catalyst expressions. This helps Spark to avoid the expensive conversion between the internal format and JVM objects as well as to leverage more Catalyst optimizations. A consequence, we can bridge the gap in performance between Datasets and DataFrames, so that users do not have to sacrifice the benefits of Datasets for performance reasons.

本演讲将重点介绍 Spark SQL 无法优化类型化 Datasets 的情况，因为它可以优化 DataFrame。我们还将努力使用字节码分析将用户定义的闭包转换为本机 Catalyst 表达式。这有助于 Spark 避免在内部格式和 JVM 对象之间的昂贵转换，以及利用更多的 Catalyst 优化。因此，我们可以弥合Datasets 和 DataFrames之间的性能差距，这样用户就不会因性能原因而牺牲 Datasets 的优势。

Outlines of the speech：

1. Apache Spark
2. Dataframe vs Dataset
3. Bytecode Analysis
4. JVM GC

Key points：

• The audiences will learn how Apache Spark works internally; particularly on how catalyst optimizer optimizes the execution plans.
• Then I will go through the current problems of Spark's Dataset implementation which expose a type-safe API and support for user-defined closures at the cost of performance.
• Finally, I'll talk about how we do bytecode analysis to understand the JVM bytecode, and then convert them into SQL expressions for further optimization. In some of our Spark jobs, we see 40x performance gain resulting less required resource and faster deliver time.

• 帮助听众了解 Apache Spark 内部的工作流程，尤其是 Catalyst 优化器如何优化执行计划。
• 了解 Spark Dataset 当前在应用方面的问题，这些问题公开了类型安全的 API，并以性能为代价支持用户定义的闭包。
• 最后，我将分享我们是如何实现字节码分析的案例，帮助理解 JVM 字节码，然后将它们转换为 SQL 表达式以进一步优化。在我们所做的一些 Spark 工作中，我们看到了40倍的性能提升，从而减少了所需的资源，交付时间也更快。

随着网易考拉、严选等电商业务的发展，成千上万的数据表被创造出来，很多员工每天的工作就是围绕这些数据开展，基于这些数据，选品分析、流量分析、智慧供应链等数十个数据产品开始涌现。数据应用规模带来了复杂的数据问题，比如指标口径不一致沟通效率低下，找数据取数据困难，数据重复建设造成大量资源浪费，数据产品故障频繁等大量问题，严重制约了业务发展。

为了应对这些问题，网易在网易猛犸大数据平台和有数可视化分析平台之上，打造了数据中台工具栈，数据中台转型初见成效。本次分享将介绍网易数据中台建设经验以及相关的支撑系统。

演讲提纲：

1. 为什么要做中台
2. 网易数据中台架构
3. 元数据管理：管理指标、模型、维度
4. 全链路数据质量中心：确保数据正确性，提升数据 SLA
5. 资产管理中心：通过资产和资源管理降低成本
6. 未来规划

听众受益点：

1. 建设数据中台带来的收益
2. 互联网数据中台建设经验
3. 数据中台支撑系统实现原理

数据驱动价值创造，而数据分析在价值创造过程起着核心作用。从传统的 OLTP 到 OLAP，再到数据湖，数据分析的方式发生很大的变化，尤其是目前大数据生态中，多场景的数据存储各显身手。不同的存储，不同的使用方式，数据分析的成本随之水涨船高。着力于降低数据分析人员分析数据的成本，360大数据分析引擎也历经几次的架构调整和演进，从原始的命令行到界面化的单一数据源查询，最终发展为多数据源混合查询，期间遇到了很多问题以及挑战。

演讲提纲：

介绍360大数据中心数据分析平台架构的演进、遇到的问题以及具体的应用场景实践：

1. 360数据分析场景
2. 遇到的问题与挑战
3. 解决⽅案与思路
4. 引擎实践案例分享

听众受益点：

1. 可以了解数据湖解决方案；
2. 多数据源混合分析引擎的架构设计原则；
3. 大数据分析引擎在实战过程中碰到的问题和解决思路。

数字化时代，企业业务数据爆炸式增长，传统架构的数据库难以承载10PB 级数据分析，并且 IoT、智能摄像头等新型应用的普及，数据源及数据结构变得日益复杂及庞大，使得数据融合分析成为一大难题。

演讲提纲：

1. 伴随企业数据爆炸式增长，如何在 Shared-Nothing 架构下利用超并行技术构筑极致数据分析性能
2. 如何通过 SQL on Anywhere 技术实现多源数据融合分析
3. 如何通过 Switch turbo 技术实现故障切换无感知，以及如何利用 Paxos 协议实现跨城市超远距离的高可用架构

听众收益：

1. 了解高斯数据库的架构演进和技术挑战
2. 了解数据融合分析过程中的问题和解决方案
3. 了解高斯数据库在大数据领域的实践路径