kudu

数据中台的由来 数据中台最早是阿里提出的，但真正火起来是2018 年，我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。为什么很多公司开始建设数据中台？尽管数据中台的文章很多，但是一千人眼里有一千个数据中台，到底什么是数据中台？数据中台包含什么? 当企业需要数据化转型、精细化运营，进而产生大规模数据应用需求的时候，就需要建设数据中台。数据中台是高质量、高效赋能数据前台的一系列数据系统和数据服务的组合。数据中台包含数仓体系、数据服务集和BI 平台。 1、是阿里拜访芬兰的一家公司—SupperCell，只有不到10个人，每个员工创造估值3.74亿 ​ 2、淘宝遇到的问题：淘宝和天猫是两套完全独立的两套系统，但是却都包含了商品、交易、评价、支付、物流 ​ 3、中台之前类似的思想 SOA（方法）：面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。 电商系统的四个发展阶段 1、单一系统 2、分布式系统 3、平台化（服务业务，支撑作用） 4、中台化（驱动业务，中枢作用） 第一阶段：数据库节点：单一业务系统阶段 第二阶段

大数据的热度在持续的升温，继云计算之后大数据成为又一大众所追捧的新星。数据的确是公司最最重要的核心资产。随着业务的迅速发展，交易数据呈几何级增加，随之而来的是系统的不堪重负。业务部门、领导、甚至是集团老总整天嚷嚷的要报表、要分析、要提升竞争力。而研发部门能做的唯一事情就是执行一条一条复杂到自己都难以想象的SQL语句，紧接着系统开始罢工，内存溢出，宕机........简直就是噩梦。OMG！please release me！！！ 俗话说，工欲善其事，必先利其器。 本专栏内容从大数据运维角度出发，指导安装大数据平台，组件调优及默认配置修改去解决内存溢出，服务器宕机，kudu超时等业务无法处理的问题。 专栏内容架构分为： 总共分为20篇文章，其中1篇理论介绍大数据平台，12篇CDH实践，7篇ambari实践。 CDH基础入门（1篇）+性能调优（4篇）+安全实战（7篇） Ambari基础入门（1篇）+性能调优（1篇）+安全实战（5篇） 扫码回复【大数据运维】，进专栏兴趣群 来源： oschina 链接： https://my.oschina.net/u/4419312/blog/4313500

作者介绍：朱志友，中通快递大数据架构师。 中通快递背景介绍 中通快递业务的规模目前是世界第一，是第一个达成年百亿业务量的快递企业，在 2019 年的双十一更是完成了订单量超过 2 亿的佳绩。中通科技是中通快递旗下的互联网物流科技平台，拥有一支千余人规模的研发团队，秉承着“互联网+物流”的理念，与公司的战略、业务紧密的衔接，为中通生态圈的业务打造全场景全链路的数字化平台服务。 上图展示了快递物流的生命周期，简单举个例子，大家如果在某宝上下了一个订单，从付款结束开始，到商家打单，大家的包裹基本上就开启了一个快递的旅程。简单的介绍可以分为五个字，收发到派签，整个物流的全链路中可以拆解成以下的关键节点，客户下单之后快递员的揽收，揽收网点的建包，建包之后会把快递交到中心，至此快递就开启了转运和运输的过程，最终负责派件的末端网点会根据三段码的解析去末端的中心把快递拉到末端的快递网点进行分拣，分拣之后会指派到指定的快递员，进行派件，快递小哥会把快递送到客户的手里，客户完成签收，在我们看来这一票件就完成了快递的全链路的生命周期。在每个环节中会产生大量的数据，对每个环节的每一个数据我们都会进行相关的分析，包括时效的监控。 2017 年的时候，我们就已经开始关注 TiDB ，那时候的关注点主要在解决一些分库分表的问题上，从 2018 年底开始调研测试大数据，我们主要想去解决存储和计算的问题，2019

1、cut：字段截取 [root@master regex]# cat stu.txt ID Name gender Mark 1 Jordan M 100 2 Kobi M 99 3 Mom F 90 [root@master regex]# cut -f 2 stu.txt Name Jordan Kobi Mom [root@master regex]# cut -f 2,3 stu.txt Name gender Jordan M Kobi M Mom F 2、printf:字符输出函数 [root@master regex]# printf '%s\t%s\t%s\t%s\n' $(cat stu.txt) ID Name gender Mark 1 Jordan M 100 2 Kobi M 99 3 Mom F 90 3、awk: 处理文本文件 [root@master regex]# awk '{printf $2 "\t" $4 "\n"}' stu.txt Name Mark Jordan 100 Kobi 99 Mom 90 [root@master regex]# awk '{print $2 "\t" $4 "\n"}' stu.txt Name Mark Jordan 100 Kobi 99 Mom 90 [root@master regex]# awk

