2019 DataFunTalk 大数据技术文章合集(电子书免费送)

导读: 本期  Ververica  将联合  DataFunTalk  为小伙伴们奉上2019 DataFunTalk  技术文章合集-大数据篇 。先来简单认识下DataFunTalk:

回望2019年, DataFunTalk  为大数据、人工智能的技术小伙伴们出品了 61场线下沙龙,16场线上直播,吸引了20000+小伙伴们 的参与。 取得这样的成绩,最应该感谢的是所有参与分享的 企业和老师们 ,你们的经验帮助了许许多多小伙伴们 缩短 了把大数据、人工智能技术 应用 在各自场景的 周期少走了很多弯路

为了让宝贵的经验传播,为了方便小伙伴们的阅读 ,小编特别整理了  DataFunTalk 2019年度"各厂最新技术应用分享"文章电子版合集 ,共 6大系 10余个子话题 ,将在农历春节前的时间里为粉丝们陆续发放新春福利。

今天, Ververica  联合  DataFunTalk  为小伙伴们发放福利: 大数据 ,共22篇 精选文章 ,417页,21.2M。

如何领取?

识别下方二维码,回复 " 大数据篇 ",即可下载。

——详细介绍——

(点击下方标题,可跳至对应原文)

1. Sophon :Hulu 智能 OLAP 缓存层技术实践

分享嘉宾:罗安宁 Hulu

Hulu 大数据的基础技术架构如上图,整体上是比较拥抱开源的,数据采集使用的是 Flume、Kafka,数据存储用的是 HDFS 和 HBase,资源调度用的是 yarn,离线计算用的是 Spark、MapReduce、Hive 等,在线计算主要用 Impala、Presto 以及一些自建的引擎,Presto 是一个 FaceBook 开源的 MPP 架构 OLAP 查询引擎,在 Hulu 主要用于 Ad Hoc 的查询,Impala 是 Cloudera 开源的 MPP 架构 OLAP 查询引擎,主要服务于一些自建的数据仓库,我们自研的主要是 Nesto 和 Sophon,Nesto 是一个能够查询嵌套数据结构,基于 MPP 架构的查询引擎,Sophon 是一个 OLAP 缓存的管理引擎,同时提供查询和路由的功能,再往上就是统一的客户端管理,包含统一的配置管理,自动更新等。 我们的监控,除了采用 Cloudera 的自带监控外,还有自研的监控组件 Hawkeye,主要是对 Cloudera 监控的补充,它可以用来统计整个 HDFS 和各种计算引擎的指标。

2. 举重若轻的人人车移动端数据平台

分享嘉宾:吴水永

在这些眼花撩乱的数据引擎中,各自有着自己特性,在不同的业务体系中,总有他们发挥的场景。 我们需要一些标准评估哪个引擎更适合自身的业务场景,POC产品原型验证以及TPC benchmark压测。

自古磨刀不误砍柴工,梳理清楚业务场景才能在对每一个引擎做POC时高效靠谱,不至于贸然上船而到后期骑虎难下。 若能转化成SQL场景,则在TPC-DS/TPC-H压测下更能科学判断一款引擎的场景能力。 前者POC是定性分析,决定引擎能不能; 后者TPC是定量分析,决定引擎到底有多强。

一见钟情 ClickHouse

人人车的BI平台选择了ClickHouse,支持较高的并发,支持亿级别量级查询,支持增量、全量同步,支持幂等性去重,支持更新update和删除delete,亚秒级延时,支持SQL。 用自身业务的sql跑压测,4台测试机就跑出了10qps/30并发,已经是一见钟情了。

列式数据引擎ClickHouse,有很多特别适合BI场景的特性。 在我们使用SQL的时候往往查询的列是很少的,列式数据库可以让我们在做聚合等操作时,只需要取出少量的列,可以大大减少内存与外存之间的数据交换。

ClickHouse性能确实太强悍了,在一台4核8G的机器上,对一亿七千条数据count,跑了3秒多。 在第一次没有任何缓存的情况下,多维度group by+order by跑了9秒多。 在我们看来ClickHouse如同AK47,简单可靠,性能强悍,手动性强。 换言之大部分需要自己配置,如分布式和副本集,数据去重幂等性。 Clickhouse已经支持update/delete,方便做数据的更新,但在大数据的性能要求下,ReplacingMergeTree在实践中仍然是更好的选择。

