在实时数据平台中,为了保证数据是可追溯的，一般会在数据生成时给每一条数据分配一个唯一的ID，以及生成的时间，最好再带上数据源的信息，这样DEBUG的时候就能知道数据是从哪来的。然后在数据的每个流转环节中，将每一条数据的ID和到达时间记录到日志或者其他存储中
这样在发生问题或者调试时，就能通过ID重现数据的轨迹，包括数据行经的每个组件以及消耗的时间。这个过程能够通过ELK轻松完成，将所有组件的日志导入ES，然后使用ID在Kibana中搜索，甚至可以通过定制图表来实现数据链路可视化，这里不做展开
最近要把Kafka集群从0.10.1.1升级到1.0.0，主要是为了使用新的ProducerRecord和ConsumerRecord中的Header来保存和传输一些metadata，要求升级过程中不能服务不能中断，所以不考虑整体停机升级的方案，升级过程如下:
最近对HBase做了升级，从0.92升级到了1.2.0-cdh5.11.1，版本跨度很大，而且从社区版转向了Cloudera。之所以改用CDH，是因为大概两年前在前一个公司做HBase CDH4到CDH5的升级，由于一开始搭建集群的时候就没用Cloudera Manager，所以导致升级非常痛苦，因为两个版本之间底层文件的格式变了，所以为了稳定，找了另外一批机器装了CDH5，然后实现源数据的双写，再用export+import把CDH4的数据全量导过去，最后稳定并行一段时间之后把CDH4停掉。整个流程听着就很麻烦，开销也很大（相当于资源*2），所以这次选择了先把0.92平移到CDH4，然后用Cloudera Manager升级，整个过程非常平滑
Elasticsearch的TTL已经在5.0之后废除，它的原理是定时标记过期数据，然后从index中删除并执行merge，这个操作的开销是很大的，这就是TTL被废除的原因。作为替代，5.0之后加入了Rollover API，我们可以基于这个功能在某种程度上实现TTL语法
最近申请了几台机器专门用来运行Kafka Streams应用，发现经常发生OOM导致应用挂掉，原因是启动的时候指定了-Xms2G -Xmx2G，所以16G内存的机器没启几个应用内存就被占满了，尽管这些程序只是空跑。查了一下一般都建议-Xms和-Xmx设置为相等，那么能不能设置为不一样呢？
Maven错误信息：Missing artifact jdk.tools:jdk.tools:jar:1.6
最近发现只要在Maven项目中引入HBase依赖，就会报错Missing artifact jdk.tools:jdk.tools:jar:1.6
如果你的ES集群的每台机器性能有比较大的差距，比如其中几台机器有SSD而其他机器用的普通磁盘，或者部分机器内存比较大，并且低配机器已经拖累了整个集群的读写性能，那么你需要考虑把写入频率和搜索频率比较高的热索引放到高性能的机器上，以获得更高的读写效率，同时把冷索引移到性能较差的机器上，以做到物尽其用
批量写入比单条写入能够提供更好的性能。BulkProcessor可以通过三个阈值控制批量大小，分别是数据条数，数据size和时间间隔。通常来讲更大的批量会带来更好的性能，但也并不尽然，如果单个批次数据量过大，高并发的情况下会导致集群内存压力增大，官方建议是不要一次发送几十兆的数据，从我测试的结果来看，这个说法过于乐观，建议不超过5M