sunlen的专栏(编程技术探讨)

在一个项目中，实时生成的统计数据需要关联另外一张表（并非维表），需要统计的数据表是Kafka数据，而需要关联的表，由于不是维度，不能按照主键查询，所以如果放在MySQL上，将存在严重的性能问题，这个时候我想到用将两张表的数据都生成为Kafka数据，然后进行Join操作。中途发现这种性能特别差，而且表变更会产生多条kakfa记录，导致计算越来越来，最后改成upsert-kafka，下面记录下处理过程。上面这种方法，可以对重复的数据，按照主键进行去重，大幅减少生成重复的数据。

ClickHouse按批生成文件，如果每一批的数量过小，那么就会产生大量的小文件，ClickHouse底层会自动会这些小文件进行merge动作，减小文件数量，但这个动作消耗大量的cpu。Clickhouse在进行大数据量同步时，感觉很爽，插入速度非常快，但是，在使用过程中却出现了几次“Too many parts”异常报错，搞得很痛苦，这里记录一下解决过程。同时，当小文件超过系统涉及的阈值，就会报“Too many parts”异常。通过分析cpu，发现在某些时刻，cpu使用率突然暴涨。

最近在开发Flink SQL的时候，需要关联Kafka事实表和MySQL维表，得到的数据写入Phoenix表中，但是其中有个字段，Kafka表、MySQL表和Phoenix表都是BigData类型，但是在实现的时候却报“java.math.BigInteger cannot be cast to java.lang.Long”异常，从报错信息来看，是由于BigInteger 和Long的转换出现问题，下面详细讲解一下报错过程。

但是性能还是不行，这是我点击查询20个子任务的执行情况，以为发现实际上只有8个任务是真实执行的，其他任务都在空跑，通过一方检查，重要发现原先我设置的kafka topic，只设置了8个partition，导致最终只有8个任务执行。但是这种方式有个问题，就是每条数据过来，都需要需要到MySQL查询一次，由于这边的数据量非常大，可以想想，需要到MySQL查询维表的次数将非常频繁，另外，由于这边另外一张表是数据量也非常大，采用这种方式，必然会MySQL的性能造成非常大的冲击。

这里底层基于Phoenix和ClickHouse作为大数据数据库，构建大数据智能分析平台，底层通过元数据管理，构建数据集、字段、指标、维度等，上面通过图表配置、看板配置，通过拖拉拽快速构建报表。ETL数据抽取、转化、加载，基于Flink Sql构建流批一体的实时数据仓库。本设计会分为多个篇文章，讲解整个系统架构设计的细节。整个大数据智能分析平台，作为一个数据中台，对外提供各种API，与第三方应用集成。首先会介绍整个系统体系设计到的各个名词。

最近遇到一个大坑，因为ClickHouse大表关联小表，如果大表放在右边，性能急速下降，甚至无法执行，我这边报的是“超过16G异常”，所以我自然而然的想到把大表放左边，然后把Left Join改成Right Join，这个逻辑在MySQL是正确的，没想到ClickHouse统计出来的结果居然差距巨大，踩了一个大坑。下面我就详细讲一下问题的情况。...

最近遇到一个问题，ClickHouse中有一张表，里面有个用户(f_user)字段，每天都有统计数据，现在想取某一个的产生的新用户数据，因为用惯了MySQL，我很自然的想到同一张表做一个Join操作，然后前表的日期大于后表，where过滤条件中，后表的日期为null，这样就能取出数据，但最后发现ClickHouse并不支持这种操作，折腾了好久，最后终于搞定这个问题，这里详细描述一下过程。...

ClickHosue是一个越来越受欢迎的大数据数据库，语法跟MySql类似，使用比较简单，下面从我们的亲身经历，讲一讲ClickHouse的语法等，让你对是否使用这个数据库来代替MySQL有着更为深刻的印象。...

这边在初始化Phoenix表数据的时候，遇到一个难题，就是需要往Phoenix里面初始化30亿的数据，而采用普通方式往phoenix插入数据，执行实在太慢，而且对现网phoenix会造成压力，导致现网phoenix的正常服务出现问题。 实际在处理过程中，发现了很多坑，和走了很多弯路。 下面详细讲一下解决方法和实现代码。 先说一下我的原始数据，原始数据是保持在MySQL里面的，采用分库分表的方式存储，HIVE也保存了一份离线数据。 刚开始想把...