3. 时序数据在滴滴实时数据开发平台中的处理和应用

分享嘉宾:张婷婷 滴滴出行

考虑到Druid、实时计算引擎、开发语言等不是所有人都了解,需要一定的学习成本。 而且大部分人参与进来,对资产管理提出了新的挑战。 从而提出了滴滴实时计算开发平台(Woater)。 主要目标: 降低开发难度和资产管理模式的优化,得到当前的技术方案如上:

数据通过多种方式接入到Kafka,通过Spark streaming或Flink处理后写入Druid。 考虑到Kafka对消息保存的生命周期,添加了对Druid数据进行一些离线的处理(Hive+Druid),保留历史数据的信息。 数据落地存储后,通过统一的实时数据API对第三方开放(开通权限后可用)。

在主线功能之外,提供了两个支线功能: 权限管理和血缘管理。 权限可以管理到模块粒度上的开放和使用,通过血缘可以清晰的看到数据的流动路径,查找数据的上下游信息。

4. 阿里巴巴双十一千万级实时监控系统技术揭秘

分享嘉宾:柴武 阿里巴巴

流式聚合引擎采用轻量单进程实现,在用户查询的时候将用户的复杂查询转换为聚合算子组合,流式聚合引擎包含了10+核心的聚合算子、20+填充策略、10+插值算法。

由于是将复杂的查询转换为算子组合运算,所以在实现上是一个松耦合的结构,扩展性很强而且每个算子的执行都非常高效,快速,减少了对内存的开销以及底层存储的压力,另外聚合出和数据还可以与外部预聚合、降精度聚合的数据实现无缝衔接,提高了查询结果的复用率。

5. 深入了解 TiDB SQL 优化器

分享嘉宾: 张健 PingCAP

在TiDB中只有两种数据,一种是表数据,一种是为表数据创建的index数据。 表数据就是tableID加RowID的形式将其映射为Key-Value中的key,表数据中具体每一行的数据一个col的映射为其value,以Key-Value的形式存储到Tikv中。 索引数据分为两种一种是唯一索引和非唯一索引,唯一索引就是tableID+IndexID+索引的值构成Key-Value中的key,唯一索引对应的那一行的RowID,非唯一索引就是将rowID encode到Key中。

6. Druid SQL 和 Security 在美团点评的实践

分享嘉宾:高大月 美团点评

美团从16年开始使用Druid,集群版本从0.8发展到现在的0.12版本。 线上有两个Druid集群, 总共大概有70多个数据节点。

数据规模上,目前有500多张表,100TB的存储,最大的表每天从Kafka摄入的消息量在百亿级别。 查询方面,每天的查询量有1700多万次,这里包括了一些程序定时发起的查询,比如风控场景中定时触发的多维查询。 性能方面,不同的应用场景会有不同的要求,但整体上TP99响应时间在一秒内的表占了80%,这和我们对Druid的定位——秒级实时OLAP引擎是一致的。

7. 网易大数据体系之时序数据技术

分享嘉宾: 范欣欣 网易大数据

上图为数据的整体架构,大部分公司都是差不多的:

  • 原始数据: MySQL、服务端的Log、APP-Data、Sensor,大家知道现在穿戴设备很多,比如手表等,这样都会产生很多数据,这些数据都称为时序数据,随着时间的变化不断产生数据。

  • 数据采集层: sqoop、DataStream、SDK、Gataway

  • 数据加工层: 数据存在kafka里,再经过一些流计算处理(Flink、Sparkstreaming)

  • 数据存储分析层:

1. 离线存储分析平台: 技术栈包括最底层的HDFS、Kudu、GP等数据存储,在这之上要做很多的计算,包括Hive、Spark、Impala等,他的应用场景包括数仓报表、机器学习、模型训练等;

2. 在线存储计算平台: 应用的业务场景包括,交易订单,优惠券,用户画像等,这里主要应用的是HBase;

