随笔｜关于数据感悟

➤明确技术与业务的关系

• 知识和发明来自实践和生产的实际需要，OSI的7层模型再美、再学院化也没有干过TCP/IP。

• 切莫强求技术驱动，技术职责第一要务是做好深度服务业务。

• 数据产品不同于一般业务系统。隔行如隔山，跨部门项目往往对双方团队的时间管理、利益妥协、沟通协作和交付提出了很高很难的要求，数据产品要有价值，必须获取足量、高质的数据，建立跨部门、跨业务的统一数据视图前景美妙但步履维艰，保持持久热情、对数据产品的价值心里有数并尽可能地获取资源上的支持，是技术之外的重要话题。

➤价值导向，数据平台架构的策略、哲学与全局意识很重要

• 成本意识——只用合适的。深入理解业务和数据规模，不走冤枉路，不用牛刀去杀机，牛刀的维护成本很高很高；不轻视MySQL、不高估Hadoop，不盲目崇拜Storm和Samza的流计算。

• 专业意识——不过分给离线计算强调效率，不过分给准实时计算强调规模（优势火力学说）。

• 产品意识——不是最牛逼的技术就是最牛逼的产品（比如企查查，码农要重视产品、市场及领域知识）。

• 机动意识——灵活处理业务场景的技术需求。空间换时间（缓存）、时间换空间（大规模数据的分布式存储、比如HDFS和MongoDB的Sharding）。

• 历史意识——不是所有的技术债都要大肆批评，为公司历史业务作出贡献的代码应该保持尊敬，其中的一些问题更应该历史地看待，自己做得不一定比前人更好。计算跑向数据——比如传统的存储过程，免去了数据传输性能好，但扩展性很差，跨数据库的DB-Link技术可以看做分布式计算的早期手段；数据跑向计算——如Hadoop的MR，有不可忽视的数据运输代价，但计算和业务逻辑处理更加自由灵活。

• 战略意识——正确认识数据产品的特点：周期长、开发难、低反馈、弱可控，客户与业务需求总是迫切的。将冗长切分，局部和阶段性反馈并测试尤为重要，重视一点可视化往往有奇效。没有客户的数据产品没有价值，从立项开始，就要有生存、竞争、运营的综合考虑。让现有数据产生价值是数据团队的第一使命，而逐步产生价值、释放数据活力、融通部门利益则是一种全局运营意识。

➤分而治之

• 测试大数据处理手段有效与否的基本方法就是去求个和、排个序、分个组。如同1+1=2，这是基本所有大数据处理场景的最小化抽象。那么就会体会到——分开了求和排序难，不分却治不了大数据。

➤存储与索引分离、冷热分离、读写分离、二八原理、分级实施

• 读写混合的通常可以上溯业务进行梳理，找出重点、降级实施。

• 有时候分布式算法想破天，不如将服务器内存升级到512G来得简单和高效，分布式的同时不要忘了集中式的简单带来的收益。

• 存储与索引在一起，既有传统关系型数据库作为代表，也有华为为HBase拓展本地二级索引的例子，但通常分离之后可以同时享受专业的分布式存储和专业的索引技术带来的双重好处，缺点是可能需要一个触发器或协程，但是同步与计算的地位是同等重要的，可以从Storm的ACK机制及Kafka的Log机制获取处理此类严峻问题的灵感；这不仅仅是ETL和微服务的需求，也是一致性的挑战。

➤专业的干专业的事、学习但不重复造轮子

• 每个框架都有自己的原语、有限的服务能力和缺点，这是极为正常的，整合和有限改造是普遍存在的。

• 克服追求技术唯美的码农心理障碍，不轻信自己可以做得比别人更好，以可控交付和快速反馈为首要原则。

• 项目的死亡通常是因为产品需求和码农的认知图像不一致造成，这需要产品了解一定技术特点，更需要技术了解产品的真正目的。

• 轻视产品或者领域专家，是技术的狭隘而不是别人的无知。

➤分布式锁，真的很难

• 锁与分布式事务永远是前沿技术。

• 即使是电话通讯这种链路型的也会中断，何况计算机网络还是分包为基础。

• 脑裂是自然的，我们要做的是局部可控、提前预案、降低损失、快速维护。

• 同步并非最差，异步并非最佳，任何优势背后都有先天劣势。

• 高性能和简约架构是一对矛盾，吸气量太大还容易爆缸，但一旦认识到代价是正常和必不可缺之后，往往可以柳暗花明。

• 不死磕，compromise是工程意义上的折衷而不是码农心理上的妥协。

➤推和拉（Push&Pull）

• 都是常用手段，难点都在于状态同步与可靠交付，相对来讲拉更简单一些，但为了一致性和状态的到达往往会浪费计算资源。

• 有时候耗费某些资源换取更简单平坦的架构，收获更低的维护代价比死磕高性能收益更大。比如全双工通讯很美，但WebSocket技术对Socket、进程、内存资源的占用让Web服务更加复杂。

• 函数计算的优点之一就是不可变的数据结构，状态的不可变意味着失败的计算环节可以被重放，看似浪费资源，但实际是用简单的变换迭代换取思维上的简洁性，让业务逻辑与计算环节更明显地浮现出来，这就是更有价值的收益。

➤可靠性与高性能是一对矛盾

• P2P还是Master-Slave，要视业务特点决定，P2P更适合高性能、硬实时系统，MS架构相对简单、易于理解和操作、但有着主节点宕机导致服务可靠性下降的危险（Hadoop为此升级了双NameNode节点、MySQL生态也有双主节点的成熟策略）。

➤重视函数式思想，不死磕面向对象，生态很关键

• 并行处理的难点之一就是状态的改变、到达、回退与追踪的复杂，这一点不仅在框架和代码级别，在流服务体系中也很重要。Storm采用Clojure作为编程语言的目的除了这种语言很酷之外，更重要的是其对不可变的数据结构和函数计算的支持很到位。

• Spark牛逼的地方就是深入贯彻函数计算，并提供了完善的RDD操作原语与多语言支持，对关系型数据库、HDFS等也有很好的支持，特色鲜明而且瞄准Hadoop生态，它的战略眼光及架构值得反复学习。

• HyperTable瞄准了HBase的某些性能瓶颈以此来打造同样的列式数据库，但在市场上它失败了。C++实现底层带来了高性能的同时也带来了生态疏离。

原文来自博客园，作者@foreach_break。

---

更多精彩，欢迎关注CSDN大数据公众号！