这边在跑Flink Sql的时候，服务老是提示重启，查询后台报“Task did not exit gracefully within 180 + seconds”错误，经过排查，又没有发现太多异常信息，监控发现同时有服务后台文件句柄数增多的现象，下面详细讲一下发现的情况和解决方法。 错误信息如下：2021-12-22 14:55:20,696-[Cancellation Watchdog for Source: TableSourceScan(table=[[default_c...

在某一天，我们的系统突然异常，大面积出现白屏，搜索页面点击后，响应非常慢，大量出现响应超过4秒的情况，异常高峰期平均查询时间达到10多秒，后台不断有ES服务宕机重启，GC告警频繁，经过一阵排查折腾，发现居然是简单的_uid字段排序导致的，下面就详细的讲一下。 我们的ES搜索收到一个小小的需求，原来我们的搜索，新的结果会被放到后面去，产品经理希望能够对搜索结果进行排序，按照创建时间倒序排序。 这里自然的相对用ES系统字段_uid进行倒序排序，因为这个字段是按照创建时间生成的...

在清空Phoenix表的时候，发现报异常信息：MutationState sizeof 512000 isbigger than max allowed size of 500000 上面这句话的意思，就是说删除的数据量超过50万，太大，不允许删除，而这边使用Phoenix表，目的就是存放大数据表，如果不能删除超过50万的数据，将导致使用极其不方便，这里就具体讲解解决方案。 之所以有这个报错，是因为我们采用了Phoenix的轻量级客户端queryserver，删除的操作...

在使用phoenix查询的时候，发现phoenix对group by嵌套查询支持并不是太好，当存在多重嵌套的时候，很容易出现异常，另外，也容易出现“ambiguous or duplicate names”这样的报错，下面详细讲解一下问题发生的情况，已经解决方法。 下面的具体的报错信息（示意错误信息，涉及业务的部分被隐藏）2021-10-27 10:57:08,598-{}-39678-[main]-com.test.dash.service.impl.TestDwbServic...

phoenix的写法对数据类型限制比较严格，对于字符串类型，需要使用to_number将字符串转换成数字，但是在使用过程中，发现一个很奇怪的现象，那就是以整10为倍数的数据，比如说100，就会被显示成科学计数法。 下面详细讲一下具体的问题。 首先，我的表在设计的时候，采用字符串来保存ID，但是另外一个表是采用BIGINT类型存储的，所有需要对该字段进行转换，转成数组，写法为：to_number(TRIM(f_test),'###0')。 这上面，'###0'...

我在使用phoenix插入数据是，使用了upsert ... on duplicate ...结构，但是在运行的时候报错，现在将错误情况同步出来。

HBase的Region损坏后果很严重，会导致整个HBase异常，数据不能用。修复Region需要花费时间，当出现大面积的Region损坏的时候，后果几乎是致命的。 这里会详细讲解我们在开发过程中发现的Region损坏情况和解决思路。 问题描述：我们在做大量数据写入的时候，突然发生Region Server重启，重启后，出现大量的Region损坏，下面是检查发现的问题。 通过分析，首先确认导致Region Server重启的原因，应该就是Full GC导致的，...

在windows环境下，跑Spark程序，报“tmp/hive”权限不对，用docs命令加上权限，又提示“ChangeFileModeByMask error”，网上没有一个正确的解决方案，几经折腾，最终搞定，经验分享给大家。 我在window10跑Spark离线任务，抛如下异常：Exception in thread "main" org.apache.spark.sql.AnalysisException: java.lang.RuntimeException: java.lan...

系统报错：WAL system stuck，如下： 出现这种异常，基本可以确定是HDFS不可读写了，一般情况下是IO被打满，或者HDFS存储被打满。 我们检查了HDFS存储，果然发现HDFS存储使用率已经达到了95%。 进一步分析发现，我们当时在做扩容，而扩容后，HBase会自动做数据迁移，迁移的过程中，HBase会自动做major compact，而做major compact的时候，数据量会翻倍，导致HDFS存储使用率超了。...

截止到2020年12月，Phoenix最高只支持到Hbase2.0版本，并不支持更高的版本。而我们采用的是腾讯云HBase，使用的版本是2.2.0版本，我们在使用Phoenix-5.0版本时，发现系统报错，无法正常使用。其实Phoenix-5.0版本已经两年多没有更新了，而Hbase还在不断演进，越来越多的人使用Hbase2.0以上版本，这个问题会越来越突出，我们跟踪发现，只要做些简单处理，Phoenix-5.0就可以支持Hbase 2.2.0版本，运行非常稳定。外面是目前支持的版本，最多只支.

Phoenix是基于HBase的，而Phoenix的索引其实是HBase的二级索引，当Phoenix的索引处于disable状态时，整个Phoenix表是无法正常使用的，要将索引修复为enable状态，往往需要重建索引，这对应一些大表来说，往往需要花费几个小时是时间，那么这几个小时，系统基本上就处于不可用状态，这对应现网系统来说，往往是不可接受的。 其实Phoenix有3个隐藏参数，这些参数在官网文档没有体现，但实际上这3个参数非常重要，可以解决上面提到的问题。 闲话不说，先来讲...

随着大数据应用的普及，所引起问题受到越来越多的关注，其中，大部分关注在于隐私泄露、信息安全和数据鸿沟上面，而大数据应用所引起的“情感趋同现象”相对研究较少，本文通过对不同学者的理论进行梳理和对比，分析大数据产品“情感趋同现象”的起因、表现方式和解决方案等，希望能引起学界的共鸣。大数据应用“情感趋同现象”的形成原因 高建国在他的《人性心理学》中指出，“趋同是指两种或两种以上亲缘关系甚远的生物，由于栖居于同一类型的环境之中，从而演化成具有相似的形态特征或构造的现象。不同的生物，无亲缘的种，在...

网络上有不少Kettle的文章，但实际上都大同小异，都是些非常基础的文章，实际上在使用过程中还有遇到不少的坑，这部分在网上资料比较少，这里主要讲一下我们在使用过程中遇到的各种问题，属于难得的实践经验。说起ETL工具，很多人都觉得这个东西简单，不用学Mysql，不用学大数据的编程，简单的通过图形化的拖拉拽，就能实现对数据的抽取、转换、加载，而实际上往往并非如此，在复杂一点的应用场景上，往往就会出现一些意想不到的坑。低代码化、无码化的系统架构，现在比较流行。Kettle作为一个大数据的ETL..

在使用Phoenix的过程中，发现了一个奇怪的异常现象，其中一个表，有个字段（VARCHAR类型），一旦这个字段被更新为null值，从此就无法重新更新该字段的值。我在测试过程中，重新新建一张表，就发现可以正常更新，是我困惑不已。最后经过反复对比，发现是另外一个字段设置成ROW_TIMESTAMP导致的，下面详细讲述一些问题的复习。目前测试发现问题的Phoenix版本为4.14.0...

最近在使用Phoenix，采用sqlline模式执行的时候，经常时不时的出现OutOfMemoryError错误，如下：java.lang.OutOfMemoryError: unable to create new native thread刚开始一直以为的Phoenix和HBase的参数设置问题，经过多次调测，问题依然没有解决，后来才发现的Linux系统的参数设置问题。原先Linux...

网上有很多Kafka的文章，但大多写得千篇一律，要么偏理论化，无实战数据参考。要么写了发现的某个问题的解决方案，对于想在实际环境上搭建真实的Kafka环境，参考意义并不大。 这篇文章基于大量的实战经验，在大规模，海量数据，以及实时处理的环境下，这些经验也是在解决Kafka很多真实问题得出的。试图在一开始就协助大家在大家在搭建真实Kafka环境的时候，提前做好最优的解决...

基于阿里云的双活灾备方案的设计说起容灾备份方案，一般说来有下面这个发展方向：​​下面简单介绍下各个方案的内容：冷备：离线手工对数据进行容灾备份，当发生故障时，手工切换到备用环境 热备：实时对主生产环境的数据进行备份，当发生故障时，自动或手工切换到灾备环境 双活：两套环境实时进行双向数据同步，每套环境都承载其中一部分流量，当发生故障时，只由其中一套环境承载所有流量...

 Disruptor是什么，怎么使用，网上有很多教材，但有些过于复杂，剖析了Disruptor的方方面面，实际上对应普通的开发人员，使用这个工具，只需要指导知道大概原理和使用方法，并不需要知道非常深入的原理。有些文章则是写了错误的实例，或者只是摘取了项目的一段代码，实际上，要把这些代码转化成项目的实际代码，却发现困难重重。这个文章主要是针对想提高性能，在项目组使用Disruptor的开...

    很多企业在启动软件开发的时候，完成没有命名规范，导致代码的可读性极差。而业界对于命名，却没有一个统一的命名规范，比如说，获取客户列表，Java类的方法是用get***List还是list****？这些完全的统一的规范 。    这里给出SaaS行业额命名规范，参考了阿里编码规范，加上我十几年来对业务的理解而写成的，可以作为一个开发人员形成一个统一的规范，建议一个项目在启动之前，采用该规...

马云：大家还没搞清PC时代的时候，移动互联网来了，还没搞清移动互联网的时候，大数据时代来了。

在线客服需求：涉及人员：客服人员，普通客户客服人员：有固定的工号登录，用户可以选择客服人员。每各客服人员可以设置最大聊天人数。客服人员不在线时，不能聊天。普通客户：匿名登录。普通客户之间不能聊天，可以选择客服人员。聊天可以由客服人员发起，或者普通客户发起。在线客服只支持聊天信息的发送。不支持注册，状态，注册等功能。在线客服的技术主要有以下几种方案（只是目前我了解的）：

Think in Pushlet 作者：cleverpig介绍         server端向浏览器client发送通知这种通讯模式在J2EE应用中很常见，通常使用采用RMI、CORBA或者自定义TCP/IP信息的applet来实现。这些技术往往由于复杂而产生诸多不利之处：技术难以实现、存在防火墙限制（因为需要打开非HTTP的通讯端口）、需要额外的server

Comet：基于 HTTP 长连接的“服务器推”技术2008-06-30 21:31 别： 中级 周 婷 (zhouting@cn.ibm.com), 软件工程师, IBM 中国软件开发技术实验室 2007 年 8 月 31 日

福建电信科学技术研究院 吴学慧    一、电信业务平台的现状    遍览福建电信的业务平台，省一级的有智能网、彩铃平台、114平台（号码百事通平台）、168、160、短信、互联星空、超级邮箱等诸多平台；地市一级也有繁多的类似平台。    这些平台建设于不同的时期，是为满足当时市场的需求，向用户提供单一的某类业务，这些平台都是相对独立的，如彩铃平台只提供被叫彩铃、企业彩铃、广告彩铃等相关

基于UML的短消息计费系统的分析与设计Cww.net.cn 2004年12月9日 17:20 通信世界网 南京邮电学院  顾强 宫婧 郑彦    短消息业务发展迅猛，形成了从手机用户到服务内容提供商的一整套产业链，并逐渐成为各移动通信运营商新的经济增长点。有数据表明，截至2003年12月31日，中国移动（香港）有限公司，包括广东、浙江、江苏、上海、北京等21家子公司，移动用户数

1　前言　　呼叫中心（CallCenter）是一种利用计算机在传统电话网上提供增值业务的技术，是企业提高服务质量。降低运作费用。优化全局管理的有效途径。最初的呼叫中心类似于现在的热线电话，由若干个人工座席（业务代表）通过电话处理用户的咨询和请求。当前呼叫中心已经发展成为一个面向用户的综合性“客户服务中心”。从应用状况来看，呼叫中心已经由最初的电信客户服务中心 （114、112、121等）发展到现在

呼叫中心沧桑巨变 颜君 2006/10/30　　呼叫中心发展至今已有近十年的历程，随着市场规模逐步扩大、技术迅速发展和客户需求多元化，呼叫中心正显示出引人注目的变革。 客服型呼叫中心愈加个性化 　　最初的呼叫中心大多应用于大型企业的客户服务部门。如今，客服仍是很多新领域构建呼叫中心的初衷。与以往不同的是，应用领域的多样化使呼叫中心个性化需求越来越突出。 　　据悉，仅在上半年，就

号码百事通开拓综合信息服务新境界2006/10/16　　“号码百事通”是一切基于中国电信114台的增值业务的统称，其目的就是要在充份挖掘和整合用户号码信息的基础上，延伸和拓展传统的查号业务，满足用户现实和潜在的各类信息查询需求，将114台打造成一个综合类信息服务平台，从而提高中国电信差异化服务优势。 　　浙江省电信有限公司是境外上市的中国电信股份有限公司的全资子公司，在浙江省设有73个