3. 时间序列存储计算平台: 应用场景包括,业务设备监控,实时广告平台,物联网应用,相关的技术包括OpenTSDB、Druid、InfluxDB等。

所以会根据不同的业务使用不同的平台来处理相关的数据,对于我们来说最大的工作是在数据存储端。

8. 快手 Druid 精确去重的设计和实现

分享嘉宾: 邓钫元 快手

a. 精确去重方案: hashset

使用 hashset 的方式存储,具备简单通用等优点,但是资源占用非常大。 以下图所示为例,将左上角的原始数据使用 hashset 方法,Year 作为维度列,City 作为指标列; 按照维度列分成2个 Segment,转换为右上角的数据格式; 接下来将指标列聚合到 broker 中,计算出 size,即得到最终结果。 整个过程如下图所示:

但是使用 hashset 的去重方式,其资源占用非常大; 具体来说,假设有 5000W 条平均长度为 10B 的 string ( 共500MB ) ,中间生成的 Hashset 会产生一系列链表结构,导致内存可达到 5G,即内存扩展可达10倍。 因此,直接使用 hashset 的方法可以是完全不可行的。

在 hashset 方法基础上可以考虑一些优化的思路: 例如,通过增加节点,将数据分散到不同机器上,查询时在每台机器上分别聚合进而求和; 另一种方式类似于 MapReduce,计算前利用 shuffle 模型将数据打散。 然而这两种优化思路和 Druid 平台属性有冲突,因此都不适用于 Druid 这个平台。

b. 精确去重方案: 字典编码+Bitmap

Bitmap 方法,即用一个位来表示一个数据 ( 这是理论上的最小值 ) 。 这种方案的思路是: 对要去重的数据列做编码,将 string 或其他类型的数据转化成 int 型的编码,摄入到 Druid 后通过 Bitmap 的形式存储; 查询时将多个 Bitmap 做交集,获取结果。 Bitmap 的范围是42亿,最大占用空间 500M 左右; 还可以使用压缩算法,使空间占用大大减少。

因此,字典编码+Bitmap 的方式,优点是存储和查询资源占用少,可以将构建和查询分开 ( 即字典不参与查询 ) ; 缺点是: 字典需要做全局编码,其构建过程较复杂。

考虑到 Kylin 曾使用过这种方案,因此快手的后续优化方案选择在这种方案的基础上进行优化。

9. 基于 Kafka 的实时计算引擎如何选择? Spark or Flink ?

分享嘉宾: 哥不是小萝莉

Flink 也是来自 Spark 类似的学术背景,Spark 来自加州大学伯克利分校,Flink 来自柏林大学。 像 Spark 一样,它也支持 Lambda ,但实现与 Spark 完全相反。 Flink 本质上是一个真正的实时计算引擎,将批处理作为有限数据流的特殊情况。 虽然两个计算框架中的 API 相似,但它们在实现中没有任何相似之处,在 Flink 中,Map、Filter、Reduce 等各个函数实现为长时间运行的运算符 ( 类似于 Storm 中的Bolt ) 。

什么是 Apache Flink?

Flink 是一个开源的实时计算引擎,是实时计算领域的领导者。 它拥有出色的图计算和机器学习功能,其底层支持 On YARN 模式,且提供了本地 & 分布式模式,以及 Docker & Kubernetes 等容器部署。

如何使用 Flink 解决问题?

在低延时场景,需要实时数据,以便能够更快的检测和解决关键事件。 例如,在使用 Flink 之前,计算的基本业务指标,实现的延时时间约为3到4小时,这意味着,如果工程师在早上10点左右检测到业务指标变化异常,只能在下午14点左右开始排查。 如果能够立马解决,则只能在下午18左右时来验证解决方案,这样实现起来效率不是很高。

假如你的业务数据是基于时间序列的,那么我们需要使用事件时间来处理在时间窗口内对业务指标进行分组。 同时,Flink 也可以很轻松的与存储在 Kafka 和 HDFS 中的业务数据进行集成。 另外,Flink 具有良好的非功能特性,便于在生产中运行,易于与不同的监控后端集成 ( 例如 Graphite、Prometheus 等 ) ,以及提供良好的 UI 界面。 此外,Flink 工作的快速开发周期以及简单的执行模型使得学习曲线平稳,开发效率高。