我的情况跟这篇blog情况几乎相似。 https://www.jianshu.com/p/d2e711862e24 后来查证结果是，由于我们的Cloudera Manager集群使用了Kudu，并对Kudu进行了监控和采集。CDH manager对于Kudu的监控项特别多，每一个Kudu表对应大概20个指标。这些时序数据，会由SMON（service monitor）接收并写入本地的LevelDB，并定时对其进行rollup操作(即把秒的变成分钟，和小时的数据)。由于这个明细数据量过大，导致SMON一直都处于高负荷状态。 解决思路有2个： 1.是干掉rollup操作 2.是停掉Kudu的数据采集(数据量极大) 个人倾向于第二个，干掉Kudu的数据采集。kudu的数据采集有大量的采集内容并不是我们想要的，而且也有很多小的表，临时表是不需要监控的。Kudu的数据采集是基于http的json结构，在每个Tablet-Server上面可以进行采集，所以最好的思路是自己采集想要的metrics进行针对性监控。 关于配置rollup的内容： https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/cm_ig_storage.html 来源： oschina 链接： https://my.oschina.net

首先我的服务器是Centos7.6。低于7版本的小伙伴不可照搬。 我选择的是使用rpm的方式进行安装，比较方便。 kudu安装包下载地址 ctrl+f 查找kudu，这6个rpm包都要下载下来，推荐使用迅雷下载 在下载的时候我们还需要做一些准备工作。执行以下命令，安装必备的包。 sudo yum install autoconf automake cyrus-sasl-devel cyrus-sasl-gssapi \ cyrus-sasl-plain flex gcc gcc-c++ gdb git java-1.8.0-openjdk-devel \ krb5-server krb5-workstation libtool make openssl-devel patch \ pkgconfig redhat-lsb-core rsync unzip vim-common which 没有安装ntp的也需要安装。 sudo yum install ntp 下载后上传至服务器，你们可以自行创建目录，我上传的目录是： ~/software/kudu 在这个目录下执行以下命令，安装rpm包。 sudo rpm -ivh --nodeps * 之后我们需要创建元数据目录、数据目录和日志目录。 master元数据目录 sudo mkdir -p /data/kudu/kudu

作者：董亭亭、徐明 摘要：作为短视频分享跟直播的平台，快手有诸多业务场景应用了 Flink，包括短视频、直播的质量监控、用户增长分析、实时数据处理、直播 CDN 调度等。此次主要介绍在快手使用 Flink 在实时多维分析场景的应用与优化。主要内容包括： Flink 在快手应用场景及规模 快手实时多维分析平台 SlimBase-更省 IO、嵌入式共享 state 存储 Tips：点击下方链接可查看作者原版PPT及分享视频～ https://ververica.cn/developers/flink-forward-asia-2019/ Flink 在快手应用场景及规模 首先看 Flink 在快手的应用场景和规模。 1. 快手应用场景 快手计算链路是从 DB/Binlog 以及 WebService Log 实时入到 Kafka 中，然后接入 Flink 做实时计算，其中包括实时数仓、实时分析以及实时训练，最后的结果存到 Druid、Kudu、HBase 或者 ClickHouse 里面；同时 Kafka 数据实时 Dump 一份到 Hadoop 集群，然后通过 Hive、MapReduce 或者 Spark 来做离线计算；最终实时计算和离线计算的结果数据会用内部自研 BI 工具 KwaiBI 来展现出来。 Flink 在快手典型的应用场景主要分为三大类： 80% 统计监控 ：实时统计

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 导读： 本文带你了解面向列与面向行的数据库。 大多数数据库系统存储一组数据记录，这些记录由表中的列和行组成。字段是列和行的交集：某种类型的单个值。 属于同一列的字段通常具有相同的数据类型。例如，如果我们定义了一个包含用户数据的表，那么所有的用户名都将是相同的类型，并且属于同一列。在逻辑上属于同一数据记录（通常由键标识）的值的集合构成一行。 对数据库进行分类的方法之一是按数据在磁盘上的存储方式进行分类：按行或按列进行分类。表可以水平分区（将属于同一行的值存储在一起），也可以垂直分区（将属于同一列的值存储在一起）。图1-2描述了这种区别：a）显示了按列分区的值，b）显示了按行分区的值。 面向行的数据库的例子很多：MySQL、PostgreSQL和大多数传统的关系数据库。而两个开源的、面向列数据存储的先驱则是MonetDB和C-Store（C-Store是Vertica的开源前身）。 01 面向行的数据布局 面向行的数据库按记录或行来存储数据。它的布局非常接近表格的数据表示方法，即其中每一行都具有相同的字段集合。例如，面向行的数据库可以有效地存储用户条目，其中包含姓名、出生日期和电话号码： | ID | Name | Birth Date | Phone Number | | 10

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