kudu

随着互联网的发展进入下半场，数据的时效性对企业的精细化运营越来越重要， 商场如战场，在每天产生的海量数据中，如何能实时有效的挖掘出有价值的信息， 对企业的决策运营策略调整有很大帮助。此外，随着 5G 技术的成熟、广泛应用， 对于工业互联网、物联网等数据时效性要求非常高的行业，企业就更需要一套完整成熟的实时数据体系来提高自身的行业竞争力。 本文从上述现状及实时数据需求出发，结合工业界案例、笔者的实时数据开发经验， 梳理总结了实时数据体系建设的总体方案，本文主要分为三个部分： 第一部分主要介绍了当下在工业界比较火热的实时计算引擎 Flink 在实时数据体系建设过程中主要的应用场景及对应解决方案； 第二部分从实时数据体系架构、实时数据模型分层、实时数据体系建设方式、流批一体实时数据架构发展等四个方面思考了实时数据体系的建设方案； 第三部分则以一个具体案例介绍如何使用 Flink SQL 完成实时数据统计类需求。 一、Flink 实时应用场景 目前看来，Flink 在实时计算领域内的主要应用场景主要可分为四类场景， 分别是实时数据同步、流式 ETL、实时数据分析和复杂事件处理，具体的业务场景和对应的解决方案可详细研究下图， 文字层面不再详述。 二、实时数据体系架构 实时数据体系大致分为三类场景：流量类、业务类和特征类，这三种场景各有不同。 在数据模型上，流量类是扁平化的宽表

简介： 对于鹰角网络遇到的数据激增以及数据统一收治方面的问题，阿里云对象存储 OSS 为其提供了统一的数据存储 池，方便鹰角网络将全球收集到的海量不同数据进行统一存储，同时阿里云对象存储 OSS 可无缝对接 云原生数据湖 分析 DLA，DLA 提供扫描量版与 CU 版的 SQL 服务，可以针对 Kudu 与 OSS 做开箱即用的数据分析。帮助鹰角网 络快速产出数据报表，让 IT 人员能投入到更多的精力在技术上，推进业务发展。 公司介绍 上海鹰角网络科技有限公司是一家网络游戏研发运营公司， 为了制作出充满挑战乐趣与拥有艺术价值的游戏而诞生，它以开发和运营了手机游戏《明日方舟》在业界闻名。 业务介绍 《明日方舟》是一款策略手游，结合二次元、塔防、养成、抽卡等元素，于 2019 年 5 月 1 日公测。一经上线，就引爆国内游戏市场，成为现象级手游，5 月流水高达 6 亿+，某应用商店2次登顶。经过半年筹备，2020 年 1 月《明日方舟》开始在日韩欧美发行，迅速抢占国外手游市场，成为全球最火爆的手游之一。 《明日方舟》作为一款免费游戏，游戏厂商的主营收来自于游戏内的道具消费，因此如何做到精细化运营，根据用户的活跃数据、充值数据、偏好数据等为用户推送不同的活动以及玩法。同时由于游戏业务出海以及各地区游戏用户激增增加，因此鹰角网络就需要一个稳定、弹性且高性能的存储与计算平台

这是【kudu pk parquet】的第二篇，query2在kudu和parquet上的对比解析，其中kudu包含有不能下发的谓词。 3台物理机，1T规模的数据集，impala和kudu版本是我们修改后支持runtime filter的版本，结果对比如下图： 纵坐标表示耗时，矮表示性能好，耗时短，响应差近三倍。 首先，来我们来看两者的执行计划，颜色越鲜艳表示越耗时： parquet kudu 可以看到kudu左右两边各有一个鲜艳的红色框（节点），说明这两个执行节点耗时比较长，放大来看： 左边部分： parquet kudu 上面两个图的执行计划红色圈起来部分，parquet的扫描（“05：SCAN KUDU”）和关联（“09：HASH JOIN”）分别只要1秒钟左右，而kudu则要7秒和11秒。 大家注意到了没有，“07：SCAN KUDU”这个节点在两个引擎上返回的数据量是不一样的，parquet只返回了5条记录，kudu则返回了25条。同时这个返回结果是作为runtime filter应用于“06：SCAN KUDU”的，所以可以看到“06：SCAN KUDU”节点上返回的数据量，呈现几何级的差异（条件宽泛，所以匹配的数据量就多了）。接着，过滤出来的结果再runtime filter应用于“05：SCAN KUDU”节点。为什么“05：SCAN KUDU

在一个大数据团队中，大数据架构师主要关注的 核心问题就是技术架构选型问题 。架构选型问题一般会受到哪些因素的影响呢？在我们的实践中，一般大数据领域架构选型最受以下几个因素影响： 数据量级 这一点在大数据领域尤其是一个重要的因素。不过从根本上讲，数据量级本身也是一种业务场景的衡量。数据量级的不同往往也就昭示着业务场景的不同。 业务需求 经验丰富的大数据架构师能够从纷繁的业务需求中提炼出核心技术点，根据抽象的技术点选择合适的技术架构。主要的业务需求可能包括：应用实时性要求、查询的维度和灵活程度、多租户、安全审计需求等等。 维护成本 这一点上大数据架构师一方面要能够清楚的了解各种大数据技术栈的优劣势，在满足业务需求的要求下，能够充分的优化架构，合理的架构能够降低维护的成本，提升开发的效率。 另一方面， 大数据架构师要能清楚的了解自己团队成员，能了解其他同学的技术专长和品位，能够保证自己做的技术架构可以得到认可和理解，也能得到最好的维护和发展。 接下来我们会围绕这几个方面去看看，做一个最适合自己团队业务的架构选型会如何受到这些因素的影响？ 技术架构选型 业务需求是五花八门的，往往影响我们做技术选型的不是种种需求的细节，而是经过提炼后的一些具体的场景。就好比，业务需求提出我们要做一个日志分析系统，或者要做一个用户行为分析系统，这些具体需求背后我们要关注哪些具体的点？这是一个很有趣的问题

去年10月份放下了一手打造的缓存服务（NKV和NCR），投身到新成立的数据科学中心从事大数据存储相关的工作，新的部门、新的项目、新的知识，脚踏实地，从零开始。 第一款调研的对象是cloudera公司刚开源的kudu产品，可以将其理解为是hadoop系统中的hdfs，一个存储引擎，但是和hdfs的不同之处是它支持update操作，这点非常重要！ 可能是因为刚开源的缘故，文档中很多的的使用方式、操作步骤的描述都和cloudera manager（简称CM）紧紧的耦合在一起，所以一开始的时候，根本不清楚怎样独立部署kudu集群以及怎样是最佳部署方式。无奈，只好先从cloudera manager管理平台安装部署，然后等到熟悉以后再将其剥离出来，事实上后来剥离的kudu和impala的配置文件的配置参数就直接参考这里的。部署CM&CDH就花了九牛二虎之力，过程就不再细说，都是泪。 就像高富帅择偶一样，大公司cloudera出来的产品，对操作系统也是百般的挑剔，又要有绝对的话语权（root权限），所以一周又一周的要求sa帮忙续命（骚瑞啊，真的不是在耍你们，向sa们致以诚挚的敬意）。成功完成集群安装部署，面临着怎么来测试，用什么工具的尴尬，大家都没经验。 一开始，我们选择了ycsb来进行测试，有两种方式：一种是通过JDBC驱动的方式，另一种是通过kudu bind的方式