10. 万亿数据下 Hadoop 的核心竞争力

分享嘉宾: 哥不是小萝莉

Hadoop 如此受人喜欢,很大程度上取决于用户对大数据存储、管理和分析需求的迫切。 大数据是目前很多企业面临的一个挑战,由于数据量的庞大、数据类型的复杂 ,特别是非结构化或者半结构化的数据远远多于结构化的数据,一些传统的基于关系型数据库的存储和分析难以满足时,且关系型数据库巨大成本压力也是很多企业考虑的问题,而 Hadoop 给人们提供了解决大数据问题的技术手段。

大数据时代需要 Hadoop ,那么 Hadoop 的核心竞争力在哪呢?

1. 降低大数据成本

Hadoop 使企业可以高效的管理数据,以降低数据成本,其中包含业务成本、硬件成本、人工成本、存储成本等。 通过易用性、权威性、时效性等特性,Hadoop 还可以帮助用户增加数据价值。 目前 Hadoop 社区的支持,以及各大 Hadoop 厂商的支持,使得 Hadoop 从一个单独的开源软件逐步演变成一个具有一定规模的生态系统,这些厂商包含 Cloudera 、MapR 、Hortonworks 等,他们在这一生态系统中扮演着不同的角色,例如有系统厂商、监控服务商、数据分析商等。

而使用者可以从这些厂商中提供的系统来简化 Hadoop 的学习成本,快速构建符合自身要求的大数据平台,同时合理利用厂商提供的附属组件来开发出高效、易用的的大数据应用。

2. 成熟的 Hadoop 生态圈

Hadoop 不是一个 “ 孤岛 ” 系统,它拥有成熟的 Hadoop 生态圈。

利用 Hadoop 生态圈设计满足自身需求的方案,需要考虑一些关键要素:

1. 从需求的最终结果开始分析,而不是从可用的工具开始。 例如,可用性、一致性等;

2. 对数据处理时效性的评估,例如离线任务 ( MapReduce 、Hive ) 、实时任务 ( Flink、Spark Streaming );

3. 尽可能使用成熟的方案。

11. Apache Doris : 一个开源 MPP 数据库的架构与实践

分享嘉宾: 赵纯 百度

Doris 的整体架构和 TiDB 类似,借助 MySQL 协议,用户使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客户端,都可以直接访问 Doris。 Doris 中的模块包括 FE 和 BE 两类: FE 主要负责元数据的管理、存储,以及查询的解析等; 一个用户请求经过 FE 解析、规划后,具体的执行计划会发送给 BE,BE 则会完成查询的具体执行。 BE 节点主要负责数据的存储、以及查询计划的执行。 目前平台的 FE 部分主要使用 Java,BE 部分主要使用 C++。

12. TiDB 的 HTAP 之路: 过去,现在和将来

分享嘉宾: 申砾 PingCAP

将存储引擎的数据通过 Raft learner 同步出去可以做更多的事情,保证日志是一个近实时同步方式。 计算引擎也可以替换成不同的东西,寄存到自己的引擎中做自己的事情。 希望用这套场景解决 AP 与 TP 相互干扰的状况,帮助用户简化使用。 在 TP 中统计信息收集比较麻烦,当数据有上百亿表,这种收集统计信息是非常耗时的,当统计信息不准可能会导致业务选错索引。 对于这种不需要完全实时,也不要求百分百准确的统计信息收集工作,可以让其后台执行,交给 TiFlash 引擎来做。

存储集群不再区分是何种引擎,是一个行列共存的存储引擎。 可以实现数据实时同步,可以实现快速将几 T 或者几十 T 的数据快速导入集群中。 有了这么多组件后维护起来比较麻烦,可以使用 TiDB Operator,让 K8s 帮助管理实例。

13. Apache Dubbo Roadmap 2019

分享嘉宾: 秦金卫 Huobi

