工作多年，期间既做过要求强一致的系统，也做过要求低延时、高吞吐的系统，还搞过微服务的拆分和管理等工作。

在这个领域里做了这么久，零零散散写过些东西，但是一直没有完整、系统地总结过这个领域里的方法论，现在是时候完成它了。

千言万语一张表：（注意里面子项有链接，可以深入了解）

部署Kubernetes集群

工具平台：GeoMesa+Hbase+spark

关于围棋这个RTS

我比较喜欢即时战略类游戏，最近开始研究围棋。

昨天感觉自己对围棋的理解成功从“数气”阶段，晋升到“走棋形”的阶段，在野狐上喜提12连胜，连升3级（12级。。。还是弱鸡）。

以我对围棋粗浅的理解，和扑克、war3做了一个比较，如下：

这么看来，war3游戏性更强是有道理了。

1. 自身

   1. 关于思考方式
      1. 空间域：结构化思考：点线面体
      2. 时间域：终局思维
      3. 问题域：
         1. 定义问题、关键字、解题
         2. 问题是。。。方案有1。。2。。。因为xxxx的原因，我推荐方案xxx
   2. 关于行事方式
      1. 反复复盘总结、抽象

2. 与合作方的桥梁

   1. 关于沟通
      1. 保持高频又高效的沟通
      2. YES! AND!

3. 合作方

   1. 关于同事
      1. 每个人都有太多问题了，看到这个不难，还是加油看看别人的闪光点吧

没有时间解释了！快上船！

在数据开发领域做了两年左右的时间，因为工作原因，视野只是集中在离线数仓搭建这一小块内容上。两年时间并没有看到更多广阔的发展空间，导致数据开发的工作面越来越窄。为了扭转这个局面，特写此文从宏观上去重新审视这个领域的机会点在哪里。

分析框架：从得到APP上舶来的“点线面体”分析视角。个人理解，每提升一个维度，都应该有给上一维度“赋能”的能力。

一张图概括

            graph TD
            A[数据集成]-->C;
B[数据开发]-->C;
K[数据质量]-->C;
L[数据安全]-->C;
M[数据服务]-->C;
C[离线数据生产线]-->E;
O[实时PV]-->D
I[实时UV]-->D
D[实时数据生产线]-->E;
E[存储和查询: 数仓理论体系]-->Z
F[挖掘关系:知识图谱]-->Z
J[挖掘能力:机器学习]-->Z
Z[数据价值]
          

乐观锁维护原则

1. 使用版本号的乐观锁 SQL

   update tab_xxx
   set column1=#{field1Value}, column2=#{field2Value},…
   sys_version=sys_version+1, update_pin=#{updatePin}, update_time=now()
   where
 id=#{id} and sys_version=#{sysVersion} and yn=0

   Read more »

背景

核心痛点

使用ODPS(hive) SQL解析JSON数据的时候你可能用过get_json_object这个内置UDF，其灵活性给JSON数据解析带来了很多的便利。

但是对于Protobuf描述的数据，解析工作就麻烦太多了，即使解析一个字段，也要写一个完整的UDF(或UDTF)，并且上传各种protobuf的jar，然而这还没有完，如果新需求来了，即使仅改了一个字段的解析需求，也需要再重新开发一个新的UDF来完成。时间久了，项目里会有很多地方散落着各种Protobuf数据解析的逻辑，如果再有些公共逻辑改变，还要涉及到重构。维护工作繁重。

大概率的说，比我们想像的更重要。

一个常见的情况是，很多工具的使用往往提供了一些概念上的扩展点，比如：

• Tmux提供分屏能力时，给出了session/window/pane等操作实体概念；
• odps提供计算能力时，给出了project/table/column等实体概念；

这些多层次的实体概念在权限管理、资源分配等管理操作上提供了很多灵活性。但也带来了一个常见的问题：在文档交代不明确的时候，会让使用者在不明确一个概念的系统定位时，出现误用的现象，导致工具本身使用的过程充满了坎坷和限制，达不到最好的使用效果。如：