Recommended
More Related Content
What's hot
What's hot (20)
Similar to AWS Summit: Strikingly analytics
Similar to AWS Summit: Strikingly analytics (20)
More from Chase Zhang
AWS Summit: Strikingly analytics
- 1. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 张晨 Data Platform Engineer @ Strikingly 史少峰 PMC of Apache Kylin, Software Architect @ Kyligence Strikingly Analytics 使用 AWS 和 Apache Kylin 实现百万用户级别的数 据服务
- 2. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. • 创立于 2012 年 • 提供一站式建站服务 • 实现盈利的时间: 两个月 • 服务全球数百万客户 • 月均访问量达到千万级别 • 2016年推出本土服务上线了 • 已为数十万中国用户提供建站服务 • 2017年率先推出微信小程序上线服务 • 领先的微信小程序平台提供商
- 3. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Strikingly Analytics • 访问者流 (ClickStream) 分析 • 服务使用 Strikingly/上线了 建站的客户和发布微信小程序的 客户 • 实现多维分析，为商业智能 (BI) 决策提供支撑 是什么？ • 提供全面的一站式建站服务 • 方便客户查询和访问数据，使得 不了解相关技术的人也可以从大 数据分析当中获益 • 掌握原始数据，支撑更为灵活细 致的商业分析需求 为什么？
- 4. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Strikingly Analytics • 处理超大规模数据 • 运维数据平台的基础设施 • 响应通用类型的查询请求 • 快速支持新增需求( 快速迭代 ) • 支撑多租户、亚秒级查询 挑战 • 功能强大的云服务 • 丰富而全面的开源生态系统 • 成熟的相关技术分析报告和论文 • 从前端到后端各个部门的配合 可以利用的资源 使用云服务 (AWS) 和开源工具 (Hadoop、Kylin) 可以快速实现相关数据分析服务！
- 5. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Web Services • Strikingly/上线了自创立起即采用 AWS 向全球客户提供服务。在中 国区仍使用 AWS 以保持系统架 构一致 • AWS 相关技术文档非常丰富。一 般的使用问题都可以使用 Google 解决 • 第三方工具链比较丰富和完善 运维方面 • 生态系统繁荣，许多开源大数据 工具提供针对 AWS 相关服务的 官方扩展和技术文档 • AWS Java SDK 功能覆盖完整， 使用方便，EMR 等服务默认集成 各类 Jar 包，可以直接使用 • S3，DynamoDB 等服务在全球 范围内久经考验，值得信赖 开发方面
- 6. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Apache Kylin • 基于 Hadoop 生态环境，方便与 EMR 配合使用，减轻了维护基础 设施的压力 • 节点数据主要储存在 HBase 等 外部储存中，容易实现容器化 • 节点类型简单 (Job、Query 等) 相互耦合较低，数据 Rebalance 由底层储存实现 运维方面 • 支持 SQL 接口，提供多维度上接 近 Ad-hoc 的查询支持 • 在预定义的模型上提供亚秒级、 多租户并发查询的服务 • 支持 JDBC 和 RESTful API 两种 查询模式 • 可以使用 RESTful API 进行部分 数据维护操作 开发方面
- 7. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Strikingly Analytics • 提供真实可靠的数据 • 自动化的故障处理和恢复 • 协调系统架构当中各个组件的运行 • 实现稳定的用户服务和较低的数据传达延迟 真正的挑战 实现从数据收集到服务用户整条管线的正确运行！
- 8. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 9. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 10. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 11. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 系统架构
- 12. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 数据收集
- 13. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 数据收集 • 研发成本低 • 数据延迟较大 • 可定制性和灵活性较差 • 昂贵 第三方服务 Application Load Balancer • 研发成本稍高 • 数据延迟较低 • 可定制性和灵活性高 • 便宜(10x)
- 14. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 数据平台
- 15. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 数据平台 • 灵活性高 • 配置和运维成本高 • 需要自己安装 AWS 相关服务的 Java Library 自行部署 • 灵活性略低 • 配置和运维成本低 • 自动集成 AWS 相关服务 Jar 包， 方便部署自研的 ETL 过程 • 自动备份到 S3 Elastic Map Reduce
- 16. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 数据处理
- 17. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 数据处理
- 18. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 数据处理 • 模型简单易用 • 兼容 EMR 部署的 Hadoop 环境 • 接近 Ad-hoc 的 SQL 查询 • 多租户、亚秒级数据查询 • 易用的 RESTful API 接口 • 开源！ Apache Kylin • 容器化 (降低部署成本) • 改进运维方式，方便在容器化和 云部署的环境下执行运维任务 • 增强的错误隔离和错误处理能力 • 将 Kylin 嵌入数据处理管线 TODO (开源版本) 需要方便的工具处理 Kylin 和各种 AWS 服务的交互！
- 19. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 系统运维与协调
- 20. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 21. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 22. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 任务调度
- 23. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 24. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 25. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 错误隔离
- 26. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 查询服务
- 27. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 28. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 总结
- 29. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. 实时数据管线
- 30. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you!
Editor's Notes
- Google Analytics 对于很多普通用户来说仍然是一种比较高端的工具 很多用户不懂如何嵌入数据收集的 Script 灵活性：可以定制化地捕捉更多特定信息
- 多租户、亚秒级是重点 与 Google Analytics 不同，我们现在已经有大量的开源工具可以使用 重点是如何选择、组织、协调和搭建这样的一个系统
- 在基础设施方面，我们选择了 AWS 除了历史原因，主要看中的是 AWS 的声誉 + 工具链丰富
- 数据处理工具方面，选择的是 Kylin 主要看中的是 容易部署（Hadoop生态）、容易使用（SQL 接口）
- 端到端 Data 应用: 提供从数据收集、数据处理到用户查询的全套服务 更加接近用户、直接服务用户 数据模块和服务模块需要有机结合、协调工作
- 错误隔离，就是管线之中的一些步骤的错误可以被隔离在一定的层次，不会影响到最终用户查询的可用性 错误恢复，即是前序步骤的问题被解决之后，系统可以自动更新后续步骤的数据，使得用户最终获得正确的数据 （最终一致性！）
- 我们将端到端数据应用定义为3个级别 最下面的层次是数据正确性（一旦数据丢失和损毁，数据就无法再被恢复，用户只能获得有偏差的结果） 中间的层级是数据可用性（也就是查询服务的可用性。数据处理过程的错误，不应该影响用户的查询，用户应该看到一个数据统计的一个一致的快照） 最高的层次是数据低延迟（如果无法做成实时，则刷勋频率越高越好——给计算集群带来了很大的压力）
- 基础的数据架构如图所示： 最下层是数据收集、储存和备份的组件，这一层级是数据服务的基础，需要极高的可靠性 中间是数据处理（ETL）过程，这一过程的计算压力很大，在分布式环境下处理出错的概率也不低，是整个数据服务的核心 最上层是数据查询服务，这一层次需要很好的可用性，我们希望数据处理过程的错误，尽量不影响数据查询服务
- 要自己开发一个高可靠、可扩展、分布式的非常困难 经过多方调研，我们发现了一种特别省事的方法：使用 ALB log AWS 的 Application Load Balancer 支持将自己的 Access Log 定期放置到 S3 上 AWS 的 EMR 又可以直接读取 S3 上的数据， 因此，对于 ClickStream 这样的数据收集需求，前端打点只需要以 Get 请求的模式将信息编码在 URL 里，我们就可以方便地收集数据
- 重点：高可靠、低延迟、可定制、便宜！
- 在 AWS 搭建 Hadoop 集群，最佳的选择自然是 EMR
- 在数据处理方面，为了最大限度的降低研发成本，我们选用了开源的 Apache Kylin 项目帮助实现 ETL 过程
- 如图是对 Apache Kylin 的简单原理的介绍，他通过将用户指定的模型转化为 MapReduce 或 Spark 的构建任务，对一些查询结果进行预聚合，从而将 Hive 上储存的数据缓存在 HBase 上，从而可以进行快速查询
- 综上所述，通过编写一个集中式的调度器，我们将 Kylin 和 AWS 的各个服务协调联系起来，实现了各种构建和运维服务。也实现了错误隔离和
- 进行容器化，一方面是因为 Kylin 几乎是无状态的，另一方面，我们为 Kylin 自行编写了启动脚本，在启动的时候，将环境变量填入 Hadoop 各个组件所需的配置文件模板，从而实现了容器启动的灵活性
- 同时 调度器 也集成了运维功能，直接使用 Java API 读写 Kylin 的 HBase + HDFS 数据，将其备份到 S3 上
- 在任务调度模型上，我们采用了两步调度的方案 在每一次任务调度时，系统会从 Kylin 和 DynamoDB 上获得此前所有任务的状态和当前系统的状态，使用这些状态信息，将需要执行的任务转化为对个针对不同资源的的小任务 这些小人物将会被加入到不同的队列当中进行执行 使用两步调度，系统就可以在 Plan 阶段发现之前构建的任务，在之前的步骤出错或者系统重启的情况下可以将系统恢复到正确的状态（比如弥补数据延迟、空洞等） 实现了错误恢复
- 在这个过程中，我们发现了构建任务时间 Skew 的问题。 有些任务构建的事件很长，如果简单的随机分配任务导致一些任务完成时间拖延 某些任务执行时间很长、有些执行很短，需要提高短任务的结束时间
- 将所有任务按照快慢分桶，快任务和慢任务在两个通道进行调度，提高了端任务的完成时间
- 借用 Kylin 的 Cache 机制，调度器可以做到，在调度失败之后不通知 Query 节点清空 Cache， 从而使用户查询停留在一个正确的状态。 增加了 Cache 控制逻辑的复杂度 增加了 GC 实现的复杂度（不能删除还被 Cache 引用的资源！） 实现了错误隔离！
- 在容器化 Kylin 之后，接下来的一个需求就是实现 Kylin 的高可用和自动扩展 Kylin 分为 Job 节点和 Query 节点 需要 Job 节点在构建结束之后通知Query 节点构建成功并清空缓存 这一模式对 Query 节点的 fail over 和 自动扩展带来了苦难：动态端口 出错重启时 自动扩展时 容器调度时
- 为了解决上述动态端口的问题，我们选择选用 Target Group 作为 Service Discovery 工具，由调度器激发构建任务并监控，因此在任务完成之后可以由调度器通知query节点
- 最后我们的系统管线从数据收集端直到用户查询服务都实现了端到端数据服务的第二个层次——高可用性