实际上今天为止,Js 和 Go 的已经比较完善了,各种外围的配套工具,像服务的发现和配置,新的管理控制平台,各种测试的支持和 Trace 跟踪是由 Spring Cloud 团队的的一个同事做的适配,这是 Dubbo 目前整体的一个生态,可以看出 Dubbo 在微服务里配套还是比较齐全的。 其实对微服务来说最大的问题不是技术问题,因为技术的问题发展的已经很完善了,我们知道把一个系统引入微服务以后,拆成粒度比较小的系统有很多好处,比如每个系统的开发和维护成本会变低,因为系统变得简单了,但是更大的问题也出现了,比如说把一个很复杂的业务系统拆成20个小系统,这20个小系统都需要单独的做测试,部署,维护,当系统出了问题,需要对20个系统去排查问题,这些对自动化测试,自动化运维,全链路跟踪,监控做提出了非常高的要求,这就对整个研发团队的技术成熟度提出了一定要求,只有当测试,运维,业务方面的监控,自动化的 Trace 做的比较完善时,容器化的改造完成以后,再去做服务化会比较合理。 微服务和单体在软件设计里面有两条曲线,叫成熟度的曲线,当你的团队规模很小的时候,单体的成本要比微服务的成本低很多,但是随着你的团队规模的增大,微服务的成本虽然起点很高,但是它的复杂度是比较平稳的,不会增加很多,比如你有50个开发人员和500个开发人员,你使用微服务的方式在保持业务的复杂度和质量的情况下是可以往前扩展的,但是单体的复杂度和成本会随着业务的复杂度逐渐递增,中间有个交叉点,这个交叉点和团队规模,业务复杂度和你的技术成熟度这几个选项有关系,超过这个交叉点就需要进行微服务改造,超不过这个点业也许单体是更好的选择。

14. 快手 HBase 在千亿级用户特征数据分析中的应用与实践

分享嘉宾: 陈杨 快手

该需求的挑战:

  • 日志量大,千亿级;

  • 任意维度,如 city、sex、喜好等,需要选择任意多个维度,在这些维度下计算留存率;

  • 秒级计算,产品面向分析师,等待时间不能过长,最好在1-2秒。

技术选型

面对这些问题,我们当时的技术选型:

①  Hive,因为大部分数据可能是存在 Hive 里,可以直接写 SQL 计算,该方案不用做数据迁移和转换,但是时延可能是分钟到小时级别,因此否定了这个方案。

②  ES,通过原始数据做倒排索引,然后做一个类似计算 UV 的方式求解,但是在数据需要做精确去重的场景下,它的耗时比较大,需要秒到分钟级。

③  ClickHouse,ClickHouse 是一个比较合适的引擎,也是一个非常优秀的引擎,在业界被广泛应用于 APP 分析,比如漏斗,留存。 但是在我们的测试的中,当机器数量比较少时 ( <10台 ),耗时依然在10秒以上。

立足于这种场景,是否存在其它解决方案,延迟可以做到2-3秒(复杂的场景10秒以下),同时支持任意维度组合? 基于 HBase,结合业界简单/通用的技术, 我们设计并实现了 BitBase 解决方案,用很少的资源满足业务需求。

15. 贝壳: 流式数据的平台化实践与挑战

分享嘉宾: 赵国贤

要理解流式数据,首先要知道数据流的流程:

1. 数据接入。 为了做好数据分析,同时给用户画像、数据挖掘等提供数据物料,就需要做好数据接入层,一般情况下我们面临的问题主要有:

① 多变: 数据来源有业务 DB、MySQL、Oracle、sql server、第三方存储 Redis 等多种数据源,怎么对多变的数据源做统一的、及时的接入。

② 异常: 举个例子,某些业务方经常在半夜刷新数据,这对数据接入的实时性和准确性产生了很大的影响。

③ 效率:

A. 离线数据接入,如何更快的把数据接入进来。

B. 实时数据接入,如何准确的接入,并及时提供需求数据。

针对这些问题,贝壳找房的解决方案就是 Databus(数据直通车),通过数据直通车来解决上述的三个问题,把行为数据和业务数据及时、高效的接入计算平台层,来满足流式数据的计算和需求。

2. 实时 ETL。 主要分为上层的数据治理和下层的计算平台。 数据接入进来之后,采用什么样的形式存储,更好的做数据分析,而实时计算又采用什么样的方式存储,这里都是通过 Ark 平台来做实时处理。

3. 数据输出。 如何把数据更好的提供给用户,这里主要会介绍日志流产品化的平台天眼。

16. Apache Beam 架构原理及应用实践

分享嘉宾: 张海涛 海康威视

Apache Beam 的总体架构是这样的,上面有各种语言,编写了不同的 SDKs,Beam 通过连接这些 SDK 的数据源进行管道的逻辑操作,最后发布到大数据引擎上去执行。 需要注意的是,Local 虽然是一个 runner 但是不能用于生产上,它是用于调试/开发使用的。

17. 实时计算引擎在贝壳的应用与实践

分享嘉宾: 王磊 贝壳

平台目前主要建设 Spark Streaming,Flink 两种在实时计算中比较常见的计算引擎。 平台化的背景就是早期如果公司内有业务想用数据流进行计算,可能需要申请客户端,自己去搭建一个客户端,然后向集群上提交实时作业。 这个产生的问题就是如果每个业务方都去自己这样做成本比较高,每个业务都需要关心自己作业的运维问题,还有监控,实时数据作业的监控建设的水平也是参差不齐。 Spark Streaming,Flink 对于业务同学直接开发也有一定的学习成本,很难直接用上大数据的能力做实时计算。

我们计算平台流数据源主要都是用 Kafka。 Kafka 数据中数据分为几类,一个是数据流,数据流指的是线上的业务日志、访问日志等,会收集到数据流平台。 Binlog 是线上 MySQL、TIDB 产生的 binlog 作为实时数据源。 Dig 是内部前端埋点项目的代号。

计算平台底层集群使用 YARN 做资源调度。 再上层就是我们现在主要基于社区版 Flink、扩展了开源 Flink 的 SQL 能力。 还有提供一些通用的实时处理模板。 流计算的输出要覆盖线上业务所有需要的存储分析引擎,例如 ES、Kafka、Hbase 等等。 在这些底层基础之上,首先要做的就是实时任务的管理管控。 包括如何帮助平台上这些所有 Flink 或者 Spark 任务,进行资源的调优,对实时数据流中的数据的元数据化。 另外还有在 Web 端提供的 SQL IDE、任务运行状态的监控报警。 在计算平台之上业务方做的一些应用: 指标分析,实时特征,安全风控,ETL、实时推荐等等。

18. 阿里小蜜新一代智能对话开发平台技术解析

分享嘉宾: 李维 阿里巴巴

在上面几个阶段我们都提供了强有力的辅助和能力对开发者赋能。 在设计构建阶段提供了 AI 智能荐句能力,用户只需要输入种子话术,平台就会自动推荐相似问法,能节省人工造句和打字时间。

构建对话流动态图时只需要拖拽式操作,在画布中将节点和边连在一起,可视化编程,对话逻辑一目了然,且条件分支简单配置,可以根据业务灵活定制。 在该阶段通过服务注册中心的方式也解耦了开发者和设计者,开发者将服务注册 到中心,设计者从中心发现并使用服务,他们基于商定好的协议沟通,开发和设计可以并行工作,使对话设计者可以做到完全不写一行代码,开发者专注于功能服务开发。

19. Hadoop or TDengine,如何做物联网大数据平台的选型?

分享嘉宾: 关胜亮  涛思数据

这样的数据处理方式是物 联网吗? 答案是肯定的,因为物联网的基本概念是物体和物体相联。 但这只是物联网的初级阶段,解决数据采集从无到有,包括数据的实时上数和告警的问题,随着测点数暴涨,数据采集频次不断提高,传统实时数据库暴露出下列问题:

  • 水平扩展: 没有水平扩展的能力,数据量增加,只能依靠硬件scale up(增加单个硬件性能,如把16G内存的机器换成256G内存的,但是这样的扩展能力还是有限的)。 所以水平扩展,在选型过程中如果解决,也是一个重要的问题。

  • 技术架构: 技术架构陈旧,使用磁盘阵列(价格比较昂贵),还运行在Windows环境下。

  • 数据分析: 数据分析能力偏弱(还需要历史数据,否则只能根据当前数据进行分析,看看有没有超过阈值,或发出报警,这其实不能算作数据分析),不支持现在流行的各种大数据分析接口。

  • 云服务: 不支持云端部署,更无法支持PaaS。

现在做物联网,在实时数据的基础上,还要进行扩充,做历史数据。 通过历史的查询,归类的统计,或者机器学习的方法把历史数据增值,获得两类信息:

1. 整体情况的统计,如有10W个设备,统计这10W个设备的总体情况,也就是常说的报表。

2. 单个设备的分析,如有一台设备经常坏,为什么经常坏呢? 我们可以看下这台设备采集的数据是什么样的,是不是电流经常发生突变等信息。 通过对单个设备进行分析,把这块的数据模式收集起来,扩展到其它设备中,能够提高整个系统运维的安全性。 同时,把单个设备进一步扩展,扩展到每个人用的手机或者手环等,能把这些大数据做好,那么我们除了To B业务外,也能在To C业务上给公司产生增值。

如果不需要历史数据,可以只做redis,因为只看当前数据,redis会比一些实时数据库的架构稳定性更好。

20. 通用高效的数据修复方法:Row level repair

分享嘉宾: Asias He @ ScyllaDB

首先介绍一下什么是 repair:

  • 修复是 Cassandra 中一个重要的维护操作。

    Cassandra 中的数据具有多个副本,有可能在写操作发生时某些节点不在线,从而拿不到数据的副本,导致了数据的不一致。 这种情况发生时,需要让各个节点的数据一致,即 repair。

  • repair 的两个步骤:

    第一步: 发现不同节点数据副本之间的不一致。

    第二步: 修复不一致的数据。

21. Cassandra 在 360 的实践与改进

分享嘉宾: 王锋 奇虎360

Cassandra 完全无中心化设计使得其具备极高的可用性和可平滑的拓展性,并且具有模式灵活,多数据中心,范围查询,列表数据结构,分布式写操作等优势:

❶ 由于其架构在中小规模部署时不需要主节点,相较于完全中心化的分布式存储设计具有更优的成本优势,从3台物理机开始一直拓展到几百台物理机,均可完全不停服情况下平滑拓展,整个过程只需要把拓展节点的进程启动加入集群;

❷ 模式灵活使得 Cassandra 可以在系统运行时随意添加或移除字段,这是一个很惊人的效率提升,特别是在大型部署上;

❸ 多数据中心是指可以调整节点布局来避免某一个数据中心失效,一个备用的数据中心将至少有每条记录的完全复制;

❹ 范围查询是指如果你不喜欢全部的键值查询,则可以设置键的范围来查询,对于每个用户的索引,这是非常方便的;

❺ 分布式写操作是指有可以在任何地方任何时间集中读或写任何数据,并且不会有任何单点失败。

22. 构建端到端的联邦学习 Pipeline 生产服务

分享嘉宾: 曾纪策 微众银行

FATE-Flow 是我们自研的联邦学习调度平台,主要有5项功能:

  • 用 DAG 定义联邦学习 Pipeline。 DAG 具有比较灵活、弹性的特点,是业界工作流调度系统常用的方式; 在联邦学习场景下,DAG 是有难点的,由于协作的机制,我们的 Pipeline 是非对称的; 我们在设计 DSL 时,考虑更多系统化对接的情况,所以我们采用了 json 格式的 DAG DSL,然后再采用 DSL-Parser 进行解析。

  • 联邦任务生命周期管理。 对应刚刚所说的痛点,对联邦任务生命周期进行管理,如多方启停、状态检测。

  • 联邦任务协同调度。 包括: 多方任务队列、分发任务、状态同步等协同调度。

  • 联邦任务输入输出实时追踪。 这个功能比较普遍,一般的调度平台都会有,包括: 数据、模型、自定义指标、日志等的实时记录存储。

  • 联邦模型管理。 联邦学习模型的管理存在一个很大的问题,尤其在纵向联邦学习场景下,就是如何保证多方模型的一致性。

受限于篇幅,更多内容欢迎下载 2019 DataFunTalk 年度技术文章合集: 大数据篇。

------

获取方式:

识别下方二维码,回复 " 大数据篇 ",即可下载。

一个「在看」,一段时光! :point_down:

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章